Date: Fri, 12 Oct 2001 20:50:34 -0500 From: Mike Meyer <mwm@mired.org> To: "Drew Tomlinson" <drew@mykitchentable.net> Cc: <questions@freebsd.org> Subject: Re: How to Allow Incoming Traffic Through Firewall? Message-ID: <15303.40426.817092.645179@guru.mired.org> In-Reply-To: <01ac01c15380$66d46780$0301a8c0@bigdaddy> References: <15303.23221.294413.552831@guru.mired.org> <01ac01c15380$66d46780$0301a8c0@bigdaddy>
next in thread | previous in thread | raw e-mail | index | archive | help
Drew Tomlinson <drew@mykitchentable.net> types: > > > was initiated from my private network. I also want to allow > incoming > > > traffic to my mail server (smtp & imap), web server, and ssh. I > know > > > the man page indicates that filtering on port numbers is not a > good > > > idea so I am also open to other ways of allowing certain traffic. > > > > Um - what man page says that filtering on port numbers is not a good > > idea? It needs to be fixed. > > From man ipfw(8): > > Note that it may be dangerous to filter on the source IP address > or > source TCP/UDP port because either or both could easily be > spoofed. Note that it says *source* port, not destination port. Filtering on the destination port is practically required. Filtering on the source port is a bad idea, but may be required for cases. > > > OK, I understand why rule 610 is denying the packet but why isn't > rule > > > 505 allowing it? What am I missing? And is there a better way to > > > accomplish allowing web, mail, etc. traffic? > > Because 505 allows traffic from all traffic going to port 23. Your > > telnet session goes from some random port on the initiating system - > > in this case it was 1027 - to port 23 on the remote system. The > > initial packet goes out, then comes back bound for that random > > port. Since it's not going to port 23, 505 won't allow it through. > I'm sorry I wasn't clear here. The above example was an *incoming* > telnet session so it was going from port 1027 on the public side (ed1) > to port 23 on the private side (ed0) (unless I'm missing something). > It was a telnet session that I initated from my DSL modem so I could > test incoming connections. The same argument works in both directions. You are filtering connections based on the *destination* port. The telnet connection in question is from port 23 on the server to port 1027 on the client. So the packet opening the connection goes through - whether inbound or outbound - but the reply packet is blocked, because it's not going to port 23. > > First suggestion - don't set rule numbers in the script. It makes it > > easier to read and follow. My apologies if you added those for the > > discussion. > I set the rule numbers per the example on www.onlamp.com. But since > you're willing to help me, we'll do it your way. :) Shall I leave > the rule numbers for discussion? Sure. Please note that there are people on the list who are much more experienced at this than I am - but there wasn't an answer in the digest, so I decided to point out what I saw as obvious things. > > Second suggestion - your setup is basically - upside down? inside > out? > > backwards? Strange, in any case. You normally used the > "established" > > rule to allow packets through for established connections, as the > rest > > of the rules will prevent unwanted connections from being setup at > > all. > I'm sure there is plenty in my setup that is not correct and I welcome > suggestions on how to do it "right". However, the reason I did it > this way is because if I put them after the "established" rule, > incoming sessions from the public interface (ed1) were denied at the > "established" rule and thus, not allowed explicit allow rules later. That's because you're using the "established" rule backwards from normal usage. If you've gotten to the point that you're blocking a packet in an established connection, it means the attacker has already gotten the packet that opens the connection to your machine. That might be sufficient for their purpose, and is certainly sufficient for a DoS. So you do things the other way - make sure they can't establish connections you don't want to happen, and always allow established connections. UDP doesn't use connections, so you use the state rules for it to get the same effect. > So what would the "right" way be to allow traffic in from the public > interface? For each service you want to allow in from outside, add a rule that allows it in. I.e, if you're running a www and bind servers as well as a mail gateway on the box, you'd do it like so: add allow tcp from any to any established add allow tcp from any to any frag add allow tcp from any to any out setup add allow tcp from any to 192.168.10.2 http,smtp,domain setup add check-state add allow udp from any to any out keep-state add allow udp from any to 192.168.10.2 domain add deny log logamount 0 all from any to any I.e. - allow established TCP connections - including fragments - to work, allow outbound TCP to setup, and allow incoming http and smtp to setup. The setup checks on the 2nd and 3rd rules are largely redundant, but do make it clear what's going on. Repeat this for udp, with check-state taking the place of established. Keep-state isn't needed for the udp domain service, as the outbound packet will be allowd in any case. > > Third suggestion - you need to set up nat if you're going to use > > 192.168 addresses. People normally block any traffic from such an > > address at their firewall, because it's usually someone trying to > > spoof their internal addresses. Letting them leak out is considered > > bad form. > > NAT is running but it is running on my ADSL modem/router. Here's my > layout: > > ISP > | > | IP is DHCP (provides DNS & NAT) > | > ADSL Modem/Router > |192.168.10.1 > | > |192.168.10.2 > Firewall > | > |192.168.1.2 > | > Server 192.168.1.4 If all your services are in 192.168.1.4, you want the tcp rule set to look more like: add allow tcp from any to any established add allow tcp from any to 192.168.1.4 http,smtp,imap setup add allow log logamount 0 tcp from any to 192.168.1.4 ssh add deny log logamount 0 tcp from any to any in via ed0 setup add allow tcp from any to any setup Basically, changing it to allow traffic to the server instead of the local box for those destinantion - not source - ports. After those have been allowed through, you deny all tcp coming in through the outside interface (that's assuming ed0 is what 192.168.10.2 is on), and finally allow everything else - which should just be outbound traffic - to go through. I believe that's correct, but can't test it, which is why I'm leaving udp as an exercise for the reader. > > Sixth suggestion: If you're serious about this, get the Chapman and > > Zwicky book mentioned in that file. Both are very sharp, have been > > doing this for a long time - Brent made a living doing nothing else > > until the firewall-in-a-box products showed up - and write well. > Did I miss the fifth suggestion? ;) I will see about the book. I probably missed it in a renumber. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Q: How do you make the gods laugh? A: Tell them your plans. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15303.40426.817092.645179>