Hi Togan,

I am trying to understand packet filtering and I am lost in what I am reading. Quoting from page 217 of Building Internet firewalls on allowing inbound and outbound SMTP and nothing else as the example.

It says as follows

Rule Direction Source Dest Proto Destport Action ====================================================================== A in Ext Int tcp 25 Permit B out Int Ext tcp >1023 Permit C out Int Ext tcp 25 Permit D in Ext Int tcp >1023 Permit E Either any any any any Deny

You need to understand the tables in the book first. As the enumeration following the tables above in the book, rules A and B apply when you have an internal mail server that accepts SMTP from external networks. Rule A says to permit inbound TCP packets from external sources to port 25 on internal destinations (or one destination in most cases). Rule B allows for the packets flying the other way within one TCP 'session'. You could attempt to apply further qualifiers to the rule outlines in B such as demanding the ACK bit or making it a stateful rule. Rules C and D are necessary when mail is transferred from internal hosts to external servers via SMTP. And rule E specifies to drop anything that isn't handled otherwise. Which combination of rules *you* need depends on your setup. Most private users and SOHO setups don't run an SMTP server that's available to the Internet, their email goes to their ISP, a server of his is specified in the domain's MX record. So they require only rules C and D, but not A and B. They might also use their ISP's SMTP server as a smart host and have their internal mail server be the only internal host sending mail. In a setup like that, 'internal' and 'external' in the rules above equate to 'internal mail server' and 'ISP's mail server' respectively.

Now based on the explanations I came out with this ipchains rule but I am not sure if it it correct or not

IPC=/sbin/ipchains $IPC -P Deny -l $IPC -A in -s Ext -d Int -p tcp --sport 1023: --dport 25 -j ACCEPT $IPC -A out -s Int -d Ext -p tcp --sport 25 --dport 1023: -y -j ACCEPT $IPC -A out -s Int -d Ext -p tcp --sport 1023: --dport 25 -j ACCEPT $IPC -A in -s Ext -d Int -p tcp --sport 25 --dport 1023: -y -j ACCEPT $IPC -b -s 0/0 -d 0/0 -j DENY

Am I on the right track or completely away ?

You're moving in the right direction. Here are the mistakes you're making: * The default policy rule syntax is wrong, as has been pointed out already. It should be: ipchains -P input DENY ; ipchains -P output DENY ; ipchains -P forward DENY or a subset thereof. * The names of the built-in chains are input, output and forward, in and out don't exist. * To specify ports above 1023, use '1024:', not '1023:'. ipchains uses inclusive port ranges. * The last rule won't work, as it doesn't specify a chain. The kernel processes the chains for every packet that enters an interface (input), exits an interface (output) or is moved between interfaces (forward). Note also that the rules above will work when applied on the SMTP server or client respectively, *not* on a packet filter sitting between the internal and external networks, *unless* the default policies for input, output and forward are set to accept. In ipchains (or rather, the kernel code that is configured with ipchains), packets travel in the following manner: Network -> [INPUT] -> [FORWARD] -> [OUTPUT] -> Network | ^ +---> local process-----+ So, any packet entering the box traverses at least the input chain. If the packet needs to go to a different interface than the one it entered on, it goes through the forward chain. If a packet needs to go to the network, it goes through the output chain. So, for a packet filter sitting between two networks, you need to make sure your packets make it through all three chains. Note that this has been modified in the 2.4 kernel packet filtering code, which is configured with the iptables tool. Here, only packets bound to or coming from local processes traverse the input and output chains, while traffic routed by the system only go through the forward chain. This is all disregarding the NAT table, BTW. Hope to have helped a bit, sure to have confused... :-/ Tobias