Re: Please help confused iptables user
- From: ibuprofin@xxxxxxxxxxxxxxxxxxxxxx (Moe Trin)
- Date: Tue, 24 Jan 2006 22:57:13 -0600
On Tue, 24 Jan 2006, in the Usenet newsgroup comp.security.firewalls, in
article <43d694d6@xxxxxxxxxxxxxxxxxxxxxx>, Jonathan wrote:
>Moe Trin wrote:
>>># WHY DOES THIS NOT WORK GOING OUT?
>>>iptables -A INPUT -i $ETHERNET -p tcp -d $MYIP --dport 22 -j ACCEPT
>>>iptables -A OUTPUT -o $ETHERNET -p tcp -s $MYIP --sport 22 -j ACCEPT
>>
>> Because you are letting the whole world connect to your :22 (and the
>> any replies - that rule isn't needed), but you aren't letting your
>> system talk to a remote 22.
>
>I don't understand what you mean. Can you clarify that?
First rule says allow IN anything destined for your IP port 22.
Second rule isn't needed because you allow in/out established/related, BUT
this rule says allow OUT anything from your IP port 22. If you want to
use SSH initiated connections from here to remote servers, you need to
change this to
iptables -A OUTPUT -o $ETHERNET -p tcp -s $MYIP --dport 22 -j ACCEPT
which says your IP (any port) can connect to the remote 22/tcp.
Now, I _really_ don't see the need for the breadth of the first rule,
saying ANYONE can connect to your SSH. You _REALLY_ want to narrow that
down to those hosts you'd expect to have a need to connect. For example,
it's HIGHLY unlikely that you (in the UK) would have a need to connect
from China or Korea, areas that are known to have a huge number of
bots trying to subvert SSH daemons. So, why let them in?
>>>iptables -A OUTPUT -o $ETHERNET -p tcp -s $MYIP --dport 25 -j ACCEPT
>>>iptables -A INPUT -i $ETHERNET -p tcp -d $MYIP --sport 25 -j ACCEPT
>
>> These six rules allow you to act as a client (asking remote servers
>> about DNS, asking remote servers if they'll accept your OUTBOUND mail),
>> but there is nothing allowing other systems to access DNS or a mail
>> server running on this box.
>
>Don't the INPUT rules do that? How would you change the above to allow
>incoming requests for DNS and mail?
Let's read those rules again. First one says you'll allow OUT stuff
from your IP (port unspecified) to remote 25/udp. Second rule says
you'll allow IN stuff to your IP (port unspecified) _from_ remote 25/udp.
DNS queries, SSH, Mail, etc does NOT originate on the reserved port.
Run tcpdump, and watch a DNS query. Ignoring ARP packets, and assuming
the "remote" DNS server is on the same network, your box sends a DNS
query (UDP) from a high port (>1025) to the IP of the first DNS server
(port 53). Hopefully, the DNS server responds, sending the reply from it's
53/udp (where you asked) to your high port number (the one you used to
send it out). Does the remote DNS server care about your port 53? No.
Is your port 53 used in the query? No.
You probably need this set of rules, because your mail server is going
to be asking about the IPs that are connecting to it (and if you are
paranoid, it's also going to be looking up the resulting name to see
if it points back at the IP address). But this says nothing about
outsiders being able to query _your_ name server. For that, you need
another set of rules
iptables -A OUTPUT -o $ETHERNET -p tcp -s $MYIP --sport 25 -j ACCEPT
iptables -A INPUT -i $ETHERNET -p tcp -d $MYIP --dport 25 -j ACCEPT
Here, the second rule allows outsiders to send to your DNS server, and
the first rule allows you to reply. Whether or not you need the TCP
rules depends on how big your answers are going to be. If your answer
fits into a 512 byte packet, you won't be setting the TC (truncated)
flag in the reply, and the remote will never ask via TCP (meaning you
don't need the extra /tcp rules)..
The mail server rules you have allow you to send mail, but not receive
any - for the same reason as the DNS. You're allowing access to remote
port 25, but no one can reach _your_ port 25 inbound. Again, the
connections are not 25 to 25, but sender:>1025 to mail.server:25 with
the other side of the conversation using EXACTLY the same ports.
>>>iptables -A INPUT -d 255.255.255.255/0.0.0.255 -j DROP
>>
>> Mask makes no sense
>>
>
>Makes sense to me when I read man iptables.
There are only two valid masks for that IP - 255.255.255.255, or /32.
See RFC1878. You're saying that the first 24 bits of the mask are zero,
but networking code only looks to the first zero from the left. The
rule itself isn't that critical, because (coupled with the rest of the
rules you have) the only thing it's going to reject is non-UDP and
non-TCP, which really boils down to ICMP. No sane router should be
passing such a packet to you - so all you are protecting against is
the local LAN. The 224.0.0.0/3 (a.k.a. 224.0.0.0/224.0.0.0) rule
would block 224.0.0.0 through 255.255.255.255.
In your other reply (Message-ID: <43d69851@xxxxxxxxxxxxxxxxxxxxxx>), you
also say:
>> Outgoing requests of what to where?
>
>Sorry, should have made myself clearer: I'm trying to stop all outgoing
>requests for anything that's not SSH, mail, DNS, rsync or HTTP (the latter
>to a specific couple of hosts only).
OK the rules should accomplish that.
>I want incoming to SSH, mail, DNS and rsync from everywhere.
DNS and mail, I can understand. SSH and rsync??? Are you REALLY REALLY
sure about that? I certainly would not recommend that.
>Everything else I want to block.
That's fine. Your defaults are doing that.
Old guy
.
- Follow-Ups:
- Re: Please help confused iptables user
- From: Jonathan
- Re: Please help confused iptables user
- References:
- Please help confused iptables user
- From: Jonathan
- Re: Please help confused iptables user
- From: Moe Trin
- Re: Please help confused iptables user
- From: Jonathan
- Please help confused iptables user
- Prev by Date: Re: Please help confused iptables user
- Next by Date: NFS across PIX515E firewall
- Previous by thread: Re: Please help confused iptables user
- Next by thread: Re: Please help confused iptables user
- Index(es):
Relevant Pages
|
