On this page, I take a look at some common services/protocols/applications (web browsing, email, msn chat, msn messenger, ) to get details on how to apply packet filtering rules for Winroute Firewall. While I was searching the web for additional information, a came across the Guide to firewall configuration, by the Cyberspace Center (University of Hongkong - Science and Technology Department) and found that they already covered everything I was planning, and more, and more detailed. So if you need more info after reading this 'primer'...
Under this heading, Winroute lets you set rules for incoming and outgoing connections. Rules are read top to bottom; if a matching rule is found, it is implemented, and the following rules lower down the list are not checked. You should thus be careful about the order of the rules : don't let a rule further down the list be overruled by a rule higher up unless that's what you need.
Last rule should be 'Deny packets from any host to any host', so that, if no 'allow' rule is found higher up the list, the packet is dropped. That is how you implement "nothing is allowed unless you've permitted it" .
You will probably want to allow certain types of activity : web browsing, email, and so on This can be achieved by allowing outgoing connections to all hosts, but for a specific TCP port, in casu the 'well-known port' for that service : eg web browsing = connect to a web server on port 80, FTP server = port 20 and 21, etc When you end the list with 'TCP : deny all hosts to all hosts', any outgoing connection to another port that those mentioned (80, 20, 21) will be denied.
If your internet provider assigns you a dynamic IP address (and/or dynamically provides addresses of DNS servers etc), you need to allow communication between your ISP's DHCP server and your gateway computer. Although the WAN interface of your router / firewall host may get an IP address shortly after startup, before Winroute starts running, the DHCP lease can expire and will have to be renewed.
DHCP uses broadcast (asking 'who is the DHCP server on this subnet ?') with UDP on ports 67 and 68 (you may need to check this for your own situation, eg by allowing all in- and outcoming packets, log them, and see what communication occurs when you release or renew the DHCP lease).
Permit in- and outgoing UDP packets both to and from ports 67 and 68 to allow dynamic configuration of your router / firewall host.
Strange thing here is that for TCP, UDP and IP to work, you need an IP address, while the purpose of DHCP is to obtain an IP address. So it's all least peculiar that DHCP would have to use TCP/IP. Here's a closer look at DHCP in action.
You may also need to permit a few incoming and outgoing connections to deal with DNS name resolution DNS uses both TCP and UDP to transmit information about addresses and the corresponding IP addresses. TCP is used for communication between DNS servers, UDP for communication with DNS clients. So depending on how DNS is set up on your network, you'll need to apply different rules. See Dealing with DNS
Web servers listen on port 80, so to allow your servers to brows the web you need to permit all outgoing TCP packets to destination port 80, and allow all incoming packets from any address, port 80. You can specify even further, that the incoming packets are allowed 'on an established connection only', thereby denying any external system to set up a connection. You might also set this as a general rule (ie from any port, not just 80).
You can block certain web sites by denying access to their IP address. This rule needs to be set before the more general port 80 rule. You can for instance deny outgoing connections to 240.141.1.128 - port 80, and (in the next line) allow all outgoing TCP to port 80 This would allow web browsing, except to the web site with IP address 240.14.1.128. You can thus block specific web sites without making web browsing totally impossible.
When using a web proxy on the far site of the firewall (eg your ISP's Web Proxy), you only need to to allow TCP between your gateway and the web proxy's address Typically, web servers listen on port 8080, but other port numbers can be used ; check your ISP's documentation In a typical situation, you would allow all TCP packets going to and coming from the ISP web proxy address, port 8080.
If you're running a web proxy on the firewall host, in a DMZ or in your internal LAN, you need to set similar rules to allow this proxy server to communicate with either another proxy server, or directly with the web servers on the internet.
When using email accounts provided by your internet provider, you need to permit communication between your network (gateway) and the provider's POP (Post Office Protocol) and SMTP (Simple Mail Transfer Protocol) servers. For POP, you need both outgoing (connect to the server) and incoming (download mail) packets, to and from the POP server's address, port 110. You can specify again that the incoming packets are only allowed on an established connection. To send mail, you need outgoing to port 25 on the SMTP server's address, and allow incoming from port 25 of this address, established connection only, for your mail client to be able to receive feedback from the server. To the client side (source of outgoing, destination for incoming packets), you can not specify port numbers because a client will use any port above 1023.
If you are running a mail server on your network, you need to enable communication between your mail server and your provider's mail server (SMTP server to relay mail, also POP if the mail is not delivered directly to your server). Rules are similar to those of a client, but can be made more specific, because, as a server, your mail server will use ports 25 and 110, while a client would use any port greater than 1023.
If the mail server is located in the Demilitarized Zone, you need to allow communication between the hosts on your network and the server in the DMZ Rules are similar to email with an external server, but would have to be applied on the interface between internal network and DMZ.
All other applications that involve a connection to a server (eg MSN Chat) can be handled this way. If the service provider is serious, he'll publish documentation about what firewall rules to apply to be able to use his service, or at least give you an IP address and port numbers so you can allow the connection. Others will just say 'sorry, you appear to be behind a firewall, you can't use this service'. As if firewalls are a bad idea and people should be encouraged to get rid of them.
What might help in such a case is the use the service, eg msn chat, from a PC, connected to the internet without any firewall, and monitor the connections that are being set up in the process, eg with the command ' NETSTAT -a 3 '. This will show all connections the PC is involved in, and refresh every 3 seconds. Good chance you'll find the IP address and port number(s) you need.
You may find that for MSN Messenger, you may need to allow TCP out to and in from TCP port 1863 of MSN server (207.46.106.127 ?). Likewise, for Yahoo Messenger : port 5050 on address 216.136.233.151 ? Since you need to sign in and therefore establish the first connection from your network to the Messenger server, you can allow incoming 'on established connection only'.
For additional features it may be necessary to permit more than what's described here. I did not investigate it any further. But you may have a look at the Netmeeting paragraph to get an idea of what else could be involved.
Netmeeting uses multiple TCP and UDP ports to support different features such as program sharing, video conferencing, chat, WhiteBoard, etc. In brief, the basic functionality can be made possible by allowing TCP to and from certain ports, and additional features such as video and audio require UDP to dynamically assigned ports between 1024 and 65535. This means you'd have to allow incoming UDP packets to all ports >= 1024. If you only use netmeeting with specific partners and they have a static IP address, you can limit this rule to those IP addresses and deny the rest.
Microsoft gives a detailed explanation on firewall configuration for Netmeeting
Apart from the UDP issue, netmeeting requires 'secondary' TCP packets to dynamically assigned ports, which again could be any port from 1024 to 65535 I'm nut sure what they mean with 'secondary TCP connections' but if you need it, you might try to allow incoming TCP to those ports 'on established connections' I don't use netmeeting myself, so i have no idea :-)
If you need to communicate with a specific host or hosts outside the firewall, you obviously need to allow communication to these addresses, to the applicable port(s). If these servers need also to initiate connections to hosts on your network, you'll have to specifically allow incoming connections from those hosts. You can set a rule for IP (Internet protocol - network level) to and from specific addresses, or a rule for TCP (transport level) to and from specific addresses and ports.
Winroute lets you make collections of addresses, either by address range, subnet mask etc, or by adding addresses to a group. So you may create groups such as 'trusted servers' or 'DNS servers' or 'My company's Lotus Notes servers' etc and use those groups to implement rules. It can reduce the number of rules you need to set and simplify management - just add or remove addresses from a group to apply the correct rules to that server. Eg you have a network where all users have their own e-mail account with an ISP. Create a group of 'trusted mail servers', allow communication with it, and add the addresses of the ISP's POP servers and SMTP servers to it.
As explained, the safe approach to setting up a firewall is : nothing is allowed unless the administrator allows in, and allow only what is strictly necessary. However, you may find that you need to allow a lot, especially when dealing with networks where users want/need a lot of communication with the outside world (games, video conference, chat, instant messaging, ...). You may also find that some things just won't work because the firewall software is not sophisticated enough to handle the requirements (or the application is not specific enough about what it needs) Netmeeting might be an example.
You may, in such case, decide to set rather loose rules, eg allow everything on ports greater than 1024 Or allow all incoming UDP packets.
When, for some reason, you decide to allow all incoming UDP packets, you should still block (i.e. deny use of) ports 137, 138, 139. These are used by Netbios and are easily exploited, especially on machines with file sharing.
Many trojans are designed to use ports in the higher end - there are many unassigned ports between 1024 and 65535, and all of them can be used. So if you allow that, you expose your network to trojan horse techniques. Blocking ports that are known to be used by trojans will help against existing trojans, not against the new ones. A bit tricky, that ...
Some programs will make direct ('peer to peer') connections to a host (certain chat programs, some file exchange programs such as Kazaa, communication software, ). So either you deny incoming connections so that these applications only work when you start them, or you allow all incoming and outgoing to make sure these things will never fail (bad idea), or you figure out exactly what you need to allow in terms of connections (to and from which addresses and/or to which ports) so that you can configure your firewall accordingly.
Even if you don't allow any external system to set up a connection to a host in your network, an application such as Kazaa can set up an (outgoing) connection. As they say on www.kazaa.com : "All you need to do is install Kazaa Media Desktop (KMD) and it will connect you to other KMD users". If your firewall allows all outgoing connections, you'll get connected to the PC's of other Kazaa users, for them to use as they see fit.
When you've set up all hosts and made all the packet filtering rules to have everything working, have another look at it. You might have quite a list of rules. All of them will be checked for each incoming and outgoing packet. This might reduce the performance of your internet connection a bit.
You may find that you're repeating identical rules for different IP addresses. Check if you can group them, by replacing the IP addresses by collection eg make a group 'trusted DNS servers' and put all the IP addresses of (external) DNS servers you know and trust, in it. You now need only one rule (or 2 : 1 in, 1 out) to filter communication with DNS servers. Likewise for POP and SMTP servers if you have several mail accounts with different providers.
Look at how often you have rules saying 'from any address' or 'to any address'. Ask yourself if it really is 'any address'. Probably you can be more specific. Incoming packets are always coming to your firewall's IP address (except maybe DHCP, this can be a broadcast address). Outgoing packets to your internal LAN should be limited to the address range / subnet mask of your LAN.
For outgoing packets to the internet, you may need to look service by service 'to any address, port 80' can be avoided if you use a web proxy ('to web proxy address, port 8080'). You may consider using proxies for other applications as well. For DNS you can use the firewall's DNS forwarder as a proxy server.
In some of the situations described earlier, you have to allow incoming UDP to all ports from 1024 to 65535. That's a lot of open ports. You may want to limit it, first by specifying the IP address(s) of the server(s) that is/are allowed to use these ports (definitely not 'any IP address' - maybe make a group? ). If not every host on your internal LAN is using Yahoo Voice Call, Netmeeting Video Conference and/or Microsoft Chat, you can specify on the firewall-to-internal LAN - interface that UDP packets to ports > 1023 should only go to the machines that require access to those services.
And so on. Be creative ...
As a final touch, have an other look at the order the rules are in. You can improve performance by putting rules that are likely to occur more often, higher up in the list. That way, they'll be found sooner. This will speed up the firewall because it needs less time to find a matching rule.
However, be careful not to change to order in such a way that you create holes in the firewall. You still need to make sure that a specific 'deny' rule is not overruled by a more general 'allow' rule higher up in the list. Or that a rule 'allow only when establishing a connection' is not overruled by a preceding 'allow always'.
Congratulations, you are now ready to set up your first firewall :-)