Problem with rdate and iptables

Problem with rdate and iptables

[Eric Bauman]

Hi there,

I'm having an issue with getting rdate working over UDP.
I'm using the rule "--append INPUT --match state --state 
ESTABLISHED,RELATED --jump ACCEPT". It works fine over TCP, but times 
out when using UDP.

Any ideas?

Cheers,
Eric

Re: Problem with rdate and iptables

[Pascal Hambourg]

Hello,

Eric Bauman a écrit :
> 
> I'm having an issue with getting rdate working over UDP.
> I'm using the rule "--append INPUT --match state --state 
> ESTABLISHED,RELATED --jump ACCEPT". It works fine over TCP, but times 
> out when using UDP.

Is this on the server or client ? That rule does not care about the
protocol, but a rule alone without the rest of the ruleset does not tell
much.

> Any ideas?

Rather a suggestion. You could trace relevant traffic with a packet
sniffer and/or iptables LOG rules and try to see what's going on.
Disable all filtering and check if it works. Does the rdate server
accept UDP queries ?

Re: Problem with rdate and iptables

[Eric Bauman]

On 25/04/2010 21:54, Pascal Hambourg wrote:
> Is this on the server or client ? That rule does not care about the
> protocol, but a rule alone without the rest of the ruleset does not tell
> much.
>
>> Any ideas?
>
> Rather a suggestion. You could trace relevant traffic with a packet
> sniffer and/or iptables LOG rules and try to see what's going on.
> Disable all filtering and check if it works. Does the rdate server
> accept UDP queries ?

Hi there, thank-you for the reply.

This is an rdate client accessing a timeserver.

The only only other rules I have are default policies (DROP for INPUT 
and FORWARD, and ACCEPT for OUTPUT), ACCEPT for all loopback traffic, 
and ACCEPT for various incoming ports (eg. HTTP etc.).

It works fine with all rules removed, and it works fine over TCP with 
all rules enabled.

Cheers,
Eric

Re: Problem with rdate and iptables

[Pascal Hambourg]

Eric Bauman a écrit :
> 
> This is an rdate client accessing a timeserver.
> 
> The only only other rules I have are default policies (DROP for INPUT 
> and FORWARD, and ACCEPT for OUTPUT), ACCEPT for all loopback traffic, 
> and ACCEPT for various incoming ports (eg. HTTP etc.).
> 
> It works fine with all rules removed, and it works fine over TCP with 
> all rules enabled.

Could you capture the time query and reply packets (port 37) with a
packet sniffer such as tcpdump or wireshark ?

Re: Problem with rdate and iptables

[Eric Bauman]

On 26/04/2010 21:28, Pascal Hambourg wrote:

> Could you capture the time query and reply packets (port 37) with a
> packet sniffer such as tcpdump or wireshark ?

Yes, I just tried that, and I think it shows the problem. It turns out 
that a TIME request is being made to IP A, but the response is coming 
from IP B! So I'm not surprised iptables isn't matching it as 
established or related.

That leads me to ask, who is in the wrong? Should iptables be matching 
the response, should the TIME server be responding with the address from 
which it receives a query, or is it my fault for not knowing that a 
request/response IP mismatch is legal behaviour and crafting an 
appropriate rule?

Cheers,
Eric

Re: Problem with rdate and iptables

[Jan Engelhardt]

On Monday 2010-04-26 15:02, Eric Bauman wrote:
> On 26/04/2010 21:28, Pascal Hambourg wrote:
>> Could you capture the time query and reply packets (port 37) with a
>> packet sniffer such as tcpdump or wireshark ?
>
> Yes, I just tried that, and I think it shows the problem. It turns out that a
> TIME request is being made to IP A, but the response is coming from IP B! So
> I'm not surprised iptables isn't matching it as established or related.
>
> That leads me to ask, who is in the wrong? Should iptables be matching the
> response, should the TIME server be responding with the address from which it
> receives a query, or is it my fault for not knowing that a request/response IP
> mismatch is legal behaviour and crafting an appropriate rule?

RFC 868 does not specify any addresses for UDP. I guess someone 
exploited that in a bogus implementation already ...

Use NTP instead? :-)