BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


BSD Firewalls: IPFW Rulesets
Pages: 1, 2, 3

Let's see what happens by adding these rules. Once I've double-checked my changes for typos and saved the file, I'll type:



killall init
press Enter, then type:
exit

and watch my boot messages to make sure my rules load without any syntax errors. If you instead receive an error message, your security level may be set to 3 or higher and you'll have to first change this line in /etc/rc.conf to a smaller value:

kern_securelevel="3"

then repeat the killall init command.

Once I'm logged back in, I'll see if I can send any IP packets out to the Internet and receive some replies back:

ping www.freebsd.org
ping: cannot resolve www.freebsd.org: Host name lookup failure

lynx www.freebsd.org
Alert!. Unable to access document.

Hmmmmm. Looks like I still don't have DNS name resolution. Let's try that again, using an IP address instead:

lynx 216.136.204.21

This time, I find myself at the home page of www.freebsd.org. Let's try pinging that IP address:

ping 216.136.204.21
PING 216.136.204.21 (216.136.204.21): 56 data bytes
ping: sendto: Permission denied
ping: sendto: Permission denied
ping: sendto: Permission denied
^C
--- 216.136.204.21 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

Now, let's try to understand this odd behaviour, as obviously some packets are going in and out of my computer and some are not. Let's start by picking apart which protocols I used in each of the examples above.

Name resolution is failing, as I was only able to access www.freebsd.org by using its IP address. When I use DNS, I send a name lookup request to my service provider's DNS server, which should send the response back to me. This seems to match our rules, as I make the request on port 53 and should receive a request back on port 53. I better double-check that I am aware of which DNS servers to send a request to:

more /etc/resolv.conf
search kico1.on.home.com
nameserver 24.226.1.90
nameserver 24.226.1.20
nameserver 24.2.9.34

That doesn't seem to be the problem, so it's time to look a bit deeper at how name resolution works. Let's see if we can glean any information from the online manual pages:

apropos resolve
dnsquery(1) - query domain name servers using resolver
res_query(3), res_search(3), res_mkquery(3), res_send(3), res_init(3), dn_comp(3), dn_expand(3) - resolver routines
resolver(5) - resolver configuration file

I'll then try

man resolver

but will end up at man 3 resolver. Being the curious type, I read it anyway and am intrigued by these lines:

RES_USEVC   Use TCP connections for queries instead of UDP datagrams.

RES_STAYOPEN   Used with RES_USEVC to keep the TCP connection open between queries. This is useful only in programs that regularly do many queries. UDP should be the normal mode used.

I may be onto something here; if DNS is using UDP instead of TCP, my name lookup will fail, as I've made rules only to allow TCP responses to my TCP connections. Now I'll try that manpage for dnsquery:

man dnsquery

<snip to just show intriguing part>

-s  Use a stream rather than a packet. This uses a TCP stream connection with the nameserver rather than a UDP datagram. This sets the RES_USEVC bit of the resolver's options field. (Default: UDP datagram.)

Now, there's a switch I want to try:

dnsquery -s www.freebsd.org
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39772
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5
;; www.freebsd.org, type = ANY, class = IN
www.freebsd.org. 49m21s IN CNAME freefall.freebsd.org.
freebsd.org. 22m43s IN NS ns1.iafrica.com.
freebsd.org. 22m43s IN NS ns2.iafrica.com.
freebsd.org. 22m43s IN NS ns.gnome.co.uk.
freebsd.org. 22m43s IN NS ns0.freebsd.org.
freebsd.org. 22m43s IN NS ns1.root.com.
ns1.iafrica.com. 1h1m3s IN A 196.7.0.139
ns2.iafrica.com. 1h1m3s IN A 196.7.142.133
ns.gnome.co.uk. 12m37s IN A 193.243.228.142
ns0.freebsd.org. 11h9m9s IN A 216.136.204.126
ns1.root.com. 1h8m12s IN A 209.102.106.178

Looks like name resolution works nicely when I make a DNS request using TCP. Let's try it one more time without that s switch to see if it works with UDP:

dnsquery www.freebsd.org
Query failed (h_errno=2) : Host name lookup failure

There we go; DNS is using UDP packets, and since I haven't allowed for UDP packets in my ruleset, I'm not getting DNS name resolution.

Pages: 1, 2, 3

Next Pagearrow





Sponsored by: