First off, I'd like to thank the CentOS community for an awesome distro. I'm a convert.
My problem isn't so much a problem as a puzzle. I'll admit that I'm relatively new to this stuff, so my understanding of how a DHCP broadcast works might be flawed. I've setup dhcpd as per the procedures found here:
[url=https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-DHCP_Servers.html]redhat.com[/url]
Everything is working great, but that's the problem. I was too dump to open up the proper ports on my firewall before I started testing out my shiny new DHCP server, and it took a moment to dawn on me that it shouldn't work yet. I never opened port 67 on my server's firewall.
I guess the question I'm left with is this. Does Netfilter handle a broadcast (like for DHCP) differently than other traffic? Is there something special about the src:0.0.0.0:68 dst:255.255.255.255:67 UDP transmission that somehow Netfilter allows it to pass through so dhcpd is able to receive it?
I was curious about what the network interface was seeing, so I ran tcpdump while a new device connected to the network. All I see is my DHCP server (172.16.0.11) handing out the address to my client. I kind of expected to see a IP 0.0.0.0:68 > 172.16.0.11:67 or something of that nature.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
07:28:50.850163 IP 172.16.0.11.67 > 172.16.0.103.68: BOOTP/DHCP, Reply, length 300
Can anyone point in the direction of some documentation that might explain to me how this is possible? ...or better yet, can anyone explain in simple English? Just about any help would be appreciated at this point. I'm lost.
[SOLVED] My DHCP server responds to requests, but port 67 is not open. How?
[SOLVED] My DHCP server responds to requests, but port 67 is
DHCP broadcast is special.
The dhclient does not have any IP to start with. It can only broadcast its MAC to local subnet hoping that there is a dhcpd willing to reply. Thus, MAC is the only info in the packet that you could filter by. The dhcpd apparently listens on the stack at a point lower than netfilter. The dhcpd/dnsmasq can itself dictate whether it gives an IP for particular MAC.
The 'ebtables' might be able to (pre)filter, because it handles the "raw" packets by MAC, rather than the IP-layer. The good part with these broadcasts (and ARP packets) is that they are not routed (unless there is a DHCP relay).
One (trickery) way to filter is to put a filtering bridge on the cable. Such device, lacking dhcpd, can see and drop the ports 67,68 successfully.
The broadcasting should not be necessary when dhclient refreshes an already granted IP, so then netfilter might make a difference.
The dhclient does not have any IP to start with. It can only broadcast its MAC to local subnet hoping that there is a dhcpd willing to reply. Thus, MAC is the only info in the packet that you could filter by. The dhcpd apparently listens on the stack at a point lower than netfilter. The dhcpd/dnsmasq can itself dictate whether it gives an IP for particular MAC.
The 'ebtables' might be able to (pre)filter, because it handles the "raw" packets by MAC, rather than the IP-layer. The good part with these broadcasts (and ARP packets) is that they are not routed (unless there is a DHCP relay).
One (trickery) way to filter is to put a filtering bridge on the cable. Such device, lacking dhcpd, can see and drop the ports 67,68 successfully.
The broadcasting should not be necessary when dhclient refreshes an already granted IP, so then netfilter might make a difference.
Re: My DHCP server responds to requests, but port 67 is not open. How?
That's the strange part. I left tcpdump running so I could watch what happened when the address lease expired. The client sends the request to port 67, and the server replies right back.
[code]
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:54:23.147366 IP 172.16.0.102.68 > 172.16.0.11.67: BOOTP/DHCP, Request from c0:d9:62:2d:d4:23, length 300
14:54:23.148197 IP 172.16.0.11.67 > 172.16.0.102.68: BOOTP/DHCP, Reply, length 300
[/code]
It made me second guess my firewall configuration, but I've tested it a little, and it's definitely locked down as far as I can tell. I configured the firewall using a script, then double checked the settings with "iptables -L", and saved it by doing "/sbin/service iptables save".
[code]
#!/bin/bash
#
# firewall.sh v0.1.0
#
# Written for dev1.iris.info as the baseline firewall configuration.
#
#
# Flush Tables
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -F POSTROUTING -t nat
iptables -F PREROUTING -t nat
# Allow Established
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state RELATED -j ACCEPT
# Allow SSH
iptables -A INPUT -p tcp --dport 44844 -j ACCEPT
# Allow loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT
# Deny everything else
iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP
[/code]
nmap shows port 67 as filtered, so I'm assuming that I'm not screwing up the firewall configuration. If dhcpd is indeed listening to traffic ahead of netfilter/iptables, it would mean that my understanding of how netfilter/iptables filters traffic is fundamentally flawed. Cool! :-) I guess I have a lot of reading to do now...
[code]
PS C:\Users\Kenny> nmap -T5 -PN -p 67 172.16.0.11
Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-20 15:09 Central Daylight Time
Nmap scan report for 172.16.0.11
Host is up (0.00s latency).
PORT STATE SERVICE
67/tcp filtered dhcps
MAC Address: 18:A9:05:90:2C:0C (Hewlett-Packard Company)
Nmap done: 1 IP address (1 host up) scanned in 2.50 seconds
[/code]
Thank you jlehtone for your help! If anyone can see a mistake that I've made, please, point it out!
[code]
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:54:23.147366 IP 172.16.0.102.68 > 172.16.0.11.67: BOOTP/DHCP, Request from c0:d9:62:2d:d4:23, length 300
14:54:23.148197 IP 172.16.0.11.67 > 172.16.0.102.68: BOOTP/DHCP, Reply, length 300
[/code]
It made me second guess my firewall configuration, but I've tested it a little, and it's definitely locked down as far as I can tell. I configured the firewall using a script, then double checked the settings with "iptables -L", and saved it by doing "/sbin/service iptables save".
[code]
#!/bin/bash
#
# firewall.sh v0.1.0
#
# Written for dev1.iris.info as the baseline firewall configuration.
#
#
# Flush Tables
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -F POSTROUTING -t nat
iptables -F PREROUTING -t nat
# Allow Established
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state RELATED -j ACCEPT
# Allow SSH
iptables -A INPUT -p tcp --dport 44844 -j ACCEPT
# Allow loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT
# Deny everything else
iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP
[/code]
nmap shows port 67 as filtered, so I'm assuming that I'm not screwing up the firewall configuration. If dhcpd is indeed listening to traffic ahead of netfilter/iptables, it would mean that my understanding of how netfilter/iptables filters traffic is fundamentally flawed. Cool! :-) I guess I have a lot of reading to do now...
[code]
PS C:\Users\Kenny> nmap -T5 -PN -p 67 172.16.0.11
Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-20 15:09 Central Daylight Time
Nmap scan report for 172.16.0.11
Host is up (0.00s latency).
PORT STATE SERVICE
67/tcp filtered dhcps
MAC Address: 18:A9:05:90:2C:0C (Hewlett-Packard Company)
Nmap done: 1 IP address (1 host up) scanned in 2.50 seconds
[/code]
Thank you jlehtone for your help! If anyone can see a mistake that I've made, please, point it out!
Re: My DHCP server responds to requests, but port 67 is not open. How?
Another thanks to whomever just went through and properly formatted my post with the proper tags. I've not spent much time with forums. I promise I won't screw it up again.
[code]
test code
[/code]
[code]
test code
[/code]
Re: [SOLVED] My DHCP server responds to requests, but port 67 is not open. How?
For anyone that may stumble upon this in the future, I think I've found the explanation. The simple answer is that DHCP is indeed special. To quote what a stranger quoted,
Per Mark Andrews of isc.org:
"DHCP uses packet filters and these tie into the IP stack before the firewall."
[url=http://thr3ads.net/netfilter-buglog/2011/07/1961358-Bug-730-New-DHCP-request-and-other-traffic-bypasses-iptables-netfilter]http://thr3ads.net/netfilter-buglog[/url]
[url=http://lkml.indiana.edu/hypermail/linux/kernel/0910.1/02073.html]indiana.edu[/url]
[url=http://www.linuxquestions.org/questions/linux-security-4/bypass-of-iptables-by-internal-programs-946035/]linuxquestions.org[/url]
I think this thread can now be marked as solved. jlehtone hit it right on the nose hours ago.
Per Mark Andrews of isc.org:
"DHCP uses packet filters and these tie into the IP stack before the firewall."
[url=http://thr3ads.net/netfilter-buglog/2011/07/1961358-Bug-730-New-DHCP-request-and-other-traffic-bypasses-iptables-netfilter]http://thr3ads.net/netfilter-buglog[/url]
[url=http://lkml.indiana.edu/hypermail/linux/kernel/0910.1/02073.html]indiana.edu[/url]
[url=http://www.linuxquestions.org/questions/linux-security-4/bypass-of-iptables-by-internal-programs-946035/]linuxquestions.org[/url]
I think this thread can now be marked as solved. jlehtone hit it right on the nose hours ago.