ulogd2-mysql patch for NFCT

Filed in Linux | Networking Leave a comment

Seems ulogd2-mysql table schema is outdated, even in git repo is not updated (but pgsql does … WTH!). So it not log conntrack event to database because missing ct_event fields.

So this is [patch version], already submitted upstream and wait for update.

In real world use. logging conntrack event to database is not really good solution because it grows very (very (very)) fast.
By default ulogd use hashing so it only insert connection on DESTROYED state unless to want it to log every events.

In case you log all events, it hard to know when the connection starts and end because it log NEW and DESTROY event separately.
Matching require connection ID which not unique after system restart.

And if you need for only logging not analyze, keep default hashing on (log only DESTROY event) and just DROP ALL INDEXES.
It slow down and quite consume the valueable disk space.

So i have some projects myself for implement real-time selective accounting of conntrack flows which also can do hashing
and also do logging, statistics, etc (For … interface with SNMP). The idea was to use libnfconntrack and netlink. But i need to find good bindings in Perl first.

UPDATE:
There is another NET::Netfilter::Netflow perl that directy use conntrack-tools for conntrack events to export Netflow v5 to netflow collector but lacks support of IPv6.

Why outdated Perl languages ? … It fast and works well with parsing something!

, , , ,

Iptables for common DNS amplification attack on recursive DNS inside your network.

Filed in Linux | Networking Leave a comment

There are a lots of DNS amplification attack now. In my network with hosts around a few hundreds of servers, my log was never stop.

What is it ? Basically it is a DDoS technique by use large reply of DNS resolving to DDoS target with hugh amount of bandwidth.
This accomplished by spoof query with source IP of the target victim to ask for (large) DNS record, such as ANY reply of ROOT record or isc.org which is most commonly found. Request is usually 60-70 bytes while reply is as much as 2-3K. (That’s why its call amplification). It not only make your network participate in attacks, but also consume your bandwidth.

More details [here]

But it indeed have some basic iptables rules that block most if it if you have some of open DNS resolver inside your network. Or if you need
to have DNS servers that response to large number of clients (i.e. ISP) you should apply this.

This is tcpdump output of the commonly found attack packets for ROOT record and isc.org record.

11:59:09.598925 IP 174.19.x.x.26252 > 202.162.x.x.domain: 39595+ [1au] ANY? . (28)
        0x0000:  4500 0038 3f1f 0000 f311 bd0b ae13 0490
        0x0010:  caa2 4e44 668c 0035 0024 0000 9aab 0100
        0x0020:  0001 0000 0000 0001 0000 ff00 0100 0029
        0x0030:  2328 0000 0000 0000

12:00:29.038230 IP 5.135.x.x.25345 > 202.162.x.x.domain: 10809+ [1au] ANY? isc.org. (36)
        0x0000:  4500 0040 1e14 0000 e811 cec3 0587 c6a2
        0x0010:  caa2 4f09 6301 0035 002c 0000 2a39 0100
        0x0020:  0001 0000 0000 0001 0369 7363 036f 7267
        0x0030:  0000 ff00 0100 0029 1000 0000 8000 0000

If you have time to look into DNS request structure. at 0x0028. 0000 ff00 is or Root DNS request, another one is isc.org request.
You can match with iptables with following u32 match rules.

iptables -A INPUT -p udp --dport 53 -m u32 --u32 "0x28=0x0000ff00"
iptables -A INPUT -p udp --dport 53 -m u32 --u32 "0x28=0x03697363 && 0x2c=0x036f7267"
iptables -A INPUT -p udp --dport 53 -m u32 --u32 "0x28=0x02646b00"

Update: add last rules for commonly found ANY query on .dk domain.

This can use to block almost 99% of the malicious query.
But … This example not drop any packages, so apply -j DROP or modify it to suit your needs.
But in some cases you need to have more advance checking to allow legitimate request.

There is another example that is really use in my Linux firewall which utilize iptables recent match to give some thresholds
for legitimate request and block if it too frequent.

iptables -t mangle -A FLOOD_DNS_ADD -j NFLOG --nflog-prefix 'FLOOD_DNS:'
iptables -t mangle -A FLOOD_DNS_ADD -m recent --name FLOOD_DNS_BLOCK --rsource --set -j DROP

iptables -t mangle -A FLOOD_DNS_CHECK -m recent --name FLOOD_DNS_BLOCK --rsource --update --hitcount 1 --seconds 60 -j DROP
iptables -t mangle -A FLOOD_DNS_CHECK -m recent --name FLOOD_DNS_BLOCK --rsource --remove -j RETURN
iptables -t mangle -A FLOOD_DNS_CHECK -m recent --name FLOOD_DNS --rsource --update --hitcount 10 --seconds 60 -j FLOOD_DNS_ADD
iptables -t mangle -A FLOOD_DNS_CHECK -m recent --name FLOOD_DNS --rsource --set -j RETURN

iptables -t mangle -A PREROUTING -p udp --dport 53 -m u32 --u32 "0x28=0x0000ff00" -j FLOOD_DNS_CHECK
iptables -t mangle -A PREROUTING -p udp --dport 53 -m u32 --u32 "0x28=0x03697363 && 0x2c=0x036f7267" -j FLOOD_DNS_CHECK
iptables -t mangle -A PREROUTING -p udp --dport 53 -m u32 --u32 "0x28=0x02646b00" -j FLOOD_DNS_CHECK

 

Do not rely on this protection. Make sure you apply ACL to your caching nameservers or turn recursive lookup off completely if you does not need it (run as authoritative name servers for your domains only). Not going in to details here, Google is your friends 🙂

, , , , ,

TOP