pitter patter on the keyboard

You may find yourself in a position where it is necessary to remove all the entries in Netfilter’s connection tracking table (ip_conntrack) for a particular criterion, like the source or destination IP.

For example, I recently detected a user on one of my networks engaged in what was likely a TCP denial of service attack against root name servers (despite the odd fact that the destination port was 80). Being a NATted user, all of their connections were being tracked. The default time-out for tracking an established connection being 5 days, simply disconnecting the user at the second layer would not relieve the congestion on my routers within an acceptable time frame.

#  cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
98636

#  cat /proc/net/ip_conntrack | grep "xxx.xxx.xxx.xxx"
tcp      6 416408 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.5.147 sport=58967 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.5.147 dst=yyy.yyy.yyy.yyy sport=80 dport=58967 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 416406 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.9.239 sport=58967 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.9.239 dst=yyy.yyy.yyy.yyy sport=80 dport=58967 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 416400 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.11.231 sport=58968 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.11.231 dst=yyy.yyy.yyy.yyy sport=80 dport=58968 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 416387 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.14.37 sport=58968 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.14.37 dst=yyy.yyy.yyy.yyy sport=80 dport=58968 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 416381 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.11.103 sport=58968 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.11.103 dst=yyy.yyy.yyy.yyy sport=80 dport=58968 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 416275 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.9.57 sport=58967 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.9.57 dst=yyy.yyy.yyy.yyy sport=80 dport=58967 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 415776 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.1.52 sport=58967 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.1.52 dst=yyy.yyy.yyy.yyy sport=80 dport=58967 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 417319 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.43.60 sport=58967 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.43.60 dst=yyy.yyy.yyy.yyy sport=80 dport=58967 packets=0 bytes=0 mark=0 secmark=0 use=1
tcp      6 417319 ESTABLISHED src=xxx.xxx.xxx.xxx dst=192.168.43.13 sport=58968 dport=80 packets=1 bytes=40 [UNREPLIED] src=192.168.43.13 dst=yyy.yyy.yyy.yyy sport=80 dport=58968 packets=0 bytes=0 mark=0 secmark=0 use=1

...

It is possible to clear tracking entries en masse by removing then reloading the iptables rule that requires them to be tracked in the first place, but on a production gateway this is even less acceptable than waiting for them to expire. Fortunately, we can interact with the ip_conntrack table via conntrack-tools.

Against common sense, conntrack-tools is not available in the repositories for (at least version 5.2) of ClearOS, my favourite router distro. I grabbed a couple recent versions in RPM form but they didn’t feel like playing ball so I ended up with version 0.9.5 from ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/updates/8/i386.newkey/conntrack-tools-0.9.5-3.fc8.i386.rpm

Apparently newer versions allow one to use -D intuitively, i.e.:

# conntrack -D -s xxx.xxx.xxx.xxx

But this is not the case for at least versions including and prior to 0.97 – these require the d, dport, s and sport flags.

This wonderful person provides a way to pipe the output of conntrack -L (which lists entries the way I’d like to delete them, i.e. -s only) into sed which then breaks the output lines up and awk runs them with conntrack -D appropriately. I had to do some cleanup to get it to work due to the way their blog software mangles punctuation (a lot of my first posts here are mangled in the same way – pobody’s nerfect!):

 conntrack -L -s xxx.xxx.xxx.xxx | sed 's/=/ /g'| awk '{system("conntrack -D -s "$6" -d "$8" -p "$1" --sport="$10" --dport="$12)}'

It should be pretty clear how conntrack -L -s can be modified to work with the destination address or more complicated pattern matching.

Now we can see the ip_conntrack table is at a more reasonable level:

[root@router ~]#  cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
46676

Connections in to and out of your network are working sporadically. Your router’s dmesg is flooded with “ip_conntrack: table full, dropping packet.” What do you do?

This condition occurs when the connection tracking table has reached its limit. Connection tracking is a function of Netfilter that stores information like the source and destination IP addresses, port numbers, protocol type, state and timeout of a two-way connection. This facility lets us create sophisticated and informed Netfilter rules in a way that is not possible to accurately derive on a packet header-by-header basis.

The conntrack table takes the form of a memory structure; if there were no constraints on the size of the table it could conceivably start knocking off userspace processes if it became too large (i.e. under DoS conditions). Entries in the conntrack table expire either when their timeout has been reached or the connection has been properly closed. In cases where connections are not being closed according to protocol (poor network connectivity, DoS, spoof attack, etc.) the table can fill rapidly causing an intermittent denial of service condition on your network.

The most prominent symptom of a full connection tracking table is that your old, running connections (secure shell sessions) will continue to function while it becomes impossible to establish new ones. Worse, as the entries continue to time out and the table keeps filling up you may “get lucky” and establish a new connection here and there, making the situation much more confusing.

Depending on the situation you may have one or two options. If you have gobs and gobs of RAM available or the (for example) attack is low-volume you can adjust the entry limit of the table. First, check what the current limit is:

# cat /proc/sys/net/ipv4/ip_conntrack_max
65536

You can see how full the table currently is by running:

# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
62168

ip_conntrack_max is determined as a multiple of how much RAM the system boots up with but generally stops at 65536 regardless. You may find that this isn’t even enough for a high volume network under normal conditions. We can adjust the limit temporarily thus:

# echo 131072 > /proc/sys/net/ipv4/ip_conntrack_max

If this turns out to be your magic bullet and you’re sure no other actions need to be taken to mitigate your particular situation add the following line to /etc/sysctl.conf:

net.ipv4.netfilter.ip_conntrack_max = 131072

To load the value from sysctl.conf run:

# sysctl -p

If you don’t have the option of throwing more RAM at the problem you may be forced to make an executive decision in the interest of preserving network services for legitimate clients. You can decrease the load on the conntrack table by removing rules that use stateful logic (i.e. containing “-t nat” or “-m state”). The brute force option is to rmmod the ip_conntrack module:

# rmmod ip_conntrack

However this may not be possible in all environments. The other option is to flush your rules and set the default policy to allow:

# iptables -P
# iptables -F

This is also typically the effect of

# /etc/init.d/iptables stop
or
# /etc/init.d/firewall stop

Apparently some among legion want to DRDoS the root name servers with the same sort of UDP-spoofing DNS amplification attack I have had personal experience defending against.

I’m not going to get into how horribly misguided this is, how negatively this is going to affect the cause’s image or some long-winded speech on ethics. I only plead with interested parties not to get involved.

Attacking “the Internet” itself for any reason makes you an enemy of freedom, an enemy of progress and above all else a disgrace to hacking.

The hottest places in hell are reserved for traitors and heretics.

“The greatest enemy of freedom is a happy slave.”

To protest SOPA, Wallstreet, our irresponsible leaders and the beloved
bankers who are starving the world for their own selfish needs out of
sheer sadistic fun, On March 31, anonymous will shut the Internet down.

———————————————————————–

In order to shut the Internet down, one thing is to be done. Down the
13 root DNS servers of the Internet. Those servers are as follow:

A 198.41.0.4
B 192.228.79.201
C 192.33.4.12
D 128.8.10.90
E 192.203.230.10
F 192.5.5.241
G 192.112.36.4
H 128.63.2.53
I 192.36.148.17
J 192.58.128.30
K 193.0.14.129
L 199.7.83.42
M 202.12.27.33

By cutting these off the Internet, nobody will be able to perform a
domain name look-up, thus, disabling the HTTP Internet, which is,
after all, the most widely used function of the Web. Anybody entering
“http://www.google.com” or ANY other url, will get an error page,
thus, they will think the Internet is down, which is, close enough.
Remember, this is a protest, we are not trying to ‘kill’ the Internet,
we are only temporarily shutting it down where it hurts the most.

While some ISPs uses DNS caching, most are configured to use a low
expire time for the cache, thus not being a valid failover solution
in the case the root servers are down. It is mostly used for speed,
not redundancy.

We have compiled a Reflective DNS Amplification DDoS tool to be used for
this attack. It is based on AntiSec’s DHN, contains a few bugfix, a
different dns list/target support and is a bit stripped down for speed.

The principle is simple; a flaw that uses forged UDP packets is to be
used to trigger a rush of DNS queries all redirected and reflected to
those 13 IPs. The flaw is as follow; since the UDP protocol allows it,
we can change the source IP of the sender to our target, thus spoofing
the source of the DNS query.

The DNS server will then respond to that query by sending the answer to
the spoofed IP. Since the answer is always bigger than the query, the
DNS answers will then flood the target ip. It is called an amplified
because we can use small packets to generate large traffic. It is called
reflective because we will not send the queries to the root name servers,
instead, we will use a list of known vulnerable DNS servers which will
attack the root servers for us.

DDoS request —> [Vulnerable DNS Server ] Normal client requests
\
| ( Spoofed UDP requests
| will redirect the answers
| to the root name server )
|
[ 13 root servers ] * BAM

Since the attack will be using static IP addresses, it will not rely
on name server resolution, thus enabling us to keep the attack up even
while the Internet is down. The very fact that nobody will be able to
make new requests to use the Internet will slow down those who will try
to stop the attack. It may only lasts one hour, maybe more, maybe even
a few days. No matter what, it will be global. It will be known.

———————————————————————–

download link in #opGlobalBlackout
The tool is named “ramp” and stands for Reflective Amplification. It is
located in the \ramp\ folder.

———-> Windows users

In order to run “ramp”, you will need to download and install these two
applications;

WINPCAP DRIVER – www.winpcap.org/install/default.htm
TOR – www.torproject.org/dist/vidalia-bundles/

The Winpcap driver is a standard library and the TOR client is used as
a proxy client for using the TOR network.

It is also recommended to use a VPN, feel free to choose your own flavor of this.

To launch the tool, just execute “\ramp\launch.bat” and wait. The attack
will start by itself.

———-> Linux users

The “ramp” linux client is located under the \ramp\linux\ folder and
needs a working installation of python and scapy.

Read more: www.disclose.tv/forum/on-march-31-anonymous-will-shut-the-internet-down-t67878.html#ixzz1modrC1Jn

“He who sacrifices freedom for security deserves neither.”
Benjamin Franklin

We know you won’t listen. We know you won’t change. We know it’s because
you don’t want to. We know it’s because you like it how it is. You bullied
us into your delusion. We have seen you brutalize harmless old womans who were
protesting for peace. We do not forget because we know you will only use that
to start again. We know your true face. We know you will never stop. Neither
are we. We know.

We are Anonymous.
We are Legion.
We do not Forgive.
We do not Forget.
You know who you are, Expect us.

UPDATE And then there are those who do God’s work: Anonymous hacks Chinese websites