From owner-freebsd-questions Fri Oct 12 17:46:10 2001 Delivered-To: freebsd-questions@freebsd.org Received: from blacklamb.mykitchentable.net (ekgr-dsl2-116.citlink.net [207.173.226.116]) by hub.freebsd.org (Postfix) with ESMTP id 6AB4A37B407 for ; Fri, 12 Oct 2001 17:46:03 -0700 (PDT) Received: from bigdaddy (bigdaddy [192.168.1.3]) by blacklamb.mykitchentable.net (Postfix) with SMTP id B3CDDEE623; Fri, 12 Oct 2001 17:45:57 -0700 (PDT) Message-ID: <01ac01c15380$66d46780$0301a8c0@bigdaddy> From: "Drew Tomlinson" To: "Mike Meyer" Cc: References: <15303.23221.294413.552831@guru.mired.org> Subject: Re: How to Allow Incoming Traffic Through Firewall? Date: Fri, 12 Oct 2001 17:45:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Mike Meyer" To: "Drew Tomlinson" Cc: Sent: Friday, October 12, 2001 2:03 PM Subject: Re: How to Allow Incoming Traffic Through Firewall? > Drew Tomlinson types: > > I'm trying to refine my firewall rules. I have followed the examples > > at www.onlamp.com and then attempted to add my own rules as needed. > > I've included my rules at the bottom. > > > > Basically, I want to allow everything out and everything back in that > > 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. > > I'm using telnet to test rule 505. The assumption is that if this > > rule works, then the others in the 500 series will work. But when I > > attempt to telnet, the packets get denied as per this log entry: > > > > Oct 12 09:27:55 blacksheep /kernel: ipfw: 610 Deny TCP > > 192.168.10.1:1027 192.168.10.2:23 in via ed1 > > > > 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. > 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? > 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. So what would the "right" way be to allow traffic in from the public interface? > The problem with the way you've done it is that it - if it worked as > you intended - it would allow intruders to reach *all* your internal > machines on any of the ports you're allowing. I'm sure that's not your > intention, right? Not ultimately. For setup and testing purposes, I left the rules as "any" and intend to refine them further with internal IP addresses later. Not that it really matters as this is just a little home network for my own amusement and *all* is really just the mail/web server (one box) and my Win2K machine. I'm pretty sure the FBSD box is secure and the Win2K machine does not remain on continuously. > 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 > Fourth suggestion: read through /etc/rc.firewall; it contains examples > of firealls of various types, along with comments about what's really > going on. That includes examples of setting up nat and allowing access > to internal servers. I have but I'll go through it again now that I'm beginning to understand how ipfw works somewhat. > 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. Thanks for your help and I look forward to any other ideas you might have to help me get this going. As far as I can tell, the dynamic rules allow me to get out everywhere I want to go. I just can't allow *in* the traffic I want; mail, web, imap, and ssh. Thanks again, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message