Ali Abbas

Cisco’s IOS Quiet Period refers to the period in which telnet/ssh/http access are disabled for an X amount of time after an Y amount of failed attempt.

While it is quite unusual to have router virtual access allowed from the WAN link, it may not hurt to go further by enabling this cisco feature to prevent a potential DOS dictionary attack from the WAN link or possibly as well from the LAN link.

The command used to enable the “Quiet Period” is “login block-for” in Global Configuration mode.

edge(config)#login block-for 600 attempts 5 within 2

In other words, block virtual login for 10mn (600 seconds) after 5 attempts within 2 seconds

Further Options

While this command should be enough to get us where we want to be, it is important to consider the following

1. Log failed login attempts

edge(config)# login on-failure log

You can view the login logs by issuing “show login failures”

2. Prevent administrative hosts to be locked out during the Quiet Period

login quiet-mode access-class {acl-name |acl-number}

edge(config)#login quiet-mode access class adminIPs

By defining an access list named adminIPs that possibly contains a range of IPs representing administrative hosts, we can avoid having ourselves be subject to the “Quiet Period” while in action.

I hope that was informative,

Cheers,

Ali

There has been a lot of buzz lately on security layer when it comes to running services/open ports and how to step away from the security risk line, at least with just one step.

Port Knocking can be summarized in three steps

1. My service’s port is locked by default

2. My service’s port will not open unless you send some packets to a sequence of port I selected

3. My service’s port therefore remains unseen to brute force bots and script kiddies scanners.

In this first part of Firewall Security, I will go over the setup and configuration of a basic port knocking deployment on a Centos FTP server using knockd

knockd is available on rmpforge, so feel free to grab the rpm from the mirror or simply yum install knockd if you have the rpmforge mirror added to your repositories.

knockd uses a single configuration file which is /etc/knockd.conf

In this study case, we will focus on securing port 21 for our FTP server application.

(I am assuming, you currently have port 21 blocked on your firewall and you are using iptables)

[options]
logfile = /var/log/knockd.log

[openFTP]
sequence = 2000,3455,6789
seq_timeout = 10
tcpflags = syn
command = /sbin/iptables -I INPUT 1 -p tcp -s 192.168.2.107 -d 192.168.2.201 --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT

[closeFTP]
sequence = 6789,3455,2000
seq_timeout = 10
tcpflags = syn
command = /sbin/iptables -D INPUT 1

start the knockd server with

/usr/sbin/knockd -d

(keep in mind, by default knockd will start listening on interface eth0)

and voila… port 21 will open on the firewall once, the corresponding port combinaison as specified in the configuration file will be met..

For testing, use knockd client (http://www.zeroflux.org/cgi-bin/cvstrac.cgi/knock/wiki) and knock on the port sequence of your ftp server.

—- Some piece of advises

1. Keep in mind, this setup provides you with only one single point of failure… whenever knockd fails, you will be left with no remote connectivity (especially for those locking out ssh port)… To prevent this, make sure to monitor the knockd daemon and to start it in case of failure

2. This security layer isn’t enough! and actually present with some potential security risks! the right port combinaison could easily be sniffed from the client to the server, thus resulting in an attacker knowing the exact port combinasion…

3. For each setup sequence, you will need to allocate a sequence of port, keep in mind, those ports need to be exclusively allocated to knockd… choose your sequences carefully!

Cheers,

One of the most annoying matter I have met when administrating a server was following and fixing messes other users (who happen to have root password) would do on the server.

Random users with root passwords often know two things… “sh” and “history -c”… and of course “I didn’t do it”.

Now, while it is important to keep logs of activities on the server, it is even better to be able to pull up logs of every single commands entered plus their arguments.

Here is a little C wrapper once can use to wrap /bin/sh so that every commands gets logged.

Now, we first need to backup our current sh executable…  so

mv /bin/sh /bin/shb

#include <pwd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>

#define LOG_FILE     "/var/log/sh.log"
#define LOG_FLAGS    O_CREAT|O_APPEND|O_WRONLY
#define LOG_MODE     S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH
#define WRAPPER "/bin/shb"

int main (int argc, char **const argv)
{
FILE *        logfile         = fopen (LOG_FILE, "a");
const char *  program         = argv[0];
argv[0] = WRAPPER;
if (logfile)
{
struct passwd *pw         = getpwuid (geteuid ());
int            i          = 0;
fprintf (logfile, "(%s)", pw->pw_name);

for (i = 0; i < argc; ++i)
fprintf (logfile, " '%s'", argv[i]);

fprintf (logfile, "\n");
fclose (logfile);
chmod (LOG_FILE, LOG_MODE);
}

execv (argv[0], argv);

exit (EXIT_FAILURE);

}

Now, compile your code into an sh executable.

Move your newly compiled sh into /bin/

And voila … whenever someone executes /bin/sh… a log will be generated in /var/log/sh.log

A friend of mine asked me what he should do when experiencing a DDOS attack.

Well the excerpt itself would be long as on how to handle a DDOS attack, as each type of Denial of Service needs different handles… as experienced is a sys-admin, as throughout he/she would be able to handle the attack.

However, for all here is a simple straight forward methodology..

1) Find the IPs from which the SYN flood is coming from

and

2) Block those IPs

easy he?

So how do you do that on a linux machine?

Again, this is just a small excerpt

a simple command such as

netstat -n -p|grep SYN_REC | wc -l

would list all the active SYN_REC connections on the server… depending on the server’s size, 30 to 40 SYN_REC could be a sign of a DDOS attack.

Again, do not be fixed on numbers, different variant play when deciding to ring the DDOS emergency bell

netstat -n -p | grep SYN_REC | awk '{print $5}' | awk -F: '{print $1}'

will therefore list all the IPs that are maintaining the SYN_REC connections.

and why not, also add a uniq -c filter etc… and get fancier?

anyway.. once you decide an IP source is flooding your port, simply block it with an

iptables -I INPUT -s IP -j DROP

cheers,

Sock Stress is a new type of Denial of Service which was developed by Jack C. Louis. According to nmap creator Fyodor, the attacker sends a TCP SYN packet to a targeted port, but first by making sure that a firewall protects his own machine as to prevent it to interfere with the attack process. The main reason for the protection is as to avoid the attacker’s computer to reset the unexpected returned SYN/ACK packet (2nd step of the TCP 3 way handshake). This is obvious since the attacker sent the SYN packet from userland and not the operating system’s API. According the Fyodor, the attacker’s pc from userland will therefore reply to each packet by sending another raw packet. That packet is therefore the acknowledgment packet.

That attempt to explain it was partially denied by Robert Lee as being the overall “methodology”, however has refused to comment further more on it. As far as it is being said, no current fix or system is known to be able to prevent Sock stress to take down a tcp stack server.

(for further info: http://blog.robertlee.name/2008/09/sockstress-podcast-interview.html)