iptables and virtual hosts problem

Hello!

I have a server which is running 2 different virtual hosts (vserver),
let's call them S for the server, A and B for the virtual hosts A and B.
S, A and B have different ip-addresses (say s.s.s.s, a.a.a.a and b.b.b.b).

Since the server isn't really forwarding anything I haven't used the
FORWARD chain for anything, and I use INPUT and OUTPUT to regulate the
flow to the different servers, for example:

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -I INPUT -d a.a.a.a -p tcp --dport 80 -j ACCEPT
on the server
seems to do what I want. In the example above letting A and only A
answer requests on port 80.

However, when I try to regulate the flow of traffic between the
different "machines" (S, A, and B) strange things happen.

For example:
iptables -I OUTPUT -d a.a.a.a -p tcp --dport 25 -j ACCEPT
doesn't only allow any of the "machines" to try to contact port 25 on A,
but it *also allows A to answer* !!!

I would very much like to know why:
iptables -I INPUT [...] -d a.a.a.a -p tcp --dport 25 -j ACCEPT
isn't required.

Thanks in advance!

/erik

--

0

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

iptables and virtual hosts problem

On Tue, Oct 30, 2007 at 05:09:50PM +0100, Erik Persson wrote:
> Hello!
>
> I have a server which is running 2 different virtual hosts (vserver), let's
> call them S for the server, A and B for the virtual hosts A and B.
> S, A and B have different ip-addresses (say s.s.s.s, a.a.a.a and b.b.b.b).
>
> Since the server isn't really forwarding anything I haven't used the
> FORWARD chain for anything, and I use INPUT and OUTPUT to regulate the flow
> to the different servers, for example:
>
> iptables -P INPUT DROP
> iptables -P OUTPUT DROP
> iptables -P FORWARD DROP
> iptables -I INPUT -d a.a.a.a -p tcp --dport 80 -j ACCEPT
> on the server
> seems to do what I want. In the example above letting A and only A answer
> requests on port 80.
>
> However, when I try to regulate the flow of traffic between the different
> "machines" (S, A, and B) strange things happen.
>
> For example:
> iptables -I OUTPUT -d a.a.a.a -p tcp --dport 25 -j ACCEPT
> doesn't only allow any of the "machines" to try to contact port 25 on A,
> but it *also allows A to answer* !!!

if by answer, you mean respond to the same request, then that is
appropriate, IIUC. The rules relate to *new* requests, not responses
to existing ones. That's why when you block port 80 inbound, you can
still recieve packets -- they match up to outbound requests your
browser has made.

I think that's right.

A

iptables and virtual hosts problem

Andrew Sackville-West wrote:
> On Tue, Oct 30, 2007 at 05:09:50PM +0100, Erik Persson wrote:
>> Hello!
>>
>> I have a server which is running 2 different virtual hosts (vserver), let's
>> call them S for the server, A and B for the virtual hosts A and B.
>> S, A and B have different ip-addresses (say s.s.s.s, a.a.a.a and b.b.b.b).
>>
>> Since the server isn't really forwarding anything I haven't used the
>> FORWARD chain for anything, and I use INPUT and OUTPUT to regulate the flow
>> to the different servers, for example:
>>
>> iptables -P INPUT DROP
>> iptables -P OUTPUT DROP
>> iptables -P FORWARD DROP
>> iptables -I INPUT -d a.a.a.a -p tcp --dport 80 -j ACCEPT
>> on the server
>> seems to do what I want. In the example above letting A and only A answer
>> requests on port 80.
>>
>> However, when I try to regulate the flow of traffic between the different
>> "machines" (S, A, and B) strange things happen.
>>
>> For example:
>> iptables -I OUTPUT -d a.a.a.a -p tcp --dport 25 -j ACCEPT
>> doesn't only allow any of the "machines" to try to contact port 25 on A,
>> but it *also allows A to answer* !!!
>
> if by answer, you mean respond to the same request, then that is
> appropriate, IIUC. The rules relate to *new* requests, not responses
> to existing ones. That's why when you block port 80 inbound, you can
> still recieve packets -- they match up to outbound requests your
> browser has made.
>
> I think that's right.
>
> A

Thanks! But that really has to do with RELATED,ESTABLISHED for
*established connections* and here I *never* have any rule that
explicitly allows any such established connection to be brought up. The
outbound rule that allows traffic out from the virtual machines to
tcp/25 on a.a.a.a *also* seems to allow traffic *into* a.a.a.a and I
have no explicit rule that allows it, but maybe the ESTABLISHED,RELATED
is the rule that makes this work here, in a fishy way, as well?

The thing is like this. If I have 2 physically distinct, and thus
different, machines, A and B, and want to connect from A to B on port
tcp/25 I have to:
1) let traffic out from A to B on tcp/25 - ie use the OUTPUT chain on A
2) let traffic in on B from A on tcp/25 - ie use the INPUT chain on B
The rest of the traffic between the two, that is outbound answers from B
to A on B, and incoming answer from B to A on A, is regulated by
RELATED,ESTABLISHED rules in the INPUT and OUTPUT-chains on A and B
resp., and that's ok.

In my case I have a server S and two *virtual* machines, A and B. The
rules that I need however differ, and there seems to be no need for #2
above - that is there is no need to let the traffic in from the other
virtual hosts.
The rule:
iptables -I OUTPUT -d a.a.a.a -p tcp --dport 25 -j ACCEPT
seems to be sufficient for both letting the traffic out from S and B (to
A) and letting it in on A. As I understand, it should only let traffic
out from S and B to a.a.a.a (A), but here it also makes a.a.a.a, A,
*accept/answer* the very same traffic. That is strange.

It could be RELATED,ESTABLISHED that makes this possible, in some
strange way, but I don't know and I can't test it at the moment (at the
moment I have only remote access to the machines).
For example if b.b.b.b tcp/whatever sends a request to a.a.a.a tcp/25,
the kernel should make some sort of note of this, and let answers from
a.a.a.a/25 in to b.b.b.b/whatever (sort of in the INPUT chain) in, but
maybe there is some part of this I'm missing.

Anyhow, *if* I'm not missing something (and it is likely I do) please
explain if you know)?

/erik

--

Syndicate content