Re: IPFW: Blocking me out. How to debug?
I don't think that below shall ever replace this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html --- #1. i suggest you should really consider moving check-state earlier so legitimate packets get in asap. #2. its never too late to start using tables #/sbin/ipfw table 1 flush #/sbin/ipfw table 1 add 0.0.0.0/8 #/sbin/ipfw table 1 add 1.0.0.0/8 #/sbin/ipfw table 1 add 2.0.0.0/8 #/sbin/ipfw table 1 add 10.0.0.0/8 #/sbin/ipfw table 1 add 127.0.0.0/8 #/sbin/ipfw table 1 add 169.254.0.0/16 #/sbin/ipfw table 1 add 192.0.2.0/24 #/sbin/ipfw table 1 add 192.168.0.0/16 #/sbin/ipfw table 1 add 172.16.0.0/12 #/sbin/ipfw table 1 add 192.88.99.0/24 #/sbin/ipfw table 1 add 198.18.0.0/15 #/sbin/ipfw table 1 add 224.0.0.0/3 #/sbin/ipfw table 1 add 240.0.0.0/4 add allow all from any to any via lo0 #3. all the hosts above are listed in a single rule: add deny ip from any to any not antispoof in add check-state add deny log all from table\(1\) to any in add deny log all from any to table\(1\) out #no comments below add allow tcp from any to me in established add allow tcp from me to any out established add deny log ip from any to any frag add count icmp from any to any icmptypes 8 in add allow icmp from any to any icmptypes 0,8,3,11 add allow udp from any to any 33434-34458 in add allow udp from any 33434-34458 to any out add allow udp from me to any 53 out keep-state add allow udp from any to me 53 in keep-state add allow tcp from any to me ssh setup add allow tcp from me to any ssh setup add allow tcp from any to me http setup add allow tcp from me to any http setup add allow tcp from any to me https setup add allow tcp from me to any https setup add allow tcp from any to me dst-port 8443 in setup add allow tcp from any to me pop3 in setup add allow tcp from any to me pop3s in setup add allow tcp from any to me smtp in setup add allow tcp from me to any smtp out setup add allow tcp from any to me smtps in setup add allow tcp from me to any smtps out setup add allow tcp from any to me imap in setup add allow tcp from any to me imaps in setup add allow tcp from any to me ftp in setup add allow tcp from me to any ftp out setup add allow tcp from any to me ftp\-data in setup add allow tcp from any ftp\-data to me setup out add allow tcp from any to me 49152-65535 in setup add allow tcp from any to me ftps in setup add allow tcp from me to any ftps out setup add allow udp from me ntp to 128.252.19.1 ntp out add allow udp from 128.252.19.1 ntp to me ntp in add allow tcp from me to any out setup uid root add allow tcp from me to 64.131.90.31 dst-port 5224 out setup add deny log udp from any to me in add deny log udp from any to me out add deny log udp from me to any in add deny log udp from me to any out add deny log tcp from any to me in add deny log tcp from any to me out add deny log tcp from me to any in add deny log tcp from me to any out add deny log all from any to any Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW: Blocking me out. How to debug?
At 08:34 12/30/2007, Ian Smith, wrote: >On Sat, 29 Dec 2007, W. D. wrote: > > At 08:49 12/22/2007, Ian Smith wrote: > > >Warning: overlong message. > > >access to only your LAN. Will this webserver later have a public IP > > >address, or run behind NAT with port forwarding? > > > > Public IP. > >So will your LAN also have access to services on this machine? ie will >this box have an address on your LAN also? alias on the same interface? Nope. Will have to go through the public IP. > > > > > > > >> # FTP: > > > > > > >> add allow tcp from any to any ftp in setup > > > > > > >> add allow tcp from any to any ftp\-data in setup > > > > > > >> add allow tcp from any ftp\-data to any setup out > > > > > > > >Mmm, I prefer using and enforcing FTP passive mode, but YMMV. > > > > > > > > How would I do that? This guy doesn't think it's even > > > > possible: > > > > http://tinyurl.com/2z6ynr > > > > > >Mmm, ok. Passive mode needs allowing connections to this port range > > > net.inet.ip.portrange.hifirst: 49152 > > > net.inet.ip.portrange.hilast: 65535 > > >which is adjustable, but I'm unsure of my ground regarding ftp - pass. > > > > How would I write this as a rule? > >I did try to pass .. > ># ipfw add allow tcp from any to me 49152-65535 in setup > >but that's only safe if you'll run no other services in that range. > >Below in your new ruleset you specify as a range: > > > # FTP Passive (Ports 1-65000): > > add allow tcp from me to any 1-65000 in setup > >but I think you mean 'any to me'?, and the range is unnecesarily larger >than ftpd uses, ie .hifirst to .hilast and you can probably limit your >range further - I'm unsure how hard passive mode ftpd hunts for free >ports to bind to, or what. Maybe someone else can help out here .. ? OK: # FTP Passive (Ports 49152-65535): add allow tcp from any to me 49152-65535 in setup There seems to be very sparse documentation on these higher ports, passive FTP, and /etc/sysctl.conf. I am hoping that these settings for sysctl.conf are proper: net.inet.ip.portrange.lowfirst=1023 net.inet.ip.portrange.lowlast=600 net.inet.ip.portrange.first=32768 net.inet.ip.portrange.last=49151 net.inet.ip.portrange.hifirst=49152 net.inet.ip.portrange.hilast=65535 > > > > > > Am using this link, since "man ipfw" doesn't work on 6.2. (I dare > > > > someone to explain to me how to get it to work): > > > > http://www.freebsd.org/cgi/man.cgi?query=ipfw&sektion=8 > > > > > >That's weird. Does man work for others in section 8, eg man mount ? > > > > Nope. How to get working? > >(re)install the manpages and doc distributions from the distribution CD, >or by FTP or whatever you used or want to use. > >You can use sysinstall / configure / distributions, select manpages and >doc, select media when asked, visit options if you need to set anything >else, then install. Don't go _anywhere near_ partitioning or labelling >disks or mess with anything else, even for a peek, in my experience. Hmmm. I guess sysinstall didn't do this to begin with. Did this: sysinstall -> Configure -> Distributions -> man -> OK -> FTP -> Primary #12 (ftp12.freebsd.org) -> Running multi-user, assume that the network is already configured? -> Yes Extracting manpages into / directory... Exit out, then test: man ipfw > > # Stop, then restart ipfw: > > # ipfw disable firewall; /etc/rc.d/ipfw start > >Or '/etc/rc.d/ipfw stop; /etc/rc.d/ipfw start' which includes the >dis/enabling. '/etc/rc.d/ipfw restart' probably works too, modulo >caveats in ipfw(8) about doing these sorts of things remotely. Yeppers. What I use (ipfw disable firewall; /etc/rc.d/ipfw start) seems to not lock out my remote connection. The others do. > > # List firewall hits: > > # ipfw -a -S -N -t list > >-S is overkill/noise unless actually using sets. -N can be slow if any >addresses prove hard to resolve, but I guess that info may be useful :) OK: # List firewall hits: # ipfw -a -N -t list > > > # Zero out hits counter: > > # ifpw zero > > I'd never use this command without including rule number/s, >but then I use counters for um, accounting. Fine while testing .. OK: # Zero out hits for a specific rule number: ipfw zero 05200 # Zero out hits counter for ALL rules: ifpw zero Additions: # Log Viewing/Searching/Studying: #tail -f /var/log/ipfw/ipfw.log # Study: less -S /var/log/ipfw/ipfw.log* # With grep filtering: cat /var/log/ipfw/ipfw.log | grep 192.168.1.103 | grep UDP | more > > > # Allow anything on the local loopback: > > add allow all from any to any via lo0 > > > > # Disallow Spoofers: = > > # For more info, see: > > # RFC3330 > > # http://en.wikipedia.org/wiki/Private_network # If you are actually using a particular # subnet, then be sure to comment out # the appropriate section. > > # > > # "This" Network: > > add
Re: IPFW: Blocking me out. How to debug?
On Sat, 29 Dec 2007, W. D. wrote: > At 08:49 12/22/2007, Ian Smith wrote: > >Warning: overlong message. > > > > > >W. D. wrote: [.. slashing mercilessly ..] > >Ok, so your nameserver will be making upstream requests too, and you'll > >need to do TCP 53 traffic with your secondary nameserver/s as well as > >UDP 53 traffic with upstream nameservers, up to the root unless you're > >only using specified upstream forwarders. Given that you're checking TCP > >setup, allowing established, then maybe: > > > > allow udp from me to any 53 out keep-state # my requests > > allow udp from any to me 53 in keep-state # serve outside requests > > allow tcp from me to $secondaries 53 setup # zone transfers out > > allow tcp from $secondaries to me 53 setup # zone transfers in > > What is $secondaries? An example of why I prefer scripted rulesets :) Here, a list of one or more secondary nameservers that need to do axfrs to refresh domain/s for which you are the primary/master, and any domains you are secondary for. > >though you'll want to protect named with ACLs for xfers as well. > > "ACLs"? What are those? Access Control Lists. See named.conf(5) and the section in the BIND 9 Administrator Reference Manual which you'll most likely want to refer to. If you installed the doc distribution (see below) then the full cross-referenced HTML version is at /usr/share/doc/bind9/arm - I usually symlink both /usr/share/doc and /usr/local/share/doc into webspace. > >access to only your LAN. Will this webserver later have a public IP > >address, or run behind NAT with port forwarding? > > Public IP. So will your LAN also have access to services on this machine? ie will this box have an address on your LAN also? alias on the same interface? > > > > > >> # FTP: > > > > > >> add allow tcp from any to any ftp in setup > > > > > >> add allow tcp from any to any ftp\-data in setup > > > > > >> add allow tcp from any ftp\-data to any setup out > > > > > >Mmm, I prefer using and enforcing FTP passive mode, but YMMV. > > > > > > How would I do that? This guy doesn't think it's even > > > possible: > > > http://tinyurl.com/2z6ynr > > > >Mmm, ok. Passive mode needs allowing connections to this port range > > net.inet.ip.portrange.hifirst: 49152 > > net.inet.ip.portrange.hilast: 65535 > >which is adjustable, but I'm unsure of my ground regarding ftp - pass. > > How would I write this as a rule? I did try to pass .. # ipfw add allow tcp from any to me 49152-65535 in setup but that's only safe if you'll run no other services in that range. Below in your new ruleset you specify as a range: > # FTP Passive (Ports 1-65000): > add allow tcp from me to any 1-65000 in setup but I think you mean 'any to me'?, and the range is unnecesarily larger than ftpd uses, ie .hifirst to .hilast and you can probably limit your range further - I'm unsure how hard passive mode ftpd hunts for free ports to bind to, or what. Maybe someone else can help out here .. ? > > > Am using this link, since "man ipfw" doesn't work on 6.2. (I dare > > > someone to explain to me how to get it to work): > > > http://www.freebsd.org/cgi/man.cgi?query=ipfw&sektion=8 > > > >That's weird. Does man work for others in section 8, eg man mount ? > > Nope. How to get working? (re)install the manpages and doc distributions from the distribution CD, or by FTP or whatever you used or want to use. You can use sysinstall / configure / distributions, select manpages and doc, select media when asked, visit options if you need to set anything else, then install. Don't go _anywhere near_ partitioning or labelling disks or mess with anything else, even for a peek, in my experience. > Here is my latest /etc/ipfw.rules. Please critique: > > #Filename: ipfw.rules > # Description: ipfw firewall ruleset > # Locattion: /etc/ipfw.rules > #Date: 2007 Dec 29 > > # By default, everything is denied access. You > # need to specifically allow something for it > # to work. > > # Debugging tools: > # > # Check the syntax of the rules file: > # ipfw -n /etc/ipfw.rules > # > # Stop, then restart ipfw: > # ipfw disable firewall; /etc/rc.d/ipfw start Or '/etc/rc.d/ipfw stop; /etc/rc.d/ipfw start' which includes the dis/enabling. '/etc/rc.d/ipfw restart' probably works too, modulo caveats in ipfw(8) about doing these sorts of things remotely. > # List firewall hits: > # ipfw -a -S -N -t list -S is overkill/noise unless actually using sets. -N can be slow if any addresses prove hard to resolve, but I guess that info may be useful :) > # Zero out hits counter: > # ifpw zero I'd never use this command without including rule number/s, but then I use counters for um, accounting. Fine while testing .. > # View the log: > #tail -f /var/log/ipfw/ipfw.log Study/search logs: less -S /var/log/ipfw/ipfw.log* > # Allow anything on t
Re: IPFW: Blocking me out. How to debug?
At 08:49 12/22/2007, Ian Smith wrote:
>Warning: overlong message.
> > > > >W. D. wrote:
> > OK, sorry. I guess I just assumed that it would be obvious
> > that this is a Web server. ("Never assume anything, my good
> > fellow" - Sherlock Holmes).
> > By the way, it is/will be running Plesk server management
> > software, if it matters:
> > http://www.swsoft.com/en/products/plesk/reqs/
>
>I know nothing of Plesk, but doubt it's relevant to this now.
>
> > Also, this server is on an internal LAN before I subject
> > it to the wild, untamed, InterWeb, with its dangerous
> > internets darting back and forth inside all of the tubes.
>
>Really good idea :)
>
> > > > >> add allow all from any to any via lo0
> > > > >> add deny ip from any to 127.0.0.0/8
> > > > >> add deny ip from 127.0.0.0/8 to any
> > >
> > >That's ok. It may help you in debugging what's happening to use:
> >
> > allow log tcp from any to any in established
> > allow log tcp from any to any out established
>In that case 'me to any' or 'any to me' provides unambiguous direction
>where appropriate. As shown in your ipfw show below, direction can help
>make things clear, and clarity means safety when it comes to firewalls,
>even if it means a slightly larger ruleset.
>
> > > > >> # Deny fragmented packets:
> > > > >> add deny ip from any to any frag
> >
> > > > >> # Show pings:
> > > > >> add count icmp from any to any icmptypes 8 in
> > > > >
> > >
> > >That's inbound ping requests. Don't forget that 'inbound' means coming
> > >into the firewall, not necessarily from the outside world. Your own
> > >ping requests _from_ this box also have to both come in, and go out.
> >
> > Hmmm. OK. Outbound Ping will be rarely used, but should
> > be allowed. Isn't that included in the next rule?
>
>Yes it is, so here ambiguous directionality works ok, as long as you're
>well aware of it.
>
> > > > >> # Allow pings, ping replies, and host unreach:
> > > > >> add allow icmp from any to any icmptypes 0,8,3
> > >
> > >Add icmptype 11 as well if you want traceroutes to work ..
>
> > >Ok, though udp rules are often better done statefully. See below.
> > >
> > > > >> # Allow DNS with name server
> > > > >> add allow udp from any to any domain out
> > > > >> add allow udp from any domain to any in
> > > > >Nope.
> > >
> > >You want to watch out here. This allows udp packets from any address
> > >with source port 53 to connect with any open udp port on your system,
> > >and allows the responses as well. It's a simple matter using such as
> > >netcat to source packets from port 53.
> >
> > Should I restrict it by specifically stating the service?
> > How can I be safe? What would the rule look like?
> >
> > >I gather from this that you're not running a DNS server yourself, but
> > >using upstream server/s? In that case a stateful rule is safer:
> >
> > Again, I apologize for not being clear. I will be running
> > DNS on this box for the domains being hosted. So, it will
> > be polled whenever a request for a hosted domain is needed.
>
>Ok, so your nameserver will be making upstream requests too, and you'll
>need to do TCP 53 traffic with your secondary nameserver/s as well as
>UDP 53 traffic with upstream nameservers, up to the root unless you're
>only using specified upstream forwarders. Given that you're checking TCP
>setup, allowing established, then maybe:
>
> allow udp from me to any 53 out keep-state# my requests
> allow udp from any to me 53 in keep-state # serve outside requests
> allow tcp from me to $secondaries 53 setup# zone transfers out
> allow tcp from $secondaries to me 53 setup# zone transfers in
What is $secondaries?
>
>though you'll want to protect named with ACLs for xfers as well.
"ACLs"? What are those?
> > > > >> # SSH
> > > > >> # Note that /etc/hosts.allow has restrictions
> > > > >> # on which IP addresses are allowed.
> > > > >> #
> > > > >> # Allow SSH:
> > > > >> add allow tcp from any to any ssh in setup
> > >
> > >By 'ssh working', I guess you mean ssh connections to this box from
> > >elsewhere, rather than ssh connections from this box? Not clear.
> >
> > Sorry! I am using SSH into this box, since it is easier to
> > cut and paste for editing and configuration.
> >
> > I can't really see a situation where I would normally need to SSH
> > outbound, can you? I use the Windoze boxes for that.
>
>You never know; you may want to use ssh or scp to other boxes, for
>backups and such, but you can always add rules whenever required.
>
> > > > >> # HTTP & HTTPS:
> > > > >> add allow tcp from any to any https in setup
> > > > >> add allow tcp from any to any http in setup
> > > > >
> > >
>access to only your LAN. Will this webserver later have a public IP
>address, or run behind NAT with port forwarding?
Public
Fwd: Re: IPFW: Blocking me out. How to debug?
>Date: Sun, 23 Dec 2007 06:04:02 -0800 (PST)
>From: Nash Nipples <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: IPFW: Blocking me out. How to debug?
>
>Dear W.D.
>
>oh come on. i have the same problem.
Which problem are we talking about?
>cut and paste logic:
>
>#!/bin/sh
>#1. count packets
>#2. allow everything on lo0 (loopback)
>#3. slow down and deny packets to buffer overflow enabled daemons
>#3.5 to list all the buffer overflow enabled daemons use this sockstat -46ul
>#4. allow everything in and out on the Ethernet interface fxp0.
>Remember - wires are long things!
What does this mean?
>#5. switch sshd to a different port like 55 and use keys to authenticate
>#6. do ipfw show every morning
Why?
>#7. do ipfw zero every evening or as often as your boss wants that
How about a cron job that sends out a report then zero's ipfw?
>#8. learn how to modify this script quickly just to plumb all the
>other things that leak
What other things?
>#9. you cant block yourself out if you run this script with a trailing
>'&' e.g. sh /etc/ipfw.rules &
Hmmm. I'll have to try that. Would something like this
work to reload the rules?
ipfw disable firewall; sh /etc/ipfw.rules &
>#TODO: write a program that sends bills to customers
>#BUGS: it cant smile
>
>cmd="/sbin/ipfw"
>ext1="fxp0"
>gentleports="21,25,514"
Why are these ports "gentle"?
>
>#accounting
>#i need these figures to see how bad things are going
>$cmd 100 count ip from any to any in via lo0
>$cmd 110 count ip from any to any out via lo0
>$cmd 120 count ip from any to any in via $ext1
>
>
>
>$cmd 130 count ip from any to any out via $ext1
>
>#if counters below grow too high u are screwed
How so?
> #this counter should not vary much comparing to the next one
>$cmd 210 count icmp from any to any out via $ext1
> #if there is an obvious difference someone's digging holes in the yard
What does this mean?
> $cmd 220 count icmp from any to any in via $ext1
> #too much of dns.
>$cmd 230 count ip from any to any 53 out via $ext1
>$cmd 240 count ip from any to any 53 in via $ext1
Why too much?
>
>#if counters below grow too high you have screwed someone else
Who? Why?
>#oh yes. someone's got mail.
>$cmd 300 count ip from any to any 25 out via $ext1
>#which way did it go
>$cmd 310 count ip from any to any 25 via lo0
>
>#policy
>$cmd 1000 allow all from any to any via lo0
>/sbin/ipfw add 1110 pipe 1 ip from any to me $gentleports in via $ext1
>/sbin/ipfw pipe 1 config bw 1Kbit/s queue 1Kbytes
>
>$cmd 1120 deny ip from any to me $gentleports in via $ext1
>$cmd 1130 allow all from any to any via ext1
>#you will wonder but the next rule still has a match
>$cmd 1140 deny log all from any to any
What is it?
>
>I'm sorry but i cant draw pretty pictures to make it any more obvious
To make what more obvious?
>
>Nash
>
>
>- Original Message
>From: W. D. <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Cc: Ian Smith <[EMAIL PROTECTED]>
>Sent: Friday, December 21, 2007 9:30:11 AM
>Subject: Re: IPFW: Blocking me out. How to debug?
>
>
>At 05:45 12/20/2007, Ian Smith, wrote:
>
>Thanks for your reply Ian. This is the kind of
>information I am looking for.
>
>
>>Firstly, this really belongs over on freebsd-net@ if not
>>freebsd-questions@, but anyway ..
>
>I'll be glad to move it there if you would like. I
>figured that since IPFW/Firewalls are security
>related, that FreeBSD-Security would be the most
>appropriate place.
>
>
>>On Thu, 20 Dec 2007, W. D. wrote:
>>
>> > At 03:49 12/17/2007, Tuomo Latto wrote:
>> > >W. D. wrote:
>> > >> How do I tell which rule is blocking me out? SSH *is* working,
>> > >> but others are not.
>> > >
>> > >It all depends on what you mean by "blocking you out" and
> "others".
>>
>>True; it's not really clear what you're trying to do, whether this is
> a
>>single server with a single net interface with no NAT or what, but
> based
>>on your present rules I'll have to make that assumption.
>
>OK, sorry. I guess I just assumed that it would be obvious
>that this is a Web server. ("Never assume anything, my good
>fellow" - Sherlock Holmes).
>
>By the way, it is/will be running Plesk server management
>software, if it matters:
>http://www.swsoft.com/en/products/plesk/reqs/
>
>Also, this server is on an internal LAN before I subject
>it to the wild, untamed, InterWeb, with its dangerous
>internets
Re: IPFW: Blocking me out. How to debug?
Warning: overlong message.
I'm moving this to questions@ from security@ as it's a usage issue.
Anyone wishing to follow the up to here can read from:
http://lists.freebsd.org/pipermail/freebsd-security/2007-December/004541.html
On Fri, 21 Dec 2007, W. D. wrote:
> Date: Fri, 21 Dec 2007 01:30:11 -0600
> From: "W. D." <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Ian Smith <[EMAIL PROTECTED]>
Never been to Uzbekistan and don't know this bloke :)
> At 05:45 12/20/2007, Ian Smith, wrote:
>
> Thanks for your reply Ian. This is the kind of
> information I am looking for.
>
> >Firstly, this really belongs over on freebsd-net@ if not
> >freebsd-questions@, but anyway ..
>
> I'll be glad to move it there if you would like. I
> figured that since IPFW/Firewalls are security
> related, that FreeBSD-Security would be the most
> appropriate place.
>
> >On Thu, 20 Dec 2007, W. D. wrote:
> >
> > > At 03:49 12/17/2007, Tuomo Latto wrote:
> > > >W. D. wrote:
> > > >> How do I tell which rule is blocking me out? SSH *is* working,
> > > >> but others are not.
> > > >
> > > >It all depends on what you mean by "blocking you out" and "others".
> >
> >True; it's not really clear what you're trying to do, whether this is a
> >single server with a single net interface with no NAT or what, but based
> >on your present rules I'll have to make that assumption.
>
> OK, sorry. I guess I just assumed that it would be obvious
> that this is a Web server. ("Never assume anything, my good
> fellow" - Sherlock Holmes).
Ok, and sorry I needed a days' sleep + $life before getting back to you.
Here are many people who can and likely will offer opinions and advice.
> By the way, it is/will be running Plesk server management
> software, if it matters:
> http://www.swsoft.com/en/products/plesk/reqs/
I know nothing of Plesk, but doubt it's relevant to this now.
> Also, this server is on an internal LAN before I subject
> it to the wild, untamed, InterWeb, with its dangerous
> internets darting back and forth inside all of the tubes.
Really good idea :)
> > > >> add allow all from any to any via lo0
> > > >> add deny ip from any to 127.0.0.0/8
> > > >> add deny ip from 127.0.0.0/8 to any
Ok.
> > > >> # Allow established connections:
> > > >> add allow tcp from any to any established
> >
> >That's ok. It may help you in debugging what's happening to use:
> >
> > allow [log] tcp from any to any in established
> > allow [log] tcp from any to any out established
>
> I assume here that "[log]" means to insert "log" for
> debugging like this:
>
> allow log tcp from any to any in established
> allow log tcp from any to any out established
>
> rather than including the square brackets, "[" & "]",
> correct?
Yeah sorry, I meant [log] as in optionally just for debugging.
> I have done that and have included my latest ruleset
> below.
>
> >and really, using 'any to any' without specifying on which interfaces or
> >whether 'any' is your box or the outside world is a bit too general, but
> >moving on ..
>
> OK. What should I do? I only plan on having one
> Ethernet interface. What would be more secure?
In that case 'me to any' or 'any to me' provides unambiguous direction
where appropriate. As shown in your ipfw show below, direction can help
make things clear, and clarity means safety when it comes to firewalls,
even if it means a slightly larger ruleset.
> > > >> # Deny fragmented packets:
> > > >> add deny ip from any to any frag
>
> > > >> # Show pings:
> > > >> add count icmp from any to any icmptypes 8 in
> > > >
> >
> >That's inbound ping requests. Don't forget that 'inbound' means coming
> >into the firewall, not necessarily from the outside world. Your own
> >ping requests _from_ this box also have to both come in, and go out.
>
> Hmmm. OK. Outbound Ping will be rarely used, but should
> be allowed. Isn't that included in the next rule?
Yes it is, so here ambiguous directionality works ok, as long as you're
well aware of it.
> > > >> # Allow pings, ping replies, and host unreach:
> > > >> add allow icmp from any to any icmptypes 0,8,3
> >
> >Add icmptype 11 as well if you want traceroutes to work ..
Traceroutes want to see 'TTL exceeded in transit' icmp messages.
> > > >> # Allow UDP traceroutes:
> > > >> add allow udp from any to any 33434-34458 in
> > > >> add allow udp from any 33434-34458 to any out
> > > >
> >
> >Ok, though udp rules are often better done statefully. See below.
> >
> > > >> # Allow DNS with name server
> > > >> add allow udp from any to any domain out
> > > >> add allow udp from any domain to any in
> > > >Nope.
> >
> >You want to watch out here. This allows udp packets from any address
> >with source port 53 to connect with any open u
