[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 477
  • Last Modified:

Odd IPTABLES behaviour

I forgot to allow bootps requests from bootpc but it worked anyway. The packet is logged as about to be dropped (that is the next rule), but the bootpc server responds so must have got it.
This is contrary to my understanding of what should happen (and makes it harder for me to sell management on iptables as a firewall solution).
Does anyone have any idea what could be going on?
#!/bin/sh
set -x
exec >/tmp/iptables-filter-mintec.out 2>&1
 
# Set up a firewall: drop all incoming UDP & connects except DNS UDP:-
 
#Don't set up these rules twice
/usr/sbin/iptables -L -n|grep ppptab >/dev/null ||
{
 
  # A chain to log & drop a packet, except don't log FIN pkts
  /usr/sbin/iptables -N logdrop
  /usr/sbin/iptables -A logdrop -p tcp -m tcp --tcp-flags FIN FIN -j DROP
  # Comment out logging if too much stuff gets logged
  /usr/sbin/iptables -A logdrop -j LOG --log-level debug
  /usr/sbin/iptables -A logdrop -j DROP
 
  # A chain to inspect incoming (to this box) packets from ppp connection
  /usr/sbin/iptables -N ppptab
  # Allow icmp but not too many
  /usr/sbin/iptables -A ppptab -p icmp -m limit --limit 5/second -j ACCEPT
  # Allow DNS replies and queries
  /usr/sbin/iptables -A ppptab -p udp --source-port 53 -j ACCEPT
  /usr/sbin/iptables -A ppptab -p udp --destination-port 53 -j ACCEPT
  # Allow reply packets to an outbound telnet
  /usr/sbin/iptables -A ppptab -p tcp --source-port 23 -j ACCEPT
  # Drop everything else
  /usr/sbin/iptables -A ppptab -j logdrop
 
  # Firewall rule - check incoming (to this box) packets from ppp connection
  /usr/sbin/iptables -A INPUT -i ppp0 -j ppptab
  /usr/sbin/iptables -A INPUT -i eth1 -j ppptab
}

Open in new window

0
Duncan Roe
Asked:
Duncan Roe
  • 10
  • 2
  • 2
4 Solutions
 
WizRd-LinuxCommented:
I'm not trying to be an idiot, but you have actually checked that the drop rule in the logdrop chain exists?

Your understanding is spot on, LOG is a non-terminating target so the next rule is processed, which in your case is drop.

Out of pure curiosity, if you change the iptables -A logdrop -j DROP line to be iptables -A INPUT -j DROP does it still get through?  I'm wondering if the double user defined chain may be causing issues?  After it has logged it will fall back to ppptab and back to input anyway and be rejected.
0
 
Duncan RoeSoftware DeveloperAuthor Commented:
Other packets *are* dropped, like attempts to connect to the FTP server. Actually the above is modelled on a firewall I have successfully run at home for years. Still, your idea has merit in he absence of anything better - I'll give it a go
0
 
Duncan RoeSoftware DeveloperAuthor Commented:
Rearranging to only have 2 tables shortened the script by 3 lines, a good result.
However it doesn't fix the problem. In the log file below, you can see the rejected bootpc->bootps UDP but you can also see dhcp actioning it
15:47:19# cat iptables-filter-mintec
#!/bin/sh
set -x
exec >/tmp/iptables-filter-mintec.out 2>&1
 
# Set up a firewall: drop all incoming UDP & connects except DNS UDP:-
 
#Don't set up these rules twice
/usr/sbin/iptables -L -n|grep ppptab >/dev/null ||
{
 
  # A chain to inspect incoming (to this box) packets from ppp connection
  /usr/sbin/iptables -N ppptab
  # Allow icmp but not too many
  /usr/sbin/iptables -A ppptab -p icmp -m limit --limit 5/second -j ACCEPT
  # Allow DNS replies and queries
  /usr/sbin/iptables -A ppptab -p udp --source-port 53 -j ACCEPT
  /usr/sbin/iptables -A ppptab -p udp --destination-port 53 -j ACCEPT
  # Allow reply packets to an outbound telnet
  /usr/sbin/iptables -A ppptab -p tcp --source-port 23 -j ACCEPT
 
  # Firewall rule - check incoming (to this box) packets from ppp connection
  /usr/sbin/iptables -A INPUT -i ppp0 -j ppptab
  /usr/sbin/iptables -A INPUT -i eth1 -j ppptab
  /usr/sbin/iptables -A INPUT -i eth0 -j ACCEPT
  # Drop everything not accepted by ppptab
  /usr/sbin/iptables -A INPUT -p tcp -m tcp --tcp-flags FIN FIN -j DROP
  # Comment out logging if too much stuff gets logged
  /usr/sbin/iptables -A INPUT -j LOG --log-level debug
  /usr/sbin/iptables -A INPUT -j DROP
}
 
=======================================================================================
 
15:47:44# iptables -L -v --line-numbers
Chain INPUT (policy ACCEPT 14697 packets, 2652K bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1       41  6831 ppptab     all  --  ppp0   any     anywhere             anywhere            
2      348 53664 ppptab     all  --  eth1   any     anywhere             anywhere            
3    10008 1694K ACCEPT     all  --  eth0   any     anywhere             anywhere            
4       24  2087 ACCEPT     all  --  lo     any     anywhere             anywhere            
5        0     0 DROP       tcp  --  any    any     anywhere             anywhere            tcp flags:FIN/FIN 
6      263 47495 LOG        all  --  any    any     anywhere             anywhere            LOG level debug 
7      263 47495 DROP       all  --  any    any     anywhere             anywhere            
 
Chain FORWARD (policy ACCEPT 146 packets, 14805 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
 
Chain OUTPUT (policy ACCEPT 2412 packets, 332K bytes)
num   pkts bytes target     prot opt in     out     source               destination         
 
Chain ppptab (2 references)
num   pkts bytes target     prot opt in     out     source               destination         
1       15   900 ACCEPT     icmp --  any    any     anywhere             anywhere            limit: avg 5/sec burst 5 
2       41  6831 ACCEPT     udp  --  any    any     anywhere             anywhere            udp spt:domain 
3       70  4458 ACCEPT     udp  --  any    any     anywhere             anywhere            udp dpt:domain 
4        0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp spt:telnet 
 
=================================================================================================
 
Apr 22 15:07:10 uno kernel: IN=eth1 OUT= MAC=00:d0:c9:a6:47:17:00:c0:3a:6b:10:6c:08:00 SRC=192.168.0.249 DST=192.168.0.1 LEN=161 TOS=0x00 PREC=0x00 TTL=1 ID=30888 PROTO=UDP SPT=22124 DPT=1900 LEN=141 
Apr 22 15:07:17 uno named[1473]: client 192.168.0.1#34461: updating zone 'loco.net/IN': deleting an RR
Apr 22 15:07:17 uno kernel: IN=eth1 OUT= MAC=00:d0:c9:a6:47:17:00:c0:3a:6b:10:6c:08:00 SRC=192.168.0.249 DST=192.168.0.1 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=30894 PROTO=UDP SPT=68 DPT=67 LEN=308 
Apr 22 15:07:17 uno dhcpd: if LocoNetServer.loco.net IN TXT "31833bf41bc38609c2d9ff0dd96ce25498" rrset exists and LocoNetServer.loco.net IN A 192.168.0.249 rrset exists delete LocoNetServer.loco.net IN A 192.168.0.249: success.
Apr 22 15:07:17 uno named[1473]: zone loco.net/IN: sending notifies (serial 105)
Apr 22 15:07:17 uno named[1473]: client 192.168.0.1#41651: updating zone 'loco.net/IN': deleting an RR
Apr 22 15:07:18 uno dhcpd: if LocoNetServer.loco.net IN A rrset doesn't exist delete LocoNetServer.loco.net IN TXT "31833bf41bc38609c2d9ff0dd96ce25498": success.
Apr 22 15:07:18 uno named[1473]: client 192.168.0.1#44873: updating zone '0.168.192.in-addr.arpa/IN': deleting rrset at '249.0.168.192.in-addr.arpa' PTR
Apr 22 15:07:18 uno dhcpd: removed reverse map on 249.0.168.192.in-addr.arpa.
Apr 22 15:07:18 uno named[1473]: zone 0.168.192.in-addr.arpa/IN: sending notifies (serial 74)
Apr 22 15:07:18 uno dhcpd: DHCPRELEASE of 192.168.0.249 from 00:c0:3a:6b:10:6c (LocoNetServer) via eth1 (found)
Apr 22 15:07:22 uno named[1473]: zone loco.net/IN: sending notifies (serial 106)
Apr 22 15:09:08 uno kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:c0:3a:6b:10:6c:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=332 TOS=0x00 PREC=0x00 TTL=128 ID=30926 PROTO=UDP SPT=68 DPT=67 LEN=312 
Apr 22 15:09:08 uno dhcpd: DHCPDISCOVER from 00:c0:3a:6b:10:6c via eth1
Apr 22 15:09:09 uno dhcpd: DHCPOFFER on 192.168.0.249 to 00:c0:3a:6b:10:6c (LocoNetServer) via eth1
Apr 22 15:09:09 uno kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:c0:3a:6b:10:6c:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=355 TOS=0x00 PREC=0x00 TTL=128 ID=30927 PROTO=UDP SPT=68 DPT=67 LEN=335 
Apr 22 15:09:09 uno named[1473]: client 192.168.0.1#40859: updating zone 'loco.net/IN': adding an RR at 'LocoNetServer.loco.net' A
Apr 22 15:09:09 uno named[1473]: client 192.168.0.1#40859: updating zone 'loco.net/IN': adding an RR at 'LocoNetServer.loco.net' TXT
Apr 22 15:09:09 uno dhcpd: Added new forward map from LocoNetServer.loco.net to 192.168.0.249
Apr 22 15:09:09 uno named[1473]: zone loco.net/IN: sending notifies (serial 107)
Apr 22 15:09:09 uno named[1473]: client 192.168.0.1#34461: updating zone '0.168.192.in-addr.arpa/IN': deleting rrset at '249.0.168.192.in-addr.arpa' PTR
Apr 22 15:09:09 uno named[1473]: client 192.168.0.1#34461: updating zone '0.168.192.in-addr.arpa/IN': adding an RR at '249.0.168.192.in-addr.arpa' PTR
Apr 22 15:09:09 uno named[1473]: zone 0.168.192.in-addr.arpa/IN: sending notifies (serial 75)
Apr 22 15:09:09 uno dhcpd: added reverse map from 249.0.168.192.in-addr.arpa. to LocoNetServer.loco.net
Apr 22 15:09:09 uno dhcpd: DHCPREQUEST for 192.168.0.249 (192.168.0.1) from 00:c0:3a:6b:10:6c (LocoNetServer) via eth1
Apr 22 15:09:09 uno dhcpd: DHCPACK on 192.168.0.249 to 00:c0:3a:6b:10:6c (LocoNetServer) via eth1
Apr 22 15:09:12 uno kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:c0:3a:6b:10:6c:08:00 SRC=192.168.0.249 DST=192.168.0.255 LEN=229 TOS=0x00 PREC=0x00 TTL=128 ID=30960 PROTO=UDP SPT=138 DPT=138 LEN=209 

Open in new window

0
A Cyber Security RX to Protect Your Organization

Join us on December 13th for a webinar to learn how medical providers can defend against malware with a cyber security "Rx" that supports a healthy technology adoption plan for every healthcare organization.

 
Duncan RoeSoftware DeveloperAuthor Commented:
I added the lo ACCEPT rule by hand in the above, because dynamic dhcp updates stopped working. This is the current script:
15:58:54# cat iptables-filter-mintec
#!/bin/sh
set -x
exec >/tmp/iptables-filter-mintec.out 2>&1
 
# Set up a firewall: drop all incoming UDP & connects except DNS UDP:-
 
#Don't set up these rules twice
/usr/sbin/iptables -L -n|grep ppptab >/dev/null ||
{
 
  # A chain to inspect incoming (to this box) packets from ppp connection
  /usr/sbin/iptables -N ppptab
  # Allow icmp but not too many
  /usr/sbin/iptables -A ppptab -p icmp -m limit --limit 5/second -j ACCEPT
  # Allow DNS replies and queries
  /usr/sbin/iptables -A ppptab -p udp --source-port 53 -j ACCEPT
  /usr/sbin/iptables -A ppptab -p udp --destination-port 53 -j ACCEPT
  # Allow reply packets to an outbound telnet
  /usr/sbin/iptables -A ppptab -p tcp --source-port 23 -j ACCEPT
 
  # Firewall rule - check incoming (to this box) packets from ppp connection
  /usr/sbin/iptables -A INPUT -i ppp0 -j ppptab
  /usr/sbin/iptables -A INPUT -i eth1 -j ppptab
  /usr/sbin/iptables -A INPUT -i eth0 -j ACCEPT
  /usr/sbin/iptables -A INPUT -i lo -j ACCEPT
  # Drop everything not accepted by ppptab
  /usr/sbin/iptables -A INPUT -p tcp -m tcp --tcp-flags FIN FIN -j DROP
  # Comment out logging if too much stuff gets logged
  /usr/sbin/iptables -A INPUT -j LOG --log-level debug
  /usr/sbin/iptables -A INPUT -j DROP
}

Open in new window

0
 
BlazCommented:
Apr 22 15:07:18 uno dhcpd: DHCPRELEASE of 192.168.0.249 from 00:c0:3a:6b:10:6c (LocoNetServer) via eth1 (found)
Apr 22 15:09:08 uno dhcpd: DHCPDISCOVER from 00:c0:3a:6b:10:6c via eth1
Apr 22 15:09:09 uno dhcpd: DHCPOFFER on 192.168.0.249 to 00:c0:3a:6b:10:6c (LocoNetServer) via eth1
Apr 22 15:09:09 uno dhcpd: DHCPREQUEST for 192.168.0.249 (192.168.0.1) from 00:c0:3a:6b:10:6c (LocoNetServer) via eth1
Apr 22 15:09:09 uno dhcpd: DHCPACK on 192.168.0.249 to 00:c0:3a:6b:10:6c (LocoNetServer) via eth1

This is a complete DHCP cycle from your logs. I can't tell at first look why it is allowed by your rules but none of the packets from this connection gets logged by your iptables script. The logged messages are from a different source (see below).

Maybe try to also block FORWARD chain?
iptables -A FORWARD -j DROP

Check also your nat and mangle tables:
iptables -t nat -L -nvx
iptables -t mangle -L -nvx

A rule there could ACCEPT packets.


The following messages are from some other computer making DHCP requests - check the source/destination port. They are not a part of your DHCP cycle.

Apr 22 15:09:08 uno kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:c0:3a:6b:10:6c:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=332 TOS=0x00 PREC=0x00 TTL=128 ID=30926 PROTO=UDP SPT=68 DPT=67 LEN=312
Apr 22 15:09:09 uno kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:c0:3a:6b:10:6c:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=355 TOS=0x00 PREC=0x00 TTL=128 ID=30927 PROTO=UDP SPT=68 DPT=67 LEN=335

From http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol :
all client-sent packets have source port 68 and destination port 67; all server-sent packets have source port 67 and destination port 68.

This means that your logged packets are some client sent packets, but as you do not log your own output packets (and they are logged on input IN=eth1) they must be sent by some other host on the network and your interface received them (because they are broadcasted).
0
 
Duncan RoeSoftware DeveloperAuthor Commented:
Hi Blaz, thanks for replying. The mangle table is empty. I can post the output from iptables -t nat -L -nvx --line-numbers when I'm at work tomorrow.
Here is my understanding of the log. The "other " machine is a Windows system, hence ipconfig and options:

1. In a cmd window on 192.168.0.249, I type "ipconfig /release"
2. A bunch of log entries appear at  15:07:17 not in the order in which the events they document actually happened:
2a. iptables logs that it is going to drop this packet:
Apr 22 15:07:10 uno kernel: IN=eth1 OUT= MAC=00:d0:c9:a6:47:17:00:c0:3a:6b:10:6c:08:00 SRC=192.168.0.249 DST=192.168.0.1 LEN=161 TOS=0x00 PREC=0x00 TTL=1 ID=30888 PROTO=UDP SPT=22124 DPT=1900 LEN=141
2b. dhcpd sees and actions this packet. Did dhcpd see the packet before iptables did? Maybe it did and that is the explanation. Certainly tcpdump can see all packets that are dropped by iptables. Perhaps the message below is only issued after some kind of acknowledgement
Apr 22 15:07:17 uno dhcpd: if LocoNetServer.loco.net IN TXT "31833bf41bc38609c2d9ff0dd96ce25498" rrset exists and LocoNetServer.loco.net IN A 192.168.0.249 rrset exists delete LocoNetServer.loco.net IN A 192.168.0.249: success.
2c. dhcpd instructs DNS to delete its entry for 192.168.0.249 and DNS does so
Apr 22 15:07:17 uno named[1473]: client 192.168.0.1#34461: updating zone 'loco.net/IN': deleting an RR
Apr 22 15:07:17 uno named[1473]: zone loco.net/IN: sending notifies (serial 105)
Apr 22 15:07:17 uno named[1473]: client 192.168.0.1#41651: updating zone 'loco.net/IN': deleting an RR

Actually, the more I look at this, the more the original order of the log appears logical, *if* it is the case that dhcpcd sees packets before netfilter does:

 
Apr 22 15:07:17 uno named[1473]: client 192.168.0.1#34461: updating zone 'loco.net/IN': deleting an RR
*** I typed "ipconfig/release on system 192.168.0.249. Dhcpd has seen this packet *before* iptables and has instructed named (bind) to delete the entry for 192.168.0.249. Named has done the first step of this.
Apr 22 15:07:17 uno kernel: IN=eth1 OUT= MAC=00:d0:c9:a6:47:17:00:c0:3a:6b:10:6c:08:00 SRC=192.168.0.249 DST=192.168.0.1 LEN=328 TOS=0x00 PREC=0x00 TTL=128
ID=30894 PROTO=UDP SPT=68 DPT=67 LEN=308
*** netfilter (iptables) sees the packet and drops it. Too late
Apr 22 15:07:17 uno dhcpd: if LocoNetServer.loco.net IN TXT "31833bf41bc38609c2d9ff0dd96ce25498" rrset exists and LocoNetServer.loco.net IN A 192.168.0.249 rrset exists
delete LocoNetServer.loco.net IN A 192.168.0.249: success.
*** dhcpd has some kind of acknowledge from bind that bind will delete 192.168.0.249
Apr 22 15:07:17 uno named[1473]: zone loco.net/IN: sending notifies (serial 105)
*** bind continues deleting
Apr 22 15:07:17 uno named[1473]: client 192.168.0.1#41651: updating zone 'loco.net/IN': deleting an RR
*** bind continues deleting
Apr 22 15:07:18 uno dhcpd: if LocoNetServer.loco.net IN A rrset doesn't exist delete LocoNetServer.loco.net IN TXT "31833bf41bc38609c2d9ff0dd96ce25498": success.
*** dhcpd gets another ack from bind
Apr 22 15:07:18 uno named[1473]: client 192.168.0.1#44873: updating zone '0.168.192.in-addr.arpa/IN': deleting rrset at '249.0.168.192.in-addr.arpa' PTR
*** bind deletes the reverse lookup entry
Apr 22 15:07:18 uno dhcpd: removed reverse map on 249.0.168.192.in-addr.arpa.
*** dhcpcd gets a message from bind that reverse entry is gone
Apr 22 15:07:18 uno named[1473]: zone 0.168.192.in-addr.arpa/IN: sending notifies (serial 74)
*** bind sends notifies of reverse lookup zone change to any other processes that would be interested
Apr 22 15:07:18 uno dhcpd: DHCPRELEASE of 192.168.0.249 from 00:c0:3a:6b:10:6c (LocoNetServer) via eth1 (found)
*** dhcpd finishes un-registering 192.168.0.249
Apr 22 15:07:22 uno named[1473]: zone loco.net/IN: sending notifies (serial 106)
*** bind sends notifies of loco.net zone change to any other processes that would be interested

All in all, I guess that's it. Now, does anyone know for a fact that dhcpcd listens in such a way that it will see requests before netfilter?
0
 
Duncan RoeSoftware DeveloperAuthor Commented:
I meant dhcpd, not dhcpcd
0
 
BlazCommented:
I believe there is no way for a program to see a packet before netfilter does.

Is there a dhcp server on this linux machine? Was the first log example about a client connectiong to your server via eth1? If so my previous post was wrong, sorry.

What about starting from ground up - drop all packets on all chains.
iptables -I INPUT -j DROP
iptables -I FORWARD -j DROP
iptables -I OUTPUT -j DROP

Don't forget to be at the console for this ;-).
If the DHCP works then maybe you have a problem with the DROP target on your machine? A hacked machine perhaps?

If it doesn't work than work your way towards your existing rule set - find where it gets strange.
0
 
Duncan RoeSoftware DeveloperAuthor Commented:
"I believe there is no way for a program to see a packet before netfilter does."
tcpdump can see them, so there is at least 1 way.
Yes there is a dhcp server on this system, and an dns that dhcp can configure (dynamic dns).Yes the first log shows a client releasing its IP, followed shortly after by acquiring one again.
This interaction did not take place when I didn't have the rule "/usr/sbin/iptables -A INPUT -i eth0 -j ACCEPT", so DROP was working then.
To clarify the network topography: there is only 1 other system on eth1's LAN (loco.net) (at least for now) and it is connected by crossover cable.
I will try your suggestion.
I think a crack is unlikely - one can never rule it out completely  of course - we are behind an outsourced firewall to a mainly Windows network.  I built uno's kernel fairly recently on a VMWare guest in that network. The guest runs an older kernel. I'll diff the files on the build system against uno anyway.

Next post, as promised earlier the nat table
0
 
Duncan RoeSoftware DeveloperAuthor Commented:

10:13:10# iptables -t nat -L -nvx --line-numbers
Chain PREROUTING (policy ACCEPT 10662 packets, 1555071 bytes)
num      pkts      bytes target     prot opt in     out     source               destination         
1           0        0 DNAT       tcp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:3389 to:192.168.0.249 
2           0        0 DNAT       tcp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:23 to:192.168.0.249 
3           0        0 DNAT       tcp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:21 to:192.168.0.249 
 
Chain POSTROUTING (policy ACCEPT 74 packets, 8129 bytes)
num      pkts      bytes target     prot opt in     out     source               destination         
1         368    35278 SNAT       all  --  *      ppp0    0.0.0.0/0            0.0.0.0/0           to:10.254.10.37 
 
Chain OUTPUT (policy ACCEPT 256 packets, 24103 bytes)
num      pkts      bytes target     prot opt in     out     source               destination         

Open in new window

0
 
Duncan RoeSoftware DeveloperAuthor Commented:
I tried:

iptables -I INPUT -j DROP
iptables -I FORWARD -j DROP
iptables -I OUTPUT -j DROP

and dhcp still worked. DNS updating stopped working as before - dhcp reports "connection refused".

diffing kernels - identical.
diffing modules directories - no modules changed, buit I added some custom-built ones by hand so dep, alias &c are different.

Looked at dhcp's open files, and as I suspected, there are some unusual-looking sockets. I think these are what is bypassing netfilter
11:09:40# lsof -p $(pgrep dhcpd)
COMMAND  PID USER   FD   TYPE     DEVICE    SIZE  NODE NAME
dhcpd   1007 root  cwd    DIR       22,1    4096     2 /
dhcpd   1007 root  rtd    DIR       22,1    4096     2 /
dhcpd   1007 root  txt    REG       22,1  507648 40113 /usr/sbin/dhcpd
dhcpd   1007 root  mem    REG       22,1   45518 32520 /lib/libnss_files-2.7.so
dhcpd   1007 root  mem    REG       22,1 1575187 32502 /lib/libc-2.7.so
dhcpd   1007 root  mem    REG       22,1  131493 32495 /lib/ld-2.7.so
dhcpd   1007 root    1w   REG       22,1    3799  8506 /var/state/dhcp/dhcpd.leases
dhcpd   1007 root    3u  unix 0xdddcc500          2512 socket
dhcpd   1007 root    4u   raw                     2515 00000000:0001->00000000:0000 st=0
dhcpd   1007 root    5u  IPv4       2519           UDP *:bootps 
dhcpd   1007 root    7u  sock        0,4          2518 can't identify protocol

Open in new window

0
 
Duncan RoeSoftware DeveloperAuthor Commented:
Guys,

Thanks for your input.

I have to say I think neither of you came close, so I am going to accept my own comment http:#24211084 as the solution.

Feel free to post an objection if you think that is unfair.

Cheers ... Duncan.
0
 
WizRd-LinuxCommented:
Have you given up or have you figured out the cause?  If the cause are you able to share it?
0
 
Duncan RoeSoftware DeveloperAuthor Commented:
I already shared it with you - at the foot of http:#24211084.
tcpdump is able to see incoming packets before iptables(netfilter) drops them. See the lsof of tcpdump below. Tcpdump only has 1 socket, and lsof can't identify its protocol. Dhcpd has a similar socket. Therefore dhcpd could be doing the same as tcpdump, thereby preempting netfilter. The man page doesn't say anything about that, and I haven't trawled through dhcpd source to see what it does with that socket (and the sock_raw socket). Given that DROP works for everything else I have tested, I was looking for a mechanism to explain why dhcp kept working, and I have found one. The existence of these unusual sockets is good enough for me as an explanation.


20:49:22# lsof -p $(pgrep tcpdump)
COMMAND  PID USER   FD   TYPE DEVICE    SIZE     NODE NAME
tcpdump 2258 dunc  cwd    DIR    8,2   12288 16220163 /home/dunc
tcpdump 2258 dunc  rtd    DIR    8,3    4096        2 /
tcpdump 2258 dunc  txt    REG    8,3  539096  2048532 /usr/sbin/tcpdump
tcpdump 2258 dunc  mem    REG    8,3   45552  1132313 /lib/libnss_files-2.5.so.incoming
tcpdump 2258 dunc  mem    REG    8,3 1528742  1132304 /lib/libc-2.5.so.incoming
tcpdump 2258 dunc  mem    REG    8,3  131484  1132301 /lib/ld-2.5.so.incoming
tcpdump 2258 dunc    0u   CHR  136,1                3 /dev/pts/1
tcpdump 2258 dunc    1u   CHR  136,1                3 /dev/pts/1
tcpdump 2258 dunc    2u   CHR  136,1                3 /dev/pts/1
tcpdump 2258 dunc    3u  sock    0,4             4492 can't identify protocol

Open in new window

0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 10
  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now