netfilter machine in between 2 servers

netfilter machine in between 2 servers

[Sandy C]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

Hi there,
   I have 3 Linux machines. One configured as a server, the second as a client, and the third sniffing packets transferring between the 2. All 3 machines are hooked up to each other over a hub, and all are running 100MB/s
 
   Using ethereal I can see the packets going between the server and the client. I would like the third, sniffing machine to be able to filter packets going between the client and the server. This doesn't seem to work though.
 
So I have the following rule on the third machine:
iptables -A INPUT -p 80 -j LOG
 
meaning just log all http requests. It doesn't work, but if I have this rule on either the client or the server, it works as expected.
 
I get the feeling I'm missing something very basic. Can anyone help?

Thanks,
S


Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam

[-- Attachment #2: Type: text/html, Size: 1137 bytes --]

Re: netfilter machine in between 2 servers

[Antony Stone]

On Sunday 14 March 2004 9:28 am, Sandy C wrote:

> Hi there,
>    I have 3 Linux machines. One configured as a server, the second as a
> client, and the third sniffing packets transferring between the 2. All 3
> machines are hooked up to each other over a hub, and all are running
> 100MB/s
>
>    Using ethereal I can see the packets going between the server and the
> client.

All sounds good so far.

> I would like the third, sniffing machine to be able to filter
> packets going between the client and the server. This doesn't seem to work
> though.

No, the third machine cannot filter anything, because nothing passes through 
it.   The third machine is simply seeing the packets as they appear on all 
the sockets of the hub, quite independently of the fact that the client and 
server are talking directly to each other through that hub.

> So I have the following rule on the third machine:
> iptables -A INPUT -p 80 -j LOG
>
> meaning just log all http requests. It doesn't work, but if I have this
> rule on either the client or the server, it works as expected.

Indeed.   The INPUT chain is for packets addressed to the machine with the 
rule running on it - so therefore it works as expected if you put the rule on 
the client or server, because they are actually sending and receiving 
packets.

It doesn't work if you look for packets in the INPUT chain of a machine which 
simply happens to be running ethereal (or tcpdump, or any other sniffer), 
because those packets are not addressed to the machine itself, and therefore 
never make they way up the TCP/IP stack and enter netfilter.   Packet 
sniffers grab the packets much closer to the interface than this, and will 
see stuff which netfilter does not.

> I get the feeling I'm missing something very basic. Can anyone help?

You should think of netfilter as an add-on to Linux's routing capabilties.   
Normal routing allows a machine to pass packets between interfaces.   
Netfilter allows those packets to be blocked, or logged, or redirected to 
another address.   If you are not routing packets through a machine, and it 
is not one of the endpoints taking part in the communication, then you cannot 
filter them with netfilter.

Your setup is not routing packet through machine 3 because client and server 
are on the same subnet, happily talking to each other directly, without any 
need to route through something else.   If you were using a switch instead of 
a hub, machine 3 wouldn't even see the packets in the first place using 
ethereal :)

Hope this helps,

Antony.

-- 
How I want a drink, alcoholic of course, after the heavy chapters involving 
quantum mechanics.

 - 3.14159265358979

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

Re: netfilter machine in between 2 servers

[Sandy C]

[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]

Hi Anthony,
    Great explanation. It seems like what you're saying is *if * I did want to keep track of whatever's going on (i.e. LOG http packets)  using iptables I would need to make sure the client and server are part of 2 different nets, correct? So...the 3rd machine would neet to route and filter.
 
   Otherwise how hard would it be to go into the code and make iptables recognize broadcast packets ala ethereal? From reading the docs, it seems like it wouldn't be possible, because the furtherest "up" that netfilter can go is to the "PREROUTING" hook.
 
 
Thanks,
S


Antony Stone <Antony@Soft-Solutions.co.uk> wrote: 
On Sunday 14 March 2004 9:28 am, Sandy C wrote:

>> So I have the following rule on the third machine:
> iptables -A INPUT -p 80 -j LOG
>
> meaning just log all http requests. It doesn't work, but if I have this
> rule on either the client or the server, it works as expected.

Indeed. The INPUT chain is for packets addressed to the machine with the 
rule running on it - so therefore it works as expected if you put the rule on 
the client or server, because they are actually sending and receiving 
packets.

It doesn't work if you look for packets in the INPUT chain of a machine which 
simply happens to be running ethereal (or tcpdump, or any other sniffer), 
because those packets are not addressed to the machine itself, and therefore 
never make they way up the TCP/IP stack and enter netfilter. Packet 
sniffers grab the packets much closer to the interface than this, and will 
see stuff which netfilter does not.

> I get the feeling I'm missing something very basic. Can anyone help?

You should think of netfilter as an add-on to Linux's routing capabilties. 
Normal routing allows a machine to pass packets between interfaces. 
Netfilter allows those packets to be blocked, or logged, or redirected to 
another address. If you are not routing packets through a machine, and it 
is not one of the endpoints taking part in the communication, then you cannot 
filter them with netfilter.

Your setup is not routing packet through machine 3 because client and server 
are on the same subnet, happily talking to each other directly, without any 
need to route through something else. If you were using a switch instead of 
a hub, machine 3 wouldn't even see the packets in the first place using 
ethereal :)

Hope this helps,

Antony.


Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam

[-- Attachment #2: Type: text/html, Size: 3001 bytes --]

Re: netfilter machine in between 2 servers

[Antony Stone]

On Sunday 14 March 2004 6:27 pm, Sandy C wrote:

> Hi Antony,
>     Great explanation. It seems like what you're saying is *if * I did want
> to keep track of whatever's going on (i.e. LOG http packets)  using
> iptables I would need to make sure the client and server are part of 2
> different nets, correct? So...the 3rd machine would neet to route and
> filter.

Correct.

>    Otherwise how hard would it be to go into the code and make iptables
> recognize broadcast packets ala ethereal?

If by "broadcast" you mean "packets sent to an IP subnet broadcast address" 
the netfilter will do that already.

However, I don't think you do mean that, I think you mean "packets which 
happen to come out of all sockets on a hub", and the answer is "very 
difficult" because netfilter is plugged into the routing mechanism, and the 
routing mechanism just doesn't see packets which aren't addressed to the 
machine, either as an endpoint or as a router.

Besides, why do you want netfilter to do your logging, if you can run 
ethereal?   You get a lot more information out of ethereal, and it can show 
you the protocols in a much more meaningful manner.

Regards,

Antony.

-- 
If builders made buildings the way programmers write programs, then the first 
woodpecker to come along would destroy civilisation.

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

Re: netfilter machine in between 2 servers

[Sandy C]

--- Antony Stone <Antony@Soft-Solutions.co.uk> wrote:
> On Sunday 14 March 2004 6:27 pm, Sandy C wrote:
> 
> >    Otherwise how hard would it be to go into the
> code and make iptables
> > recognize broadcast packets ala ethereal?
> 
> If by "broadcast" you mean "packets sent to an IP
> subnet broadcast address" 
> the netfilter will do that already.
> 
> However, I don't think you do mean that, I think you
> mean "packets which 
> happen to come out of all sockets on a hub", and the
> answer is "very 
> difficult" because netfilter is plugged into the
> routing mechanism, and the 
> routing mechanism just doesn't see packets which
> aren't addressed to the 
> machine, either as an endpoint or as a router.

Correct, this is really what I meant. Didn't realize
you were psychic as well :-)

> Besides, why do you want netfilter to do your
> logging, if you can run 
> ethereal?   You get a lot more information out of
> ethereal, and it can show 
> you the protocols in a much more meaningful manner.

I really need something that can do a little bit of
both.  I need to be able to sniff the packets (ala
ethereal), and if they are of a certain type, I need
to take some action on them (ala netfilter) I'd prefer
not to do any routing.

Now you've spelled it out though, its not clear to me
if its possible.

Thanks!
S


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com

Re: netfilter machine in between 2 servers

[Antony Stone]

On Sunday 14 March 2004 7:47 pm, Sandy C wrote:

> --- Antony Stone wrote:
>
> > Besides, why do you want netfilter to do your logging, if you can run
> > ethereal?   You get a lot more information out of ethereal, and it can
> > show you the protocols in a much more meaningful manner.
>
> I really need something that can do a little bit of
> both.  I need to be able to sniff the packets (ala
> ethereal), and if they are of a certain type, I need
> to take some action on them (ala netfilter) I'd prefer
> not to do any routing.
>
> Now you've spelled it out though, its not clear to me
> if its possible.

Think of the setup like this:

One machine (client or server) sends a packet to the other, and that packet 
also gets picked up by the sniffer.

It's too late then to think about doing any filtering, or other action to 
change the packet, because by the time the sniffer has seen it, so has the 
machine it was addressed to (server or client).

I hope this explains why you cannot possibly do what you wanted.

Regards,

Antony.

-- 
People who use Microsoft software should be certified.

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