DHCP and Ident

DHCP and Ident

[Erik Wikström]

Hi

I've been thinking for some time now about the rules needed to allow the
firewallbox to receive its public IP from a DHCP-server but everywhere I
look it's done in different ways.

My first thought was to open up for the DHCP-request in the OUTPUT-chain
(all policies DROP) and let netfilters connection-tracking abilities
take care of the rest. Like this:

iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A INPUT -i $WAN -p UDP --dport 67 --sport 68 -j ACCEPT

But then I realised that since I don't have a source or destination
address netfilter will probably not be able to track the connection.

On the net I found this:
$IPTABLES -A OUTPUT -o eth1 -p tcp -s 0.0.0.0/32 --sport 67 \
	-d 255.255.255.255/32 --dport 68 -j ACCEPT
$IPTABLES -A OUTPUT -o $internal_int -p udp -s $internal_ip --sport 67 \
	-d 255.255.255.255 --dport 68 -j ACCEPT

$IPTABLES -A INPUT -i $internal_int -p tcp --sport 68 --dport 67 -j ACC\EPT
$IPTABLES -A INPUT -i $internal_int -p udp --sport 68 --dport 67 -j ACCEPT

Looks a bit much I think. Also found this:

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

But this opens two ports and the only protocol I know of that uses two
ports is FTP, so If someone could give me some hints I'd be happy.


I was also wondering if about Ident, today I use it only when connecting
to IRC-servers and have port 113 forwarded to the computer running the
IRC-client but this solution is not so good if another computer on my
network should have a need of Ident. So I was wondering: If I install an
Identd on my firewallbox and let it take care of requests would it work,
considering that the connection does not origin from the firewallbox?

Thanks for your time.

--
Erik Wikström

Re: DHCP and Ident

[Antony Stone]

On Saturday 10 July 2004 3:12 pm, Erik Wikström wrote:

> Hi
>
> I've been thinking for some time now about the rules needed to allow the
> firewallbox to receive its public IP from a DHCP-server but everywhere I
> look it's done in different ways.

> But then I realised that since I don't have a source or destination
> address netfilter will probably not be able to track the connection.

You'll find it (almost?) impossible to use netfilter to control DHCP requests.

You can do all the usual stuff with follow-up lease renewals and so on, but as 
you already said, before the first DHCP request, you don't have an IP 
address, and you're right - the IP stack and netfilter don't do much under 
those circumstances.

Another way to look at what I'm saying is "you don't have to do anything 
special with netfilter to allow your machine to get an address by DHCP", so I 
wouldn't worry about it.

> $IPTABLES  -I INPUT -i $LAN_IFACE -p udp --dport 67:68 --sport \
> 	67:68 -j ACCEPT
>
> But this opens two ports and the only protocol I know of that uses two
> ports is FTP, so If someone could give me some hints I'd be happy.

UDP 67 is used by the DHCP server - this is the port the client sends requests 
to, and it's the port the responses (and, often, informational messages once 
you have your lease) come from on the server

UDP 68 is used by the DHCP client - this is the port the client sends requests 
from, and it's the port the response from the server are sent to.

So, if you're running the client end, you only need to allow packets in to 
port 68 (and they'll be coming from the server's port 67)

RFC2131 is the definitive reference.

Just as a point of information, by the way, I get a DHCP address from my ISP 
on a cable modem, and I allow the requests out from my firewall, and the 
replies back again, but I block any new connections initiated from the 
outside (including the ISP).   My logs show a DHCP packet from ISP port 67 to 
my firewall port 68 about every 20 seconds (the lease time is 86400 seconds = 
24 hours).

> I was also wondering if about Ident, today I use it only when connecting
> to IRC-servers and have port 113 forwarded to the computer running the
> IRC-client but this solution is not so good if another computer on my
> network should have a need of Ident. So I was wondering: If I install an
> Identd on my firewallbox and let it take care of requests would it work,
> considering that the connection does not origin from the firewallbox?

My experience of most things which want an ident response is that if they get 
any response at all, they're happy.   It doesn't matter whether it's accurate 
or not - they just want some sort of response.

This may depend on the particular IRC server, however, and as always, YMMV.

For some "fake identd" software, see for example:

http://www.guru-group.fi/~too/sw/identd.readme
http://hangout.de/fakeidentd

And even a trivial Perl script to do it for you:

http://www.bovine.net/~jlawson/coding/fake-identd/identd.txt

Regards,

Antony.

-- 
I love deadlines.   I love the whooshing noise they make as they go by.

 - Douglas Noel Adams

                                                     Please reply to the list;
                                                           please don't CC me.

Re: DHCP and Ident

[Georgi Alexandrov]

Antony Stone wrote:

>On Saturday 10 July 2004 3:12 pm, Erik Wikström wrote:
>
>  
>
>>Hi
>>
>>I've been thinking for some time now about the rules needed to allow the
>>firewallbox to receive its public IP from a DHCP-server but everywhere I
>>look it's done in different ways.
>>    
>>
>
>  
>
>>But then I realised that since I don't have a source or destination
>>address netfilter will probably not be able to track the connection.
>>    
>>
>
>You'll find it (almost?) impossible to use netfilter to control DHCP requests.
>
>You can do all the usual stuff with follow-up lease renewals and so on, but as 
>you already said, before the first DHCP request, you don't have an IP 
>address, and you're right - the IP stack and netfilter don't do much under 
>those circumstances.
>
>Another way to look at what I'm saying is "you don't have to do anything 
>special with netfilter to allow your machine to get an address by DHCP", so I 
>wouldn't worry about it.
>
>  
>
>>$IPTABLES  -I INPUT -i $LAN_IFACE -p udp --dport 67:68 --sport \
>>	67:68 -j ACCEPT
>>
>>But this opens two ports and the only protocol I know of that uses two
>>ports is FTP, so If someone could give me some hints I'd be happy.
>>    
>>
>
>UDP 67 is used by the DHCP server - this is the port the client sends requests 
>to, and it's the port the responses (and, often, informational messages once 
>you have your lease) come from on the server
>
>UDP 68 is used by the DHCP client - this is the port the client sends requests 
>from, and it's the port the response from the server are sent to.
>
>So, if you're running the client end, you only need to allow packets in to 
>port 68 (and they'll be coming from the server's port 67)
>
>RFC2131 is the definitive reference.
>
>Just as a point of information, by the way, I get a DHCP address from my ISP 
>on a cable modem, and I allow the requests out from my firewall, and the 
>replies back again, but I block any new connections initiated from the 
>outside (including the ISP).   My logs show a DHCP packet from ISP port 67 to 
>my firewall port 68 about every 20 seconds (the lease time is 86400 seconds = 
>24 hours).
>
>  
>
>>I was also wondering if about Ident, today I use it only when connecting
>>to IRC-servers and have port 113 forwarded to the computer running the
>>IRC-client but this solution is not so good if another computer on my
>>network should have a need of Ident. So I was wondering: If I install an
>>Identd on my firewallbox and let it take care of requests would it work,
>>considering that the connection does not origin from the firewallbox?
>>    
>>
>
>My experience of most things which want an ident response is that if they get 
>any response at all, they're happy.   It doesn't matter whether it's accurate 
>or not - they just want some sort of response.
>
>This may depend on the particular IRC server, however, and as always, YMMV.
>
>For some "fake identd" software, see for example:
>
>http://www.guru-group.fi/~too/sw/identd.readme
>http://hangout.de/fakeidentd
>
>And even a trivial Perl script to do it for you:
>
>http://www.bovine.net/~jlawson/coding/fake-identd/identd.txt
>
>Regards,
>
>Antony.
>
>  
>
About the identd stuff:
If you're DROPing it (or like most cases - default DROP policies), not 
forwarding it to the clients or not having identd server that will 
probably cause slow irc connecting. The irc server will wait for some 
kind of response (any kind in most cases ;-) as -j DROP really drops 
requests without replying.
So the solution is to forward identd requests to the clients or use 
something like on the router/gw/fw:
iptables -A INPUT -p tcp --dport 113 -j REJECT
that will return icmp-port-unreachable (or just port-unreachable, not 
sure) to the server and will resolve the irc issue.

regards,
Georgi Alexandrov