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
--
Bookmark/Search this post with:
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
--