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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]