Изменить стиль страницы

Letting DHCP requests through iptables

This is a fairly simple task really, once you get to know how DHCP works, however, you must be a little bit cautious with what you do let in and what you do not let in. First of all, we should know that DHCP works over the UDP protocol. Hence, this is the first thing to look for. Second, we should check which interface we get and send the request from. For example, if our eth0 interface is set up with DHCP, we should not allow DHCP requests on eth1. To make the rule a bit more specific, we only allow the actual UDP ports used by DHCP, which should be ports 67 and 68. These are the criteria that we choose to match packets on, and that we allow. The rule would now look like this:

$IPTABLES -I INPUT -i $LAN_IFACE -p udp --dport 67:68 --sport \

67:68 -j ACCEPT

Do note that we allow all traffic to and from UDP port 67 and 68 now, however, this should not be such a huge problem since it only allows requests from hosts doing the connection from port 67 or 68 as well. This rule could, of course, be even more restrictive, but it should be enough to actually accept all DHCP requests and updates without opening up too large of holes. If you are concerned, this rule could of course be made even more restrictive.

mIRC DCC problems

mIRC uses a special setting which allows it to connect through a firewall and to make DCC connections work properly without the firewall knowing about it. If this option is used together with iptables and specifically the ip_conntrack_irc and ip_nat_irc modules, it will simply not work. The problem is that mIRC will automatically NAT the inside of the packets for you, and when the packet reaches the firewall, the firewall will simply not know how and what to do with it. mIRC does not expect the firewall to be smart enough to take care of this by itself by simply querying the IRC server for its IP address and sending DCC requests with that address instead.

Turning on the "I am behind a firewall" configuration option and using the ip_conntrack_irc and ip_nat_irc modules will result in Netfilter creating log entries with the following content "Forged DCC send packet".

The simplest possible solution is to just uncheck that configuration option in mIRC and let iptables do the work. This means, that you should tell mIRC specifically that it is not behind a firewall.

Appendix C. ICMP types

This is a complete listing of all ICMP types. Note the reference pointing to the RFC or person who introduced the type and code. For a complete and absolute up to date listing of all ICMP types and codes, look at the icmp-parameters document at Internet Assigned Numbers Authority.

Note Iptables and netfilter uses ICMP type 255 internally since it is not reserved for any real usage, and most likely will never have any real usage. If you set a rule to match iptables -A INPUT -p icmp --icmp-type 255 -j DROP, this will DROP all ICMP packets. It is in other words used to match all ICMP types.

Table C-1. ICMP types

TYPECODEDescriptionQueryErrorReference
Echo Replyx RFC792
3Network Unreachable xRFC792
31Host Unreachable xRFC792
32Protocol Unreachable xRFC792
33Port Unreachable xRFC792
34Fragmentation needed but no frag. bit set xRFC792
35Source routing failed xRFC792
36Destination network unknown xRFC792
37Destination host unknown xRFC792
38Source host isolated (obsolete) xRFC792
39Destination network administratively prohibited xRFC792
310Destination host administratively prohibited xRFC792
311Network unreachable for TOS xRFC792
312Host unreachable for TOS xRFC792
313Communication administratively prohibited by filtering xRFC1812
314Host precedence violation xRFC1812
315Precedence cutoff in effect xRFC1812
4Source quench  RFC792
5Redirect for network  RFC792
51Redirect for host   
52Redirect for TOS and network  RFC792
53Redirect for TOS and host  RFC792
8Echo requestx RFC792
9Router advertisement - Normal router advertisement  RFC1256
916Router advertisement - Does not route common traffic  RFC2002
10Route selection  RFC1256
11TTL equals 0 during transit xRFC792
111TTL equals 0 during reassembly xRFC792
12IP header bad (catchall error) xRFC792
121Required options missing xRFC1108
122IP Header bad length xRFC792
13Timestamp request (obsolete)x RFC792
14 Timestamp reply (obsolete)x RFC792
15Information request (obsolete)x RFC792
16Information reply (obsolete)x RFC792
17Address mask requestx RFC950
18Address mask replyx RFC950
20-29 Reserved for robustness experiment  Zaw-Sing Su
30Traceroutex RFC1393
31Datagram Conversion Error xRFC1475
32Mobile Host Redirect  David Johnson
33IPv6 Where-Are-Youx Bill Simpson
34IPv6 I-Am-Herex Bill Simpson
35Mobile Registration Requestx Bill Simpson
36Mobile Registration Replyx Bill Simpson
39SKIP  Tom Markson
40Photuris  RFC2521