Webservers love Syn Cookies

In a few posts now, I’ve mentioned this concept of syn cookies. Syn cookies is a lesser known technique that allows for each incoming syn packet to be tagged with a unique identifier by the kernal. These identifiers are encoded into the TCP timestamp and then SYN is droped from the socket qeue.

This allows for these identifiers to be used to control the flow of a TCP communication. These cookies could be used for something as simple as killing outstanding sessions (which is does by defualt by removing them from the qeue) or as complex as load balancing active connections between servers in a web cluster (having multiple servers using the same encoding algorithm with an intermediate controling the flow). However, these days syn cookies are more often used to limit the amount of active connections are in the socket qeue, in an effort to stop DOS attacks.

This feature comes precompiled into Linux kernals 2.6+ and can be easily implemented.

To check and see if syn cookies is already enabled use the following command. Note, a 1 is enabled and a 0 is disabled.

cat /proc/sys/net/ipv4/tcp_syncookies

To enable syn cookies edit the /etc/sysctl.conf file and apend the following line.

net.ipv4.tcp_syncookies = 1

After the chnage, relaod the config file with the following command.

sysctl -p

iptables for Cyber Defense

Linux operating systems are very popular within the Cyber Security competition space for several reason, the foremost likely being that its free. Nonetheless, this abundance often calls for competitors to have at least a basic understanding of how to defend Linux systems. Arguable the first step in defending a Linux system is strong passwords, but a strong firewall is defiantly the second.

First of all, make a bash script for your firewall configuration, run it often (I like rc.local, cron, and init), and hide it well (I like a places I would frequent as a defender, but not as an attacker, like /etc/apache2/sites-available). This iptables script should at the very least include an IN and OUT filter for ssh and the port(s) core service(s). A basic script might look like the following.

iptables -F #clear the table
#iptables tricks
iptables -A INPUT -i lo -j ACCEPT #accept connections on our loop back
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP #drop bull packets
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP #drop syn floods (couple with syn.cookies)
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP #drop xmas packets cause this isn't the 90s
iptables -A INPUT -p tcp --dport 80,443 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT #limit incoming connections
#IN Chain
iptables -A INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT #open ssh
iptables -A INPUT -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT #open http
iptables -A INPUT -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT #open https
#OUT Chain
iptables -A OUTPUT -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT #allow ssh out
iptables -A OUTPUT -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT #allow http out
iptables -A OUTPUT -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT #allow https out
iptables -P OUTPUT DROP #drop other out
iptables -P INPUT DROP #drop other in

Allow this is likely not all the rules one might require throughout a competition, I’ve found its a good place to start. I hope to add more examples and useful rules as I learn of them in my career. If anyone has any questions feel free to hit me up.

Just Dash Out: Getting root by Just Running the Dash Shell

I often find myself building up vulnerable and/or misconfigured systems for a wide range of actives in my efforts to learn all the things. In doing so, I’ve found my first step is always the same, a simple one liner at the shell prompt that flips a machine on its head.

sudo chmod +s /bin/dash

This command, as many may very well know, sets the sticky bit on the dash shell, which is install in most debian based systems by default. Dash is a lot like the standard bash prompt that most users running Linux are accustom to.  That being said the purpose of the sticky bit, in this case the setuid bit, is to launch the executable with the rights of the owner of the executable. In this case, the owner of dash is root by default, so all users with read and execute permission can run dash and get a root shell. So any user on the system could simply run dash from their shell and gain root access.

user@dashtest:~$  whoami


user@dashtest:~$  dash

# whoami


But the fun doesn’t stop there. By default on Lenny, Squeeze, and most other debain based distro’s the default shell, /bin/sh is just a system link to dash.

lrwxrwxrwx  1 root root       4 Mar 29  2012 sh -> dash

This means that by default all service accounts on the system and possibly even users now have root access on their default shells. In fact most daemon users installed on debian systems with aptitude or dpkg are given the default shell /bin/sh. This can easily be seen in /etc/passwd.







Most daemon’s these days do not need to shell out so my first recommendation is to just go through your /etc/passwd file and change all the /bin/sh to either /bin/bash a proper shell or /bin/false to disable the ability to gain an shell from a popped daemon in the first place.

My second recommendation is rather simple as well, just cast two commands to set up bash as the default shell and then remove dash.

dpkg-reconfigure dash

dpkg –r dash

Of course there is no prefect fix for this issue, because even if you change your default shell and remove dash, it’s just three commands as a privileged user to be back in the same place. This is why I highly recommend setting non-user shells to /bin/false in your passwd file, while we all hope for a developer fix.