iptstate

iptstate is a ncurse tool that displays information held in the netfilter conntrack table in a top-like format. Output can be sorted by any field, reversed, and has several formatting option:

Verify a SSL certificate installation with openssl

Usually people use their browser or a dedicated website like ssltest to test a server certificate installation.

But you can do it directly with the openssl command:

# openssl s_client -CApath /etc/ssl/certs/ -connect www.foobar.com:443
...
...
New, TLSv1/SSLv3, Cipher is AES256-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-SHA256
    Session-ID: 9E01CD86FA9F1483AD505F17E34C0B9BF99F57BBF9B5E6A5F2946F8858A86807
    Session-ID-ctx: 
    Master-Key: 8ED5443DCD5F6706A0DF5C0196E1B3AFBAAD3FB0B5B680EB212D4FC3F2BCC24209D0E241FBA746D85559CFA8539D99F4
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1474905181
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

The line Verify return code: 0 indicate a correct installation. Note that the -CApath option tells openssl where to look for the CA certificates. On Debian the directory is /etc/ssl/certs/.

[OpenVZ] NFSd v3 inside a container

Hypervisor prerequisite

In order to get a working NFS server daemon inside a container, you must satisfy some prerequisites on the hypervisor. First the kernel version must be recent enough. Using the latest RHEL5 or RHEL6 OpenVZ kernels is recommended. Also you need vzctl in version 3.0.24 or superior. Next you must install and load the nfsd kernel module.

Only then you can enable the nfsd capability for the container, like this:

vzctl set $ID --feature nfsd:on --save

Don’t forget to restart the container to activate this capability. After that, to simplify the VM firewall configuration i recommend you to explicitly set the lockd binding ports:

hypervisor:~# vi /etc/modprobe.d/lockd.conf
options lockd nlm_udpport=2045 nlm_tcpport=2045

NFS VM configuration

First install the nfs-kernel-server and rpcbind packages. Specify the RPC ports to use and disable NFSv4 support:

nfsvm:~# vi /etc/default/nfs-kernel-server
# Options for rpc.mountd.
# If you have a port-based firewall, you might want to set up
# a fixed port here using the --port option. For more information,
# see rpc.mountd(8) or http://wiki.debian.org/SecuringNFS
# To disable NFSv4 on the server, specify '--N 4' here
RPCMOUNTDOPTS="--manage-gids -N 2 -N 4 --port 2048"
nfsvm:~# vi /etc/default/nfs-common
# Options for rpc.statd.
#   Should rpc.statd listen on a specific port? This is especially useful
#   when you have a port-based firewall. To use a fixed port, set this
#   this variable to a statd argument like: "--port 4000 --outgoing-port 4001".
#   For more information, see rpc.statd(8) or http://wiki.debian.org/SecuringNFS
STATDOPTS="--port 2046 --outgoing-port 2047"

Don’t forget to restart the daemon.
Lastly, modify the VM firewall configuration: open the ports 111 tcp/udp and the range 2045-2049 tcp/udp for all NFS-clients IP.

Further Reading and sources

[OpenBSD] DDoS survival guide

First keep calm and check your firewall/router state table:

fw1:~# pfctl -si | grep current
current entries                    421356 

Here we have a state table with much more entries than usual (400K instead of 100K). There is very probably an ongoing attack.

Which IP is targeted ?

For this task i use this script:

fw1:~# fw1:~# pfctl -ss | top_states.pl
62.210.216.82 (387654)
62.210.119.54 (1544)
62.210.216.10 (900)
62.210.216.13 (864)
...

The targeted IP will have an abnormally large number of entries. Here the winner is 62.210.216.82

On which port ?

fw1~# pfctl -ss | grep -- "-> 62.210.216.82" | awk '{print $5}' | sort -n | uniq -c
200307 62.210.216.82:80

Classic HTTP Flood attack.

At this point we have two possibilities:

  • limits the number of simultaneous connections to the targeted IP
  • block any access to the targeted IP

The first solution is appropriate in case of small scale attack. The latter is more extreme but has the advantage to not put at risk the rest of the network.

Limit the number of simultaneous connections

Add the following rule before the one authorizing the port 80:

pass in quick on $ext_if proto tcp to 62.210.216.82 port http keep state (max 10000)

Then kill all the supernumerary state entries:

fw1:~# pfctl -k 0.0.0.0/0 -k 62.210.216.82
fw1:~# pfctl -k 62.210.216.82

Block any access

Add the following rule:

block in quick on $ext_if to 62.210.216.82

Then kill all the supernumerary state entries:

fw1:~# pfctl -k 0.0.0.0/0 -k 62.210.216.82
fw1:~# pfctl -k 62.210.216.82