netfilter iptables and firewall

What people? From where? To where? Which messenger?

Never EVER set the default policy to ACCEPT.

Why are you limiting this? You do realize that this is a DoS condition, don't you?

Why are you logging this?

You should use stateful filtering here, too.

A limit of 1/s seems a bit low to me.

This probably doesn't solve your problem, but simplifies your ruleset a little:

iptables -P FORWARD DROP

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p icmp -j Icmp_Related_And_New iptables -A FORWARD -j r_drop iptables -A FORWARD -p tcp -s $LOCALNET -d 202.72.104.1 --dport 110 -j LOG iptables -A FORWARD -p tcp -s $LOCALNET -d $INTERNET -m multiport \\ --dport 22,25,53,443,6667,8383 -m state --state NEW -j ACCEPT iptables -A FORWARD -p udp -s $LOCALNET -d $INTERNET --dport 53 \\ -m state --state NEW -j ACCEPT # use REJECT rather than DROP iptables -A FORWARD -p tcp -m limit --limit 10/s --limit-burst 10 \\ -j REJECT --reject-with tcp-reset iptables -A FORWARD -p udp -m limit --limit 10/s --limit-burst 10 \\ -j REJECT --reject-with icmp-port-unreachable iptables -A FORWARD -j LOG

iptables -A r_drop -p tcp --dport 135:139 -j DROP iptables -A r_drop -p udp --dport 135:139 -j DROP iptables -A r_drop -p tcp --dport 445 -j DROP iptables -A r_drop -p tcp --dport 1433:1434 -j DROP

iptables -A Icmp_Related_And_New -p icmp --icmp-type destination-unreachable \\ -m state --state RELATED -j ACCEPT iptables -A Icmp_Related_And_New -p icmp --icmp-type source-quench \\ -m state --state RELATED -j ACCEPT iptables -A Icmp_Related_And_New -p icmp --icmp-type parameter-problem \\ -m state --state RELATED -j ACCEPT iptables -A Icmp_Related_And_New -p icmp --icmp-type time-exceeded \\ -m state --state RELATED -j ACCEPT iptables -A Icmp_Related_And_New -p icmp --icmp-type echo-reply \\ -m state --state ESTABLISHED -j ACCEPT iptables -A Icmp_Related_And_New -p icmp --icmp-type echo-request \\ -m state --state NEW -m limit --limit 20/s -j ACCEPT

cu

59cobalt

"some people" - but none of your rules limit to individual addresses. Of course, if your LAN is running DHCP because it's to much trouble to set the boxes to static addresses, then you can't allow "some" people to access the Internet unless everything is done through an authenticated proxy, in which case your rules should block ALL access to/from the world except via that proxy. HOWEVER - you should not depend on your firewall to _replace_ written policy.

See that a _written_ policy detailing allowed Internet use is in place. Depending on your jurisdiction, there may or may not be legal implications. You _probably_ should consult with your company's legal advisor to be sure.

Temporarily, jack up the logging, so that you are logging all NEW and ESTABLISHED connections (all you need it headers), for a month or so. Use common scripting tools to sort out source and destination IPs, and destination port numbers. Who is talking to who, and why? Is such traffic beneficial, or tolerable? If you don't understand scripting, see the "Bash-Prog-Intro-HOWTO" (should be on your system in /usr/share/HOWTO) and "Advanced Bash-Scripting Guide" (version 4.1 was released two weeks ago - try

When we did this (using tcpdump because the firewall logging of the era wasn't very good), we wound up with a log of roughly 350 Megabytes. It two two people _less_than_two_days_ to ID every site, showing about 200 "holes" that had to be created through our "block everything by default" firewall.

If it's not explicitly in the rules, allow ??? WTF?!? In the comments below, I'm assuming $INTERNET means 0.0.0.0/0 or literally, the entire world.

Some mail admins don't like to accept mail from systems not designated as mail servers. Allow the mail to be forwarded to a smarthost, and sent on from there only.

Log stuff to a specific destination, but allow to anywhere? Seems reversed.

Allow _all_ SSH outbound???

Allow _all_ https outbound???

And the reason your employees need IRC to do their jobs is what exactly?

What's 8383/tcp, and why is it needed?

I don't have to deal with windoze, but I'd drop INPUT and OUTPUT as well, as nothing runs on my firewall box except the firewall, and the ordinary users (much less the entire world) has no reason to be connecting to that box.

OK

Stretching - I rarely see a source-quench.

I can't recall the last time I saw one of those

In the modern Internet, the only time you see this is in traceroute.

We allow ICMP Echo request outbound, and ICMP Echo reply inbound only.

Old guy

First i would like to thank you for your help, true it's look like a bit more easy to read it like this.

Still i'm a bit confuse here shouldnt't we put the rules with limit on top of the rules?

I would like also to explain a bit more let say that my network is a bit like this hosts->firewall->router->internet so most of the hosts who use the proxy is fine and are efectively limited now if they remove the proxy and access the apache server on the bridge and then go to yahoo.com they have a full access to internet :_) and more sometimes they manage to use yahoo messenger wich is the point why i put this firewalll... only way i manage to block it was to drop or reject the port for http and yahoo (5000-5100) i also put a preroute rules to redirect them to the proxy but it's not working as the server need them to be identified...

Also i made a mistake on the mail, i forgot the ! in front of the destination

Oups forget the ! in front of the destination still i won't be in this country and i know the support would be quite difficult so i just prefer to allow them access to any smtp server (i would prefer to block it but then who will change the rules to match the new destination...)

Might be right i can remove this i'm the only one to use ssh.

hum that was for me :)

arg this one i would prefer to remove it but they got an application on this port wich need to access their intranet...

hum i will folow the example in the first post for my input and output seem good for me.

Hum ok i will just remove them

There are only three rules that make use of the limit module: the two REJECT rules, and the rule limiting echo-requests. The former two need to be at the end of the FORWARD chain, and for the latter it doesn't matter where in the Icmp_Related_And_New chain it is.

You seem to lack understanding of how the chains in netfilter work. The three rule-blocks that are quoted above set rules in three different chains. The second and third blocks set rules in user-defined chains into which the second and third rule in the FORWARD chain (first block) branch. A packet that has gone through a user-defined chain and not matched a rule in it is returned to the "parent" chain.

So what you really want is a transparent proxy. I haven't done this myself, but IIRC you need to mark packets to get it to work.

You mean the logging rule? That still doesn't explain why you want to log it.

cu

59cobalt

I'd strongly recommend against that unless you have a very good reason to do it. ICMP is needed whenever you have to troubleshoot IP problems. You should rather add type 3 (destination-unreachable) to the list of allowed packets.

cu

59cobalt

This is port 110 - "Post Office Protocol v3" or RFC1939. This is where the users connect to collect their individual mail. It's downstream of the SMTP protocols (RFC0821 and/or RFC2821). Depending on your layout, this _should_ be a fixed server behind your firewall, or at worst, the pop-server of your ISP. Your users shouldn't need to be connecting to "other" pop servers.

You're allowing everyone access to everywhere. Hardly very secure.

Same thing - you are allowing everyone access to everywhere.

Accessing _their_ intranet - you've got the directions wrong. You also should recommend changing the port number, as 8383-8385 is used for a web mail application that has no place in a business environment.

Rusty Russell of Samba.org (author of the netfiltering code) has a number of "unofficial" HOWTOs at

[TXT] NAT-HOWTO.txt 17-Oct-2004 14:34 25K [TXT] netfilter-double-nat-HOWTO.txt 17-Oct-2004 14:34 9.4K [TXT] netfilter-extensions-HOWTO.txt 17-Oct-2004 14:34 79K [TXT] netfilter-hacking-HOWTO.txt 17-Oct-2004 14:35 84K [TXT] networking-concepts-HOWTO.txt 17-Oct-2004 14:34 28K [TXT] packet-filtering-HOWTO.txt 17-Oct-2004 14:34 52K

(also available in HTML, Postscript, and SGML at the same directory), and there are several of the official Linux Documentation Project HOWTOs as well - see

-rw-rw-r-- 1 gferg ldp 271987 Oct 17 12:54 HOWTO-INDEX

-rw-rw-r-- 1 gferg linux 96946 Oct 17 12:54 INDEX

-rw-rw-r-- 1 gferg ldp 708351 Nov 14 2005 IP-Masquerade-HOWTO

-rw-rw-r-- 1 gferg ldp 17605 Jul 21 2004 Masquerading-Simple-HOWTO

-rw-rw-r-- 1 gferg ldp 155096 Jan 23 2004 Security-HOWTO

-rw-rw-r-- 1 gferg ldp 278012 Jul 23 2002 Security-Quickstart-HOWTO

Several years ago, the (US) National Security Agency had a web page with recommendations for firewall rules (now 404s) that was derived from page

89 of the (then current) Cisco Security Guide. Briefly, they said

deny icmp any any echo deny icmp any any redirect deny icmp any any mask-request permit icmp any (allow pings where needed obviously)

Translated, that is block Type 8, 5, 17. I disagree, suggesting that you allow 0, 3, and 11 INBOUND, 3, and 8 OUTBOUND, while denying all else. YMMV.

Old guy

I concur largely. However, I still don't see a good reason to not allow types 4 and 12 inbound as well.

cu

59cobalt

Because the general/first rule of security is to not allow anything that has no reason on your network. ICMP (any) is not needed between the LAN/WAN interface in most cases.

4 0 Source Quench 12 Parameter Problem 0 Pointer indicates the error 1 Missing a Required Option (RFC1108) 2 Bad Length

Both of those have been used for denial of service _far_ more often than used for their "intended" purpose. RFC1108 _rarely_ applies

1108 U.S. Department of Defense Security Options for the Internet Protocol. S. Kent. November 1991. (Format: TXT=41791 bytes) (Obsoletes RFC1038) (Status: HISTORIC)

Agreed

Well, you do qualify that - but I stand by my suggestion noted above. If you actually look at ftp://ftp.iana.org/assignments/icmp-parameters (and if you use IPv6, the very different '/assignments/icmpv6-parameters'), there are 28 ICMPv4 types (30 ICMPv6 types). Just for giggles, during the month of March 2006, I ran a packet sniffer on our primary link to the world, snarfing _only_ ICMP packets. Type 3 accounted for ~86.2% (roughly

506k), Type 8 was about 13.2% (~79k), type 0 ~0.5% (~3k) and type 11 the remainder. My notes remark that there were less than 100 others (well under 0.02%), mainly type 5 and a single (apparently unsolicited) type 4. I was a bit surprised that the inbound pings were so low (at home, they were roughly a third, with the others reduces proportionally). I had previously run this test in March or April of 2003, and while I don't have the notes, I recall that type 8s were the majority - perhaps related to a worm that was active at the time.

Old guy

Could you provide some more details on what kind of DoS, and in which scenarios they were used?

Even though the applicability of RFC 1108 is questionable, there are still the codes 0 and 2 which AFAICS are not subject to RFC 1108.

Ah, but they do have a reason, as specified in RFC 792. Don't get me wrong, there's nothing wrong with blocking them at the border when you are certain noone will ever need to receive these messages from outside the network in question, but *be* certain about it in the first place.

cu

59cobalt