My Firewall Page - "A Firewall is a concept..."

here you'll find information about some security concepts, some protocols, typical communications, and example rules and rulesets for linux and windows firewalls. (All down at the bottom, there is a small collection of further ressources.)
"Firewall" is the principle of controlling which information gets in and out of your computer/net. Thus it covers several areas where such control can be applied: You can (try to) control which processes and programs are running on your host(s) that generate and propagate information in the first place. You can try to control your Operating Systems behaviour and you can try to control which information is "on the wire". Only this last area is covered by a family of programs called firewalls in turn (although some of them provide functionality in the other areas as well), which sometimes are even running on dedicated machines. And only these programs are covered here... (Although i have a short paragraph about wrappers (see here), which can be best described by the first idea.)
The most basic distinction is the one between Application Gateways (Proxies with security functionality falling into this category) and Packet Filters:

Zum Seitenanfang

Application Gateways

This is the most powerful way of controlling which information is transmitted. Let's first see what generic proxies are:
A generic proxy is a program that is inserted in a communication between sender and recipient, which simply relays the messages and can hardly be used to filter anything.
 
back...

Zum Seitenanfang

Packet Filters

 
back...

Zum Seitenanfang

Wrappers

A Wrapper is a program that hooks into a connection request, and can, based on some decision logic, perform some command - like, in the most simple case, respond to the request. However, mostly the word refers to one special application, Wietse Venema's tcpwrapper (I have to remember to look it up). To understand what this does, you need to know what the inet daemon does first:
Whenever a linux host configured to use the inet daemon (inetd) gets a connection request (i.e. a connection attempt for a service that's supposed to be offered), this is handled by the inetd. This daemon (an alternative to inetd is xinetd, which provides more security features, but is not compatible.) decides which service is meant by the request and only then starts the server. F.ex. you have a host running no service/server except for identd. Then a request comes in on port 80, inetd starts the webserver and hands the request over to it. A request coming in on port 21 would cause identd to start the ftp server. When the connection is done, the server is shut down again and ident remains the only active server. This in itself is a wrapper of some sort.
Now what tcpwrapper does is this: Inetd doesn't start the adequate server, but rather hands the whole thing over to tcpwrapper. This in turn looks into some configuration files (/etc/hosts.allow and /etc/hosts.deny) to decide what to do. It can simply start the adequate (i.e. http, ftp or whatever) server, it can filter on certain hosts and start the server only if it's a legitimate host trying to connect, or it can even perform a shell command (like retrieve some info about the connecting host, deny the connection, don't start any server but send a notification mail to the administrator).
As you can see, a wrapper is a useful additional layer of protection which operates on the host offering some service to the internet. (btw, there are also wrappers that transpose this logic of operation to a different, but in certain respects similar domain: Installation wrappers like InCtrl5 (yes, look up this url, too) are a good example, or you can have a program that starts IE and when IE is done, wipes those temporary files and other garbage created (Radsoft's Extreme Power Tools feature such a wrapper (and this can even be extended): E3...)
 
back...

Zum Seitenanfang

Generic Packet-Filter Ruleset

Now to the issue that started this whole thing off: After looking through many ruleset recommendations and example or default rulesets, i think i have distilled a logic that can be applied to a generic ruleset. Keep in mind that these hints are for a single workstation-computer connected to the Internet - if your setup is different (i.e. if you're offering services, have your comp act as ICS gateway, have a dedicated firewall host, etc.) then of course your setup requires some more work. (And in each step, there are some tweaks to it, so don't forget to see the details below):
  1. Make your default policy drop - for in- and for outbound packets.
  2. Drop all packets that come from impossible sources (your internet IP, localhost, unroutable addresses).
  3. Accept inbound ICMP Types Echo Reply (0), Destination Unreachable (3), Source-Quench (4), TTL exceeded (11), Parameter Problem (12), Timestamp-Reply (14), Address-Mask-Reply (18).
  4. Drop the rest of inbound ICMP packets.
  5. Accept outbound ICMP Types Fragmentation Needed (3/4), Network prohibited (3/9), Host prohibited (3/10), Communication prohibited (3/13).
  6. Drop outbound Echo Reply (0), the rest of the Destination Unreachable (3/*) codes and Time-Exceeded (11) - These are used to traceroute and scan your comp).
  7. Accept the rest of outbound ICMP packets.
  8. Accept UDP packets to and from your nameservers, their port 53.
  9. Reject inbound Ident requests (TCP:113) (Reject meaning to tell that there is no ident service running here, instead of leaving the inquirer hanging in the air without response. See below).
  10. Accept inbound TCP and UDP packets belonging to legitimate connections (stateful firewalls are a great thing here - as is per-application/owner filtering).
  11. Accept outbound ARP request (Opcode 1) broadcasts (to FF:FF:FF:FF:FF:FF).
  12. Accept inbound ARP replies (Opcode 2) from your gateway (find out its MAC address - see below).
  13. Drop the Rest.
  14. Insert some logging logic (and protect it against log flooding) and review your logs regularly.
Obviously finding out which connections are legitimate is a crucial point in this...
 
back...

Zum Seitenanfang

Here's a basic ruleset then:

(This ruleset makes your host (which should not be offering any service to the outside) rather safe from the point of view of packetfilters. The ruleset is stripped of all logging logic (which you should add yourself) and presupposes that the firewall program works its way through them from top to bottom and skips the rest of the rules once it encounters one that matches the packet currently being examined.)
No. Application/Description Allow/Deny/Reject In/Outbound Protocol Source address:Port Destination address:Port ICMP Type/Code Comment LnS Screenshot Kerio Screenshot Sygate Screenshot Outpost Screenshot ZAP Screenshot iptables command
1 Default Policy D I&O All All:All All:All All/All If your firewall has a "policy" setting, you may want to set this, otherwise a "drop" rule should be appended as last rule of your ruleset (see below) n/a n/a n/a n/a n/a 
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
2 Drop impossible sources D I All your Internet IP
192.168.0.0/16
172.16.0.0/12
10.0.0.0/8
224.0.0.0/3
204.152.64.0/23
169.254.0.0/16
127.0.0.0/8
0.0.0.0/8
255.255.255.255/32
192.0.0.0/16
1.0.0.0/24		 All:All All/All see http://security.royans.net/info/articles/nonroutableip.shtml n/a n/a n/a n/a n/a 
iptables -A INPUT -j DROP -s your Internet IP
iptables -A INPUT -j DROP -s 192.168.0.0/16
iptables -A INPUT -j DROP -s 172.16.0.0/12
iptables -A INPUT -j DROP -s 10.0.0.0/8
iptables -A INPUT -j DROP -s 224.0.0.0/3
iptables -A INPUT -j DROP -s 204.152.64.0/23
iptables -A INPUT -j DROP -s 169.254.0.0/16
iptables -A INPUT -j DROP -s 127.0.0.0/8
iptables -A INPUT -j DROP -s 0.0.0.0/8
iptables -A INPUT -j DROP -s 255.255.255.255/32
iptables -A INPUT -j DROP -s 192.0.0.0/16
iptables -A INPUT -j DROP -s 1.0.0.0/24
3 Accept Source-Quench in A I ICMP All localhost 4/. This is an issue of some debate - it has some performance reasons for it, on the other hand it opens a DOS door. Choose your poison ;-) (Log it at least!) n/a n/a n/a n/a n/a 
iptables -A INPUT -j ACCEPT -p icmp --icmp-type source-quench
4 Accept Echo-Reply in A I ICMP All localhost 0/. ... --> n/a n/a n/a n/a 
iptables -A INPUT -j ACCEPT -p icmp --icmp-type echo-reply -m state --state ESTABLISHED,RELATED
5 Accept Destination-Unreachable in A I ICMP All localhost 3/All ... n/a n/a n/a n/a n/a 
iptables -A INPUT -j ACCEPT -p icmp --icmp-type destination-unreachable -m state --state ESTABLISHED,RELATED
6 Accept TTL-Exceeded in A I ICMP All localhost 11/All ... n/a n/a n/a n/a n/a 
iptables -A INPUT -j ACCEPT -p icmp --icmp-type time-exceeded -m state --state ESTABLISHED,RELATED
7 Accept Parameter-Problem in A I ICMP All localhost 12/All ... n/a n/a n/a n/a n/a 
iptables -A INPUT -j ACCEPT -p icmp --icmp-type parameter-problem -m state --state ESTABLISHED,RELATED
8 Accept Timestamp-Reply in A I ICMP All localhost 14/. ... n/a n/a n/a n/a n/a 
iptables -A INPUT -j ACCEPT -p icmp --icmp-type timestamp-reply -m state --state ESTABLISHED,RELATED
9 Accept Address-Mask-Reply in A I ICMP All localhost 18/. ... n/a n/a n/a n/a n/a 
iptables -A INPUT -j ACCEPT -p icmp --icmp-type address-mask-reply -m state --state ESTABLISHED,RELATED
10 Drop the rest of inbound ICMP D I ICMP All localhost All/All ... n/a n/a n/a n/a n/a 
iptables -A INPUT -j DROP -p icmp
11 Accept Fragmentation-Needed out A O ICMP localhost All 3/4 ... n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p icmp --icmp-type fragmentation-needed
12 Accept Network-Prohibited out A O ICMP localhost All 3/9 ... n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p icmp --icmp-type network-prohibited
13 Accept Host-Prohibited out A O ICMP localhost All 3/10 ... n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p icmp --icmp-type host-prohibited
14 Accept Communication-Prohibited out A O ICMP localhost All 3/13 ... n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p icmp --icmp-type communication-prohibited
15 Drop TTL-Exceeded out D O ICMP localhost All 11/All this can be used for tracerouting your comp or hosts behind it. n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j DROP -p icmp --icmp-type time-exceeded
16 Drop TTL-Exceeded out D O ICMP localhost All 11/All this can be used for tracerouting your comp or hosts behind it. n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j DROP -p icmp --icmp-type time-exceeded
17 Drop Echo-Reply out D O ICMP localhost All 0/. used for pinging/tracerouting your comp. n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j DROP -p icmp --icmp-type echo-reply
18 Drop the rest of Destination Unreachable out D O ICMP localhost All 3/All (except 4,9,10,13 allowed above) used for tracerouting (scanning) your comp. n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j DROP -p icmp --icmp-type destination-unreachable
19 Accept the Rest of ICMP out A O ICMP localhost All All/All ... n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p icmp -m state --state NEW,ESTABLISHED,RELATED
20 Accept DNS A I&O UDP dns.isp.com:53 localhost:1024-65535 ./. get your isp's dns and use it/them here. (See below on how to do this.) n/a n/a n/a n/a n/a 
iptables -A INPUT -j ACCEPT -p udp -s dns1.isp.com --sport 53 --dport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
iptables -A OUTPUT -j ACCEPT -p udp -d dns1.isp.com --dport 53
21 Time Synchronisation/NTP client A I&O UDP ntp.server.com:123 localhost:1024-65535 ./. If you insist on getting your time from the internet (which opens possibilities to some "replay" attacks), you should use ntp to synch and configure explicitly three different servers. n/a n/a n/a n/a n/a 
iptables -A INPUT -j ACCEPT -p udp -s ntp1.isp1.com --sport 123 --dport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
iptables -A OUTPUT -j ACCEPT -p udp -d ntp1.isp1.com --dport 123
iptables -A INPUT -j ACCEPT -p udp -s ntp2.somewhere.org --sport 123 --dport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
iptables -A OUTPUT -j ACCEPT -p udp -d ntp2.somewhere.orgom --dport 123
iptables -A INPUT -j ACCEPT -p udp -s ntp3.bla.com --sport 123 --dport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
iptables -A OUTPUT -j ACCEPT -p udp -d ntp3.bla.com --dport 123
22 ICQ A I&O UDP localhost:1024-65535 All:5190 ./. If you want ICQ, you have to open up somewhat big holes... n/a n/a n/a n/a n/a 
iptables -A INPUT -j ACCEPT -p udp --sport 5190  -m state --state NEW,ESTABLISHED,RELATED
iptables -A OUTPUT -j ACCEPT -p udp --dport 5190
23 Drop the rest of UDP D I&O UDP All:All All:All ./. maybe you prefer to rely on your default policy to have these dropped, maybe you want to set it explicitly. n/a n/a n/a n/a n/a 
iptables -A INPUT -j DROP -p udp
iptables -a OUTPUT -j DROP -p udp
24 POP/Mail Client A O TCP localhost:1024-65535 pop.isp.com:110 ./. restrict this to the servers you get your mail from (if you use POP, that is. Otherwise you don't need this rule at all.). n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p tcp -d pop.isp.com --dport 110 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
25 IMAP/Mail Client A O TCP localhost:1024-65535 imap.isp.com:143 ./. Restrict this to your IMAP server(s) (if you use IMAP, that is. Otherwise you don't need this rule at all.). n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p tcp -d imap.isp.com --dport 143 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
26 SMTP/Mail Client A O TCP localhost:1024-65535 smtp.isp.com:25 ./. Restrict this to your outgoing mail server (or some relay ;-). If you're running your own smtp server, restrict it to All:25. n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p tcp -d smtp.isp.com --dport 25 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
27 Browser (http only) A O TCP localhost:1024-65535 All:80 ./. You can try to restrict this to remote port 80, although some http connections use port redirections to other ports. Maybe you want to add ports (also so that your browser may use ftp (21) and nntp (119))... n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p tcp --dport 80 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
iptables -A OUTPUT -j ACCEPT -p tcp -m multiport --destination-port 80,443,119,21,3128,8070,8080 -m state --state NEW,RELATED,ESTABLISHED
28 Browser (shttp) A O TCP localhost:1024-65535 All:443 ./. Secure http connections almost always use port 443, so it should be okay to restrict this. On the other hand, you may want to have a single browser rule, then remember to include port 443 in that other (port 80 etc.) one. I, for one, have a rule to allow IE shttp but nothing else (my online banking co. requires damn IE but i don't trust it (IE) very much...) n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p tcp --dport 443 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
29 Browser (using proxies) A O TCP localhost:1024-65535 ProxyIP:ProxyPort ./. Maybe you want to use a local or remote proxy on your browsing sessions (Actually, this is pretty advisable - see above). Then you can restrict your browser to access only your proxy (common ports are 3128,1080 and in the 8000-8888 range) - and if it's a local proxy, allow it to access those remote ports that a browser normally needs access to (80,21,119). You may also chain proxies - allow your browser to access only the first proxy, allow this one only to access the second one and the second one to access all sorts of external ports... (How about a cache-adfilter-anonymizing proxy cascade? ;-P) n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p tcp -d localhost --dport 3128 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
iptables -A OUTPUT -j ACCEPT -p tcp -d proxy.isp.com --dport 8080 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
30 FTP-Client/Browser (ftp out) A O TCP localhost:1024-65535 All:21 ./. As you can see from ftp being split into two rules, ftp is a tricky issue. This has mainly to do with ftp using a dedicated connection for dataflow control. You have to think about restricting servers, client applications, using passive ftp, using a stateful inspection firewall etc. Otherwise you open up huge holes. See below for details on ftp. n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p tcp --dport 21 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
31 FTP-Client/Browser (ftp in) A I TCP All:All localhost:20 ./. Also see the previous rule and below for details on ftp. n/a n/a n/a n/a n/a 
iptables -A INPUT -j ACCEPT -p tcp --dport 20 -m state --state ESTABLISHED  ! --syn
32 Newsreader A O TCP localhost:1024-65535 nntpserver.isp.com:119 ./. You can restrict this to the newsserver(s) you're using. n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p tcp -d nntpserver.isp.com --dport 119 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
33 SSH-Client A O TCP localhost:1024-65535 All:22 ./. SSH is a recured version of telnet. (passwords don't travel unencrypted etc.) If you can, try to use ssh instead of telnet, you might even use ssh's port-forwarding to secure e.g. our pop connection. If you want to offer remote access to your own machine, never use telnetd, always use sshd (and check for security patches/vulnerabilities)! n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p tcp --dport 22 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
34 Telnet-Client A O TCP localhost:1024-65535 All:23 ./. Telnet gives you a shell access to a remote machine. Remember that it is not very secure and try to use ssh instead, if possible. Remember that it's not only insofar as it can be used to hack into hosts offering telnet service, but also insofar as you as a client also may send your own security-relevant info (passwords!) unencrypted over the internet. (See previous rule for ssh.) n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p tcp --dport 23 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
35 IRC A O TCP localhost:1024-65535 irc.ircnetwork.com:6667 ./. If you use primarily a single or a handful of irc servers, try to restrict your ruleset to this/these. If not, use All:6667. (Remember that there are so-called "bots", that silently and secretly connect to some hard-coded irc server, join a certain channel and wait for their coder to come there and give them orders on what to do. Maybe you can make their job a little harder by restricting your irc servers - as well as by restricting irc to your irc client... An interesting coverage of this bot stuff can be found at grc.com.) n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p tcp -d irc.ircnetwork.com --dport 6667 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
36 IRC-DCC/IRC-Client (ddc out) A O TCP localhost:7701-7800 All:All ./. IRC features an ftp of sorts. There's a server and a client part to each dcc connection - with every client supporting dcc running a server (warning lights should start blinking here). On clients that support it, configure listening and outbound ports so that you can restrict your firewall rules. I have my client configured to listen on 7700 (see next rule) and to use 7701-7800 for its outbound connections. Since you don't know from the outset how other people have their clients configured, you can't restrict much on the remote side of the connections... IPTables also has some irc connection tracking but i am not sure how much this covers... n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p tcp --sport 7701:7800 -m state --state NEW,ESTABLISHED,RELATED
37 IRC-DCC/IRC-Client (ddc in) A I TCP All:All localhost:7700 ./. This is the server (listening) part of DDC. See the previous rule for some more talk about DCC. This rule example also presupposes the client to be configured to listen on port 7700. n/a n/a n/a n/a n/a 
iptables -A INPUT -j ACCEPT -p tcp -d localhost --dport 7700 -m state --state NEW,ESTABLISHED,RELATED
38 Finger A O TCP localhost:1024-65535 All:79 ./. The Finger protocol allows you to find out if a certain email adress is valid. There are not very much servers offering finger services, but here's how you allow outbound finger requests. n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p tcp --dport 79 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
39 WhoIs A O TCP localhost:1024-65535 All:43 ./. The Whois/Nicname protocol allows you to find out registration information about domains. Some traceroute programs use it for example. And of course you can also use it manually. Here's how you allow outbound whois requests. n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p tcp --dport 43 --sport 1024:65535 -m state --state NEW,ESTABLISHED,RELATED
40 Ident R I TCP All:All localhost:113 ./. Reject Ident requests so your mail reacts faster. If your IRC servers won't let you in, then accept it (maybe make different rules for mailserver reject / ircserver accept behaviour). (See below.) n/a n/a n/a n/a n/a 
iptables -A INPUT -j REJECT -p tcp --dport 113 --syn --reject-with tcp-reset
iptables -A INPUT -j ACCEPT -p tcp -s irc.ircnetwork.com --dport 113 --syn
41 Accept ARP requests out A O ARP localhost's MAC address FF:FF:FF:FF:FF:FF ./. Accept localhost (winipconfig.exe (ifconfig on linux) is the command you can use to learn about localhost's MAC addy...) to send out ARP request (OpCode 1) broadcasts to its own subnet (that's the ff:ff:ff:ff:ff:ff). Actually both the ff:ff:etc. and the IP address specify it to be an arp request subnet broadcast. n/a n/a n/a n/a n/a 
iptables -A OUTPUT -j ACCEPT -p arp -m mac --mac-source 66:55:44:33:22:11
42 Accept ARP replies in A I ARP gateway's mac address localhost ./. Accept ARP replies (OpCode 2) from your gateway (see below). n/a n/a n/a n/a n/a 
iptables -A INPUT -j ACCEPT -p arp -m mac --mac-source 11:22:33:44:55:66
43 Termination Rule D I&O All All:All All:All ./. Drop anything that was not matched yet... n/a n/a n/a n/a n/a 
iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP
99 Complete Ruleset Samples - - - - - - Here you can find sample rulesets for the different firewall programs. Sometimes they're just screenshots, sometimes, textfiles, sometimes complete pages... Look'n'Stop Kerio Sygate Outpost ZAP IPTables

Zum Seitenanfang

What's the difference between DROP and REJECT, or: What is STEALTH?

Normally the TCP protocol definition specifies that when someone connects to your computer on some port that no service is running on, the TCP stack is supposed to tell the connecting host so (ICMP 3/3 - destination/port unreachable). Some malicious hacker may use this to learn about which machines/IP's are online - she just would have to scan a subnet trying to connect on any port and machines responding either way (agreeing to the handshake or telling "port unreachable") are of course online. This has lead people to think it advantageous not to reply anything to these "invalid" connection attempts. While such a behaviour is not completely conform to protocol specifications, someone scanning your IP address and not getting any reply at all wouldn't even know if there is a machine associated to this address, even less if you're currently online. This is what came to be called "STEALTH" (a term coined by Steve Gibson from grc.com). Firewalls who almost all adopt this behaviour refer to their action as simply "DROPPING", "DENYING" or "BLOCKING" the request without any further actions or notifications.
On the other hand, there are some drawbacks with this behaviour - even apart from its not being protocol compliant - and they pertain to the IDENT service (which uses port 113) :
  1. SMTP (sendmail) servers very often use to ask connecting machines "who's there?" and they do so not only by password etc. but also by querying a dedicated service on the connecting machine. If the machine is running an ident server, it will reply with the account name that initiated the smtp connection, if not, the smtp server probably will continue anyway. BUT... it will continue no sooner than it's sure that there is or will be no ident reply coming - either being notified (port unreachable) that there is no such service offered on the connecting machine or seeing the ident request simply time out. In the latter case, depending on the timeout value, it will take a considerable amount of idle time until your message gets sent. Mainly for this reason some (not all) firewalls also provide a "REJECT" action which mirrors protocol compliant failure notification (you could also specify to reject with a TCP RESET packet instead of ICMP).
  2. Most IRC servers also query the ident service of connecting machines. To make matters worse, most of them won't let you in until they get a valid ident response. Here the REJECT option won't help much. Many irc clients have a built-in ident server (like mIRC (i have yet to look up the url), for example, which can switch the server off once it's logged onto irc...). If you want to do IRC, you have to find out if your favourite irc server requires you to run an ident server and how to cope with it.
A final word about protocol compliance and "stealth": There is a lengthy discussion about this and i haven't made up even my own mind: On the one hand it's somewhat suspicious trying to connect to hosts on ports that they don't have a listening service on - as said above, scanners may thus learn about the mere existence of an online host and then launch a dedicated attack (that's why IMHO the argument that goes "if there's no way to get in on that specific port, nothing harmful can happen when you reject a connection on it (either by firewall or by tcp/ip stack)" is not completely valid.
But on the other hand, if there is a protocol compliant router upstream of your host, this router already would notify the scanner if there were no machine online on the requested IP addy (The codes 0 (host unreachable), 1 (net unreachable), 6 (host unknown), and 7 (net unknown) of ICMP type 3 (destination unreachable) can be used to do this (although right now i don't know which one the router would use to comply to specifications - i will look it up). So again, the scanner would know which IP addresses represent online hosts: Those that either agree to the handshake, or reject the connection or simply time out without the routers in between seeing anything worthy of their intervention. In short all that don't raise some upstream router icmp "destination unreachable" message. And all the stealth would be lost.
On the other hand then again, not all routers are completely compliant and why not try it....
 
back...

Zum Seitenanfang

How to get your Nameserver's IP address:

On windows hosts, you can use the winipconfig.exe command to learn about your nameserver's IP.
On Unix hosts, you use the ifconfig command.
You can of course always ask your isp or try to find out something on its homepage.
 
back...

Zum Seitenanfang

How to get your gateway's MAC address:

Explanation of IP vs. MAC layer?
(winipconfig.exe (ifconfig on linux) is the command you can use to learn about localhost's MAC addy...)
"arp -a" is the command you enter on a commandline (DOS Prompt/console) to have your arp cache listed. In the arp cache your comp maintains a list of IP/MAC address pairs it knows about. So when you type "arp -a" at the beginning of your session there will be no entries at all. Even if you simply connect to the internet there will be no entry at all yet. But once you connect to any device on your net, an entry will be generated. Normally there will be entries for some TCP/IP host in your LAN with its MAC addy, maybe an entry for a firewall host with its MAC addy, maybe one for a Network-Printer with another MAC addy, and finally one - this is the important one - for IP adresses external to your LAN (or several entries, each one with the same MAC addy), with the gateway's MAC address. Some seconds ago i tried it out on my comp and my arp cache had entries for my name server, my onlinebanking site and my ISP's mailserver - each of them with their respective IP address and with one and the same MAC address. That's the adress we're after (Packets get sent to the Interface with that MAC and the host on the other end reckognizes that although the packets are adressed to it, they contain IP packets that are adressed to some other place and it forwards them).
 
So, i'd suggest you do the following:

 
back...

Zum Seitenanfang

What is "Stateful Packet Inspection"?

Stateful inspection means that your firewall keeps track of what connection is in which state. Thus it can tell if a reset command received belongs to an established connection that is supposed to be reset or if it's simply an invalid packet not belonging to any connection at all - maybe sent to you in order to generate some chaos or even a reply from which to gain information about your host. If i got this right, this was first used in unix/linux firewalls and is now starting to be used in windows programs as well. The current linux firewall netfilter/iptables knows several types of packets depending on the state of current connections: NEW, ESTABLISHED, RELATED and INVALID.
A NEW packet is one that tries to establish a connection and that is suitable for this role, i.e. it does bear a SYN flag and no other flags that might contradict this SYN, has valid fields in general etc.
An ESTABLISHED packet is a packet being part of a connection that has seen packets in both directions. (The third part of a three-way handshake is already an "established" packet.)
A RELATED packet is a packet generated in relation to an "established" connection but not exactly belonging to it, e.g. an icmp error message.
INVALID packets are packets that contain wrong or wrongly formatted header information, refer to non-existant connections etc.
In addition to this "simple" stateful inspection, there is so-called "connection-tracking": Certain protocols (esp. ftp and irc) occasionally open new connections. Of course it is good to know if the new connection is opened on behalf of a legitimate existing communication or not. The problem is that there is no way to specify which of these "secondary" (my term) communications are legitimate and which aren't since their characteristics are negotiated in a flexible handshake in the "primary" communication and vary each time. Connection-Tracking now means that your firewall "eavesdrops" your primary connection and listens for signs of such a handshake. Once one is encountered, it knows which characteristics to expect from the to-be-opened connection. In ftp connections, also new connections (speaking in tcp terms) thus sometimes actually "belong" to an already established connection and can be considered of ESTABLISHED state (speaking in firewall terms now).
 
back...

Zum Seitenanfang

What's so special about ftp connections?

There are two basic mechanisms in ftp, called active and passive. Normally, you'd do "active" ftp, which is the following:
The client connects to the server on port 21. This connection (XY <-> 21) is called the tcp control connection. only commands, directory listings etc. are transferred there. The actual data is transferred on the tcp data connection. Whether a tcp connection is active or passive depends on who initiates the data connection (from the perspective of the server). So if it's the server that actively connects to some port on your (the client's) computer, then it's an active ftp session, if the server is just waiting for the client to connect a second time, then it's a passive session.
There are two caveats:
  1. There is a standardized port (20) for ftp data connections, but the negotiation of the ftp data connection is somewhat complicated (in an active session, the server needs a way to know to what port to connect to, i.e. on which port the ftp client is listening. It binds its own outgoing connection to its port 20 alright, but how should it know on which port the client expects the incoming connection? and how is the client to tell that an incoming connection from some port 20 to its listening port YZ belongs to the ftp session already active on the control channel XY<->21? Or maybe server and client both use port 20, but can we (and the ftp communication) rely on this? (Actually all this is negotiated in the ftp control channel, of course, so basically the involved parties don't have much problems that the protocol doesn't take care of. But...)).
  2. How is the firewall to determine and eventually permit all this? Good firewalls deny all incoming connection attempts, at least all that they don't know are related to some exactly defined legitimate server process on the firewalled host. Now this (active) ftp data connection is not so exactly defined, since it is the client that acts as a sort-of-server, only on some port that is not predictable for the firewall.
There are also two strategies to deal with these caveats:
  1. The firewall eavesdrops the ftp control communications and learns what port(s) the data channel will use. Allowing the already connected (on the ftp control channel) server to connect with the negotiated values (port, packet's "serial number" or whatever) is then simple, the eavesdropping/listening/learning is the difficult part. AFAIK only commercial firewalls and linux iptables firewalls currently support this. Also see above.
  2. Use passive ftp. With this, the client is the one that is initiating the connection and most of the firewalls permit outgoing connection attempts to any port. I am not so sure if port 20 plays any role in passive ftp connections as well. But what about a firewall on the server host? Maybe you could do some research...? Or i will look it up one day.
  3. Actually there is a third, somewhat quick-and-dirty way of dealing with this with firewalls that don't support connection tracking (and ftp tracking in particular) but which support defining ports-per-app rules. With these firewalls, you could allow any connection coming in to any port that "belongs to" your ftp client. This is a security hole of sorts, but the risk of other people than the ftp server you're just dealing with connecting to that single, arbitrary port that the client just now listens on for an ftp data connection in just the time that your ftp client is active is very low - for home users who are not using their ftp client for hours.

 
back...

Zum Seitenanfang

Per-Application Packet-Filtering

(Note that this is not what you'd call an Application Gateway. (See above.))
This is supposed to mean that on each packet you can specify the application generating it or listening for it and restrict your rule to that single application. E.g. you can allow Opera to browse the internet, but not IE. On windows hosts there is a technology behind it that is a little complicated (you have to insert different firewall modules in different places in windows tcp/ip stack and try to infer which connections are the same in these different places), so not all firewalls support it and not all that do, do it in the same way. I am very much in favor of this and of restricting your rulesets to single applications.
On linux hosts, per-application-filtering is complicated but possible. I haven't yet seen anyone doing it, but here's how one should do it: Maybe i will find time to work on this - when i have a solution i'll post it here...
 
back...

Zum Seitenanfang

Web Ressources (Mostly Linux):

iptables ressources

Comparison of IPTables Automation Tools (from April 2001): http://online.securityfocus.com/infocus/1410
LinuxGuruz IPTables Portal: http://www.linuxguruz.org/iptables/
Linux Firewall and Security Site: http://www.linux-firewall-tools.com/linux/
Gnome IPTables GUI and ruleset compilers: http://www.fwbuilder.org/
LinuxSecurity Article: http://www.linuxsecurity.com/feature_stories/feature_story-93.html

SuSE Security Team:

Marc Heuse: http://www.suse.de/~marc/ (check here for SuSEfirewall2)
Thomas Biege: http://www.suse.de/~thomas/
Roman Drahtmüller: http://www.suse.de/~draht/
Sebastian Krahmer: - SuSE's own security page: http://www.suse.de/security
SuSE's security announcements: http://www.suse.com/us/support/security/index.html
SuSE's updates, patches, bugfixes: http://www.suse.com/us/support/download/updates/index.html
SuSE's *german* HowTo's and FAQ's: http://www.suse.de/de/support/howto/index.html

German Linux Sites - with focus on beginners and security

Ipchains firewall setup: http://www2.little-idiot.de/firewall/
Marc Heuse's description on setting up a secure webserver: http://www.suse.de/de/support/howto/secure_webserv/index.html
SuSE 7.1 installation diary: http://www.ag-intra.net/linux-suse71.html
German linux portal: http://www.pro-linux.de/
Linux beginners site: http://www.ag-intra.net/linux.html

Good Books (you know, the paper ones):

General Security Books:
Thomas Biege's Bookshelf: http://www.suse.de/~thomas/book-reviews/index.html
Hacker's Guide: german and english
 
On Firewalls:
Einrichten von Internet Firewalls (Zwicky, Elizabeth D.; Cooper, Simon; Chapman, Brent)
Firewalls und Sicherheit im Internet (Cheswick, William R.; Bellovin, Steven M., 1996)
 
On TCP/IP:
TCP/IP Illustrated Vol. 1-3 (Rich Stevens) THE TCP/IP Bible - rather expensive, but excellent (rather for programmers, however).
Internetworking with TCP/IP Vol. 1-3 (Doug Comer) Another (?) Bible. Similar cost, also a good book.