swappiness is the route to happiness

February 28, 2008 Leave a comment

hmm.  Stuff like this is really hard for me to gauge, but it’s apparently hard for others too, as I browse through some of the old kernel mailing lists (circa like 2004).

I’ve been playing with different values in /proc/sys/vm/swappiness (it can be anywhere from 1-100).  The higher the number, the more a system will swap.

Mr. Andrew Morton sets his to 100, because he just ‘sticks his fingers in his ears and sings la la la until people tell him ‘I set the swappiness to zero and it didn’t do what I wanted it to do’.

He  says, “My point is that decreasing the tendency of the kernel to swap stuff out is wrong. You really don’t want hundreds of megabytes of BloatyApp’s untouched memory floating about in the machine. Get it out on the disk, use the memory for something useful.”

The other side is if ‘bloatyapp’ is swapped out too aggressively, when the user returns to it there is a delay.

Well, so far I set it to zero for a day and 100 for a day, going away from the default of 60.  To be honest, I’ve had a hard time gauging the performance, other than by feel.  I’ll have to think about some measurable benchmarks to look at normal lab usage on progeny.

Filed under Misc Tagged with

fail2ban attack

February 26, 2008 Leave a comment

I was talking about fail2ban running from my firewall and a certain IP being the only one allowed in (as specified in iptables).  First of all, I should probably be using port knocking or something better for this scenario (in fact, after the comment I went ahead and put spa on the firewalls – something I’ve been meaning to do anyway for awhile now) but that’s beside the point.

fail2ban works by denying an ip address for x amount of time because of failed logins.  It does this by using log entries from /var/log/auth.log and writing corresponding iptables rules.  This is mostly for limiting ssh login failures.

If you spoofed the ipaddress of the machine I was logging in from, you could maybe launch a dos by getting the legitimate machine banned. Realistically, I think the attack would not succeed.  Here’s what would happen.

  1. An attacker sends a spoofed connection packet to my firewall with a legitimate ip address (so it makes it through my dummy firewall)
  2. The ssh server responsds with a syn/ack to the correct ip address (not the attacker)
  3. The correct ip address doesn’t know where this came from, so either drops it or sends a RST packet if there are no firewall controls on the sender machine.

The point is that the handshake is never completed, so there is never a failed login entry in /var/log/auth, and it never gets so far as to fail2ban.

 

Filed under Pentest Tagged with , , , ,

strong passwords with pam_cracklib

February 25, 2008 Leave a comment

Traditionally I have checked weak passwords with jtr, but one problem is that you have to run it after a user already has a password.  A much more standard way is to check weak passwords with pam.  There are a couple modules for this – one is pam_cracklib.  Another is passwdqc.  I chose cracklib.  You should never use both.

Typically, you’ll edit a conf file in /etc/pam.d/ – normally like commmon-auth or common-password.  The entry you need to add is at the top.  All the entries are of course related to ‘password’.

password    requisite     pam_cracklib.so difok=2 minlen=10 dcredit=2 ocredit=2 try_first_pass retry=3

The fields are pretty straightforward.  Requisite means it’s required. difok specifies how many characters in your new password need to be different from the old password.  minlen is not as straightforward as it may seem.  It specifies the minimum length of the password, for sure, but you can get ‘credit’ for harder passwords.  This is where dcredit and ocredit come into play (amongst others).  dcredit=2 means if your password contains digits you get a bonus character. ocredit is the same thing but with special characters.  retry is the maximum trys you can have to change your password before you have to start again.

The cracklib also checks for particularly weak passwords (it runs them against the unix dictionary with some basic permutations/numbers etc). It’s not close to as strong as jtr, but still pretty darn good, and it’s nice to have your authentication stuff in one place.

The rest of the password rules come next, and should look something like the following.

password    sufficient    pam_unix.so nullok use_authtok md5 shadow
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

This checks the unix passwords, followed by the ldap. use_authtok means strong passwords are already enabled so the modules don’t need to check for themselves (it’d be redundant). The pam_fail indicates failure.

Anyways, though many distros have password checking by default, ubuntu doesn’t. It’s probably a good idea to turn it on if you have a multi-user system

Filed under Misc Tagged with , ,

Unintended consequences of half open scans

February 21, 2008 Leave a comment

Short analysis of the nmap half open scans (also called syn scans).

These scans are distinguished from the default operation of full connection scans, which completes the full tcp handshake. i.e.

SYN –>
<—SYN+ACK
ACK–>

A half open scan just does

SYN–>
<–SYN+ACK

The scanner determines weather the port is up or not based on if the SYN+ACK comes back.  Obviously, the final ack is never sent back.  This can be performed by

$ nmap -P0 -sS target

This was a popular method due to it being ‘stealthy’ though it’s not so much stealthy anymore and because it’s fast – though it doesn’t seem to be faster than a full connection scan in practice.

Anyways, now to something everyone doesn’t already know (maybe, at least I didn’t).

nmap uses raw sockets to craft these packets, which is why syn scans must be run as root.  What’s interesting is that if the remote host responds with a SYN+ACK – the local stack receives this packet, which did not come from the local stack (because again, it was crafted with a raw socket by nmap).  As far as the scanning computer knows, the SYN+ACK is not part of a handshake and appears to have come out of nowhere, so the scanner sends a RST back to the target system.  Nuts.

You can stop this by using simple iptables, on INPUT or OUTPUT, by having a default drop policy (only allowing ESTABLISHED,RELATED and known services through is probably a good rule of thumb).

Filed under Pentest Tagged with , ,

View/change UUID in Linux

February 20, 2008 Leave a comment

This may seem obvious, but you can view/change uuids with tune2fs

This is a fact I’ve stumbled upon quite a bit, but when trying to remember it, it slipped my mind and googling for ‘view uuid’ sort of came up fruitless, so I thought I’d post it here.  I knew it was one of the common commands I use quite a bit, so after manning hdparm (yeah, again, it seems obviously not that in retrospect) I tried tune2fs, which is where I’ve seen the option before.

tune2fs -l /dev/hda1

will let you see the uuid of /dev/hda1

The -U flag will let you set it.  Of course, you can then mount by uuid, which is a lot of times better because hey, device names change.

Filed under Misc Tagged with

← Older posts

Follow

Get every new post delivered to your Inbox.