No subject

INPUT: line 5 to ufw-before-logging-input
ufw-before-logging-input: fall through back to INPUT
INPUT: line 6 to ufw-before-input
ufw-before-input: line 11 to ufw-not-local
ufw-not-local: line 3 return to ufw-before-input
ufw-before-input: line 13 to ufw-user-input
ufw-user-input: fall through back to ufw-before-input
ufw-before-input: fall through back to INPUT
INPUT: line 7 to ufw-after-input
ufw-after-input: line 5 to ufw-skip-to-policy-input
ufw-skip-to-policy-input: line 1 DROP

Using the TRACE mechanism in iptables, I have confirmed that these are, in
fact, the rules that are triggered.  The inbound packet should be dropped,
according to netfilter, and yet it reaches the DHCP server, which processes it.
 I will attach a syslog trace of a DHCP transaction, including both syslog
events by dhcpd and netfilter.  (Note that the client machine had not been
connected to the LAN since the last server reboot, so no ESTABLISHED, RELATED
relationship should exist for that machine/port.)  The log file is called
iptables-trace.txt.

In the syslog, it shows that dhcpd processed the DHCPDISCOVER packet before
iptables did, but I don't know whether to chalk that up to the uncertainty of
two different processes writing to the log file at nearly the same time...

To be perfectly crystal clear, I manually added the following rule to the
beginning of the INPUT chain to drop all incoming UDP traffic on port 67
unconditionally:

iptables -I INPUT 1 -p udp --dport 67 -j DROP

Once again, connecting a system to the LAN produced another syslog trace, which
I will attach as iptables-trace2.txt.  This trace shows that netfilter
terminates the trace at the first INPUT rule (i.e., the DROP rule), and then
shows that dhcpd sees the packet and responds to it.

Because the port 67 DROP rule was a newly added rule, its packet counter was 0
when I added it.  Immediately upon connecting the client to the network, the
DROP rule packet counter incremented to 1.

Note that during the above-mentioned experiments, the network was controlled so
that no client machines other than my test machines were present.

I think that this conclusively proves that iptables intended to/did drop the
packets incoming on eth1 to broadcast port 67.  However, those packets were
delivered to dhcpd anyway.

Some possibilities:

1) The DROP mechanism is somehow broken.  Note that previous nmap scans have
shown what I expected to see, so I do not know if this is somehow limited to
DHCP packets, or perhaps to broadcast...

2) dhcpd somehow gets a copy of the packet before iptables/netfilter processes
it.  Prior to today, I would not have thought this possible.


-- 
Configure bugmail: http://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.