Ray Olszewski <[EMAIL PROTECTED]> on 11/01/2002 02:03:13 PM
To: [EMAIL PROTECTED]
cc: (bcc: Phillip Watts/austin/Nlynx)
Subject: Re: [leaf-user] Need logging help.
At 12:55 PM 11/1/02 -0600, [EMAIL PROTECTED] wrote:
"whenever"? How many different sites did you test? Is this behavior
associated with every WEb site or just some of them?
REPLY: www.kernel.org and www.coogle.com
Without seeing some examples, any suggestions about why these packets show
up really are wild guesses. Are they coming from the same IP addresses as
the Web sites? What port(s) are they to? As a general matter, the
commercialization of the Web has created any number of "services" that are
fairly intrusive, and you might be connecting to sites that (either
themselves or via third parties) trigger some unwanted traffic. Or they may
be some sort of authentication (like port 113 conenctions, the "auth"
service). Or they may be something completely different.
REPLY: Yes same address as website, all port 80
As to whether the rules do what you want ... rulesets need to be reviewed
as a whole, since the order of the rules matters, and you've only given us
fragments. That said ... are you getting *any* "TCP LOG:" or "IP LOG:"
entries from these rules?
REPLY: The IP LOG entries are catching udp and icmp.
The TCP LOG entries are showing up
I would presume that is because BEFORE the connection is established,
the step 1 rules would not apply.
That is the way I intended it and it seems to be working.
The only mystery to me is why there are non SYN packets in the
log for port 80, since as you pointed out, if they are part of
an established connection, they should have cease to traverse in
step 1.
Also these "NEW non SYN" packets are DROPped right after they
are logged. But the web browsing and ftp downloads from kernel.org
work fine, as does a google search which is a lot of packets.
Therefore, maybe these packets are legitimately junk.
This a very interesting phenomenon. I'm involved in an ISP changeover
in a few hours. Monday if the changeover goes well, I will recreate
this scenario, empty the log, google a little and send you a complete log
and firewall script.
If you care to take the time to look at this mess.
Bye the Bye, let me ask something.
These couldn't be data packets arriving before the connection packets could
they?
These are the assumptions I make which say not:
1.The server will not send data until the connection is acked.
2. Since the router is running nat, it is actually the endpoint.
Therefore it will order the tcp packets.
3. The tcp stack orders packets BEFORE submitting them to
netfilter rules.
Those are three pretty important assumptions, if you're willing to comment.
Since the step 1 rules (seemingly) come before
the step 3 rules, they would cause the packets they match to jump to
ACCEPT, causing them never to reach the -j LOG rules. To log those packets,
the -j LOG rules should precede the -j ACCEPT rules (the way the step-2
rules do), not follow them ... assuming, of course, that you want the
step-3 rules to log those packets.
You may want step 3 to log only packets that do not match either step 1 or
step 2 ... but here too, trying to figure this out (or even what such
packets might be, since the only unprocessed state is INVALID) without
seeing the complete ruleset is tough.
> Step 1
># ALLOW ALL replies to established connections
>$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>
>Step 2
># LOG and DISALLOW BAD TCP packets, NEW non connections
>$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix
>"IP New
> non SYN: "
>$IPT -A FORWARD -p tcp ! --syn -m state --state NEW -j LOG --log-prefix
>"IP New
> non SYN: "
>$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
>$IPT -A FORWARD -p tcp ! --syn -m state --state NEW -j DROP
>
>Step3
># INSERT LOGGING RULES
>$IPT -A INPUT -i $XT_DEVICE -p tcp --syn -j LOG --log-prefix "TCP LOG: "
>$IPT -A FORWARD -i $XT_DEVICE -p tcp --syn -j LOG --log-prefix "TCP LOG: "
>$IPT -A INPUT -i $XT_DEVICE -p ! tcp -j LOG --log-prefix "IP LOG: "
>$IPT -A FORWARD -i $XT_DEVICE -p ! tcp -j LOG --log-prefix "IP LOG: "
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA [EMAIL PROTECTED]
-------------------------------------------------------------------------------
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
