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.

Small Steps

These are some small steps you can take to make it harder for an attacker to figure out what version of some things you have running. These are specific to ubuntu:

apache

Go into /etc/apache2/apache2.conf and change

ServerTokens Full

to

ServerTokens Prod

This will change your info for things like 404s, so instead of listing your exact os, version of apache, etc, it will only say something like ‘Apache Server at progeny.isu.edu Port 80’

postfix

change the smtpd_banner line to something like “smtpd_banner = $myhostname ESMTP $mail_name (Linux)” which will be much harder to figure out than all the crap this normally prints, which, once again, is the exact version of postfix you are running along with the os.

bind

By default, bind also lets people know all this info.  You can change this by changing the version = lines as follows

options {

version “back off, dirt bag!”;

}

Though many of these services can still be fingerprinted without too much effort, not reporting your version info for every service you run is probably a good idea.  So, for example, because of this, you may have a harder time figuring out that this server is running apache2.2 on ubuntu7.04 and postfix2.5… damn it.

getfacl, setfacl

From http://www.suse.de/~agruen/acl/linux-acls/online/

Traditionally, systems that support the POSIX (Portable Operating System Interface) family of standards [11,2] share a simple yet powerful file system permission model: Every file system object is associated with three sets of permissions that define access for the owner, the owning group, and for others. Each set may contain Read (r), Write (w), and Execute (x) permissions. This scheme is implemented using only nine bits for each object. In addition to these nine bits, the Set User Id, Set Group Id, and Sticky bits are used for a number of special cases. Many introductory and advanced texts on the UNIX operating system describe this model [19].

But there are obviously times this is insufficient.  Like, say Bob is working in a group with Alice, so he wants to share files with her, but they don’t want to share files with everybody else.  I guess root could go and create a group, add Bob and Alice to it, then they could set the file to the new group or whatever, but this becomes unmanagable with very large systems.

A short definition from the man page of what an ACL is

This manual page describes POSIX Access Control Lists, which are used to define more fine-grained discretionary access rights for files and directories.”

The following tags are defined

ACL_USER_OBJ The ACL_USER_OBJ entry denotes access rights for the file owner.
ACL_USER ACL_USER entries denote access rights for users identified by the entry’s qualifier.ACL_GROUP_OBJ The
ACL_GROUP_OBJ entry denotes access rights for the file group.
ACL_GROUP ACL_GROUP entries denote access rights for groups identified by the entry’s qualifier.
ACL_MASK The ACL_MASK entry denotes the maximum access rights that can be granted by entries of type ACL_USER, ACL_GROUP_OBJ, or ACL_GROUP.
ACL_OTHER The ACL_OTHER entry denotes access rights for processes that do not match any other entry in the ACL.

When an access check is performed, the ACL_USER_OBJ and ACL_USER entries are tested against the effective user ID. The effective group ID, as well as all supplementary group IDs are tested against the ACL_GROUP_OBJ and ACL_GROUP entries.

I won’t go into the not-really-that-gory details of how to implement it here, other than to say ACLs can be easily modified with the getfacl and setfacl commands.

So for example, if Alice wanted to give Bob read access to a file, she could type

$ setfacl -m u:Bob:r myfile

swappiness is the route to happiness

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.