Date: Sat, 13 Oct 2001 09:46:21 -0500 From: Mike Meyer <mwm@mired.org> To: "Drew Tomlinson" <drew@mykitchentable.net> Cc: "Mike Meyer" <mwm@mired.org>, <questions@freebsd.org> Subject: Re: How to Allow Incoming Traffic Through Firewall? Message-ID: <15304.21437.632304.993114@guru.mired.org> In-Reply-To: <024701c1539f$e2c65a00$0301a8c0@bigdaddy> References: <15303.23221.294413.552831@guru.mired.org> <01ac01c15380$66d46780$0301a8c0@bigdaddy> <15303.40426.817092.645179@guru.mired.org> <024701c1539f$e2c65a00$0301a8c0@bigdaddy>
next in thread | previous in thread | raw e-mail | index | archive | help
Drew Tomlinson <drew@mykitchentable.net> types: > > > > > 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. > > I thought that "add 00620 allow tcp from any to any out setup > keep-state" would allow it but since the connection wasn't initiated > from my private network, the "deny established" rule killed the > packet? Actually, no - it was denied by 610 before it got to 620. For a connection - or udp packet exchange - to go through a firewall, you've got to allow packets in *both* directions. That's what allowing established connections does - it automatically enables TCP in both directions once you've allowed the setup. You can do the same thing with keep-state on the tcp rules. The two methods leave you vulnerable to different types of DoS attacks. Remove the whitespace from your rules, and taking advantage of ability to list multiple ports on a single rule gives us something we can pass back and forth: add 00400 allow ip from any to any via ed0 add 00500 allow tcp from any to any 22,23,25,80,143 add 00600 check-state add 00610 deny log logamount 0 tcp from any to any in established add 00620 allow tcp from any to any out setup keep-state add 00700 allow ip from any to any out keep-state add 65500 deny log logamount 0 ip from any to any I'm going to ignore 400 for now. Any packet - setup or otherwise - going to one of the ports listed on rule 500 will go through, in either direction. The reply packet for those connections won't match those rules, but will be for an established connection, and so denied by 610. The setup packet for something that's *not* one of those protocols will be allowed by 620, which keeps the state. That means any future packets on that connection will be allowed by 600. That covers *all* the tcp cases. 700 allows everything else through outbound keeping the state, and 600 allows the replies, if any, through. Being paranoid, I restrict that to udp, and then handle icmp on a case-by-case basis. 400 looks like it allows all traffic of any type that goes through ed0, in either direction. Once a packet is allowed by 400, any reply packets will also be allowed by 400, as they have to go through ed0. This is probably not good. Normally, interface specs are used with directions of some kind or another, except for lo0. I.e. - you can either allow all incoming traffic from the internal interface, or deny all incoming traffic on the external interface after you pass the ones you want to let in. <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?15304.21437.632304.993114>