I don''t think this has anything to do with Shorewall but I am not too familiar with iptables stuff yet so I''m not sure. Running Shorewall shorewall-1.4.9 on Mandrake Linux release 9.2 (FiveStar) for i586 Kernel 2.4.22-37mdk. Run "nmap -sP 192.168.x.x/24" (for example), where 192.168.x.x/24 is the LAN. You can do this from a firewall/router, or even from a single-interface computer that only runs Shorewall for its own protection. Then run "shorewall show connections" and you will see a bunch of unreplied, inuse connections for all the IP addresses in 192.168.x.x/24 that didn''t respond. This seems like a too easy way to use up memory and possibly create a DOS situation. My first thoughts are that only connections that have actually been masqueraded need to be tracked. Since no masquerading is required on a single-interface computer, there is no requirement to track connections. Even for a typical firewall/router with LAN, DMZ and WAN interfaces, I would not expect connections between the LAN and DMZ to be tracked, whereas connections from the LAN & DMZ to the WAN would require tracking. What do people think about this?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Taso Hatzi wrote:> > This seems like a too easy way to use up memory and possibly create a DOS > situation. > > My first thoughts are that only connections that have actually been > masqueraded need to be tracked. Since no masquerading is required > on a single-interface computer, there is no requirement to track > connections. Even for a typical firewall/router with LAN, DMZ and > WAN interfaces, I would not expect connections between the LAN and > DMZ to be tracked, whereas connections from the LAN & DMZ to the > WAN would require tracking. > > What do people think about this?I think that you should investigate the re-use policy of these unreplied inuse conntrack entries before spreading this FUD. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBbIVJO/MAbZfjDLIRAnksAJ0TVLQ98f5Fo5qFvmIKA9GsGxv9HwCgtgZo n82xWMflr94dPTNqxLxkh2w=ENlr -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Eastep wrote:> Taso Hatzi wrote: > > >>>This seems like a too easy way to use up memory and possibly create a DOS >>>situation. >>> >>>My first thoughts are that only connections that have actually been >>>masqueraded need to be tracked. Since no masquerading is required >>>on a single-interface computer, there is no requirement to track >>>connections. Even for a typical firewall/router with LAN, DMZ and >>>WAN interfaces, I would not expect connections between the LAN and >>>DMZ to be tracked, whereas connections from the LAN & DMZ to the >>>WAN would require tracking. >>> >>>What do people think about this? > > > I think that you should investigate the re-use policy of these unreplied > inuse conntrack entries before spreading this FUD. >And you should probably also acknowledge that it is necessary to have Patch-O-Matic[-ng] patches in your kernel and iptables in order to be able to selectively omit connections from tracking. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBbI4gO/MAbZfjDLIRAvpQAJ0Z24vkJEAHmSkJxqe4xklEZCxTcQCdF/GP uaIk5myXrnaXYITCV3FCbC4=r/m3 -----END PGP SIGNATURE-----
Tom Eastep wrote:> > > I think that you should investigate the re-use policy of these unreplied > inuse conntrack entries before spreading this FUD. >What I had in mind was the effect of sustained churning through 7 or 8K connection records by kernel code, not the soundness of the code or the algorithms. If you regard this as FUD, I am more than happy to accept that someone (who knows more about this me) rates it as no big deal. I have been down the patch-o-matic route in the past and would only go there again as a last resort. There are too many compelling reasons to stick with one of the popular (and hopefully well sorted out) distributions. The message overhead has been incurred so I will take this opportunity to say that I believe the breadth and quality of Shorewall docs is exemplary.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Taso Hatzi wrote:> Tom Eastep wrote: > >> >> >> I think that you should investigate the re-use policy of these unreplied >> inuse conntrack entries before spreading this FUD. >> > > What I had in mind was the effect of sustained churning through 7 or 8K > connection records by kernel code, not the soundness of the code or the > algorithms. If you regard this as FUD, I am more than happy to accept that > someone (who knows more about this me) rates it as no big deal. >Two points: a) The entries that you are concerned about are subject to re-use so DOS isn''t so much of a concern (except for the ''churning'' you mention). b) Given my policy of not supporting Patch-O-Matic features, I couldn''t do anything about it if it were a problem. The availability of the ''raw'' table patch in Patch-O-Matic indicates that someone besides you has concerns in this area so characterizing your concern as ''FUD'' was probably an over-reaction on my part.> I have been down the patch-o-matic route in the past and would only go > there > again as a last resort. There are too many compelling reasons to stickwith> one of the popular (and hopefully well sorted out) distributions.I agree fully -- at such time as the ''raw'' table feature is available in vendor-supplied kernels, I will take up your concern again. Note also that at the recent Netfilter summit in Oregon, it was agreed that Patch-O-Matic features are now going to be categorized and one of the categories will be ''Kernel-track'' (scheduled for inclusion in the standard kernel tree). When this classification system is fully implemented, I may start providing support for ''kernel-track'' patches, especially in the development Shorewall thread (I''m essentially doing that already with the ''policy match'' patch although that patch is included in SuSE kernels).> > The message overhead has been incurred so I will take this opportunity to > say that I believe the breadth and quality of Shorewall docs is exemplary.Thanks, - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBbT60O/MAbZfjDLIRAih7AJ9yYmaGNasQK7N9Hn9oSLiH1UE+GgCfXR9p V0jg693SI0VWN6tz8tx3sm8=kwEh -----END PGP SIGNATURE-----