Building an Inline Transparent Bridging Firewall with ebtables (Stealth Firewalls)
|
| As of the 2.6 Linux kernel, the ability to perform advanced bridge mode filtering using ebtables (http://ebtables.sourceforge.net) is supported by default. Patching the kernel or iptables is not required as of the 2.6 Linux kernel. 2.4.x Linux kernel users will first need to patch their kernel from the ebtables website using the ebtables-brnf-5 patch. In addition, the user-space ebtables tool will be required on both kernels to manipulate the filtering rules. In the following documentation we will assume that the system, minimoose, has two ethernet interfaces, eth0 and eth1. This system will be inserted between two networks, 10.10.10.0/8 and 10.10.11.0/8, in such a way as the hosts on either side of these networks are not aware that a firewall has been put in place. This is outlined in Figure 11.3. Figure 11.3. Inline transparent bridging firewall.
After your kernel has been built with ebtables support, you can move on to the next phase, which is to create the bridge interface on the kernel. There is an additional user space tool for this, which is included by most distributions by default, called brctl, which you can find in the bridge-utils rpm on rpm-based distributions (redhat, mandrake, suse, and so on). If you do not have brctl on your system, it is available at http://bridge.sourceforge.net. In our example, we will assume that minimoose, our soon-to-be stealth firewall, has no IP addresses associated with it. This is a perfectly normal configuration for a stealth firewall, and provided you have physical console or serial console access, it is not difficult to maintain. You can, however, assign IP addresses to this firewall, provided you don't mind giving away its existence. If you're attempting to build a truly "stealth" firewall, you do not want this system to have any IP addresses assigned to where the systems on either side of the bridged networks can see the stealth firewall directly. That being saidon to creating our bridged interface... A bridged network involves creating a third logical interface, which is a combination of the two (or more) bridged physical interfaces:
At this point your bridge will be active, and hosts between the two networks will be none-the-wiser. In this example we're splicing the transparent firewall in between two switches. You could, however, just as easily put this system up in between a router and a switch or even between the switch and a single host. This poses all sorts of useful configurations, transparent proxy servers, forensics logging hosts, network diagnostics/monitoring, IDS platforms, and of course "stealth" firewalls. This then brings us to filtering traffic. Outlined in the following section are a few basic recipes for Layer 2 firewalls (this list is by no means complete). Filtering on MAC Address Bound to a Specific IP Address with ebtablesThe first example describes a rule only allowing a specific IP address, 10.10.10.12, to pass through the firewall if it is bound to the MAC address, 00:11:22:33:44:55. This is useful in the case of wireless networks (although not foolproofMAC addresses can be spoofed, too!). $EBTABLES -A FORWARD -p IPv4 --ip-src 10.10.10.12 \ -s ! 00:11:22:33:44:55 -j DROP Filtering Out Specific Ports with ebtablesThe following rule demonstrates a more powerful target in ebtables, the BROUTING policy. The following example shows the ebtables rule being used to only allow port 25 traffic (SMTP) to the host at 10.10.10.12. $EBTABLES -t broute -A BROUTING -p ipv4 \ --ip-dst 10.10.10.12 -ip-proto tcp \ -ip-dport 25 -j ACCEPT $EBTABLES -t broute -A BROUTING -p ipv4 \ --ip-proto tcp --ip-dport 25 -j DROP |
|
- ERP Systems Impact on Organizations
- Context Management of ERP Processes in Virtual Communities
- Data Mining for Business Process Reengineering
- Intrinsic and Contextual Data Quality: The Effect of Media and Personal Involvement
- Relevance and Micro-Relevance for the Professional as Determinants of IT-Diffusion and IT-Use in Healthcare