l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2001 Dec 30 17:07

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
[vox-tech] Firewall question...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vox-tech] Firewall question...

Hey guys,

I'm running a DNS server for a domain on my Linux box at home. I used
www.linux-firewall-tools.com orginally to generate my firewall script. The
online tool originally generated ipchains commands which allow traffic to
and from port 53 as would be expected. Here are the lines in my firewall
shell script (please note that my default rules for input, output and
forward are DENY, REJECT and DENY, respectively).

EXTERNAL_INTERFACE is defined eth0
IPADDR             is my public IP address
PRIVPORTS          is 0:1023
UNPRIVPORTS        is 1024:65535
ALLPORTS           is 0:65535

ipchains -A input  -i $EXTERNAL_INTERFACE -p udp  \
             --source-port $UNPRIVPORTS \
             -d $IPADDR 53 -j ACCEPT

ipchains -A output -i $EXTERNAL_INTERFACE -p udp  \
             -s $IPADDR 53 \
             --destination-port $UNPRIVPORTS -j ACCEPT

ipchains -A output -i $EXTERNAL_INTERFACE -p udp  \
             -s $IPADDR 53 \
             --destination-port 53 -j ACCEPT

ipchains -A input  -i $EXTERNAL_INTERFACE -p udp  \
             --source-port 53 \
             -d $IPADDR 53 -j ACCEPT

The trouble is that remote servers will attempt to connect to my machine
using a priviledged port (in the range of PRIVPORTS), which of course my
firewall won't allow. This is a bad thing because then it looks like my
domain name doesn't work to the outside work.

For example. three lines from my syslog message file:

Jul  2 15:10:38 solo kernel: Packet log: input DENY eth0 PROTO=17 L=66 S=0x00 I=7309 F=0x0000 T=105 (#89)

Jul  2 15:26:56 solo kernel: Packet log: input DENY eth0 PROTO=17 L=66 S=0x00 I=22942 F=0x0000 T=105 (#89)

Jul  2 15:31:07 solo kernel: Packet log: input DENY eth0 PROTO=17 L=66 S=0x00 I=11170 F=0x0000 T=105 (#89)

I recognize the incoming IP as one at where I work (I was attempting to do
an nslookup (via NT) to the domain name in question) and was monitoring
my messages file (gotta love secure shell). It seems to be the only IP
address with this problem.

My solution was to substitute UNPRIVPORTS for ALLPORTS for the first two
ipchains lines above like so:

ipchains -A input  -i $EXTERNAL_INTERFACE -p udp  \
             --source-port $ALLPORTS \
             -d $IPADDR 53 -j ACCEPT

ipchains -A output -i $EXTERNAL_INTERFACE -p udp  \
             -s $IPADDR 53 \
             --destination-port $ALLPORTS -j ACCEPT

This cleared up the connection problem. My question, however, is this--why
should I care from which port a DNS client on a remote machine may connect
*from*? As long as I only allow connections *to* port 53, shouldn't that
be good enough? So why do I have the sneaking suspicion that my solution
isn't very secure? :)

R. Douglas Barbieri

"There is no case...there never was! It's all just a joke, a big joke!"
--Former Inspector Wollenski

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.