Re: Iptables on Redhat 7.3

[Joel Newkirk <netfilter@newkirk.us>]

On Thursday 20 March 2003 10:21 am, Chris Garringer wrote:
> I am implementing iptables on 2 Redhat 7.3 boxes, one a WEB server and
> one a FTP server.  Both are running the latest Redhat kernel for
> 7.3,Linux version 2.4.18-27.7.xsmp.  Both are dual processor boxes.  I
> setup iptables by adding rules to the INPUT chain (single NIC, no
> routing) to accept the connections I wanted, and had a log rule at the
> end to see what made it past the accepts.  Once I was not getting any
> logs I assumed I had written the rules to accept all connections I
> wanted and put a DROP policy in effect for INPUT.  For the WEB server
> it worked, for a while.  For the FTP server as soon as I changed the
> policy iptables --list got REALLY slow.  There are only 10-12 rules,
> iptables --list took 10-15 seconds per line to list them.  Also some

Are you listing with the -n option?  That tells iptables to list with IPs 
instead of resolving to actual host names.  This usually results in 
near-instant rules listings.  The most useful form (IMHO) is

iptables -v -n -L

which lists IPs instead of names, and packet & byte counts that match 
each rule.  By putting the -L last, it is also easier to hit up-arrow, 
and add a chain name.  ("iptables -v -n -L INPUT" for example)

> connections were refused, but not logged (the log rule is still

What exactly IS the log rule?

> there).  Changing the policy to accept fixed the problem.  After a
> reboot the ftp server is working with policy DROP, but after a reboot
> to update the WEB server last night (with policy DROP) sendmail
> stopped working.   There is nothing in the logs from iptables about
> packets getting past the ACCEPT rules for sendmail, but the connection
> is not made (sendmail 8.11.6). Sendmail is in queue mode and should
> make only outgoing connections which have no rules and an ACCEPT
> policy.  When I change the INPUT policy back to ACCEPT sendmail starts
> sending mail to the relay host. What is going on here?  Is changing

Likely you don't have a rule in INPUT to allow return traffic, so full 
2-way connections cannot be established once policy is DROP.  Do you 
have at least something like the following rule in place?

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

This will allow replies back in, without explicitly opening any ports, 
and without necessarily allowing any NEW incoming connections.

> the policy to DROP not a good way to do this?  This is frustrating as
> the logs seem to show everything OK, but the policy change causes
> problems.

The only way a policy can affect anything is if a packet is failing to 
match any effective rules in the chain.  If it matches a LOG rule, it 
will LOG, but still pass to policy at then end if there is not a rule to 
specifically handle that traffic.

If you post your script it would be much more likely that someone here 
could see the problem and offer a solution.  Most people are more 
comfortable if they sanitize the script by removing their public IP.  
(if a static IP is in the rules - of course you sent this message from 
work, but if you send one from home chances are your IP will be trivial 
to discover...)

j