Databases, Systems & Networks

iptables « recent » module and hit limits

iptables « recent » module and hit limits

Those annoying ssh attacks

You know those. you have tried blockhosts, denyhosts, fail2ban, and they can still be annoying.

an alternative is to use some feature or features of iptables.

Two possible uses … examples

Your default INPUT chain policy is ACCEPT

This is the version that is found online, typically under tags such as Brute-force.

one adds lines to ones iptables

iptables -N SSHSCAN

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j SSHSCAN 

iptables -A SSHSCAN -m recent --set --name SSH --rsource 
iptables -A SSHSCAN -m recent --update --seconds 3600 --hitcount 5 --name SSH --rsource -j LOG --log-prefix "Anti SSH-Bruteforce: " --log-level 6 
iptables -A SSHSCAN -m recent --update --seconds 3600 --hitcount 5 --name SSH --rsource -j DROP

Your default INPUT chain policy is DROP

This is a variation of the above, but takes into account the DROP policy. It is a small change, but necessary if you really want to be able to log in via ssh.

iptables -N SSHSCAN

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j SSHSCAN

iptables -A SSHSCAN -m recent --set --name SSH --rsource
iptables -A SSHSCAN -m recent --update --seconds 3600 --hitcount 5 --name SSH --rsource -j LOG --log-prefix "Anti SSH-Bruteforce: " --log-level 6
iptables -A SSHSCAN -m recent --update --seconds 3600 --hitcount 5 --name SSH --rsource -j LogDrp
iptables -A SSHSCAN -j ACCEPT

Discussion

The recent module takes a number of options, and the examples above demonstrate some.

• —name xyz give a name to the particular ‘class’ you are defining
• —rsource in the list you keep, use the remote (source) address
• —rcheck see if the address is in the list
• —update like rcheck, but update the timestamp for tracking hits
• —seconds the number of seconds to track the address
• —hitcount the number of hits withing the time defined be —seconds at which point the rule gets activated.

So, in the examples, after the chain is defined to exist ( -N SSHSCAN), we have an INPUT rule that says ‘go to chain SSHSCAN if the destination port is 22’. In that chain, we set the module’s reference to this as SSH; then we tell it how to log this, if we have gotten 5 hits within 3600 seconds (actually more, as the time is updated rather than checked) and after that, DROP the next packets.

If the address has not gone up to 5 hits, it passes through and gets ACCEPTed.

Depending on your kernel and version of iptables, you can find the current list in

/proc/self/net/xt_recent/SSH

or

/proc/net/ipt_recent/SSH

ipsets

what does one do when one’s iptables rules start to get long? cpu and memory hit hard? convert a table to an ipset.

here is an example of something i need to test:

ipset -N sshban iphash --hashsize 4096 --probes 2 --resize 50

for i in ` cat /proc/net/xt_recent/SSH  | awk '{print $1;}' | cut -d '=' -f 2 `; do 
ipset -A sshban $i;
echo -$i > /proc/net/xt_recent/SSH
done

where we also have iptables rule

iptables -I INPUT -m set —set sshban src -j DROP

Source: we.riseup.net

Send email notifications using Gmail SMTP

Using Gmail SMTP: Suppose you want to configure a Linux app to send out email messages from your server or desktop. The email messages can be part of email newsletters, status updates (e.g., Cachet), monitoring alerts (e.g., Monit), disk events (e.g., RAID mdadm), and so on. While you can set up your own outgoing mail server to deliver messages, you can alternatively rely on a freely available public SMTP server as a maintenance-free option.

One of the most reliable free SMTP servers is from Google’s Gmail service. All you have to do to send email notifications within your app is to add Gmail’s SMTP server address and your credentials to the app, and you are good to go.

One catch with using Gmail’s SMTP server is that there are various restrictions in place, mainly to combat spammers and email marketers who often abuse the server. For example, you can send messages to no more than 100 addresses at once, and no more than 500 recipients per day. Also, if you don’t want to be flagged as a spammer, you cannot send a large number of undeliverable messages. When any of these limitations is reached, your Gmail account will temporarily be locked out for a day. In short, Gmail’s SMTP server is perfectly fine for your personal use, but not meant for commercial bulk emails.

With that being said, let me demonstrate how to use Gmail’s SMTP server in Linux environment.

Google Gmail SMTP Server Setting

If you want to send emails from your app using Gmail’s SMTP server, you need to adjust the security setting of the Gmail account to be used. Go to the Google account settings, and enable the option to allow less secure apps, which is off by default.

Then you will need to provide your app with the following details.

• Outgoing mail server (SMTP server): smtp.gmail.com
• Use authentication: yes
• Use secure connection: yes
• Username: your Gmail account ID (e.g., « alice » if your email is [email protected])
• Password: your Gmail password
• Port: 587 (TLS) or 465 (SSL)

Exact configuration syntax may vary depending on apps. In the rest of this tutorial, I will show you several useful examples of using Gmail SMTP server in Linux.

Send Emails from the Command Line

As the first example, let’s try the most basic email functionality: send an email from the command line using Gmail SMTP server. For this, I am going to use a command-line email client called Mutt.

First, install Mutt as follows.

For Debian-based system:

$ sudo apt-get install mutt

For Red Hat based system:

$ sudo yum install mutt

Create a mutt configuration file (~/.muttrc) and specify in the file Gmail SMTP server information as follows. Replace <gmail-id> with your own Gmail ID. Note that this configuration is for sending emails only (not receiving emails).

$ vi ~/.muttrc

set from = "<gmail-id>@gmail.com"
set realname = "Dan Nanni"
set smtp_url = "smtp://<gmail-id>@smtp.gmail.com:587/"
set smtp_pass = "<gmail-password>"

Now you are ready to send out an email using mutt:

$ echo "This is an email body." | mutt -s "This is an email subject" [email protected]

To attach a file in an email, use « -a » option:

$ echo "This is an email body." | mutt -s "This is an email subject" [email protected] -a ~/test_attachment.jpg

Using Gmail SMTP server means that the emails appear as sent from your Gmail account. In other words, a recipient will see your Gmail address as the sender’s address. If you want to use your domain as the email sender, you need to use Gmail SMTP relay service instead.

Another note is that if you are concerned about placing your SMTP password in the plain-text .muttrc file, you can encrypt the password using GnuPG.

Lire la suite…

sudo su
mkdir /tmp/.psad
cd /tmp/.psad
wget http://cipherdyne.org/psad/download/psad-2.4.3.tar.gz
tar -zxvf psad-2.4.3.tar.gz
cd psad-2.4.3
./install.pl 
cd /tmp
rm -R .psad
exit

vi /etc/psad/psad.conf

iptables -A INPUT -j LOG
iptables -A FORWARD -j LOG
ip6tables -A INPUT -j LOG
ip6tables -A FORWARD -j LOG

psad -R
psad --sig-update
psad -H

psad --Status

Lire la suite…

Source: xmodulo

There is ongoing debate on the pros and cons of using passwords versus keys as ssh authentication methods. A main advantage of key authentication is that you can be protected against brute-force password guessing attacks. However, requiring a private key for ssh access means that you have to store the key somewhere on client system, which can be another avenue of attack.

Still, one can argue that the ramification of a cracked password is more significant than a compromised private key, because any single password tends to be used for multiple hosts and services, while the validity of a given private key is generally limited to a specific ssh server.

If you are using openssh, you can flexibly enable or disable password authentication and key authentication. Here is how to disable ssh password authentication so that you can force ssh login via public key only.

NOTE: This guide is about the SSH server side configuration for preventing password authentication and forcing key authentication. I assume that you already set up key authentication on the client side, so you can log in to SSH via key authentication (without using password). Before proceeding with the rest of this tutorial, make sure to verify this key authentication works. Otherwise, you may lose SSH access while testing this tutorial. So be careful!

Open sshd configuration file, and add the following line (or uncomment it if it’s commented out).

$ sudo vi /etc/ssh/sshd_config
PasswordAuthentication no

Make sure that you have the following in /etc/ssh/sshd_config, in order to allow private/public key authentication.

RSAAuthentication yes
PubkeyAuthentication yes

Finally, reload ssh server configuration to make the change effective.

$ sudo /etc/init.d/ssh reload

The above setting will disable ssh login via password, system-wide. If what you want is to disable ssh password login for individual users, you can do the following.

If you want to disable ssh password authentication for specific users only, add the following « Match User » block at the end of sshd config file.

Match User alice,bob,john
PasswordAuthentication no

If you want to disable ssh password login for specific Linux group(s), put « Match Group » block at the end of sshd config file. For example, to disable ssh password login for all users belonging to « sudoers » group:

Match Group sudoers
PasswordAuthentication no

If you want to force ssh key authentication for non-root normal users, place the following « Match User » block at the end of sshd config file.

Match User !root
PasswordAuthentication no

Source: linoxide.com

Lire la suite…