Ian Smith <smi...@nimnet.asn.au> writes:
> Just on your last point: if your internet-connected device is providing
> any services whatsoever on its outside interface (netstat -finet -an)
Or sockstat -4l, which is far more readable.
> As assorted experts have suggested, you need a stateful rule. It's
> really not that hard; if you _only_ needed to protect ntp on udp:
>
> kldload ipfw && add 65000 allow ip from any to any # load null fw
> ipfw add allow udp from me to any ntp out xmit $outsideif keep-state
> ipfw add deny udp from any to me ntp in recv $outsideif
>
> Done. Perfectly configured for this one purpose, statefully no less ..
Wrong, wrong, wrong. Whitelist, not blacklist.
I haven't used ipfw in years, but with pf:
| set block-policy return
| set skip on lo0
| scrub in all
| block quick inet6
| block log all
|
| # allow ping
| pass inet proto icmp all icmp-type echoreq
|
| # allow incoming ssh
| pass in inet proto tcp from any to self port ssh
|
| # allow outgoing tcp
| pass out on proto tcp from self to any
|
| # allow outgoing DNS and NTP
| pass out inet proto udp from self to any port { domain, ntp }
Unlike ipfw, pf keeps state by default and retains it when you reload
the ruleset, so you can safely do "sudo service pf reload" over ssh.
Note that I didn't include echoresp in the list of allowed ICMP types,
because an incoming or outgoing echoreq packet will create a state rule
which allows the corresponding echoresp.
I have the following rule at on at least one machine:
| # Allow outgoing TCP RST packets
| pass out proto tcp from any to any flags R/R no state
but I don't remember the exact circumstances in which outgoing RST
packets were being blocked. Try connecting to a TCP port other than ssh
from outside, and if the connection times out instead of immediately
failing, you need the RST rule.
This ruleset blocks UDP traceroute. Use TCP ('traceroute -P TCP host')
instead.
DES
--
Dag-Erling Smørgrav - d...@des.no
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
