Weblog

All | China | Cricket | General | IPFilter | OpenSolaris | Solaris IPFilter | USA vs.... | Zones
« Modern pollution in... | Main | DNS proxy for IPFilt... »
20070610 Sunday June 10, 2007

IPFilter 4.1.23

In the never ending quest for perfection and chasing platform changes, this latest update fixes some bugs that are new and some that are old.

I've also added this extra line to "ipfstat -s" output:

        82% hash efficiency

The routing header problem is perhaps the most serious from a security perspective - if you weren't (or aren't) blocking these packets explicitly, e.g

block in quick with v6hdrs routing

then the presence of the routing header would cause ipf to not find the next (TCP/UDP) header in the correct place. A regression test (ipv6.5) has been added to check for dealing with IPv6 routing header packets.

Darren


4.1.23 - Released 31 May 2007

4.1.22 - Released 13 May 2007

  • fix endless loop when flushing state/NAT by idle time
  • 4.1.21 - Released 12 May 2007

    4.1.20 - Released 30 April 2007

    4.1.19 - Released 22 February 2007

    4.1.18 - Released 18 February 2007

    4.1.17 - Released 20 January 2007

    4.1.16 - Released 20 December 2006

    4.1.15 - Released 03 November 2006

    ( Jun 10 2007, 11:29:55 PM PDT ) Permalink Comments [2]

    Trackback URL: http://blogs.sun.com/avalon/entry/ipfilter_4_1_23
    Comments:

    When will this get into solaris? This bug:

    some TCP state steps when closing do not update timeouts, leading to them being removed prematurely.

    Looks like it could be bug 6563892 which would be excellent to have fixed.

    Posted by Chris Gerhard on June 11, 2007 at 02:49 AM PDT #

    I'm using ipf 4.1.10 on Solaris 9, and have a problem that the same connection (with 2 same IPs and 2 same port numbers) can not be established for the second time, right after the first connection is closed. Here's the ipf rules: # Rule to block ICMP type 17 messages (Address mask requests) block in log quick proto icmp icmp-type maskreq # Rule to block any TCP packet for which the SYN flag is not alone # or that doesn't have a state pass in log quick proto tcp flags S keep state keep frags pass out log quick proto tcp flags S keep state keep frags block return-rst in log quick proto tcp block return-rst out log quick proto tcp Here's the ipf log (IPs are changed for privacy) Jul 25 16:41:47 aps17 ipmon[249]: 16:41:46.969448 uplink0 @0:1 p 192.168.10.17,2428 -> 192.168.20.42,2424 PR tcp len 20 64 -S K-S K-F OUT Jul 25 16:41:47 aps17 ipmon[249]: 16:41:46.970418 uplink0 @0:1 p 192.168.20.42,2424 -> 192.168.10.17,2428 PR tcp len 20 64 -AS K-S K-F IN Jul 25 16:41:47 aps17 ipmon[249]: 16:41:46.970546 uplink0 @0:1 p 192.168.10.17,2428 -> 192.168.20.42,2424 PR tcp len 20 52 -A K-S K-F OUT Jul 25 16:41:47 aps17 ipmon[249]: 16:41:47.031519 uplink0 @0:1 p 192.168.10.17,2428 -> 192.168.20.42,2424 PR tcp len 20 80 -AP K-S K-F OUT Jul 25 16:41:47 aps17 ipmon[249]: 16:41:47.032836 uplink0 @0:1 p 192.168.20.42,2424 -> 192.168.10.17,2428 PR tcp len 20 52 -A K-S K-F IN Jul 25 16:41:47 aps17 ipmon[249]: 16:41:47.033330 uplink0 @0:1 p 192.168.20.42,2424 -> 192.168.10.17,2428 PR tcp len 20 276 -AP K-S K-F IN Jul 25 16:41:47 aps17 ipmon[249]: 16:41:47.044669 6x uplink0 @0:1 p 192.168.10.17,2428 -> 192.168.20.42,2424 PR tcp len 20 76 -AP K-S K-F OUT Jul 25 16:41:47 aps17 ipmon[249]: 16:41:47.045278 uplink0 @0:1 p 192.168.20.42,2424 -> 192.168.10.17,2428 PR tcp len 20 52 -A K-S K-F IN Jul 25 16:41:47 aps17 ipmon[249]: 16:41:47.045372 uplink0 @0:1 p 192.168.10.17,2428 -> 192.168.20.42,2424 PR tcp len 20 52 -A K-S K-F OUT Jul 25 16:41:47 aps17 ipmon[249]: 16:41:47.045436 5x uplink0 @0:1 p 192.168.20.42,2424 -> 192.168.10.17,2428 PR tcp len 20 52 -A K-S K-F IN Jul 25 16:41:47 aps17 ipmon[249]: 16:41:47.045713 uplink0 @0:1 p 192.168.10.17,2428 -> 192.168.20.42,2424 PR tcp len 20 76 -AP K-S K-F OUT Jul 25 16:41:47 aps17 ipmon[249]: 16:41:47.046381 uplink0 @0:1 p 192.168.20.42,2424 -> 192.168.10.17,2428 PR tcp len 20 52 -A K-S K-F IN Jul 25 16:41:47 aps17 ipmon[249]: 16:41:47.054489 uplink0 @0:1 p 192.168.10.17,2428 -> 192.168.20.42,2424 PR tcp len 20 88 -AP K-S K-F OUT Jul 25 16:41:47 aps17 ipmon[249]: 16:41:47.055031 uplink0 @0:1 p 192.168.20.42,2424 -> 192.168.10.17,2428 PR tcp len 20 52 -A K-S K-F IN Jul 25 16:41:47 aps17 ipmon[249]: 16:41:47.055320 uplink0 @0:1 p 192.168.10.17,2428 -> 192.168.20.42,2424 PR tcp len 20 76 -AP K-S K-F OUT Jul 25 16:41:47 aps17 ipmon[249]: 16:41:47.055679 uplink0 @0:1 p 192.168.10.17,2428 -> 192.168.20.42,2424 PR tcp len 20 40 -R K-S K-F OUT Jul 25 16:41:47 aps17 ipmon[249]: 16:41:47.055875 uplink0 @0:1 p 192.168.20.42,2424 -> 192.168.10.17,2428 PR tcp len 20 52 -A K-S K-F IN Jul 25 16:41:47 aps17 ipmon[249]: 16:41:47.055951 uplink0 @0:1 p 192.168.10.17,2428 -> 192.168.20.42,2424 PR tcp len 20 40 -R K-S K-F OUT Jul 25 16:41:52 aps17 ipmon[249]: 16:41:52.191109 uplink0 @0:2 b 192.168.10.17,2428 -> 192.168.20.42,2424 PR tcp len 20 64 -S OUT OOW Jul 25 16:41:56 aps17 ipmon[249]: 16:41:55.560387 uplink0 @0:2 b 192.168.10.17,2428 -> 192.168.20.42,2424 PR tcp len 20 64 -S OUT OOW Jul 25 16:42:02 aps17 ipmon[249]: 16:42:02.310369 uplink0 @0:2 b 192.168.10.17,2428 -> 192.168.20.42,2424 PR tcp len 20 64 -S OUT OOW Jul 25 16:42:04 aps17 ipmon[249]: 16:42:03.676088 uplink0 @0:2 b 192.168.10.17,2428 -> 192.168.20.42,2424 PR tcp len 20 40 -R OUT OOW Has this issue been found and fixed as one of the recent release mentioned here? A couple of them sound similar, but I want to confirm.

    Posted by Qing on July 25, 2007 at 07:06 PM PDT #

    Post a Comment:

    Name:
    E-Mail:
    URL:

    Your Comment:

    HTML Syntax: NOT allowed

    Calendar

    RSS Feeds

    Search

    Links

    Navigation

    Referers