From SieveFirewall

Contents 1 Introduction 1.1 Copyright 1.2 Disclaimer 1.3 Credits 2 What is Sieve? 2.1 The Name 2.2 Design Goals 2.3 Design Objectives 2.4 =Security 2.5 =Usability 2.6 Components 2.6.1 LEAF 2.6.2 Shorewall 2.6.3 tc 3 How it works 4 Installation 5 Setup 6 Configuration 6.1 Zones 6.2 Filters 6.3 Pipes and rules 7 Using 8 Further Development 9 Advanced Topics 10 =DHCP 10.1 MAC Addresses 11 Troubleshooting 12 More Information 13 Version History

Introduction

Copyright

Disclaimer

Credits

What is Sieve?

The Name

According to WordNet 2.0, a sieve is a strainer for separating lumps from powdered material or grading particles. It's one of those old wire mesh strainers your Grandmother used, but strainer sounded so pedestrian...:)

Design Goals

The idea behind Sieve is to take advantage of the capabilities in Linux netfilter and traffic control from Windows. While there are certainly firewalls that are available that are more polished, more glitzy, and for enough money more powerful, Sieve can provide most any capability those can for free. The primary design requirements were:

All components must be open source and freely distributable, not only to satisfy the design requirements of the competition, but to help "evangelize" FOSS to the Windows community Restrict engineering to functionality not currently available, don't reinvent the wheel. There are many programmers out there better than we are, we're not going to compete with them. We're trying to provide new capabilities with a new focus. Provide all necessary functionality, but focus work on areas where functionality is not already available to Windows, i.e. connection rate limiting and bandwidth control. The best way to attract talent for future development is to interest them in the product. Providing a replacement for a Windows Firewall is not very interesting. Appliance should be as transparent as possible, the server applications and end users should not know it exists As server engineers, we understand the issues with working in an installed base. To be adopted, it must not require significant changes to a running server. Overall feel should be more representative of a Windows application than a Linux one, target environment is Windows administrators. Linux administrators could probably do this without an installer or anything else we're providing. We're not trying to make work easier for Linux people, but to make it possible for Windows people. The point of view of the configuration utilities should be that of a Windows server administrator, not that of a network engineer or Linux administrator Again, we want Windows admins to feel at home. Install should be as streamlined as possible, taking care of as much of the setup as is possible Security should be the primary design goal. Given the short time period and limited resources available for construction of the project, loss of features is preferable to loss of security. If it can't intuitively be guaranteed to be secure, leave it out.

Design Objectives

Goals are nice, and give a direction for the project, but the objectives are what have been used to guide the design and coding process.

=Security

The primary objective from a security standpoint is for the firewall OS and virtual machine to be invisible to the outside world. If nothing can communicate with it while it is running, the difficulty of compromising the firewall increases exponentially. While it seems counterintuitive from the stated goals of the competition, no use will be made of VMWare tools' communications features. Vmxnet network drivers will be used for the network devices, and vmmemctl will also be available and loaded. A simple yet powerful idea from the world of physical Linux firewalls is to have no hard drive and run the OS from CD. This same model will be used in the virtual implementation. No IP address will need to exist within the VM that is routable outside the physical machine.

=Usability

Given that both contributors to this project are engineers in a mid-sized environment, a good deal of thought went into not only the usability from the point of view of a single server administrator, but the point of view of an administrator of hundreds of servers. Several problem issues were encountered when going through this “think big” scenario. An installed server typically already has a static IP address registered in DNS. To avoid downtime associated with propagating a change in IP, the project should not require a change in the host's IP address. Installation of this project should be possible against many servers in the same environment without requiring any changes to the environment. The biggest issue here is to not require externally routable addresses. While many internal networks are NAT-translated private networks, a large address space should not be a requirement.

Components

LEAF

Shorewall

tc

How it works

Please reference the diagram in Appendix A during this discussion.

The basic idea behind Sieve is to put a Linux-based firewall between Windows' physical adapter and the Windows OS. It does this by forcing Windows to use a VMWare virtual adapter for outside communications.

First, TCP/IP is unbound from the physical adapter in Windows that is attached to the outside world. At this point, the host OS is off the network. We then create a Linux virtual machine in which eth0 is bridged to this physical adapter, that can communicate over IP to the outside world.

From this point, the Linux virtual machine looks exactly like a Shorewall bridged firewall running on an external box. Eth0 is the outside interface, eth1 is internal, and they are bridged to create br0. Shorewall then runs on this bridged adapter setup, filtering traffic.

In VMWare terms, eth1 is a host-only adapter, which means it communicates virtually over a host only network to the host's vmnet1 adapter. Vmnet1 cannot see the outside world, only a virtual segment that exists between the host and guest OS. This vmnet1 adapter is then considered to be Window's external adapter, taking the place of the physical adapter.

An incoming packet follows this path into the Windows' host OS:

• • The packet comes in on the physical adapter, and is also available to eth0 in the guest OS since the two are bridged. TCP/IP has been disabled on the host physical adapter, so it is ignored and processed only by the guest's eth0

• • Within the guest OS, Shorewall processes the packet to determine whether or not it should be forwarded. If it is not dropped, it is forwarded on to eth1.

• • Eth1 is bridged to the host's vmnet1, so the processed packet is then processed by the host.

The short version: physical adapter – eth0 – eth1 – vmnet1 – host OS. Only filtered packets are seen by the host OS.

Installation

Setup

Configuration

Zones

Sieve takes the concept of Zones from Shorewall and expands upon it. A zone is a group of computers that you want to control as an administrative unit. Examples of how you may want to group computers:

• • • By department

• • • • ACCT – Accounting

• • • • PUR – Purchasing

• • • • MKT – Marketing

• • • • SAL – Sales

• • • • ADM – Administration

• • • • HR – Human Resources

• • • By function

• • • • SAD – Site administrators

• • • • NOR – Normal users

• • • • EXE – Executive users

• • • • LOW – Low priority users

Once you have your zone list in mind, you create a record for each zone and assign computers to it by IP address. Any IP addresses that do not fall within a zone are in the default zone NET. Using the department example above:

ACCT – 192.168.10.0/24 PUR – 192.168.11.0/24 MKT – 192.168.14.1 – 192.168.14.34 SAL – 172.16.32.0/23

And so on

Filters

Now that we have our zones defined, we will use them to define what traffic we will allow in.

Web Server example Zone ACCT, Protocol TCP, Port 80, inbound, allow Zone PUR, Protocol TCP, Port 80, inbound, allow Zone MKT, Protocol TCP, Port 80, inbound, allow Zone NET, Protocol TCP, Port 80, inbound, allow

Note that if these are the only rules we define, SAL, ADM, and HR zone machines WILL NOT be allowed to see the web site, since what we don't explicitly allow we deny. ACCT, PUR, MKT allow those three zones, and NET allows everything we didn't assign to a zone.

File Server example Zone SAL, Protocol TCP, Port SMB, inbound, allow Zone ADM, Protocol TCP, Port SMB, inbound, allow Zone HR, Protocol TCP, Port SMB, inbound, allow

Notice two things here. First, we used a macro called SMB to add all of the Microsoft file sharing ports as a group. Second, since we didn't add the default NET zone, only these three groups of computers will be able to connect.

Pipes and rules

Pipes allow you to define how you want traffic to flow into and out of your server. The analogy is a water pipe, a smaller diameter pipe will flow less than a larger one. There are a few basic rules to understanding how pipes work and what limitations there are to them.

• • • For a pipe to have any effect on traffic flow, the pipes must be the limiting factor. If a server has a gigabit network card, and all your pipes are set to 1000Mb, they will be useless. A typical server will never have resources competing for that much bandwidth.

• • • Any traffic not assigned to a pipe is restricted to the size of the interface, which can be considered the default pipe. Default traffic is the lowest priority.

• • • Priorities are ordered from low to high, with 0 being the highest priority.

• • • The minimum bandwidth is the bandwidth that the scheduler will try its best to give to this pipe, borrowing from any other pipe that is using more than its minimum.

• • • The maximum bandwidth is the bandwidth that the scheduler will not allow this pipe to exceed, no matter how much is available.

• • • Priorities affect two things in Sieve. First, lower priority packets are always serviced and classified before higher priority packets, so they will experience less delay. Second, when borrowing bandwidth requests from lower priority pipes will be honored first.

• • • Rules simply assign zones to pipes.

Now that some of the rules are out of the way, let's go to the web server example from above. Let's assume this is a marketing website that is used occasionally by other groups. Marketing should be first priority and have all the bandwidth they want, Accounting and Purchasing should be second and have all the bandwidth they want, and all others should be a lower priority and be limited to 512kbits. Our web server is easily capable of pushing 2Mbit so we'll set the interface to 2Mbit first. Then:

Pipes Pipe MKT – Min 50% Max 100% pri 0 Pipe ACCTPUR – Min 50% Max 100% pri 1 Pipe OTHER – Min 512kbit Max 512kbit pri 2

Rules Zone MKT Pipe MKT Zone ACCT Pipe ACCTPUR Zone PUR Pipe ACCTPUR Zone NET Pipe OTHER That's all of the zones that are allowed in, so that's all the pipes and rules we need to define.

Using

Further Development

There are many directions this can take from here. The fundamental problems have been solved of packaging, implementing in a VM, and networking. LEAF is a very powerful idea, and is a very good implementation of that idea. A few of the ideas we kicked around during development but cut due to time constraints are:

• • Snort – With or without snort_inline, snort would be a very powerful addition to Sieve, and will probably be the first one added if we continue development ourselves.
  • Creation of zones from Active Directory groups, allowing the firewalls on many boxes to be managed externally through AD
  • Centralized management system to control multiple firewalls on multiple machines through a single management console
  • Centralized reporting

Advanced Topics

=DHCP

If the Windows host has its address assigned by DHCP, additional precautions must be taken. As far as Windows is concerned, the network interfaces come up normally when the host starts up. However, no traffic will flow to vmnet1 until after the Sieve virtual machine starts, which can take upwards of 30 seconds. Since the network interface is already available but it cannot get a DHCP address, it will assign an automatic address since it assumes the DHCP server is unavailable. To work around this, a registry entry must be added to prevent Windows assigning an APIPA address. This change is documented in Microsoft KB article 244268. It reads in part as follows: 1.Use Registry Editor to create the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 2.Add the following value to this key: Value name: IPAutoconfigurationEnabled Value type: REG_DWORD Value in hexadecimal: 0 (A value of 0 disables APIPA support on this computer) NOTE: If the IPAutoconfigurationEnabled entry is not present, a default value of 1 is assumed, which indicates that APIPA is enabled. 3.After you make this change, restart your computer.

MAC Addresses

The VMWare installations assume that vmnet1, or any host-only interface, will not be visible on the network. Consequently, there is no concern for ensuring that the MAC address is unique. These MAC addresses are typically constructed with the VMWare OUI, 00-50-56, and a unique part of C0-00-0x where x is the interface number. Since we are using vmnet1, our MAC address will be 00-50-56-C0-00-01 for every host we install Sieve on. Obviously this will not work. If you use the Sieve application to modify this, Sieve will default to using the VMWare OUI of 00-50-56 and the last 6 digits of the physical NIC. You will still need to ensure that there are no MAC address duplications with this scenario, but in a typical large server environment where most servers are from the same vendor, this should work fairly well. The registry key to change is located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318} . Under this is a list of interfaces. Find the subkey that corresponds to vmnet1, which will have a REG_SZ value named VMNET that has a value of “\DosDevices\VMnet1”. In this subkey create a REG_SZ value called NetworkAddress and enter the MAC that you wish to use there, no hyphens and no spaces. An acceptable entry would be “005056c01001”, which would set the MAC address to 00-50-56-C0-10-01. Active Directory and Computer Policy As in the issue above with DHCP, a machine in an Active Directory domain must wait for Sieve to start before it can communicate with the domain controllers. Microsoft KB article 840669 describes registry entries required to make the OS wait a predetermined amount of time before deciding that the domain is unavailable.

Troubleshooting

More Information

Tools Used All written documentation was created with OpenOffice 2.0.2 on Microsoft Windows XP. Diagrams were created with Inkscape 0.43, using graphics from OpenClipart 0.18. All Visual Basic code was written in Microsoft Visual Basic Express. Original ideas were born and cultivated in Mike 2.17 and expressed in Kenny 1.89.

Version History