Date: Fri, 12 Oct 2001 17:45:48 -0700 From: "Drew Tomlinson" <drew@mykitchentable.net> To: "Mike Meyer" <mwm@mired.org> Cc: <questions@freebsd.org> Subject: Re: How to Allow Incoming Traffic Through Firewall? Message-ID: <01ac01c15380$66d46780$0301a8c0@bigdaddy> References: <15303.23221.294413.552831@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----
From: "Mike Meyer" <mwm@mired.org>
To: "Drew Tomlinson" <drew@mykitchentable.net>
Cc: <questions@freebsd.org>
Sent: Friday, October 12, 2001 2:03 PM
Subject: Re: How to Allow Incoming Traffic Through Firewall?
> Drew Tomlinson <drew@mykitchentable.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01ac01c15380$66d46780$0301a8c0>