VOICE Home Page: http://www.os2voice.org
[Newsletter Index]
[Previous Page] [Next Page]
[Feature Index]
|
VOICE Home Page: http://www.os2voice.org |
February 2003
[Newsletter Index]
|
| By Doug Bissett© February 2003 |
A guide to creating a Quick and Dirty Firewall, using the support included in the later versions of IBM's TCP/IP packages for OS/2, and eComStation (basically TCP/IP 4.1 and above).
Okay, there has been a lot of discussion about what you need, and what you don't need, to create an effective firewall. Here are my ideas on how to go about getting started. I make no claims that this will work for everybody. The end result will be a NON-SECURE system, until YOU change it so that it is secure. Use your own discretion about using these instructions. I will make no attempt to explain what some of these things do. You can see:
http://www.os2.spb.ru/guru/tcpip/ipsece.htmlwhere you will find more information, and detail.and
Be aware, that these instructions are ONLY for the user who has no idea about
where to begin, and they are NOT suitable for someone who is running a server. It
might be a place to start, if you are careful about what you are doing.
USE THESE INSTRUCTIONS AT YOUR OWN RISK!
1) First, you need a basic set of rules, to get you started. Edit, or create,
the file
<boot_drive>:\MPTN\ETC\SECURITY\FWFILTRS.CNF
and change the contents to:
(just one line).
This rule permits ALL traffic, both in and out, so be aware that this is effectively the same thing as running without a firewall. I use this rule because it enables logging, and it will allow your system to work the same as if there were no firewall. It should still work, without any problems. We will build more rules, and eliminate this one, later.
2) Next, you need a file
<boot_drive>:\MPTN\ETC\FWLOG.CNF
which should contain the logging level desired Put the single line:
in it.
And, you need a file
<boot_drive>:\MPTN\ETC\FWSECAD.CNF
which should contain a list of any secure interfaces on your system (those interfaces
that it is impossible for an outsider to access). In my case, the only two interfaces,
that I have, are my normal interface, that is connected to the outside world, and
the software loopback address (127.0.0.1). I assume that 127.0.0.1 is secure, because
it is not supposed to ever allow traffic in, or out, of the local machine (I may
be wrong). [Editor note: 127.0.0.1 is not inherently secure, but that it usually
shouldn't pose any problem.] So, I have a single line in this file:
3) Then, you need to be sure that you have all of the appropriate drivers etc. loaded. You should find the following lines in your CONFIG.SYS, and, of course, the files to go with them (if you don't have the files, you, likely, don't have the firewall support installed):
DEVICE=<boot_drive>:\MPTN\PROTOCOL\IPSEC.SYS
DEVICE=<boot_drive>:\MPTN\PROTOCOL\FWIP.SYS
DEVICE=<boot_drive>:\MPTN\PROTOCOL\CDMF.SYS
DEVICE=<boot_drive>:\MPTN\PROTOCOL\MD5.SYS
4) Then, you need to actually get the firewall program started, with logging enabled. To do that, edit (or create) <boot_drive>:\TCPIP\BIN\TCPEXIT.CMD and add the following three lines:
That will start the firewall, then start the logging program, then enable the firewall, with the appropriate options.
Reboot.
At this point, you are NOT PROTECTED, in any way, but you can look at the logs, to see what is happening.
5) Okay, now that you have the firewall started, and logging is enabled, you need to be able to look at the log. The logging program creates a file with the name FWmmdd (where mm is the month, and dd is the day), in the <boot_drive>:\MPTN\ETC directory. "Easy", you say. Well, not quite. The current day log is locked by the logging program (older logs are not locked), and looking at it with an editor, like the system editor, won't tell you much anyway. There is a program, that is designed to display the logs. It is a command line program, and you can use it by going to an OS/2 Command Prompt, switching to the <boot_drive>:\MPTN\ETC directory, and typing
(where mm is the month, and dd is the day, of the log you want to look at, including the current day). Run the program, with no parameters, for other options.
The first thing that you will realize, is that there is far too much data there, and you need to study each different type of log, to learn how to read the information. I am not even going to try to teach that, but I will help you build a couple of new rules, that should cut down on the number, and type, of logs.
6) Creating rules is more of an art, than a science. To help you do that, I suggest getting a program called ZAMPA. This program comes as part of eComStation, but it can be obtained from:
http://www.mo.himolde.no/~ltning/os2/index.htm
WARNING: Even the author admits that this program has some deficiencies. I find it useful to help to edit the rules, but I recommend not using it for anything else.
Okay, the first thing we want to do, is eliminate some of the logging of "normal" traffic. This traffic is stuff that you want to happen, so that you can work on the Internet. Well, you can either make a rule, permitting each specific action, or, you can make some general, all encompassing rules. (The rule that is already in place is of the latter type). Okay, one approach, is to allow all traffic, that has the TCP/ACK flag turned on. This should only be the case, when some web server is sending you data, that you have actually requested. That should be pretty safe, and that should account for most of the legitimate incoming traffic. So, open ZAMPA, and you should see the one rule, that permits everything, in the list. Select that, and click Change rule, and you should see the basic rule, that allows EVERYTHING, formatted in the editor. Don't change that one, just inspect it, and click cancel. Now, click Add rule, and you should see a default rule, that will deny everything. That is, in fact, the default rule, if no other rule matches a situation, so you don't really need to define that. Okay, so we want to allow all incoming traffic, as long as the TCP/ACK flag is active. Select the following (leave anything, not mentioned, as default):
Permit (this rule will permit the defined actions)You can change the Destination address, and Netmask, IF you have a fixed IP address (if you don't know, you probably don't, so just leave it alone, for now - all zeros means allow any address). Okay, save that (Add). Now, you need to realize, that these rules are checked, from the top of the list, to the bottom. The first rule that specifically allows, or denies, the traffic is the one that is used, and that is the end of the check. So, now you have a rule that says allow everything, then one that restricts what is allowed. Well, it might be a good idea to move the one that restricts activity, to a position where it will be checked, before the one that allows everything. Highlight the new rule (it was added at the end), and click Move up (when there are more rules, you need to move it to the position where you want it). For the moment, keep the rule that allows everything at the end.
Logging disabled (we don't need to log this)
TCP/ACK packets (applies to packets with TCP/ACK set)
Non-secure (applies only to the Non-secure interface)
Inbound (applies only to traffic coming to you)
Next, save the changes, by clicking the Write Config button. Then (IMPORTANT), click the Start/update button to activate the new config file.
We still have a firewall, that allows EVERYTHING, so you are still not secure, but what we have done, is eliminate the logging for legitimate incoming traffic (well, a lot of it anyway).
Okay, if you look at the log, you will still see a tremendous amount of junk, so, we will build a couple of new rules, to allow legitimate traffic, but not log it. Back to ZAMPA, and create some new rules:
Now, since we will, eventually, remove the rule that allows everything, we had better make a rule that allows us to send anything to the internet.
PermitClick Add, and move it up.
Logging disabled
Any protocol
Non-secure
Outbound
You want to have access to Domain Name Servers (DNS):
PermitClick Add, and move it up. The destination port, greater than 49152, is suggested, because OS/2 uses ports above that value.
Logging disabled
UDP packets
Source port equals 53
Destination port greater than 49152
Non-secure
Inbound
The following rule is not really required, since you have allowed ALL outbound traffic, but I will include it as an example of doing specific outbound rules:
PermitAdd, move it up.
Logging disabled
UDP packets
Source port greater than 49152
Destination port equals 53
Non-secure
Outbound
Okay, that is enough, for now. Click Write config, and Start/update.
Now, you still have a NON-SECURE system, but the logs should be small enough for you to sort out what needs to be addressed. There will be some other rules required, to make your system secure, but I am going to leave that up to you to figure out. Once you get the log, so that it only shows the traffic that you think should be blocked, create a rule that will deny everything (this is actually the default), with logging enabled, and move it ahead of the rule that allows everything. After you activate that set of rules, you should have a reasonably secure system. Perhaps too secure, and something won't work. If that happens, look at the logs, to see what is being denied, that you may need to permit. Then, create a new rule to allow that. If you need to use the blocked program, just move the Permit All rule ahead of the Deny All rule, and do what needs to be done, then, figure it out when you have some time. Be sure to move the Deny All back ahead of the Permit All rule, after you finish with the affected program. You can remove both of these rules, once you get the firewall working properly. Deny all is the default, if no other rule is matched.
Well, you are far from finished with this project, but, as long as you have the Deny All rule ahead of the Permit All rule, your system is a lot safer than it was before you started. I also suggest, that you will, generally, want to place any "deny" rules, ahead of any "permit rules", but there may be reasons to do it the other way. REMEMBER, the rules are checked, from the top of the list, and the first rule that specifically allows, or denies the traffic, is the one that prevails. Think through what you are doing, step by step, to see what the rules will do with individual packets of data.
I recommend, that you err on the side of being too secure, when you create rules. Better to have a rule that may need to be relaxed somewhat to make it work properly, than to have one that is too wide open (a couple of the ones, above, may be to be too wide open). If something doesn't work, check the logs, and that activity should be obvious (but don't forget that something may not be working for other reasons). After a while, you will figure out how to read the log, and determine what should be allowed, while you laugh at the attempts to access your system, that did not work. You may want to enable logging, for individual rules, to be sure that they are doing what you think they should be doing, but that is part of the ongoing project.
As an interesting exercise, go to https://grc.com/x/ne.dll?bh0bkyd2 to see what the outside world thinks about your system. (READ the information about what that site will attempt to do, and what you might see in your logs, when it tests things). There is also a reference to, what seems to be, a good firewall, for windows, as well (more important than for OS/2).
OKAY, you now have a basic firewall, and you have some clues about how to tweak it up, so that it works better. Are you safe? Well, that depends on what you are permitting (the rules, that I have outlined above, MAY NOT BE CORRECT, but they seem to be working, for me), and what the hackers are doing to break into your system. There may be some unknown security holes in the OS/2 system, and in the firewall, but it is unlikely, that a hacker will even recognize that you are running OS/2, and that, in itself, helps to protect you. All I can say, is that it appears that this simple setup does stop most (if not all) of the unwanted internet traffic. By adding more rules, you can eliminate the logging of unwanted traffic, but be sure that you really want to eliminate it.
You can also eliminate the rule that permits all outgoing traffic, and make specific rules for that, as well, but that will be a lot more work, and may not be required, in most cases.
You can get some clues about what the different ports are used for, by inspecting the file <boot_drive>:\MPTN\ETC\SERVICES, but you may need to ask, in the news groups, if you don't understand something. One "rule" about rules. Don't permit something, unless you are reasonably sure that you need it, to make something work. It may be a good idea, to make some rules, to deny certain things, just to cut down on the number of log entries, but that is something that you can experiment with (HINT: look for incoming access requests to ports 137, 138, and 139, but I suspect that this is normal, IF, and only IF, you are using an internal network, using NETBIOS over TCPIP - NOT recommended anyway, but that is what windows defaults to, in most cases).
If you are wondering who is trying to access your system, you can use the HOST command, and/or get the WHOIS package (it is at HOBBES), but I would recommend holding off on trying to get them to stop. I suspect that a lot of the activity is caused by viruses, and the person "responsible", may not even know what is happening. You also run the risk of being targeted by worse things, if the person doing it decides to do that. It is best to just think "Well, that one didn't get me", and leave it at that.
References:
|
[Feature Index]
editor@os2voice.org
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: http://www.os2voice.org