At 12:55 PM 11/1/02 -0600, [EMAIL PROTECTED] wrote:

I'm trying to understand what's going on here
My goal is log everything that hits the external
interface, except the body of file transfers and
lengthy web sites.

Here's what I THINK I'm doing:
Step 1 accepts everything previously established.

Step 2 logs and drops NEW non connections, those should
be really bad packets

Step 3 logs all (external port) tcp connections and all non tcp.

I think this is working pretty well.
BUT I see some "IP New non SYN" in the log, whenever
I do web browsing thru the router.
These I don't get.
"whenever"? How many different sites did you test? Is this behavior associated with every WEb site or just some of them?

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.

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? 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

Reply via email to