Contents
What is Bridging?
Installing a Bridge
Configuring a Bridge
What is a Bridging Firewall?
Installing a Bridging Ebtables Firewall
Configuring a Bridging Ebtables Firewall
Installing a Bridging Iptables Firewall
Configuring a Bridging Iptables Firewall
What is an Intrusion Prevention System?
Installing an Intrusion Prevention System
Configuring an Intrusion Prevention System
What is Bridging?
A bridge is a network device, that connects two network segments of any network type (ethernet, token ring etc.) transparently to form one subnet. Transparency means, that you do not have to tell any component (computer, application etc.) that there is a new device between them. So, no configuration on them is needed. And your bridge is really stealthy, because it does not need any IP address.
You can easily build a bridge using a computer with at least two network interfaces. Here, in this section, I want to decribe howto setup a bridge using Linux (here wirth kernel 2.4.24), because based on the transparency characteristics of a bridge, you can build security enhancing network devices like bridging (transparent) firewalls and intrusion prevention systems.
Installing a Bridge
There are two things to do. First, you have to install the bridge-utils. Under gentoo you just type:
emerge bridge-utils
If your distribution is not shiped with bridge-utils, then you can download them from sourceforge. You can configure, compile and install bridge-utils the standard way.
The second thing to do is to prepare the kernel. Fortunately, you have to activate all drivers you need to run your box properly. In addition, you have to active (this depends on the development status of the kernel features):
Code maturity level options –> Prompt development and/or incomplete code/drivers
Networking options –> 802.1d Ethernet Bridging
Then simply recompile and install your new kernel. Reboot. If you are using modules, then load them!
Configuring a Bridge
Configuring a bridge a really straightforward. See table 1.
Table 1: Configuring the Bridge
$ ifconfig eth0 0.0.0.0 up
$ ifconfig eth1 0.0.0.0 up
$ brctl addbr br0
$ brctl addif br0 eth0
$ brctl addif br0 eth1
$ ifconfig br0 0.0.0.0 up
Now you have a network device, that forwards traffic between two network segments transparently. But what do the commands in table 1 do exactly? With the first two lines, you bring the two ethernet interfaces eth0 and eth1 up, without assigning an IP address to them. The 0.0.0.0 garantees, thet even if an IP address was assigned at startup, it will be overwritten. In the third line a new device, here a bridge, called br0 is created. Lines 4 and 5 add the two interfaces eth0 and eth1 to our bridge br0. In the last line, we bring our bridge br0 up. Again, we assign no IP address to it.
What is a Bridging Firewall?
A bridging firewall is also often called a transparent firewall and some benefits come with its’ design:
Zero configuration. From a networking standpoint, there are virtually no changes. How can this be? Easy, the bridging firewall is plugged in-line with the network it is protecting. This means you can put it between two routers, or a router and a switch. You could even put it in front of a single machine. While it might be placed exactly where it should be if it were acting as a gateway or router, it’s not. Remember, it merely moves frames after inspecting them between interfaces. This means that there’s no need to make any changes to your existing network. It is completely transparent. No subnetting headaches or configuration updates are required with this device.
Performance. Because they are simpler devices, there’s less processing overhead. This cost cutting either boosts the capabilities of the machines or allows for deeper examination of the data.
Stealth. A key aspect of this device is the fact that it operates at layer 2 of the OSI model. This means the network interfaces have no IP addresses. Such a feature carries more weight than merely ease of configuration. Without an IP address, this device is unreachable and invisible to the outside world. If it cannot be reached, how can anyone attack it? No network probes, denial of service floods or firewalking on this machine. Your attackers won’t even know it’s in place, silently inspecting everything they send.
The are two possibilities to realize a bridging firewall: with ebtables or with iptables. In ebtables the focus is more on OSI layer 2-3, where in iptables it is more on ISO layer 3-4. Ebtables might be more suitable in scenarios, where the bridge connects two network segments within one subnet, where iptables might be more suitable where the bridge is placed before a router that connects the subnet to another net.
Installing a Bridging Ebtables Firewall?
First of all you need a bridge. Above I have decribed how to install and configure it. Secondly you have to install the ebtables packages. Under gentoo just do a
emerge ebtables
But keep in mind, that this package is masked. If this package is not shipped with your distribution, then download it from sourceforge. You can configure, compile and install ebtables the standard way. ebtables can be seen as a replacement for iptables. But it uses other tables within the kernel.
The next step is to enhance the kernel with the ebtables-brnf-patch (not necessary for kernel 2.6, because it is already in there). You can download it from sourceforge. Decompress it and the patch your kernel with the corresponding version of ebtables-brnf:
patch -p1 <patch_file
Within the kernel you have to activate:
Networking options –> Network packet filtering (replaces ipchains)
Networking options –> 802.1d Ethernet Bridging
Networking options –> 802.1d Ethernet Bridging –> Bridge: ebtables (NEW)
Then a list of options for ebtables pops up. you can select, for simplicity, all of them. Then simply recompile, and install your new kernel. Reboot. If you are using modules, then load them!
Configuring a Bridging Ebtables Firewall?
The bridge is now running and the kernel already prepared for configuring a firewall via ebtables. The best is always to have a real life example to show how it works. My example will be based on the following environment:
There is a NAT-Router with the IP address 192.168.1.1 playin the role of a gateway all clients within the subnet 192.168.1.0/24 and connection them to the internet
On the NAT-Router runs an DNS forwarder, so that he is the DNS server for all clients in the subnet.
The subnet 192.168.1.0/24 is divided into two parts. The clients within the first part of the subnet are directly connected to the NAT router via a switch. The clients of the second part of the subnet are connected with the first part of the subnet via our new bridge.
There is a client in the second part of the subnet with the IP address 192.168.1.52. This client wants to surf the WWW. So it has to pass the bridge and the NAT router.
Table 2: Configuring the Bridging Ebtables Firewall
$ ebtables -P FORWARD DROP
$ ebtables -A FORWARD -p 0x806 -j ACCEPT
$ ebtables -A FORWARD -p 0x800 –ip-dst 192.168.1.52 –ip-proto tcp –ip-sport 80 -j ACCEPT
$ ebtables -A FORWARD -p 0x800 –ip-src 192.168.1.52 –ip-proto tcp –ip-dport 80 -j ACCEPT
$ ebtables -A FORWARD -p 0x800 –ip-src 192.168.1.52 –ip-dst 192.168.1.1 –ip-proto udp –ip-dport 53 -j ACCEPT
$ ebtables -A FORWARD -p 0x800 –ip-src 192.168.1.1 –ip-dst 192.168.1.52 –ip-proto udp –ip-sport 53 -j ACCEPT
The syntax of ebtables is quite similar to the one of iptables.Because we are using briding, that has in our case a lot of similarities to routing, we have to configure only our FORWARD chain. In the first line we set our default policy to DROP, meaning, that all packages not matching any other rule, are dropped by default. The second line says, that our bridging firewall will let ARP packages pass. The parameter -p is used to specify a protocol in hex. 0x806 is ARP (Address Resolution Protocol). This is needed, because the clients within a subnet communicate based on layer 2 of the OSI model. And so they have to find the MAC addresses based on the IP addresses they know.
In the third and fourth line we grant the client 192.168.1.52 to do surf the WWW. -p 0x800 is the well known Internet Protocol (IP). –ip-dst and –ip-src give the destination and source IP respectively. –ip-proto specifies the IP protocol, here TCP. With –ip-dport and –ip-sport we specify the destination and sourceport, here port 80 (the standard port for http traffic).
The last two lines eneble the client 192.168.1.52 to do dns requests. The NAT router 192.168.1.1 serves as a DNS forwarder. In this case the source and destination addresses are well known. The IP protocol used is UDP and the port on the NAT router serving DNS is 53.
Configured this way, our bridging firewall will only let one client through and will enable him to surf in the WWW.
Installing a Bridging Iptables Firewall?
First of all you need a bridge. Above I have decribed how to install and configure it. Secondly you have to install the iptables packages. Under gentoo just do a
emerge iptables
The software is shiped with really every distribution. So you do not need to download it.
Within the kernel you have to activate at least the following options:
Networking options –> Network packet filtering (replaces ipchains)
Networking options –> IP: Netfilter Configuration –> Connection Tracking (required for masq/NAT)
Networking options –> IP: Netfilter Configuration –> IP tables support (required for filtering/masq/NAT)
Networking options –> IP: Netfilter Configuration –> Connection state match support
Networking options –> IP: Netfilter Configuration –> Connection tracking match support
Then simply recompile, and install your new kernel. Reboot. If you are using modules, then load them!
Configuring a Bridging Iptables Firewall?
Because iptables is well documented (and there is also a howto on linuxsecure) I will not go into detail here. I will only show a very small example here that uses connection tracking. The bridged iptables firewall will only let connections from client 192.168.1.52 out (willforward them) but no connections in. See table 3 for details.
Table 3: Configuring the Bridging Iptables Firewall
$ iptables -P FORWARD DROP
$ iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT
$ iptables -A FORWARD -s 192.168.1.52 -m state –state NEW -j ACCEPT
The first line in table 3 configures the default policy. Any traffic, that is not matched by a rule is dropped. The next two lines tell iptables to let only packets in that belong to an existing connection or are related to it. As configured in line 3, new connections can only be established from client 192.168.1.52.
What is an Intrusion Prevention System?
I have already written a few lines about Intrusion Detection System (IDS) here One big point about flexible responses I have made there, is that despite the practicability of flexible responses, it is not fast/reliable enough. So If you want it, then you have to implement IDS with flexible response (or something similar) onto a router. A bridge is very similar to a router. It is a single entry or exit point to a network segment. So all traffic going in or out has to go through it. If you install an Intrusion Detection System on a bridge (or router) and if you configure it in a way, that it will not forward packages identified as containing an attack signature, then you have an Intrusion Prevention System (IPS).
Installing an Intrusion Prevention System
Here, I will show how to install an IPS on a bridge. Installing one on a router is quite the same. First, we have to set up the bridge, as shown above. Then we have to download snort_inline from sourceforge. Then just do
./configure –enable-inline
make
make install
Because snort_inline receives the network packages via iptables, we have to activate userspace queueing in the kernel:
Networking options –> Network packet filtering (replaces ipchains)
Networking options –> IP: Netfilter Configuration –> Userspace queueing via Netlink (EXPERIMENTAL) (NEW)
Then simply recompile, and install your new kernel. Reboot. If you are using modules, then load them!
Configuring an Intrusion Prevention System
The configuration of snort_inline is nearly the same as for snort, exept for the rule types. There are three new rule types, namely drop, reject, and sdrop:
The drop rule will tell iptables to drop the packet and log it via usual snort means.
The recet rule type will tell iptables to drop the packet, log it via usual snort means, and send a TCP reset if the protocol is TCP or an icmp port unreachable if the protocol is UDP.
The sdrop rule type will tell iptables to drop the packet. Nothing is logged.
Now we have to tell iptables to sent all packages going through the bridge to the table QUEUE, so that snort_inline can get them from there. This can be archived with the commands in table 4.
Table 4: Preparing Iptables for Snort_Inline
$ IPTABLES -P FORWARD DROP
$ IPTABLES -A FORWARD -j QUEUE
The first line is not really necessary. The second line configures netfilter to push all packages in the FORWARD chain in to the table QUEUE.
What we have to do now is to change some of the rules in a way, that network packages matching attack signatures are not only detected, but also droped, so that they will never arrive at the target host. For example, we can prohibit packages matching the ICMP PING NMAP signature by simply changing the rule
alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:”ICMP PING NMAP”; dsize: 0; itype: 8; reference:arachnids,162; classtype:attempted-recon; sid:469; rev:1;)
to
drop icmp $EXTERNAL_NET any -> $HOME_NET any (msg:”ICMP PING NMAP”; dsize: 0; itype: 8; reference:arachnids,162; classtype:attempted-recon; sid:469; rev:1;)
Within snort_inline the rule application order has changed, in order to get intrusion prevention functionality. The new rule application order is now:
->activation->dynamic->drop->sdrop->reject->alert->pass->log
To start snort in inline mode, we have to use the new switch Q, meaning, that snort will not receive packages by sniffing on the wire, but via iptables:
snort_inline -QDc /etc/snort_inline/snort.conf -l /var/log/snort_inline
where /var/log/snort_inline is the directory, where snort logs the alerts/drops.
Recent Comments