Databases, Systems & Networks

Source: zioup.org

Linux iptables now offers extended packet matching modules. The recent module tracks IP addresses and allows to match against them using other criteria.

We are going to use a combination of lists created by the recent module and a new chain to track attackers. The two problems we are trying to minimise are:

• centralised port scans.
• ssh attacks: somebody tries to log in through ssh from a unique ip address using different user IDs and passwords.

port scan

A port scan will try to talk to our machine on different ports. The idea here is to ban the offending ip address as soon as it touches a non-authorised port.

We accomplish this by creating two rules. The first one has to be the last rule in the INPUT chain, it replaces your rule that says that if a packet has not matched any rule it should be DROPped. Additionally to DROPping the packet, we add the source ip address to the « badguys » list:

iptables ...
 .
 .
 .
iptables -A INPUT  -t filter -i $OUTS -j DROP -m recent --set --name badguys

The next rule will be the first rule of the INPUT chain and will block any packet from ip addresses that are present in the badguys list and for which we have received packet within the last hour. Note that we use the « –update » option rather than « –rcheck », so that any new packet resets the clock ; offenders have to be completely silent for one hour in order to be able to communicate with us again:

iptables -A INPUT -i $OUTS -m recent --name badguys --update --seconds 3600 -j DROP
iptables ...
 .
 .
 .
iptables -A INPUT  -t filter -i $OUTS -j DROP -m recent --set --name badguys

Lire la suite…

Iptables is a powerful firewall/packet filtering framework inside Linux, and obviously used for firewalls on desktop, servers, and even embedded Linux devices such as most home internet routers. I was asked to write a script that could monitor and report network usage on one of our machines at work.

I took on the challenge and after searching package repositories and Google for cool Linux console apps that will report network usage, I came came across the idea of using iptables.. seeing as I love iptables, and it is installed by default on most machines it was the perfect solution for us.

The Idea
Iptables can be thought of a bunch of tables each containing some lists of rules called “chains”. There are some default chains which packets must progress through depending on the packets origin and destination. The main and default table that most people use is the ‘filter’ table, the default chains are:

• INPUT – Packets coming to the machine from the network.
• OUTPUT – Packets leaving your machine,
• FORWARD – Packets passing through your machine, if your machine routes packets.

Each of these chains have a default policy, that is what should happen if there is no rules or no rules matching the packet, this is either:

• ACCEPT – Allow the packet into the machine.
• DROP – Drop the packet,

Now the default chains cannot be changed, the packets will work through one of those chains, we can add any rules we want to filter these packets. Netfilter/iptables tracks the amount of data running through chains. So if you want to track all your incoming network usage you can just use the INPUT chain, but if we want to track more specific traffic, we can create a custom chain, add a rule to pass the specific packets to this new chain, and thus monitor the specific traffic! Easy huh!

Before I go into the script and specific iptables configuration I’ll show you readers some useful itptables commands:

• To see the manual page on iptables: man iptables
• To list the rules on the default (filter) table: iptables -L
• To list rules on other tables: iptables -t <tablename> -L

NOTE: If you add a -v you can see packet and byte counts.

Now we move onto what I did.

Lire la suite…

Source: Jack Brennan

#  Plex
-A INPUT -m state --state NEW -m tcp -p tcp --dport 32400 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 32400 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 32410 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 32412 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 32414 -j ACCEPT

#  UPnP Disabled in router open for the sake of science
-A INPUT -m state --state NEW -m udp -p udp --dport 1900  -j ACCEPT

# Generated by iptables-save v1.4.7 on Thu Jan  9 11:05:53 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --sport 513:65535 --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 32400 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 32400 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 32410 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 32412 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 32414 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 1900 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --sport 53 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -p tcp -m tcp -m state --state ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p tcp -m tcp --sport 22 --dport 513:65535 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --dport 443 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -j DROP
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Thu Jan  9 11:05:53 2014

Source: microhowto.info

Content

• 1 Objective
• 2 Background
• 3 Symptoms
• 4 Scenario
• 5 Investigation
  • 5.1 Strategy
  • 5.2 Inspecting the tables
  • 5.3 Monitoring traffic flow using counters
  • 5.4 Monitoring traffic flow using the LOG target
    

Objective

To ensure that iptables has been correctly configured.

Background

iptables is a component of the Linux kernel that allows IPv4 traffic to be manipulated as it traverses the network stack. Its two main uses are:

• packet filtering (firewalling) and
• network address translation (NAT).

The behaviour of iptables is controlled by rules, each of which specifies the action to be taken if a packet meets a particular set of conditions. The rules are organised into chains, and the chains into tables. Chains may be either built-in or user-defined.

For more information about the architecture and configuration of iptables see:

• the netfilter/iptables project homepage,
• the iptables tutorial and
• the Packet Filtering and NAT HOWTOs

Symptoms

The most likely symptoms of an iptables configuration error are:

• traffic being dropped or rejected,
• traffic not being NATted when it should have been,
• traffic being NATted when it shouldn’t have been, or
• traffic being NATted to the wrong address.

A wide variety of other effects are possible, but unlikely unless the configuration is an unusual one.

Scenario

Suppose that a machine has been configured to act as a boundary router between a local area network (connected to interface eth0 with the address 192.168.0.1/24) and the public Internet (connected to interface ppp0 with the address 203.0.113.144/32). The default gateway is 203.0.113.1. Because the local area network uses a private address range, iptables on the boundary router has been configured to SNAT them to its public IP address.

In order to test this configuration you have attempted to ping a machine on the public Internet (198.51.100.1) from a machine on the local area network (192.168.0.2), but this has failed.

Lire la suite…

Source: defendagainstddos.wordpress.com

On the 25th of January one of my sites was struggling to stay up, my “Dos Deflate” emails were popping into my inbox at a great frequency.

A quick run of the following command:

netstat -tn 2>/dev/null | grep :80 | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -nr | awk ‘{print $2}’

Gave me a list of addresses connected to the site. The number of addresses was way way above the number normally connected to the site.  A site which although modestly doing 100,000s of page views per day will normally have only 300-500 port 80 connections at any one instance.  This time however we had a 2 or 3 thousand.

A quick copy and paste into the following tool http://software77.net/geo-ip/multi-lookup/ (max 2000 ips per lookup) which is very usefully for bulk ip address to location lookups, yielded the following

1.26.199.253 # CN China
 1.81.157.62 # CN China
 1.83.168.34 # CN China
 1.180.57.96 # CN China
 1.26.201.167 # CN China
 1.62.140.66 # CN China
 1.189.82.78 # CN China
 1.193.76.146 # CN China
 1.26.241.209 # CN China
 1.190.209.36 # CN China
 1.189.162.213 # CN China
 1.31.57.105 # CN China
 1.62.17.196 # CN China
 1.58.137.111 # CN China
 1.83.229.4 # CN China
 1.180.10.45 # CN China
 1.180.5.200 # CN China
 1.26.169.201 # CN China
 1.180.187.10 # CN China
 1.190.2.102 # CN China
 1.25.134.125 # CN China
 1.62.161.233 # CN China
 1.182.28.181 # CN China
 (And on and on)

We clearly had an issue with China, but a quick log in to Google Analytics indicated almost no real-time traffic visiting the site.

Due to the sheer volume of connections for the next 45 mins, I was regularly running this command pasting into excel, then bulk iptabling the the ip address as well as the 65,000 neighbouring addresses.

sudo iptables -A INPUT -s 59.56.0.0/16 -m comment –comment “China IP” -j DROP
sudo iptables -A INPUT -s 1.26.0.0/16 -m comment –comment “China IP” -j DROP

etc etc.

Lire la suite…