Databases, Systems & Networks

An important aspect of any firewall are the log files. Iptables on Linux provides logging functionality, however by default, it will get outputted to the /var/log/messages log file. This can clutter things up, and make it hard to check the logs.

If you want to change the file that IPTables logs to, you need to set up your iptables rules to output a log prefix. Rsyslog will then be configured to pick up this prefix, and output the information to a custom log file, containing just the iptables log information.
Install rsyslog if it is not already installed.

$ sudo apt-get install -y rsyslog

Lire la suite…

1. Traffic Control, la QoS, les bases

1.1 Premier contact

1.2 Netfilter MARK

# iptables -t mangle -A OUTPUT -o eth0 -p tcp --sport 80 -j MARK --set-mark 80

# iptables -L OUTPUT -t mangle -v
Chain OUTPUT (policy ACCEPT 74107 packets, 109M bytes)
 pkts bytes target prot opt in  out  source   destination
73896  109M MARK   tcp  --  any eth0 anywhere anywhere    tcp spt:www MARK xset 0x50/0xffffffff

1.3 Deux classes dans un arbre

# tc qdisc add dev eth0 root handle 1: htb default 20
# tc class add dev eth0 parent 1:0 classid 1:10 htb rate 200kbit ceil 200kbit prio 1 mtu 1500
# tc class add dev eth0 parent 1:0 classid 1:20 htb rate 1024kbit ceil 1024kbit prio 2 mtu 1500

# tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 80 fw flowid 1:10

# nc -l -p 80 < /dev/zero

Lire la suite…

SIP Server protection

IPtables rules

iptables -I INPUT -p udp -m udp –dport 5060 -m string –string "REGISTER sip:" –algo bm -m recent –set –name VOIP –rsource
iptables -I INPUT -p udp -m udp –dport 5060 -m string –string "REGISTER sip:" –algo bm -m recent –update –seconds 60 –hitcount 12 –rttl –name VOIP –rsource -j DROP
iptables -I INPUT -p udp -m udp –dport 5060 -m string –string "INVITE sip:" –algo bm -m recent –set –name VOIPINV –rsource
iptables -I INPUT -p udp -m udp –dport 5060 -m string –string "INVITE sip:" –algo bm -m recent –update –seconds 60 –hitcount 12 –rttl –name VOIPINV –rsource -j DROP
iptables -I INPUT -p udp -m hashlimit –hashlimit 6/sec –hashlimit-mode srcip,dstport –hashlimit-name tunnel_limit -m udp –dport 5060 -j ACCEPT
iptables -I INPUT -p udp -m udp –dport 5060 -j DROP

# RTP – the media stream
# (related to the port range in /etc/asterisk/rtp.conf)
iptables -A INPUT -p udp -m udp –dport 10000:20000 -j ACCEPT

# MGCP – if you use media gateway control protocol in your configuration
iptables -A INPUT -p udp -m udp –dport 2727 -j ACCEPT

Sample script

#!/bin/bash
EXIF="eth0"
# Clear any existing firewall stuff before we start
/sbin/iptables –flush
# As the default policies, drop all incoming traffic but allow all
# outgoing traffic. This will allow us to make outgoing connections
# from any port, but will only allow incoming connections on the ports
# specified below.
# Allow connections from my machines
/sbin/iptables -A INPUT -p tcp -i $EXIF -m state –state NEW -s 109.161.251.214 -j ACCEPT
/sbin/iptables –policy INPUT DROP
/sbin/iptables –policy OUTPUT ACCEPT
# Allow all incoming traffic if it is coming from the local loopback device
/sbin/iptables -A INPUT -i lo -j ACCEPT
# Accept all incoming traffic associated with an established connection, or a "related" connection
/sbin/iptables -A INPUT -i $EXIF -m state –state ESTABLISHED,RELATED -j ACCEPT
# Check new packets are SYN packets for syn-flood protection
/sbin/iptables -A INPUT -p tcp ! –syn -m state –state NEW -j DROP
# Drop fragmented packets
/sbin/iptables -A INPUT -f -j DROP
# Drop malformed XMAS packets
/sbin/iptables -A INPUT -p tcp –tcp-flags ALL ALL -j DROP
# Drop null packets
/sbin/iptables -A INPUT -p tcp –tcp-flags ALL NONE -j DROP
# Allow connections to port (4501) – ssh. You can add other ports you need in here
/sbin/iptables -A INPUT -p tcp -i $EXIF –dport 4501 -m state –state NEW -j ACCEPT
# Allow connections to port (4500) – Webmin . You can add other ports you need in here
/sbin/iptables -A INPUT -p tcp -i $EXIF –dport 4500 -m state –state NEW -j ACCEPT
# Allow connections to port (80&443) – www. You can add other ports you need in here
/sbin/iptables -A INPUT -p tcp -i $EXIF –dport 80 -m state –state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp -i $EXIF –dport 443 -m state –state NEW -j ACCEPT
# Allow connections from my machines
/sbin/iptables -A INPUT -p tcp -i $EXIF -m state –state NEW -s 80.241.212.93 -j ACCEPT
# Allow SIP connections
/sbin/iptables -A INPUT -p udp -i $EXIF –dport 5060 -m udp -j ACCEPT
/sbin/iptables -A INPUT -p tcp -i $EXIF –dport 5060 -m tcp -j ACCEPT
/sbin/iptables -A INPUT -p udp -i $EXIF –dport 10000:20000 -m udp -j ACCEPT
# Allow icmp input so that people can ping us
/sbin/iptables -A INPUT -p icmp –icmp-type 8 -m state –state NEW -j ACCEPT
# Log then drop any packets that are not allowed. You will probably want to turn off the logging
#/sbin/iptables -A INPUT -j LOG
/sbin/iptables -A INPUT -j REJECT

Source: Ahmad Sabry ElGendi

http://sysadminman.net/blog/2008/iptables-for-asterisk-49

http://www.voip-info.org/wiki/view/Asterisk+firewall+rules

Neat tricks with iptables: The past few months have seen me digging deep into the world of TCP/IP and firewalls. It has been a fascinating journey into packet queueing and TCP headers, three-way handshakes and ICMP broadcasts.

The result of this research has been the ongoing creation of a firewall to protect my laptop against open networks, and my Internet server from port scanning and DoS attacks. I’m pretty certain I haven’t even scratched the surface yet, but I have found some settings to protect against the most common attacks. Below I’ll summarize the major pieces of my new firewall, and the logic behind it.

Address spoofing: win with iptables

The easiest way to fool a server is to construct a packet that whose source address is faked, or spoofed. This is surprisingly easy to do. To craft packets, I use a very powerful network analysis tool called Scapy. Scapy will allow you to create packets on the fly, transmit them, and scan your network for any response.

For example, let’s say I’m on my local network (which I am right now, as I write this), connected via wireless as192.168.15.113. I’m going to interact with the router, which is at 192.168.15.1. For the purposes of analysis, I’ve also setup a virtual machine running on 192.168.15.114, so I can see what happens when I spoof the packet.

So, let’s say I spoof an ICMP echo-request packet, sent to .1 (router) from .113 (me) but spoofed as if it had come from .114 (virtual machine). In Scapy this is quite easy to do. I run two scapy session in two terminal windows. In the first I type:

>>> send(IP(src="192.168.15.114", dst="192.168.15.1")/ICMP())
.
Sent 1 packets.

Although my machine is at .113, I’m telling scapy to set the source address for the ICMP echo-request packet to.114, which is the host I want to attack. I’m sending this “ping” to the router, which should now send its response back to .114 instead of me.

In my other terminal window, I run scapy again, this time in promiscuous mode as a packet sniffer. Promiscuous mode means that it will capture all packets seen on the network, not just those destined for my own machine. Here’s what I see:

>>> sniff(filter="icmp")
^C
>>> _.show()
0000 Ether / IP / ICMP 192.168.15.114 > 192.168.15.1 echo-request 0
0001 Ether / IP / ICMP 192.168.15.1 > 192.168.15.114 echo-reply 0

I ran the sniffer, then did the ping, then stopped the sniffer by pressing Control-C. I can see that two ICMP packets were seen during the sniff. By showing the contents of these packets, I can see both the packet that I transmitted, and the response – which came back to .114!

That’s a spoof. How can it be used to attack someone? Read on in the next section, since what we just did forms the basis for a smurf attack.

Some packet spoofs, however, are more obvious. For example, a packet coming from the Internet bound for a private IP address or certain broadcast addresses, such as address beginning with 192.168 or 224. These are never valid, so it’s a good idea to drop such packets immediately upon receipt. Here are the iptables rules to do this:

# Reject packets from RFC1918 class networks (i.e., spoofed)
iptables -A INPUT -s 10.0.0.0/8     -j DROP
iptables -A INPUT -s 169.254.0.0/16 -j DROP
iptables -A INPUT -s 172.16.0.0/12  -j DROP
iptables -A INPUT -s 127.0.0.0/8    -j DROP

iptables -A INPUT -s 224.0.0.0/4      -j DROP
iptables -A INPUT -d 224.0.0.0/4      -j DROP
iptables -A INPUT -s 240.0.0.0/5      -j DROP
iptables -A INPUT -d 240.0.0.0/5      -j DROP
iptables -A INPUT -s 0.0.0.0/8        -j DROP
iptables -A INPUT -d 0.0.0.0/8        -j DROP
iptables -A INPUT -d 239.255.255.0/24 -j DROP
iptables -A INPUT -d 255.255.255.255  -j DROP

Here’s the same thing, now for ipfw users:

# Verify the reverse path to help avoid spoofed packets.  This means any
# packet coming from a particular interface must have an address matching the
# netmask for that interface.
ipfw add 100 deny all from any to any not verrevpath in

# Deny all inbound traffic from RFC1918 address spaces (spoof!)
ipfw add 110 deny all from 192.168.0.0/16 to any in
ipfw add 120 deny all from 172.16.0.0/12 to any in
ipfw add 130 deny all from 10.0.0.0/8 to any in
ipfw add 140 deny all from 127.0.0.0/8 to any in

ipfw add 150 deny all from 224.0.0.0/4 to any in
ipfw add 160 deny all from any to 224.0.0.0/4 in
ipfw add 170 deny all from 240.0.0.0/5 to any in
ipfw add 180 deny all from any to 240.0.0.0/5 in
ipfw add 190 deny all from 0.0.0.0/8 to any in
ipfw add 200 deny all from any to 0.0.0.0/8 in
ipfw add 210 deny all from any to 239.255.255.0/24 in
ipfw add 220 deny all from any to 255.255.255.255 in

Lire la suite…

Source: Per Linde, Martynas Pumputis and Guillermo Rodr ́ıguez iptables revisited: a not so ordinary ‘firewall’

iptables revisited: Abstract

At the present time, security on the internet, and networks in general have evolved, and become an issue that should not be disregarded. It is well known that many experts recommend Linux as the main operating system for the machines that have to be in charge of security (also for a desktop computer). Linux included a basic firewall tool called ipchains in the series of its kernel until 2.4 version, though after that version it switched to iptables. iptables is known for its efficiency and functionality, but the enormous functionality means a more complex tool to be configured. This paper will overview some mechanisms to do advanced configuration of iptables based on two main scenarios. The different configurations presented will try to prove the remarkable power of iptables as an independent firewall and also as a tool that can work in conjuntion with other tools usually incorporated when included this one.

Introduction

iptables is a firewall developed by the Netfilter Project 1 . Presently, this firewall is becoming more and more popular (both among end users and network administrators). The popularity of this firewall it closely related to Linux operating system, because iptables works with Linux kernels 2.4 and 2.6 and almost every major Linux distribution comes with pre-installed iptables firewall. This firewall is also known as a stateful packet filter. It is a main difference between iptables and ipchains (an ancestor of iptables that was used with Linux kernel versions up to 2.4). The firewall supports not only a packet filtering, but it is also able to log, forward packets and it could be used together with such tools as psad, snort, etc. In this paper we will look a bit deeper into more advance iptables configurations, but first of all, we would like to introduce a reader to a basic usage of iptables. The core of the firewall consists of four parts [7]: tables, chains, matches and targets. A system administrator is able to define an iptables policy, i.e. tables of chains, which describe how a kernel should react against different groups of packets. Rules are used to create a chain – collection of rules that is applied to every packet. There are five predefined chains:

• INPUT: used for incoming packets before routing.
• OUTPUT: used for packets coming into the box itself.
• FORWARD: used for packets being routed through the box.
• PREROUTING: used for locally-generated packets before routing.
• POSTROUTING: used for packets as they about to leave iptables.

Every rule should have a set of matches, that helps to filter packets (e.g. -d 10.100.1.1 matches a destination IP 10.100.1.1), and it also has to have a target – an action which should be performed when a rule matches on a packet (e.g. ACCEPT, DROP, LOG…). All the examples presented in this paper (excluding the one used at section 6) will be based on the scenario presented in the figure 1. In the following scenario, WebServer#1 (10.100.1.101 assigned to its ‘eth0’ interface), WebServer#2 (10.100.1.102 assigned to its ‘eth0’ interface) and PC (10.100.1.33 assigned to its ‘eth0’ interface) belong to a local network and every packet that comes from the Internet/LAN is filtered by the firewall (‘eth1’ interface for LAN’s traffic, ‘eth0’ for Internet’s traffic). PC (212.59.0.1 assigned to ‘eth0’ interface) is reachable directly through the Internet. The listing 1 shows a couple of rules, the first one appends a rule to the end of the INPUT chain and it specifies that every packet from the source with IP address 212.59.0.1 will beDROPed and the second rule logs all outgoing connections from eth1 interface.

iptables -A INPUT -s 212.59.0.1 -j DROP
iptables -A OUTPUT -o eth1 -j LOG

Lire la suite…