From: Todd Goodman <tsg@bonedaddy.net>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: [OT router advice] a router capable of detailed logs
Date: Thu, 28 Apr 2011 10:36:27 -0400 [thread overview]
Message-ID: <20110428143627.GQ22703@ns1.bonedaddy.net> (raw)
In-Reply-To: <87zknbaqmx.fsf@newsguy.com>
* Harry Putnam <reader@newsguy.com> [110428 01:06]:
> Yeah I had a look at the lines containing LOG and of course had no
> idea of what they meant or how to alter them.
>
> The entire iptables is inlined below... maybe you will know how to alter
> them so that ports show up in logs. That is, only if you are still
> patient enough to continue.... so far, no one has complained about the
> OT thread... but I fear I must be nearing the end of your patient
> willingness to continue, if not the lists willingness to allow my OT
> thread.
>
> ------- --------- ---=--- --------- --------
> There only 4 instances of LOG in the tables. But I wonder if it might
> just be an increase in log level that is required.
I don't think so. That's the syslog level and changing it might change
if you see the logged entries at all (depending on your syslog config.)
>
> I wanted to try that out, but was a bit chicken, thinking I'd destroy
> whatever setup there is that invokes the iptable rules.
You won't really break anything by changing the log levels.
If you're changing things using iptables commands from the shell then
it's unlikely any changes are permanent anyway (everything will go back
to how it was.) To make a permanent change you'll need to figure how
and where the iptables rules are being loaded from when the system comes
up (it might be using iptable-save and iptables-restore or a firewall
script or similar.)
Now I'm not an expert on iptables logging and I'm sure Mick and/or
someone else will respond too.
I think your iptables output is truncated at 80 columns too so some of
the info is missing at the ends of some of the lines.
Also, I apologize but I forget exactly the traffic for which you're
trying to get the port #'s logged?
But let's go through what's there (apologies if you already know what
I mention:)
First, iptables has different tables that it (netfilter in the kernel)
uses for different purposes. The one you're interested in (and which
you dumped and is the default for the iptables command if you don't
specify one) is the filter table.
Other tables that are of interest for other things are the nat table
and, for most people, to a lessor degree the mangle table.
Inside tables there are standard chains of rules and there are
(potentially) user-defined chains.
The path a packet takes in the system determines which tables and chains
are processed.
>
> Chain INPUT (policy DROP)
The filter table INPUT chain is used when a packet is destined for the
box itself (i.e., not sourced on the box and not being forwarded through
the box.)
The policy is to DROP any packets that aren't matched by terminating
rules (e.g., ACCEPT) in the chain.
> target prot opt source destination
> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:23
> ACCEPT esp -- 0.0.0.0/0 0.0.0.0/0
> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:4500
> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:500
These ACCEPT rules allow certain traffic destined for the router itself.
> DROP tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp flags:
Other TCP traffic that's not allowed above is dropped if it's a NEW TCP
connection to the router itself (i.e., not a response to TCP traffic
initiated by the router.)
> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABL
This accepts any traffic that's part of a flow initiated from the
router.
> INPUT_UDP udp -- 0.0.0.0/0 0.0.0.0/0
Go process the the user defined INPUT_UDP chain if the packet is a UDP
packet. If that chain reaches the end of its rule list without matching
a terminating rule it will return back here (as with all jumps to other
chains.)
> INPUT_TCP tcp -- 0.0.0.0/0 0.0.0.0/0
Go process the the user defined INPUT_TCP chain if the packet is a TCP
packet
> DOS icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8
Go process the the user defined DOS chain if the packet is a ICMP
packet with icmp type 8
> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW
ACCEPT all traffic that's in state NEW to the router. Presumably if a
packet hasn't been dropped above or in the user defined chains then the
router wants to see that traffic.
>
> Chain FORWARD (policy DROP)
The filter table FORWARD chain is used when a packet is being forwarded
by the system. The default policy is to DROP packets not matched by any
terminating rules in the chain.
> target prot opt source destination
> ip_filter all -- 0.0.0.0/0 0.0.0.0/0
Go process the user defined ip_filter chain for all packets
> POLICY icmp -- 0.0.0.0/0 0.0.0.0/0
Go process the user defined POLICY chain for ICMP packets
> POLICY udp -- 0.0.0.0/0 0.0.0.0/0
Go process the user defined POLICY chain for UDP packets
> TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02
Go process the user defined TCPMSS chain for TCP packets with certain
flags set in the packet
> POLICY tcp -- 0.0.0.0/0 0.0.0.0/0
Go process the user defined POLICY chain for all TCP packets
> TREND_MICRO tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 http me
Go process the user defined TREND_MICRO chain for tcp traffic destined
for TCP port 80 (HTTP)
> DMZ_PASS all -- 0.0.0.0/0 0.0.0.0/0
Go process the user defined DMZ_PASS chain for all traffic
> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABL
ACCEPT any traffic that's already been set up (state RELATED or
ESTABLISHED.)
> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW
ACCEPT any traffic that's being initiated
> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT any traffic
>
> Chain OUTPUT (policy ACCEPT)
The filter table OUTPUT chain is for traffic sourced by the router
itself. The default policy is to ACCEPT any traffic initiated by the
router.
> target prot opt source destination
> ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
Allow any ICMP packets from the router
> DROP icmp -- 0.0.0.0/0 0.0.0.0/0 state INVALID
Drop any invalid ICMP packets
>
> Chain BLOCK (0 references)
User defined chain BLOCK. It's not used by anyone (0 references) so we
can ignore it
> target prot opt source destination
> LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4
> DROP all -- 0.0.0.0/0 0.0.0.0/0
>
> Chain DMZ_PASS (1 references)
> target prot opt source destination
Empty user defined chaing DMZ_PASS
>
> Chain DOS (6 references)
User defined DOS chain
> target prot opt source destination
> RETURN tcp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 200/sec b
rate limit TCP packets (return to caller if it's OK)
> RETURN udp -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABL
Return to caller if it's a RELATED or ESTABLISHED UDP packet
> RETURN udp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 200/sec b
Rate limit UDP packets (return to caller if it's OK)
> RETURN icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8 limit: a
Rate limit ICMP type 8 packets (return to caller if it's OK)
> LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/sec bu
Create a log entry
> DROP all -- 0.0.0.0/0 0.0.0.0/0
And then drop the packet
>
> Chain FORWARD_TCP (1 references)
The user defined FORWARD_TCP chain.
> target prot opt source destination
> DOS tcp -- 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW tc
Call DOS if it's an INVALID or NEW TCP connection
> RETURN tcp -- 0.0.0.0/0 0.0.0.0/0
Return if it's a TCP packet (it's going to return anyway...)
>
> Chain FORWARD_UDP (1 references)
The user defined FORWARD_UDP chain
> target prot opt source destination
> DOS udp -- 0.0.0.0/0 0.0.0.0/0
Call DOS if it's a UDP packet
> RETURN udp -- 0.0.0.0/0 0.0.0.0/0
Return if it's a UDP packet
>
> Chain HTTP (0 references)
User defined HTTP chain. No one is using it so we can ignore it.
> target prot opt source destination
>
> Chain INPUT_TCP (1 references)
User defined INPUT_TCP chain.
> target prot opt source destination
> SCAN all -- 0.0.0.0/0 0.0.0.0/0 psd weight-threshold
Call SCAN for any packet that's part of a port scanning attempt (as
defined by the parameters to the psd match.)
> DOS tcp -- 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW tc
Call DOS for any INVALID or NEW TCP packet
> ACCEPT tcp -- 0.0.0.0/0 192.168.0.20 tcp dpt:30443
ACCEPT any TCP packet destined for port 30443 and change the destination
IP address to 192.168.0.20
> DROP tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 23,
DROP any TCP traffic matching destination ports 23 and the rest that are
truncated.
> RETURN tcp -- 0.0.0.0/0 0.0.0.0/0
Return if it's a TCP packet
>
> Chain INPUT_UDP (1 references)
The user defined INPUT_UDP chain
> target prot opt source destination
> SCAN all -- 0.0.0.0/0 0.0.0.0/0 psd weight-threshold
Call SCAN if it matches the psd match
> DOS udp -- 0.0.0.0/0 0.0.0.0/0
Call DOS if it's a UDP packet
> ACCEPT udp -- 68.87.72.13 0.0.0.0/0 udp spt:67 dpt:68
Accept UDP traffic from host 68.87.72.13 with a source port of 67 and a
destination port of 68
> RETURN udp -- 0.0.0.0/0 0.0.0.0/0
Return if it's a UDP packet
>
> Chain POLICY (3 references)
User defined POLICY chain
> target prot opt source destination
> PORT_FORWARD all -- 0.0.0.0/0 0.0.0.0/0
Call PORT_FORWARD for all packets
> RETURN all -- 0.0.0.0/0 0.0.0.0/0
RETURN for all packets
>
> Chain PORT_FORWARD (1 references)
User defined PORT_FORWARD chain
> target prot opt source destination
> DOS icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8
Call DOS if it's an ICMP type 8 packet
> FORWARD_TCP tcp -- 0.0.0.0/0 0.0.0.0/0
Call FORWARD_TCP if it's a TCP packet
> FORWARD_UDP udp -- 0.0.0.0/0 0.0.0.0/0
Call FORWARD_UDP if it's a UDP packet
> RETURN all -- 0.0.0.0/0 0.0.0.0/0
RETURN for any packet
>
> Chain SCAN (2 references)
User defined SCAN chain
> target prot opt source destination
> LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/sec bu
Log the packet but not more than 10/sec
> DROP all -- 0.0.0.0/0 0.0.0.0/0
DROP the packet
>
> Chain TREND_MICRO (1 references)
User defined TREND_MICRO chain. It doesn't really do anything
> target prot opt source destination
> RETURN all -- 0.0.0.0/0 0.0.0.0/0
>
> Chain ip_filter (1 references)
User defined ip_filter chain. Doesn't do anything
> target prot opt source destination
>
OK, so that's what is going on in your iptables.
Without knowing what specific traffic (and the situation) I'm not sure
where to look at the LOG rules. Sorry I forget this.
All this being said, my LOG rules always include source and destination
ports for TCP and UDP traffic.
Can you post (or send me in private email) some of your log output to
look at?
Thanks,
Todd
next prev parent reply other threads:[~2011-04-28 15:12 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-19 3:31 [gentoo-user] [OT router advice] a router capable of detailed logs Harry Putnam
2011-04-19 6:02 ` Mick
2011-04-20 15:56 ` [gentoo-user] " Harry Putnam
2011-04-21 5:55 ` Mick
2011-04-21 5:58 ` Mick
2011-04-22 19:28 ` Harry Putnam
2011-04-22 22:17 ` Mick
2011-04-25 17:37 ` Harry Putnam
2011-04-25 18:20 ` Paul Hartman
2011-04-25 19:04 ` Mick
2011-04-25 18:44 ` Mick
2011-04-25 22:23 ` Jake Moe
2011-04-26 6:08 ` Mick
2011-04-26 22:27 ` Harry Putnam
2011-04-27 6:23 ` Mick
2011-04-28 5:31 ` Harry Putnam
2011-04-28 14:36 ` Todd Goodman [this message]
2011-04-30 4:28 ` Harry Putnam
2011-04-30 15:02 ` Todd Goodman
2011-04-28 16:07 ` Mick
2011-04-19 6:54 ` [gentoo-user] " Joost Roeleveld
2011-04-20 16:16 ` [gentoo-user] " Harry Putnam
2011-04-19 9:15 ` [gentoo-user] " Peter Humphrey
2011-04-20 16:23 ` [gentoo-user] " Harry Putnam
2011-04-20 18:49 ` Dale
2011-04-20 19:38 ` Harry Putnam
2011-04-20 19:50 ` Dale
2011-04-20 22:36 ` Peter Humphrey
2011-04-20 22:36 ` Harry Putnam
2011-04-20 23:35 ` Dale
2011-04-21 5:37 ` Pandu Poluan
2011-04-19 10:17 ` [gentoo-user] " Pandu Poluan
2011-04-19 10:18 ` Stroller
2011-04-19 14:50 ` Paul Hartman
2011-04-20 2:01 ` W.Kenworthy
2011-04-20 18:50 ` [gentoo-user] " Harry Putnam
2011-04-20 18:15 ` Harry Putnam
2011-04-20 18:15 ` Todd Goodman
2011-04-20 19:01 ` Harry Putnam
2011-04-20 18:48 ` Paul Hartman
2011-04-20 19:28 ` Harry Putnam
2011-04-20 20:11 ` Paul Hartman
2011-04-20 22:41 ` Harry Putnam
2011-04-21 12:22 ` Todd Goodman
2011-04-22 20:25 ` Harry Putnam
2011-04-22 22:47 ` Todd Goodman
2011-04-20 19:14 ` Harry Putnam
2011-04-30 17:47 ` James
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110428143627.GQ22703@ns1.bonedaddy.net \
--to=tsg@bonedaddy.net \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox