/* ==================================================================== Zampa eComStation firewalling made easy! ==================================================================== */ Contents: - Introduction - Who is this for? - Software requirements - Installation - Setting up a firewall - Included sample rule sets - Words of caution - Known bugs/limitations - Closing up ------------ Introduction Back to top For quite a while now, it has been known to many that somewhere inside the new 32-bit TCP/IP stack of OS/2 and eComStation, there is a firewall. It has been a well-kept secret, however, how to configure and use it. Through studying IBM rebooks and a lot of trial and failure, it was possible to figure out how the firewall works and how to configure it. While I believe it to still be a lot of things about it still unknown, it has come to a point where what IS known is worth being put to some use. Thus, I decided to write this application to make peoples life easier. ------------ Who is this for? Back to top This program is for anyone running eComStation who wants to protect themselves or their business from hackers and other mean heads out there. It is also ideal for people who are using their computer as a gateway to the internet, if they wish to keep unwanted traffic out. ------------ Software requirements Back to top To use this cute piece of software you'll need to do the following: - MPTS v5.x or above (comes with TCP/IP 4.1 and above) - The following line in your config.sys: DEVICE=C:\MPTN\PROTOCOL\FWIP.SYS This line is automagically added if you select VPN support during TCP/IP installation. - VROBJ.DLL - can be downloaded from hobbes: ftp://hobbes.nmsu.edu/pub/os2/dev/rexx/vrobj21d.zip or http://hobbes.nmsu.edu/pub/os2/dev/rexx/vrobj21d.zip Make sure this file is located in a directory in your libpath. It should be included in the eComStation distribution. ------------ Installation Back to top The installation script INSTALL.CMD can be run to install Zampa if you choose not to deploy it using WiseMachine. In any case, there will be a folder on your desktop named Zampa, and your CONFIG.SYS might have been modified. In this case, you'll have to reboot before the firewall will work. When you have created a set of rules you want to use permanently, you can create a shadow of the "start firewall" object in your startup folder. This will make sure the firewall and, if used, ip forwarding and synattack protection will be started every time you boot. ------------ Setting up a firewall Back to top The rules you define in the firewall are always read from the top and down. That means, whenever a packet comes in or goes out, it's compared to each and every one of the current firewall rules, starting from the top. If it finds a rule that matches the packet in question, that packets action (deny or permit) is applied to it, and it's again ready for the next packet. It no rule is found, it reaches the end of the firewall configuration file, and applies the default rule, which is "deny all". That means that if you set up the firewall with no rules, no packets will be allowed to or from your computer on any interface. You will be defining two sets of rules: one for the interface(s) defined as secure, and one for interface(s) defined as non-secure. The secure interface is typically the one connected to the local network, while the insecure is the one connected to the internet (or another untrusted network). The idea is that you define a set of rules that apply to traffic flowing through each of the adapters (or set of adapters), and how traffic going between them is treated. Ofcourse you can also define rules that apply to all interfaces. In addition, you are able to define rules depending on if the traffic in question has the firewall machine as destination, if it's going through the firewall machine (gateway operation), or both. Available options include: Packet action (permit or deny) Defines what to do with packets matching this rule Source address definition (IP address and netmask) Defines what is to be the source address of matching packets. Can be either a specific IP, or a whole net/subnet. Destination address definition (IP address and netmask) Same as above. Protocol matching Defines which protocols the rule applies to (all, tcp, udp, icmp, tcp/ack, IBM IPSP) Source port/ICMP type Source port of the packet, or the ICMP type for ICMP packets Destination port/ICMP code Destination of the packet, or the ICMP code for ICMP packets Adapter Which adapter the packet is going through (secure, non-secure, or any) Routing Wether or not the packets are going through the firewall machine, or only to/from the firewall machine itself. (local, route, both) Direction Which way the packet are flowing (inbound, outbound, both) Logging Wether or not this rule should be logged. Default for permit rules is no, for deny rules it's yes. (l=yes, y, no, n) Fragmentation Determines if the filter should act on the whole packet only (default), only the packet headers and every fragment of the pack, or if it should match both fragments, headers AND the packet as a whole. (f=yes, no, only) Tunnel ID Identifies the tunnel the traffic is flowing through. (t=x, x is any tunnel ID) All of these options except the tunnel ID can be specified when creating a rule in Zampa. For the normal simple use, the fragmentation parameter may also be left with the default value. Logging can be specified if you wish, but currently I don't have routines built-in to read/analyze the logs, although I'm looking into adding functionality for this in a future release. You will also define at least one of your interfaces as secure, if not, they will all default to be non-secure. This has (as far as I know) no effect on how the firewall acts, but you will either have to specify non-secure or both in the interface field. When you create a rule, it will show up at the end of the rule list. You will then have to change it's position in the list before saving the configuration and updating the running firewall configuration. --- Summary: When creating a rule, keep in mind the following logic: The rules are read top-down, until a rule that maches the packet in question is found. At this point the rule action is performed on the packet. If no rule is found, it uses the default rule, which denies everything. ------------ Included sample rule sets Back to top Three sample rulesets are included in this distribution of Zampa. I hope they will be of some help and guidance. Please remember that the IP addresses in these files are fictive, you have to change them to suit your needs. Addresses/netmasks used in samples: 10.10.10.10 - Firewall PC external IP (insecure) 192.168.1.1 - Firewall PC internal IP (secure) Remember that when specifying a single host, the netmask is always 255.255.255.255. Sample1.Z This file contains a set of rules that will protect your machine from most outside traffic. It will also prevent others from pinging you. The impact on your ability to use internet services is minimal with this ruleset. Rule 1: Action: permit Source IP: 10.10.10.10 Netmask: 255.255.255.255 Destination IP: 0.0.0.0 Netmask: 0.0.0.0 Protocols: All Source port: Any 0 (any port) Destination port: Any 0 (any port) Adapters: Both Routing: Local Direction: Both Fragmentation: Nonfrag only Explanation: This rule allows your machine to access any external resource without other limitations than those put in place by rules limiting incoming traffic. Rule 2: Action: permit Source IP: 0.0.0.0 Netmask: 0.0.0.0 Destination IP: 10.10.10.10 Netmask: 255.255.255.255 Protocols: TCP/ACK Source port: Any 0 (any port) Destination port: Any 0 (any port) Adapters: Both Routing: Local Direction: Both Fragmentation: Nonfrag only Explanation: This rule allows any incoming package that has the ACK bit set. This means that any outgoing TCP connection you make will be allowed to be "returned". However, TCP connections initiated from the outside will not be allowed. Rule 3: Action: permit Source IP: 0.0.0.0 Netmask: 0.0.0.0 Destination IP: 10.10.10.10 Netmask: 255.255.255.255 Protocols: TCP Source port: Any 0 (any port) Destination port: Equals 21 (ftp) Adapters: Both Routing: Local Direction: Both Fragmentation: Nonfrag only Explanation: This rule allows incoming connections to port 21 on your machine, that is, your FTP server (if any). If you don't run a FTP server, or don't want everybody to be able to access it, remove this rule, or change the source IP/Netmasks to match trusted hosts you want to be able to connect. Rule 4: Action: permit Source IP: 0.0.0.0 Netmask: 0.0.0.0 Destination IP: 10.10.10.10 Netmask: 255.255.255.255 Protocols: TCP Source port: Any 0 (any port) Destination port: Equals 23 (telnet) Adapters: Both Routing: Local Direction: Both Fragmentation: Nonfrag only Explanation: This rule allows incoming connections to port 23 on your machine, that is, your TELNET server (if any). If you don't run a TELNET server, or don't want everybody to be able to access it, remove this rule, or change the source IP/Netmasks to match trusted hosts you want to be able to connect. Rule 5: Action: permit Source IP: 0.0.0.0 Netmask: 0.0.0.0 Destination IP: 10.10.10.10 Netmask: 255.255.255.255 Protocols: UDP Source port: Equals 4000 Destination port: Any 0 (any port) Adapters: Both Routing: Local Direction: Both Fragmentation: Nonfrag only Explanation: This rule allows ICQ servers to communicate with your computer via UDP, port 4000. It is required to be able to connect to ICQ servers. Rule 6: Action: permit Source IP: 0.0.0.0 Netmask: 0.0.0.0 Destination IP: 10.10.10.10 Netmask: 255.255.255.255 Protocols: ICMP ICMP Type: Equals 0 (Echo reply) ICMP Code: Any 0 (any code) Adapters: Both Routing: Local Direction: Both Fragmentation: Nonfrag only Explanation: This rule allows external hosts to send ping replies to you. Through the first rule in the list, you allowed any kind of traffic going OUT from your machine, including PING requests. Note that by only allowing ping replies to get in, you effectively prevent others from being able to ping you. Rule 7: Action: permit Source IP: 0.0.0.0 Netmask: 0.0.0.0 Destination IP: 10.10.10.10 Netmask: 255.255.255.255 Protocols: TCP Source port: Any 0 (any code) Destination port: Greater or Equal to 32768 Adapters: Both Routing: Local Direction: Both Fragmentation: Nonfrag only Explanation: This rule allows incoming TCP connections in the port range 32768 and above. This is a "Dirty Hack" to make IRC DCC requests through. Without this, you will not be able to send files or initiate DCC CHAT sessions. Rule 8: Action: permit Source IP: 0.0.0.0 Netmask: 0.0.0.0 Destination IP: 10.10.10.10 Netmask: 255.255.255.255 Protocols: UDP Source port: Equals 53 (DNS) Destination port: Any 0 (any code) Adapters: Both Routing: Local Direction: Both Fragmentation: Nonfrag only Explanation: This rule allows DNS servers to reply to you. This is essential to be able to use the Internet. Rule 9: Action: permit Source IP: 0.0.0.0 Netmask: 0.0.0.0 Destination IP: 10.10.10.10 Netmask: 255.255.255.255 Protocols: UDB Source port: Equals 53 (DNS) Destination port: Any 0 (any code) Adapters: Both Routing: Local Direction: Both Fragmentation: Nonfrag only Explanation: Same as above, but for UDP packets. Some DNS servers use UDP, some TCP. Sample2.Z This file can be used on any machine that is exclusively used as an internet gateway, with some third-party application (like InJoy dialer or firewall) doing Network Address Translation (NAT). It will not allow any connections from the inside network directly to the gateway, but will allow any traffic to flow out through it. Rule 1: Action: permit Source IP: 0.0.0.0 Netmask: 0.0.0.0 Destination IP: 0.0.0.0 Netmask: 0.0.0.0 Protocols: All Source port: Any 0 (any port) Destination port: Any 0 (any port) Adapters: Secure Routing: Through Direction: Both Fragmentation: Nonfrag only Explanation: This rule allows any machine connected to your secure interface to use your machine as a gateway. Rule 2: Action: permit Source IP: 0.0.0.0 Netmask: 0.0.0.0 Destination IP: 0.0.0.0 Netmask: 0.0.0.0 Protocols: All Source port: Any 0 (any port) Destination port: Any 0 (any port) Adapters: Insecure Routing: Both Direction: Both Fragmentation: Nonfrag only Explanation: This rule allows any machine on the internet respond to connections made by machines on your internal network. Sample3.Z The last sample is for gateways that do NOT use NAT, that is, they are "real" internet gateways. It includes total hiding of the gateway itself. Rule 1: Action: permit Source IP: 0.0.0.0 Netmask: 0.0.0.0 Destination IP: 0.0.0.0 Netmask: 0.0.0.0 Protocols: All Source port: Any 0 (any port) Destination port: Any 0 (any port) Adapters: Both Routing: Through Direction: Both Fragmentation: Nonfrag only Explanation: This is the only rule needed to accomplish what we want. It allows any traffic that wants to be routed through the machine, while the "default" rule (the one that applies to all packets not matched by any rule in the configuration file) blocks everything else. ------------ Words of precaution Back to top This software is still beta. And since the firewall is not at all documented from IBM, I have to assume that they do not provide support for it either. This means that the quality of the product can't be determined either. I believe that it is good, on par with the AIX firewall, but ofcourse I can not document this or guarantee it. As with all software of this kind, it's always a good idea to back up vital parts of your system before using this software. As they say, real men don't take backups. But they cry a lot. ------------ Known bugs/limitations Back to top There is still a few quirks to come around in this program, but since it's still a beta, I expect to get these fixed by the time it goes out of beta. I expect this space to be filled as I get more feedback from users.. ;) ------------ Closing up Back to top Send bugs/suggestions/comments to: ltning@anduin Please include the word "Zampa" in the subject, just to make sure I read the mail ;-) -- ADD ALL THE USUAL DISCLAIMERS HERE -- |