Re: [OT] Firewall Rule Set not allowing access to DNS servers?

• Previous message: Clint Olsen: "kernel: sk0: watchdog timeout"
• In reply to: Giorgos Keramidas: "Re: Firewall Rule Set not allowing access to DNS servers?"
• Next in thread: JJB: "RE: Firewall Rule Set not allowing access to DNS servers?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sat, 31 Jul 2004 13:51:18 -0400 (EDT)
To: "Giorgos Keramidas" <keramida@ceid.upatras.gr>

> There are many ways in which your ruleset might break. Two of the
> most
> important comments I wanted to make when I first saw the posts of this
> thread are:
>
> a) Why do you use static rule numbers?
>
> You'd only have to use static rule numbers if your ruleset
> had more than 65536/100 = 655 rules. This limit is
> relatively hard to hit in a SOHO installation (Small Office,
> Home Office). If you do reach such limits, there's
> definitely something weird going on with the way your ruleset
> is written ;-)
>

Giorgos, I am interested in where I can get more information about
this. Are you suggesting that IPFW reads the ruleset and formulates a
rule number according to position in the script? (I always use custom
scripts).

If this is true, how does this ``dynamic'' feature get affected when
one houses multiple rule _sets_?

Can you please provide any links to information that I can gain
valuable information on this? This would certainly make ruleset
creation much easier ;o)

Also, links to any information on how/what/why on the 16b/100 limit on
the dynamic rules, so I (we) can learn more about this?

I must admit, I've never even come within 1/15 of this number, but it
is interesting. All my rules have always been simply, allow, allow,
allow, DENY.

Tks much,

Steve

> b) Why do you use so many rules that 'filter' outgoing traffic?
>
> I saw smtp, pop3, time, http, https and many others. You
> don't need to explicitly allow outgoing connections unless
> the users in the internal LAN are not to be trusted at all
> and even then IPFW is most of the time not the right way to
> do it.
>
> I'd probably just use something of this form in the /etc/ipfw.rules
> file
> and let rc.firewall find it by setting firewall_type="/etc/ipfw.rules"
> in my rc.conf file:
>
> # First clean up all the rules of ipfw.
> flush
>
> # Packets should be passed to natd *before* any other rule as
> # mentioned in the natd(8) manpage, unlike your current script.
> add divert natd all from any to any via dc1
>
> # Allow only lo0 interface to use the 127.0.0.1 address.
> add allow ip from 127.0.0.1 to 127.0.0.1 via lo0
> add deny ip from 127.0.0.1 to any
> add deny ip from any to 127.0.0.1
>
> # Add only the dc0 interface to receive or send packets in the
> # 192.168.0.0/16 address range.
> add allow ip from 192.168.0.0/16 to 192.168.0.0/16 via dc0
> add deny ip from 192.168.0.0/16 to any
> add deny ip from any to 192.168.0.0/16
>
> # Block packets with addresses that are used in private networks
> # and should not appear in any of our interfaces below this point.
> add deny ip from 10.0.0.0/8 to any
> add deny ip from any to 10.0.0.0/8
> add deny ip from 172.16.0.0/12 to any
> add deny ip from any to 172.16.0.0/12
>
> # Allow DNS and NTP through.
> add allow udp from any to any 53,123 keep-state out
>
> # Pass all ICMP messages through. They're rate limited by the
> # kernel if sysctl net.inet.icmp.icmplim is enabled, so this is
> # not very unsafe to do.
> add allow icmp from any to any
>
> #
> # Stateful tcp filtering.
> #
>
> add check-state
> add deny tcp from any to any established
>
> # All outgoing and incoming connections are allowed in dc0 (private
> iface).
> # Only outgoing connections are allowed on dc1 (external iface).
> add allow tcp from any to any keep-state out xmit dc0 setup
> add allow tcp from any to any keep-state in recv dc0 setup
> add allow tcp from any to any keep-state out xmit dc1 setup
>
> # Only selected services are allowed to pass through external iface.
> add allow tcp from any to any 22 keep-state in recv dc1 setup
> add allow tcp from any to any 113 keep-state in recv dc1 setup
>
> # The default firewall policy.
> add deny log logamount 0 ip from any to any
>
> No inline numbers, a simpler layout and a logic that you can hopefully
> extend at the second from last paragraph to allow more services
> through
> your external interface (the `in recv dc1 setup' rules).
>
> Note that I haven't tested this, so it might contain syntax errors
> because it's based on the ruleset I'm using at home but it also
> includes
> some modifications. Instead of untangling the ruleset you're now
> trying
> to use which seemed unnecessarily complex to me, I'm posting this just
> in case it's useful but it's up to you to bring it to shape for your
> setup if it doesn't "Just Work(TM)" when you load it.
>
> - Giorgos
>
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscribe@freebsd.org"
>

_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"

• Previous message: Clint Olsen: "kernel: sk0: watchdog timeout"
• In reply to: Giorgos Keramidas: "Re: Firewall Rule Set not allowing access to DNS servers?"
• Next in thread: JJB: "RE: Firewall Rule Set not allowing access to DNS servers?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]