Antony, When I originally had the problem, I thought I could make a difference by where I placed the rule. My method was full manual operation. iptables-save >file; edit file; iptables -F; iptables-restore < file.
However, later on that same evening I could not reproduce the 'solution'; now none of my added rules worked no matter where I put them. I struggled with it for a few days then went to 1.2.6a I just tried the -I option and it worked fine. I'm confused. I never used to use -I, always -A and it worked without a hitch. Is this different due to 1.2.6a? (i'm logged in via ssh, I verified a host was pingable, DROPped that host, no more ping replies received, even though I checked the host from here and it's up) I usually check for established connections via netstat. However, please explain where the "connection tracking table" is located. Also, could this explain why even though I 'neaten up my rules' before reloading, they seem to be in the 'out-of-order state' they're in now upon save? I'm still a bit rattled from all my chasing around on this. If I get home and the -I doesn't work, the first thing I'm gonna do is SSH to work, jump on another machine and SSH back (Irrelvant I'm sure, but If it works then I'll probably go bonkers ;-} ) Thanks for the help. Here's the basic ruleset: # Generated by iptables-save v1.2.6a on Wed May 15 18:41:51 2002 *mangle :PREROUTING ACCEPT [6217838:1612907814] :OUTPUT ACCEPT [6014921:1150719896] COMMIT # Completed on Wed May 15 18:41:51 2002 # Generated by iptables-save v1.2.6a on Wed May 15 18:41:51 2002 *nat :PREROUTING ACCEPT [55226:3602256] :POSTROUTING ACCEPT [274252:18928852] :OUTPUT ACCEPT [311462:21408214] -A POSTROUTING -o eth0 -j MASQUERADE COMMIT # Completed on Wed May 15 18:41:51 2002 # Generated by iptables-save v1.2.6a on Wed May 15 18:41:51 2002 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [1669309:646398474] :INT_IN - [0:0] :INT_OUT - [0:0] :PUB_IN - [0:0] :PUB_OUT - [0:0] -A INPUT -d 127.0.0.0/255.0.0.0 -i ! lo -p tcp -j DROP -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -f -j DROP -A INPUT -i lo -j ACCEPT -A INPUT -s 224.0.0.0/240.0.0.0 -j DROP -A INPUT -i eth1 -j INT_IN -A INPUT -i eth0 -j PUB_IN -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth1 -j ACCEPT -A OUTPUT -o eth1 -j INT_OUT -A OUTPUT -o eth0 -j PUB_OUT -A INT_IN -p tcp -m tcp --dport 80 -j ACCEPT -A INT_IN -p tcp -m tcp --dport 901 -j ACCEPT -A INT_IN -p tcp -m tcp --dport 443 -j ACCEPT -A INT_IN -p tcp -m tcp --dport 22 -j ACCEPT -A INT_IN -p icmp -j ACCEPT -A INT_IN -j DROP -A INT_IN -p tcp -m tcp --dport 53 -j ACCEPT -A INT_IN -p udp -m udp --dport 53 -j ACCEPT -A INT_IN -p tcp -m tcp --dport 143 -j ACCEPT -A INT_OUT -p icmp -j ACCEPT -A INT_OUT -j ACCEPT -A PUB_IN -p icmp -j DROP -A PUB_IN -p tcp -m tcp --dport 80 -j ACCEPT -A PUB_IN -p tcp -m tcp --dport 443 -j ACCEPT -A PUB_IN -p tcp -m tcp --dport 22 -j ACCEPT -A PUB_IN -p tcp -m state --state INVALID,NEW -m tcp --dport 23 -m limit --limit 5/sec --limit-burst 8 -j LOG --log-prefix "audit" -A PUB_IN -p tcp -m state --state INVALID,NEW -m tcp --dport 21 -m limit --limit 5/sec --limit-burst 8 -j LOG --log-prefix "audit" -A PUB_IN -p tcp -m state --state INVALID,NEW -m tcp --dport 143 -m limit --limit 5/sec --limit-burst 8 -j LOG --log-prefix "audit" -A PUB_IN -p tcp -m state --state INVALID,NEW -m tcp --dport 110 -m limit --limit 5/sec --limit-burst 8 -j LOG --log-prefix "audit" -A PUB_IN -p tcp -m state --state INVALID,NEW -m tcp --dport 79 -m limit --limit 5/sec --limit-burst 8 -j LOG --log-prefix "audit" -A PUB_IN -p tcp -m state --state INVALID,NEW -m tcp --dport 111 -m limit --limit 5/sec --limit-burst 8 -j LOG --log-prefix "audit" -A PUB_IN -p tcp -m state --state INVALID,NEW -m tcp --dport 512 -m limit --limit 5/sec --limit-burst 8 -j LOG --log-prefix "audit" -A PUB_IN -p tcp -m state --state INVALID,NEW -m tcp --dport 513 -m limit --limit 5/sec --limit-burst 8 -j LOG --log-prefix "audit" -A PUB_IN -p tcp -m state --state INVALID,NEW -m tcp --dport 22 -m limit --limit 5/sec --limit-burst 8 -j LOG --log-prefix "audit" -A PUB_IN -p udp -m state --state INVALID,NEW -m udp --dport 31337 -m limit --limit 5/sec --limit-burst 8 -j LOG --log-prefix "audit" -A PUB_IN -j DROP -A PUB_OUT -j ACCEPT COMMIT # Completed on Wed May 15 18:41:51 2002 ----- Original Message ----- From: "Antony Stone" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, May 15, 2002 6:11 PM Subject: Re: Odd Behavior with 2.4.86mdk & 1.2.2, 1.2.6a > On Thursday 16 May 2002 12:00 am, Ron Gedye wrote: > > > Hello Folks! > > > > What happens now is that my basic rules > > for closing ports, logging SYN's, dropping icmp, inside-outside GW/NAT/MASQ > > etc. works great. But any additional rules I want to apply HAVE NO EFFECT, > > even after clearing the 1800 or so rules and 'starting over'. > > I've looked at the URL you posted for LinuxQuestions.org, and you seemed to > say there that "you had just the basic rules" and then to block a bad IP > address you used iptables -A INPUT -s aaa.bbb.ccc.ddd -j DROP, and the > packets still kept coming in on your log files. > > > Two things occur to me here: > > 1. If you do not delete the connection tracking table, any ESTABLISHED > connections will still be able to get in on that rule (I assume you have one > - I couldn't find any listing of what your 'basic' ruleset was) even if you > have some later rule which blocks specific addresses. > > 2. If you're seeing an entry in your logfile, you must have a LOG rule, and > if you're adding a DROP rule with -A to append it at the end of the ruleset, > it will naturally come after the LOG rule, therefore the packet is still > going to get logged whether or not your new rule DROPs it. > > > For both these reasons I recommend you *insert* (not append) rules such as > iptables -I INPUT -s aaa.bbb.ccc.ddd -j DROP so they go in at the very > beginning of the ruleset, before any logging and before any connection state > matching such as ESTABLISHED. > > > If this doesn't fix the problem post your full basic ruleset here and tell us > a specific problem with it and someone will likely help. > > > > Antony. > >
