I just discovered a security issue, I was reviewing my IP tables rules, and discovered that there was no rule for DHCP traffic (I have DROP-policy for all chains), but I still get IP-address, subnet-mask etc. from the DHCP server. So I stater to look into it, and after running wireshark, and few searches, I found that DHCPCD uses AF_PACKETs sockets, so it bypasses TCP/IP stack (?).

I looked deeper into it, wrote a short program in C, using (AF_PACKET,SOCK_RAW,ETH_P_ALL) with static HW,IP and TCP header (just for testing purpose). Try to require data from a server that's not on the IPTables whitelist. I got a little heart jumps, when i discovered that IPTables had no chance to block it.

I'm running Debian 8 «Jessie». And for you guys who thinks that I have overlooked something in my IPTables rules, I have very strict rules, where every single target is very spesific, filtered by interfaces, IP-addresses, destination-ports, protocols, ctstates, etc.

Is there anyone else who knowns anything more about this issue? Or has any solution on how to block this traffic, or force all traffic to go by TCP/IP-stack and IPTables before leaving the host?

  • trivia: Linux (2.0) allowed the use of the address on an interface. The dhcp client then didn't need anything special to emit a DHCP DISCOVERY packet (with source This can be found for eg in the source of isc's dhcp version 2, with the shipped client/scripts/linux using ifconfig $interface inet netmask .... It was found that with certain settings, Linux would use its IP for ARP which is of course not allowed, so the feature was removed, and using a raw socket became needed for the DHCP clients to build the packet with source – A.B Jun 10 '18 at 8:46

You need root privilege (or at least CAP_NET_RAW) to use AF_PACKET. It is in general difficult to prevent root processes from doing anything. The best solution is to not run untrusted processes.

An alternative would be to run all (root) processes in a separate network namespace so that all traffic has to be routed through the host. That way you could force (namespace) AF_PACKET traffic to go through the IP stack (of the host).

| improve this answer | |
  • With another namespace, you mean like sandboxing or VM? But in this case I was a little quick with my conclutions, I didn't think so far ahead. @sourcejedi made a good point. – BufferOverflow Jun 3 '18 at 20:29
  • @BufferOverflow I am talking about ip netns (man ip-netns) which is lightweight sandboxing. – Hauke Laging Jun 5 '18 at 17:29

It certainly does have implications to watch out for. It's irritating, though it's a relatively special case.

AF_PACKET is a privileged operation. This means it's not something your unprivileged users can get into trouble by using.

Software that uses it will be similar to a DHCP server - low level network infrastructure - otherwise it would be able to use the normal, simpler interface. As a sysadmin, you will surely know if you have installed a DHCP server. The same would apply in some other cases as well.

1. firewall with different zones

It's possible you define a firewall with multiple "zones" or similar using iptables, e.g. on a Linux box acting which acts as a firewall between your network and the internet. In this case, since DHCPD etc bypasses this firewall, you must indeed configure your policy into DHCPD etc separately. E.g.

If more than one network interface is attached to the system, but the DHCP server should only be started on one of the interfaces, configure the DHCP server to start only on that device. In /etc/sysconfig/dhcpd, add the name of the interface to the list of DHCPDARGS:

# Command line options here 

This is useful for a firewall machine with two network cards. One network card can be configured as a DHCP client to retrieve an IP address to the Internet. The other network card can be used as a DHCP server for the internal network behind the firewall. Specifying only the network card connected to the internal network makes the system more secure because users can not connect to the daemon via the Internet.

-- https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-dhcp-configuring-server.html

AFAICT, there is not any finer grained option for ISC DHCPD. If you wanted finer grained control, you would have to implement this at the network level... while using DHCP relays of your choice which do provide more fine-grained control. Since the initial DHCP receiver needs to be on the same network as the DHCP client. As pointed out by Hauke Laging, a Linux server is capable of creating virtual networks in a number of ways, e.g. it shouldn't be necessary to resort to a physically separate firewall box unless you really want to :).

2. Packet sniffers

You're supposed to be terrified of running the Wireshark packet sniffer, because it's running a whole bunch of parsers written in a memory-unsafe language. And the traffic it receives won't be limited by the firewall. https://wiki.wireshark.org/Security

3. outgoing firewall

It's slightly ambiguous, but it sounds like your test program sent a packet which would have been blocked by your iptables firewall. I.e. you are filtering outgoing packets.

This is not the most common configuration. This question doesn't seem to be super specific about the threat model being used, and why this uncommon configuration is being used, so I'm not sure what advice I can give.

If you run a program with privileges that include CAP_NET_RAW then yes, it has the ability to send packets which are not affected by iptables. But equally, if you run a program with privileges that include CAP_NET_ADMIN, it has the ability to install an iptables rule which allows it to send whatever packet it wants :).

| improve this answer | |
  • You have a good point in the last section. My attempt was to prevent malicious software (In case I get infected), to calling «home». But as you wrote, in case of root access, it also has access to alter the iptables rules. – BufferOverflow Jun 3 '18 at 20:25
  • @BufferOverflow yea... if you get infected and the infection is running with some level of privilege on your linux installation, then AFAIK it is not very practical to try to configure that same linux installation to prevent the infection from phoning home. – sourcejedi Jun 3 '18 at 20:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.