Security in an Insecure Environment

Auto Restore Virtualbox

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.

/etc/network/interfaces

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
    address 134.50.1.2
    netmask 255.255.0.0
    gateway 134.50.1.254
    bridge_ports eth0 vbox0 vbox1

# The loopback network interface
auto lo
iface lo inet loopback

/etc/vbox/interfaces

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

md5check directories

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[3].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[1], sumcont, md5_1)
os.path.walk(sys.argv[2], sumcont, md5_2)
print 'n'
print 'First  dir (',sys.argv[1],') hash : n', md5_1.hexdigest()
print 'Second dir (',sys.argv[2],') hash : n', md5_1.hexdigest()

ldap by hosts

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

pam_check_host_attr yes
pam_filter |(host=skynet.coe)

Then on our main server do not add these, as these entries only restrict access to users with the applicable host attributes.

The easiest way to backup an ldap database

slapcat.

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

Using smbclient to view public cifs shares

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).

syn cookies

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:

syn
syn-ack
ack

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://www.mail-archive.com/netdev@vger.kernel.org/msg61116.html

Despite this, it probably make sense in many environments.

Follow

Get every new post delivered to your Inbox.

Join 34 other followers