I'm not 100% sure about your specific problem, but why are you using so many "quicks" in your ruleset? Keep in mind that it is a last matching rule order, you don't need a quick for every rule. Also, do you specifically *not* want to keep state on inbound connections? I'm a bit confused about your actual question.
I would think, though, that these rules would be a bit more successful (note: these are only barebones, i also recommend looking into 'block in quick all with short' and such): #------SNIP------# pass in quick on lo0 all #local loopback #you seem to want to deny SSH from this IP: block in log quick proto tcp/udp from a.b.c.d to any port = 22 block in all #default to deny block return-icmp (3) in log proto tcp from any to any port = 80 flags S keep state keep frags pass in on hme0 proto tcp from any to x.x.x.x/32 port = 22 pass out on hme0 all pass out on hme0 proto tcp from any to any flags S keep state keep frags #------SNIP-----# I hope this helps. Also, anyone feel free to criticize those rules, I make no claims of being an ipfilter guru. -Jim Keller http://www.centerfuse.net ----- Original Message ----- From: "Yiming Gong" <[EMAIL PROTECTED]> To: "'IPFilter (mailing list)'" <[EMAIL PROTECTED]> Sent: Friday, December 06, 2002 11:03 PM Subject: keep state question > Hi all, > > I am a ipfilter user, today when i reread the document "ip filter based > firewalls howto" i find something puzzled me. In this document,the > author wrote: > ----snip---- > "State is pretty handy, but it��s also a bit tricky. You can shoot > yourself in the foot in strange and mysterious ways. Consider the > following ruleset: > > pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 23 > pass out quick on tun0 proto tcp from any to any keep state > block in quick all > block out quick all > > At first glance, this seems to be a good setup. We allow incoming > sessions to port 23, and outgoing sessions anywhere. Naturally packets > going to port 23 will have reply packets, but the ruleset is setup in > such a way that the pass out rule will generate a state entry and > everything will work perfectly. At least, you��d think so. > The unfortunate truth is that after 60 seconds of idle time the state > entry will be closed (as opposed to > the normal 5 days). This is because the state tracker never saw the > original SYN packet destined to port 23,it only saw the SYN ACK. IPF > is very good about following TCP sessions from start to finish, but it�� > s not very good about coming into the middle of a connection, so > rewrite the rule to look like this: > > pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 23 keep > state > pass out quick on tun0 proto tcp from any to any keep state > block in quick all > block out quick all" > ----snip---- > > Ok, I really think the concept is quite good. So i gonna have a test on > my solaris 2.7 box with ipfilter 3.4.30 installed, my ipf.conf is like > this > > block return-icmp (3) in log quick proto tcp from any to any port = 80 > block in log quick proto tcp/udp from a.b.c.d to any port = 22 > pass in quick on hme0 proto tcp from any to x.x.x.x/32 port = 22 > pass out quick on hme0 proto tcp from any to any keep state > block in quick all > block out quick all > > when i ssh x.x.x.x from a client y.y.y.y using this config, i was > astonished to notice that the connection is in "4/4" manner! and now > the idle time is 5 days. > > below is the output of "ipftables -t" > > nms - IP Filter: v3.4.30 - state top > 10:37:54 > > Src = 0.0.0.0 Dest = 0.0.0.0 Proto = any Sorted by = # bytes > > Source IP Destination IP ST PR #pkts #bytes > ttl > > x.x.x.x,22 y.y.y.y,32931 4/4 tcp 32 5324 > 119:58:31 > > and below is a part of "ipmon -a" command output > > 07/12/2002 11:32:00.939096 hme0 @0:3 p y.y.y.y,32931 -> x.x.x.x,22 PR > tcp len 20 60 -S IN > 07/12/2002 11:32:00.939282 hme0 @0:1 p x.x.x.x,22 -> y.y.y.y,32931 PR > tcp len 20 64 -AS K-S OUT > 07/12/2002 11:32:00.939495 hme0 @0:3 p y.y.y.y,32931 -> x.x.x.x,22 PR > tcp len 20 52 -A IN > 07/12/2002 11:32:00.954671 hme0 @0:1 p x.x.x.x,22 -> y.y.y.y,32931 PR > tcp len 20 75 -AP K-S OUT > 07/12/2002 11:32:00.954864 hme0 @0:3 p y.y.y.y,32931 -> x.x.x.x,22 PR > tcp len 20 52 -A IN > 07/12/2002 11:32:00.954991 hme0 @0:3 p y.y.y.y,32931 -> x.x.x.x,22 PR > tcp len 20 74 -AP IN > 07/12/2002 11:32:00.955033 hme0 @0:1 p x.x.x.x,22 -> y.y.y.y,32931 PR > tcp len 20 52 -A K-S OUT > 07/12/2002 11:32:00.955477 hme0 @0:1 p y.y.y.y,32931 -> x.x.x.x,22 PR > tcp len 20 588 -AP K-S IN > 07/12/2002 11:32:00.960599 hme0 @0:1 p x.x.x.x,22 -> y.y.y.y,32931 PR > tcp len 20 588 -AP K-S OUT > 07/12/2002 11:32:00.998472 hme0 @0:1 p y.y.y.y,32931 -> x.x.x.x,22 PR > tcp len 20 52 -A K-S IN > 07/12/2002 11:32:01.053009 hme0 @0:1 p x.x.x.x,22 -> y.y.y.y,32931 PR > tcp len 20 52 -A K-S OUT > 07/12/2002 11:32:01.053213 hme0 @0:1 p y.y.y.y,32931 -> x.x.x.x,22 PR > tcp len 20 76 -AP K-S IN > 07/12/2002 11:32:00.939274 STATE:NEW x.x.x.x,22 -> y.y.y.y,32931 PR tcp > 07/12/2002 11:32:01.060155 hme0 @0:1 p x.x.x.x,22 -> y.y.y.y,32931 PR > tcp len 20 332 -AP K-S OUT > 07/12/2002 11:32:01.060386 hme0 @0:1 p y.y.y.y,32931 -> x.x.x.x,22 PR > tcp len 20 52 -A K-S IN > 07/12/2002 11:32:01.077661 hme0 @0:1 p y.y.y.y,32931 -> x.x.x.x,22 PR > tcp len 20 324 -AP K-S IN > 07/12/2002 11:32:01.193016 hme0 @0:1 p x.x.x.x,22 -> y.y.y.y,32931 PR > tcp len 20 52 -A K-S OUT > 07/12/2002 11:32:01.272056 hme0 @0:1 p x.x.x.x,22 -> y.y.y.y,32931 PR > tcp len 20 644 -AP K-S OUT > > I noticed the state on the seventh packet has been "established" and > from this packet,all the communication are using output policy @0:1 > which keep state the established connection without checking the input > policy anymore. > > I don't know what's wrong, so anybody can tell me the reason? > > TIA! > > -- > ��Ҫ���õ����� > > > > Yiming Gong > Senior System Administrator > China Netcom > [EMAIL PROTECTED] > http://security.zz.ha.cn > 0086-371-7934907 > >
