Archives pour la catégorie ‘Sécurité’

How to install PSAD Intrusion Detection on Ubuntu 16.04 LTS server

10/12/2019 Comments off


This guide is based on various community forum posts.

This guide is intended as a relatively easy step by step guide to:

  • Install CipherDyne PSAD Intrusion Detection and Log Analysis with iptables on Ubuntu 12.04 LTS or later.
  • psad is a collection of three lightweight system daemons that run on Linux machines and analyze iptables log messages to detect port scans and other suspicious traffic.
  • From version 2.2 it also offers full IPv6 support. 


  • Tested on Ubuntu 12.04 LTS – 16.04 LTS server.
  • Should work on most Ubuntu/Debian based ditro’s.

1. Download and install the latest version of PSAD.

  • Download and install the latest version from the Cipherdyne website.
  • Visit the CipherDyne PSAD download page and select the latest source tar archive, as of writing this the latest version is PSAD 2.4.3
  • To download and install the latest version open a Terminal and enter the following :
sudo su
mkdir /tmp/.psad
cd /tmp/.psad
tar -zxvf psad-2.4.3.tar.gz
cd psad-2.4.3
cd /tmp
rm -R .psad


2. Edit the PSAD configuration file. 

  • Three main settings need to be set in the PSAD configuration file before we can complete the install, edit the others as required.
  • open a Terminal Window and enter :
vi /etc/psad/psad.conf
  • EMAIL_ADDRESSES – change this to your email address.
  • HOSTNAME – this is set during install – but double check and change to a FQDN if needed.
  • ENABLE_AUTO_IDS – set this to Y if you could like PSAD to take action – read configuration instructions before setting this to Y.
  • ENABLE_AUTO_IDS_EMAILS – set this to Y if you would like to receive email notifications of intrusions that are detected.

3. Add iptables LOG rules for both IPv4 and IPv6.

  • For an explanation of this step click here.
  • Add the following iptables policies :
iptables -A INPUT -j LOG
iptables -A FORWARD -j LOG
ip6tables -A INPUT -j LOG
ip6tables -A FORWARD -j LOG

4. Reload and update PSAD.

  • To restart, update the signature file and reload PSAD to complete the install open a Terminal Window and enter :
psad -R
psad --sig-update
psad -H
  • To check the status of PSAD, open a Terminal Window and enter :
psad --Status

Lire la suite…

How to force ssh login via public key authentication

10/12/2019 Comments off

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
Categories: Sécurité, Système Tags:

Mass-blocking IP addresses with ipset

15/04/2019 Comments off

Using ipset to block many IP addresses

I was sponsoring an upload of ipset to Debian the other day. This reminded me of ipset, a very cool program as I am going to show. It makes administering related netfilter (that is: firewall) rules easy along with a good performance. This is achieved by changing how rules match in iptables. Traditionally, an iptables rule matches a single network identity, for example a single IP address or a single network only. With ipsets you can operate on a bunch of (otherwise unrelated) addresses at once easily. If you happen to need bulk actions in your firewall, for example you want to blacklist a long list of IP addresses at once, you will love IP sets. I promise.

Drawbacks of netfilter

IP sets do exist for a longer time, however they made it into the upstream Linux kernel as of version 2.6.39. That means Debian Wheezy will support it as is; for Debian Squeeze you can either use a backported kernel or compile yourself the module shipped in the ipset-source package. In any case you additionally need the command line utilities named ipset. Thus, install that package before you can start. Having that said, Squeeze users should note the ipset syntax I am demonstrating below slightly differs from the syntax supported by the Squeeze utilities. The big picture remains the same, though.

IP utils do not conflict with iptables, but extend it in a useful way. You can combine both as you like. In fact, you still need iptables to turn IP sets into something really useful. Nonetheless you will be hitting iptables‘ limitation soon if you exceed a certain number of rules. You can combine as many conditions within a filter rule as you like, however you can only specify a single pattern for each condition. You figure, this does not scale very well if a pattern to match against does not follow a very tight definition such as a CIDR pattern.

This means you can happily filter whole network blocks such as (which translates to 255 hosts) in iptables, but there is no way to specify a particular not specially connected set of IP addresses within this range if it cannot be expressed with a CIDR prefix. For example, there is no way to block, say,, and in a single statement only. You really need to declare three rules which only differ by the IP address. Pretend, you want to prevent these three addresses from accessing your host. You would probably do something like this:

iptables -A INPUT -s -p TCP -j REJECT
iptables -A INPUT -s -p TCP -j REJECT
iptables -A INPUT -s -p TCP -j REJECT

Alternatively you could do

iptables -A INPUT -s -p TCP -j REJECT

but this would block 251 unrelated hosts, too. Not a good deal I’d say. Now, while the former alternative is annoying, what’s the problem with it? The problem is: It does not scale. Netfilter rules work like a fall-through trapdoor. This means whenever a packet enters the system, it passes through several chains and in each of these chains, netfilter checks all rules until either one rule matches or there are no rules left. In the latter case the default action applies. In netfilter terminology a chain determines when an interception to the regular packet flow occurs. In the example above the specified chain is INPUT, which applies to any incoming packet.

In the end this means every single packet which is sent to your host needs to be checked whether it matches the patterns specified in every rule of yours. And believe me, in a server setup, there are lots of packets flowing to your machine. Consider for example a single HTTP requests, which requires at very least four packets sent from a client machine to your web server. Thus, each of these packets is passing through your rules in your INPUT chain as a bare minimum, before it is eventually accepted or discarded.

This requires a substantial computing overhead for every rule you are adding to your system. This isn’t so much of a problem if you haven’t many rules (for some values of “many” as I am going to show). However, you may end up in a situation where you end up with a large rule set. For example, if you suffer from a DDoS attack, you may be tempted to block drone clients in your firewall (German; Apache2. Likewise: for Lighttpd). In such a situation you will need to add thousands of rules easily.

Being under attack, the performance of your server is poor already. However, by adding many rules to your firewall you are actually further increasing computing overhead for every request significantly. To illustrate my point, I’ve made some benchmarks. Below you find the response times of a HTTP web server while doing sequential requests for a single file of 10 KiB in size. I am explaining my measurement method in detail further below. For now, look the graph. It shows the average response time of an Apache 2 web server, divided into four parts:

  • connect time: this is the time passed by until the server completed the initial TCP handshake
  • send time: this is the time passed by which I needed to reliably send a HTTP request over the established TCP connection reliably (that means: one packet sent and waiting for acknowledged by the server)
  • first byte: this is time passed by until the server sent the first byte from the corresponding HTTP response
  • response complete: this is time passed by until the server sent all of the remaining bytes of the corresponding HTTP response (remaining HTTP header + 10 KiB of payload)


Lire la suite…

How to secure SSH login with one-time passwords on Linux

13/04/2019 Comments off

As someone says, security is a not a product, but a process. While SSH protocol itself is cryptographically secure by design, someone can wreak havoc on your SSH service if it is not administered properly, be it weak passwords, compromised keys or outdated SSH client.

As far as SSH authentication is concerned, public key authentication is in general considered more secure than password authentication. However, key authentication is actually not desirable or even less secure if you are logging in from a public or shared computer, where things like stealth keylogger or memory scraper can always a possibility. If you cannot trust the local computer, it is better to use something else. This is when « one-time passwords » come in handy. As the name implies, each one-time password is for single-use only. Such disposable passwords can be safely used in untrusted environments as they cannot be re-used even when they are stolen.

One way to generate disposable passwords is via Google Authenticator. In this tutorial, I am going to demonstrate another way to create one-time passwords for SSH login: OTPW, a one-time password login package. Unlike Google Authenticator, you do not rely on any third party for one-time password generation and verification.

What is OTPW?

OTPW consists of one-time password generator and PAM-integrated verification routines. In OTPW, one-time passwords are generated apriori with the generator, and carried by a user securely (e.g., printed in a paper sheet). Cryptographic hash of the generated passwords are then stored in the SSH server host. When a user logs in with a one-time password, OTPW’s PAM module verifies the password, and invalidates it to prevent re-use.

Step One: Install and Configure OTPW on Linux

Debian, Ubuntu or Linux Mint:

Install OTPW packages with aptget.

$ sudo apt-get install libpam-otpw otpw-bin

Open a PAM configuration file for SSH (/etc/pam.d/sshd) with a text editor, and comment out the following line (to disable password authentication).

#@include common-auth

and add the following two lines (to enable one-time password authentication):

auth       required
session    optional


Fedora or CentOS/RHEL:

OTPW is not available as a prebuilt package on Red Hat based systems. So let’s install OTPW by building it from the source.

First, install prerequites:

$ sudo yum git gcc pam-devel
$ git clone
$ cd otpw

Open Makefile with a text editor, and edit a line that starts with « PAMLIB= » as follows.

On 64-bit system:


On 32-bit system:


Compile and install it. Note that installation will automatically restart an SSH server. So be ready to be disconnected if you are on an SSH connection.

$ make
$ sudo make install

Now you need to update SELinux policy since /usr/sbin/sshd tries to write to user’s home directory, which is not allowed by default SELinux policy. The following commands will do. If you are not using SELinux, skip this step.

$ sudo grep sshd /var/log/audit/audit.log | audit2allow -M mypol
$ sudo semodule -i mypol.pp

Next, open a PAM configuration file for SSH (/etc/pam.d/sshd) with a text editor, and comment out the following line (to disable password authentication).

#auth       substack     password-auth

and add the following two lines (to enable one-time password authentication):

auth       required
session    optional

Lire la suite…

How to run iptables automatically after reboot on Debian

13/04/2019 Comments off

reboot iptablesIf you have customized iptables rules, and would like to load the customized iptables rules persistently across reboots on Debian, you can leverage if-up.d scripts that are located in /etc/network/if-up.d. On Debian, any script that is marked as executable and placed in /etc/network/if-up.d gets executed when a network interface is brought up.

In order to run iptables automatically after reboot on Debian, do the following.

First, customize iptables as you wish, and then save the current iptables rule-set using iptables-save command.

$ sudo iptables-save > /etc/firewall.conf

The above command will dump the current iptables rule set into /etc/firewall.conf file which iptables-restore command can later use to restore the same rule set.

Now create the following if-up.d script called iptables that restores the saved iptables rule set.

$ sudo vi /etc/network/if-up.d/iptables
iptables-restore < /etc/firewall.conf
$ sudo chmod  x /etc/network/if-up.d/iptables

Alternatively, you can add « iptables-restore < /etc/firewall.conf » command to /etc/rc.local, which gets executed at the end of system boot-up.

Source: Xmodulo