Category: Security

Posted on

[OpenBSD] ftp-proxy and ephemeral port

As you may already know, FTP is a pain in the a** for firewall configuration and doesn’t work well through NAT. Hopefully OpenBSD propose an elegant solution: diverting FTP traffic through a proxy server while dynamically modify Packet Filter’s rules on the fly 🙂

This proxy is very simple to enable. Just add something like this in your PF setting file:

anchor "ftp-proxy/*"
pass in quick on $int_if proto tcp to port 21 divert-to 127.0.0.1 port 8021

Then start the ftp-proxy daemon. By default it’s bound on TCP 8021.

Now you may encounter a connection issue with some ‘old’ FTP client in active mode. The reason for that is that ftp-proxy doesn’t strictly follow the RFC 959. In order to avoid port collisions ftp-proxy use an ephemeral port as a source port instead of the port 20. To force a very ‘RFC-compliant’ behaviour add the option -r to startup like this:

vi /etc/rc.conf.local
ftpproxy_flags="-r"
Posted on

SSH through HTTPS proxy

connect-proxy is a simple relaying command to make tunnel TCP connection via SOCKS4/5 or HTTPS proxies. It is mainly intended to be used as proxy command for OpenSSH. To use it first install the appropriate package, connect-proxy on GNU/Debian.

Then adjust your ssh configuration:

# vi ~/.ssh/config 
Host 10.10.1?.* 10.10.2?.* 10.10.3?.* *.foobar.fr
   User root
   ProxyCommand connect-proxy -H 10.2.0.217:3128 %h %p

Here in order to reach these specific hosts we connect through an HTTPS proxy on the port 3128 of the machine 10.2.0.217 Note that you can also use other program, like corkscrew instead of connect-proxy.

Posted on

[OpenVZ] iptables: Memory allocation problem

Let say you add a new iptable rule inside an container, but this time this happen:

# iptables -I INPUT -s 123.123.123.123 -j DROP
iptables: Memory allocation problem

Where does it come from ?

You probably hit the limit of the numiptent parameter. Check its failcounts:

# egrep "failcnt|numiptent" /proc/user_beancounters

If it’s greater than zero, you have your answer.

Increase the limit

On the host you can redefine the limit (soft and hard) for a container like this:

# vzctl set VPS_ID --save --numiptent 800:1000

Here i double default values.

Posted on

[OpenVZ] Enable iptable inside containers

To enable iptable inside containers, you must first make sure the proper modules are loaded on the host:

modprobe xt_state
modprobe xt_tcpudp
modprobe ip_conntrack

Don’t forget to add them to /etc/modules
Them inside the /etc/vz/vz.conf setting file, add the following line:

IPTABLES="ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ipt_state"

Then restart the vz service.

Posted on

Block the DFind scanner

Dfind is a vulnerability scanner, and a very pain in the *** one, as it will pollute your apache log with lines such as this:

84.145.78.74 [16 / Oct / 2008: 18: 12: 34] "GET /w00tw00t.at.ISC.SANS.DFind :) HTTP / 1.1" 400

How to get rid of this junk ?
The apache return code is 400, which implies that the query syntax is invalid. Looking in the logs we see this:

client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23)

As the request is invalid, it’s useless to try to block it with a rewrite rule or a mod_security pattern.

The best solution is to block it before the HTTP server using iptables, like that:

iptables -I INPUT -d -p tcp -dport 80 -m string -to 70 -algo bm -string 'GET /w00tw00t.at.ISC.SANS.' -j DROP
Posted on

[OpenSSL] Generate a self-signed SSL certificate

First let generate an RSA key for the server:

openssl genrsa -out server.key 2048

Next, for a “true” certificate, we must generate a certificate request (CSR).
But for a self-signed certificate, we can generate it directly like this: 

openssl req -new -days 3650 -key server.key -out server.csr

Here we will generate a x509 certificate valid for ten year. You don’t have to respond to any question beside the “Common Name ( eg, YOUR name )“. Correct value is the domain name you are going to use the certificate for.

Posted on

Debian OpenSSL vulnerability

In May 2008 a bug was discovered in the Debian OpenSSL package which affected the seeding of the random number generator. Any SSH keys generated by affected systems should be considered “insecure”. That doesn’t mean an attacker could immediately guess your private key but because there was significantly less entropy during key generation, the key space was significantly reduced making a brute-force attack feasible.

ssh-vulnkey

A new tool has been added to OpenSSH after this event: ssh-vulnkey. This tool check if a key belong to the reduced “key pool”. If result is positive you must immediately regenerate a new key on an up-to-date server. Note also that security updates for all distribution has been released to blacklist the vulnerable keys.

Further Reading and sources