Thursday, August 11, 2011

Rate limiting login attempts with iptables

SkyHi @ Thursday, August 11, 2011
Rate limiting login attempts is an easy way to prevent some of the high speed password guessing attacks. However, it's hard to limit distributed attacks and many run at a low pace over weeks or months. I personally prefer to avoid using automated response tools like fail2ban. And this is for two reasons:

Legitimate users sometimes forget their passwords. I don't want to ban legitimate users from my server, forcing me to manually enable their accounts again (or worse, try to figure out which of the 100/1000 banned IP addresses is theirs).
An IP address is not a good identifier for a user. If you have multiple users behind a single IP (for example, a school that runs NAT on 500 student machines) a single user making a few bad guesses can land you in a world of pain. At the same time the majority of the password guessing attempts I see are distributed.

Therefore I don't consider fail2ban (and similar automated response tools) a very good approach to securing a server against brute force attacks. A simple IPTables rules set to cut down on the log spam (which I have on most of my linux servers) is something like this:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP


It prevents more than 4 connection attempts from a single IP to ssh in any 60 second period. The rest can be handled by ensuring passwords are reasonably strong. On high security servers forcing the users to use public key authentication is another way to stop guessing.

REFERENCES
http://serverfault.com/questions/216995/is-it-worth-the-effort-to-block-failed-login-attempts

sendmail use of clientmqueue and mqueue folders

SkyHi @ Thursday, August 11, 2011
The flag for flushing the queue is -q (issue sendmail -q). However, I presume you are having sendmail run as a daemon, therefore, you would want to start it as sendmail -bd -q5m. If RH8.0 is configured as RH7.3, the startup flags are in /etc/sysconfig/sendmail and should look as follows:

DAEMON=yes
QUEUE=5h

The script in /etc/init.d (sendmail) will read this file for the options.

-db starts sendmail as a daemon, -q5m says flush every five minutes. Note that most mail is sent and forwarded immediately, flushing is needed only if for some reason the route to intended recipient (and intended mail exchangers) is down (most usually for me, my own internet connection), or if you are acting as a MX for another mail server. In those cases, mailed is spooled in /var/spool/mqueue until it either timesout (usually about 5 days, depending on setup) or can be sent on.


=======================================================================

When submitting mail by using sendmail as a mail submission program, sendmail copies all messages to "/var/spool/clientmqueue" first. Sendmail is a setgid smmsp program and thus gives any user the permission to do so (/var/spool/clientmqueue belongs to user and group smmsp). Later, another sendmail process, the sendmail mail transfer agent (MTA) copies the messages from /var/spool/clientmqueue to /var/spool/mqueue and sends them to their destination.

/var/spool/clientmqueue is thus the holding area used by the MSP (Mail Submission Protocol) sendmail instance before it injects the messages into the main MTA (Mail Transport Agent) sendmail instance.

Sendmail will save the message in /var/spool/clientmqueue for safe keeping before trying to connect to the MTA to get the message delivered. Normally there would be a 'queue runner' MSP sendmail instance which every half hour would retry sending any message that couldn't be sent immediately. Each message will generate a 'df' (message routing info) and 'qf' (message headers and body) file. You can list out all of the messages and their status by:
# mailq -v -Ac

When files accumulate in /var/spool/clientmqueue, this is probably due to sendmail localhost MTA not running, and thus the mails don't get send.

=======================================================================
 The E-mail Message's Way from Client to Client


 After you have sent the e-mail message to the SMTP server that communicates with your computer the message still has a long way to travel before it reaches your recipient's computer. The moment after the e-mail message has been successfully transferred to your SMTP server; the server must find your recipient's mail server and transfer the message to that server. To locate the server that the recipient uses, the recipient's e-mail address will be examined and the domain name extracted by reading the information after the "@" character (the domain name is always found after the "@" character in the e-mail address). By using this domain name and then checking with a Domain Name Server (DNS), the location (the IP number) of this server will be found. After that, a communication line will be established between your mail server and your recipient's mail server.

The communication between these two mail servers are basically the same as the communication between your computer and your SMTP server. The SMTP protocol is used and the port number 25 (at your recipient's mail server) is used. The commands used are normally also the same and the e-mail message is transferred in similar way as when it was transferred from your computer to your SMTP server.

However, sometimes there can be technical problems at the recipient's server and the e-mail message can not be transferred. To handle such a situation the message goes into a queue. The SMTP server on most machines uses a program called sendmail to do the actual sending, so this queue is called the sendmail queue. Sendmail will periodically try to resend the messages in its queue. For example, it might retry every 15 minutes. After 4 hours, it will usually send you a piece of mail that tells you there is some sort of problem. After 5 days, most sendmail configurations give up and return the mail to you undelivered.
 
If the message have been successfully transferred to your recipient's mail server, it will then be stored in his/her POP3 server and when the recipient start downloading his/her e-mails, your e-mail message will appear in the inbox of the recipient's e-mail client program.


=======================================================================

# service sendmail stop
# cd /var/spool/mqueue
# for ML in `grep 
-l "misspelled_address\@gmail.com" *`; do sed -i -e 
's/misspelled_address\@gmail.com/postmaster\@localhost/g' $ML; done
# service sendmail start
# sendmail -q -v 



REFERENCES

http://emailitis.com/support/faqs/email-faqs/76-what-is-greylisting-spam
 http://www.samlogic.net/articles/smtp.htm
http://arstechnica.com/civis/viewtopic.php?f=16&t=1111517

Wednesday, August 10, 2011

Change the Queue Runner Interval in Sendmail

SkyHi @ Wednesday, August 10, 2011
The default in CentOS 5.x is 1 hour:
# pgrep -lf "Queue runner"
12443 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
 
You can change it editing /etc/sysconfig/sendmail (ie. set 30 minutes):
DAEMON=yes
QUEUE=30m
 
It’s easy, isn’t it? Useful for mail backup MXs that may need shorter queue run times.

REFERENCES
http://rambleon.usebox.net/post/317857580/change-the-queue-runner-interval-in-sendmail