Please help confused iptables user

Hi - I'm using iptables v1.2.11 under Debian Sarge.

I'm trying to install a very basic firewall to lock down a secondary DNS/MX box, and having some problems. Specifically, the outgoing requests I want don't work (either timing out or getting not permitted):

Here's what I got - can anyone give me any tips? Any help much appreciated.

iptables -P INPUT DROP iptables -P OUTPUT DROP

iptables -F iptables -F INPUT iptables -F OUTPUT

iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT

iptables -A INPUT -i $ETHERNET -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -o $ETHERNET -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i $ETHERNET -s $MYIP -j DROP iptables -A OUTPUT -o $ETHERNET -s ! $MYIP -j DROP iptables -A INPUT -i $ETHERNET -s 10.0.0.0/8 -j DROP iptables -A INPUT -i $ETHERNET -s 172.16/12 -j DROP iptables -A INPUT -i $ETHERNET -s 192.168/16 -j DROP

# 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

iptables -A INPUT -i $ETHERNET -p udp -d $MYIP --sport 53 -j ACCEPT iptables -A OUTPUT -o $ETHERNET -p udp -s $MYIP --dport 53 -j ACCEPT iptables -A INPUT -i $ETHERNET -p tcp -d $MYIP --sport 53 -j ACCEPT iptables -A OUTPUT -o $ETHERNET -p tcp -s $MYIP --dport 53 -j ACCEPT

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

iptables -A OUTPUT -o $ETHERNET -p udp -s $MYIP --dport 123 -j ACCEPT iptables -A INPUT -i $ETHERNET -p udp -d $MYIP --sport 123 -j ACCEPT

iptables -A INPUT -i $ETHERNET -p tcp -d $MYIP --sport 873 -j ACCEPT iptables -A OUTPUT -o $ETHERNET -p tcp -s $MYIP --dport 873 -j ACCEPT

iptables -A OUTPUT -o $ETHERNET -p tcp -s $MYIP -d mirror.bytemark.co.uk

--dport 80 -j ACCEPT iptables -A OUTPUT -o $ETHERNET -p tcp -s $MYIP -d security.debian.org

--dport 80 -j ACCEPT

iptables -A INPUT -d 255.255.255.255/0.0.0.255 -j DROP iptables -A INPUT -d 224.0.0.1 -j DROP

iptables -A INPUT -j LOG iptables -A OUTPUT -j LOG

[ends]
Reply to
Jonathan
Loading thread data ...

[...]

What is the value of $MYIP?

cu

59cobalt
Reply to
Ansgar -59cobalt- Wiechers

Geez, I'd hate to see what you call a complex firewall. Outgoing requests of what to where? Timeout means you are being blocked by a 'DROP' rule outbound, or the reply is being DROPed or REJECTed inbound. The 'not permitted' means you did get out, but the server doesn't like you.

Set the default, then drop all rules. Don't you think it might be better the other way? Using DROP instead of REJECT makes it harder to troubleshoot because you don't know if the packets never got there, or were dropped. Try setting it to REJECT at least for testing.

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.

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.

Mask makes no sense

Just the one (All Systems on this Subnet)? I'd normally expect to see

224.0.0.0/224.0.0.0 (or 224.0.0.0/3) which would get all multicast and that 255.255.255.255 host with one rule.

You may want to thumb through the Security-Quickstart-HOWTO, and refer back to Rusty's two howtos (packet-filtering-HOWTO and iptables-HOWTO) from Samba.org.

Old guy

Reply to
Moe Trin

No. Flushing doesn't affect the default policy, and by setting the default policy after flushing the chains one might get a (small) period of time where the chains may inadvertently accept packets. Deleting user-defined chains (iptables -X) might be a useful addition, though.

REJECT can't be set as a default policy, because it's not applicable for all protocols. You need to create REJECT rules if you want to reject stuff (which I agree is a good idea).

I wouldn't consider outbound SSH a requirement in his scenario.

cu

59cobalt
Reply to
Ansgar -59cobalt- Wiechers

Why? Just about all the HOWTOS I've read say the above is the reccomended config because it protects you from being open when you run from cold.

I don't understand what you mean. Can you clarify that?

Don't the INPUT rules do that? How would you change the above to allow incoming requests for DNS and mail?

Makes sense to me when I read man iptables.

OK I'll try that.

I have (and some of the stuff above comes from these documents, and others). That's why I'm posting here.

Jonathan

Reply to
Jonathan

It's the public address of the machine: eth0's IP address.

Come to think of it, the machine only has one interface and one IP address. Perhaps I should stop being specific about the address?

Jonathan

Reply to
Jonathan

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). I want incoming to SSH, mail, DNS and rsync from everywhere.

Everything else I want to block.

Reply to
Jonathan

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?

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.

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: ), you also say:

OK the rules should accomplish that.

DNS and mail, I can understand. SSH and rsync??? Are you REALLY REALLY sure about that? I certainly would not recommend that.

That's fine. Your defaults are doing that.

Old guy

Reply to
Moe Trin

OK I gotcha.

I would think the fact that I'm attempting to do this firewall would indicate that if I could, I would ;-) Multiple shell users, DHCP leases, different ISPs etc. etc. FWIW only named users can SSH in, and they cannot use password auth, but I hear what you're saying.

Ah - so part of my problem is that I didn't understand the protocols I was trying to control. That's a good lesson learnt, beause I just assumed it was basically "protocol foo uses port bar."

Thanks greatly for your help. I'll give it all a go later.

By the way, you originally said that you'd hate to see what I thought was a complex firewall. Would you do this all differently? I can't work out if you're making the above reccommendations (which actually make the script

*more* complex) just to fix my ham-fisted attempt...

Jonathan

Reply to
Jonathan

The usual problem is 'bots' doing dictionary attacks (trying lots of common usernames with simple passwords), and you can reduce your exposure by some simple "tricks". If your users actually have three neurons, you can just move the SSHD to a less obvious port - they have to learn to include the portnumber in the command, but that's about it. Most port scanning programs currently default to scanning "interesting" port numbers, or the range 1 to

1025.

The other obvious one is to limit the IP ranges allowed to connect. If your users are UK based only;

[compton ~]$ grep -E '(GB|UK)' IP.ADDR/stats/[ALR]* | cut -d' ' -f2 |cut -d'.' -f1 | sort -un | column 25 80 83 86 135 138 193 196 204 217 51 81 84 87 136 152 194 199 212 62 82 85 88 137 158 195 203 213 [compton ~]$

that's the first octet of the addresses assigned to the UK as of the 15th, and even that can be trimmed further. The '203' refers to a single /24 that's actually in Singapore, and you probably don't have to much traffic with 25/8 or 51/8.

Only on the server. The client will _normally_ be some number in the range

1025 to 65535 (some only go as high as 32767 - but that's a minor detail).
[grizzley ~]% grep -v '^#' /etc/conf/firewall.rules | grep -vc '^ *$' 92 [grizzley ~]%

"Simple" is relative. My home firewall has a total of 11 rules, including the flush and defaults.. 'grizzley' is a box that's protecting an internal DMZ (behind firewalls at the company and facility perimeters).

Old guy

Reply to
Moe Trin

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.