April 22, 2009 Leave a comment
March 18, 2009 1 Comment
For the security class I’m teaching we recently had a box to pwn. Problem is, they would sometimes get the address wrong and crash the virtual system. I probably would have just distributed the vdi, but not all of them have machines robust enough to run a vm, so I had to set something up.
First off, I gave the virtual vulnerable box a public IP by bridging.
auto eth0 iface eth0 inet manual auto br0 iface br0 inet static address 18.104.22.168 netmask 255.255.0.0 gateway 22.214.171.124 bridge_ports eth0 vbox0 vbox1 # The loopback network interface auto lo iface lo inet loopback
vbox0 lundeen br0 vbox1 lundeen br0
Awesome, now firewall rules work. In the vulnbox, I give myself an ip address. On the host, I set up very strict firewall rules using iptables.
Another big issue is auto-restore. Since the class often gets an address wrong, the vulnbox often crashes.
The following will shut the box down, revert to a snapshot, and turn it back on.
/usr/bin/VBoxManage controlvm vulnxp poweroff; sleep 5; /usr/bin/VBoxManage snapshot vulnxp discardcurrent -state sleep 10; /usr/bin/VBoxManage startvm vulnxp</pre>
Anyway, I put this in crontab to do every 20 minutes.
0,20,40 * * * * /path/to/virtualscript
July 12, 2008 Leave a comment
This is a python script that recursively md5sums all the files in your directory and compares it with another directory. It is similar, and probably less good than
find /dirone -type f -print0 | md5sum
but this was coded to check if the directory structure copied cleanly to a *windows* box. It seems to work ok. TODO: only read line by line if file is over a certain size, else read line by line like it does now.
#!/usr/bin/env python import os, sys, getopt from Crypto.Hash import MD5 from Crypto.Hash import SHA def usage(): print """ DESCRIPTION compares topdir1 to topdir2 using a hash algorithm USAGE hashsum.py -h prints this message hashsum.py topdir1 topdir2 [sha1|md5] """ def sumcont(hasharg, dirname, fnames): for file in fnames: try: myfile = open(os.path.join(dirname, file)) for i in myfile.readlines(): hasharg.update(i) myfile.close() except: pass print "*", if len(sys.argv) 3: if sys.argv.lower() == 'sha1': print "HASH ALGORITHM: sha1" md5_1 = SHA.new() md5_2 = SHA.new() else: print "HASH ALGORITHM: md5" else: print "HASH ALGORITHM: md5" os.path.walk(sys.argv, sumcont, md5_1) os.path.walk(sys.argv, sumcont, md5_2) print 'n' print 'First dir (',sys.argv,') hash : n', md5_1.hexdigest() print 'Second dir (',sys.argv,') hash : n', md5_1.hexdigest()
May 26, 2008 Leave a comment
These are some things I recently ran into when trying to restrict a certain ldap user to a certain number of hosts.
For example, at the school we have a cluster where we may only want the parallel processing students to have access, cadence where we may only want vlsi students to have access, and our main server where we want everyone to have access.
Here’s the preliminary way that seems to work. Here, I assume most of your ldap is setup.
First, add the account objectclass to your user. You may need to do some mangling here (for example if you use the inetorgperson objectclass). You can create your own joined schema for this. The reason you want the account objectclass is so you have access to the host attribute.
Next, for every user, add the restricted hosts you want that user to have access to. For example, for the cluster I add a host=skynet.coe.isu.edu attribute.
Finally, on skynet.coe.isu.edu, in ldap.conf, add
Then on our main server do not add these, as these entries only restrict access to users with the applicable host attributes.
May 22, 2008 Leave a comment
There are a lot of ways to do this, and I have experimented with several.
For example, you can copy the master’s database files to the replica. But this comes with some restrictions. 1. Both hosts must have compatible versions of the dbm libraries2 both hosts must be roughly the same architecture 3 some methods of copying sparse dbm files (eg copy) will fill in the holes, making the files larger.
A more general way to backup an ldap database or to replicate the db is slapcat. eg.
root@master # slapcat -b “dc=myldap,dc=org” -l backupcontents.ldif
#… copy backupcontents.ldif to backup or slave
#Then, to restore or add or whatever
root@slave # slapadd -l backupcontents.ldif
May 7, 2008 Leave a comment
Easy? yes. Trivial? yes. But I always have to look up the syntax.
smbclient -L //localhost Password: Domain=[MIDEARTH] OS=[Unix] Server=[Samba 3.0.26a] Sharename Type Comment --------- ---- ------- IPC$ IPC IPC Service (Samba 3.0.26a) data Disk Data Domain=[MIDEARTH] OS=[Unix] Server=[Samba 3.0.26a] Server Comment --------- ------- HOBBIT Samba 3.0.26a Workgroup Master --------- ------- MIDEARTH HOBBIT</pre>
Just leave the password empty to do it as guest. For some reasone I tend to always mix up smbclient and smbmount (depricated, usually mount.cifs now).
April 20, 2008 Leave a comment
An interesting cryptographic way to deal with syn floods is syn cookies. SYN floods are simply a bunch of syn packets from spoofed ip addresses, and are a fairly common dos attack. Some other ways to deal with these include increasing the syn queue size and decreasing the wait for reply time, but these don’t really solve the problem.
SYN cookies are built into the Linux kernel by default (though usually not enabled by default). You can find and configure this feature in proc/sys. For example, to enable them you could
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
syn cookies provide a way to build the syn number in a tcp handshake so that it can be used to reconstruct initial syn numbers of legitimate clients after they return the final ack (it checks it using a function and rebuilds the syn queue). This allows kernel resources to be reused that would normally be waiting on the connection after receiving the first syn.
A normal tcp handshake looks like:
Under a syn attack, most syn-acks sent by you (the target of the attack) will never respond with that final ack since they were falsely generated. syn cookies are an effective defense against this. A server that uses SYN cookies doesn’t have to drop connections when its SYN queue fills up.
For more information about syn cookies, see http://cr.yp.to/syncookies.html
For why it might not be enabled by default see: http://firstname.lastname@example.org/msg61116.html
Despite this, it probably make sense in many environments.