Some ruleset-related questions

Marecki Marek Szuba <cyberman@if.pw.edu.pl>
Mon, 11 Jun 2001 19:41:00 +0200 (MET DST)


On Mon, 11 Jun 2001, Andrew Heberle wrote:

> The behaviour you mention looks like connections which have expired
> (according to conntrack) but the other end doesn't know it yet.  Certain
> web servers do this, I got around the DNS one by ACCEPT'ing DNS
> connections from my ISP's DNS.
So that's the other people's, and their broken software's, issue. Figures,
apart from the DNS one all of them came from WWW servers and the flag
combinations looked kinda weird (eg. I got FIN SYN once). I have to check
if that was IIS or something else...
About the DNS one: while the problem will certainly be solved if I ACCEPT
such connections, what is the ISP's DNS actually trying to do? There is no
official nameserver running on this box, furthermore it is usable in the
MASQed net only. There should be no DNS connections from the outside, of
that I am sure.

> > after they get logged via the LOG target
> They continue their merry way
Ahh, that's exactly what I needed to know (and was too lazy to check
myself)! Thanks. I wonder why it isn't mentioned anywhere in the docs...
After all I found it very good in other aspects.

> No you set this manually with --log-prefix "Blah: " on your LOG rule.
Yeah, I saw that in the HOWTOs. I guess I'll have to implement that
myself, as well as update the "get firewall entries out of kernel log"
script.

> > 4. Last but not least: any comments regarding the ruleset
> Not at the moment :)
Hmm, that could mean either everything is in order or there is something
particularly nasty yet to be found ;-) If you have any later, don't
hesitate to mention them: looks like I'm going to stay on this list for a
while.


BTW. Yet another question: does rp_filter check only inbound traffic, or
the outgoing as well? The docs mention input only, that would mean it was
right not to delete the related rules in the OUTPUT chain, but I want to
make sure.

-- 
Marecki