Re: [vox-tech] more fires to put out
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox-tech] more fires to put out
- Subject: Re: [vox-tech] more fires to put out
- From: Ted Deppner <tMAPSed@psyber.com>
- Date: Sat, 12 May 2001 09:41:21 -0700
- References: Pine.GSO.email@example.com
On Sat, May 12, 2001 at 04:08:42AM -0700, Gabriel Rosa wrote:
> 1. is there a way to only allow return packets in? iirc, with tcp you set the
> syn flag to specify that the packet is a return packet, and ipchains has an
> option for that. is there a similar method for udp, or do I have to spend some
> time figuring out which ports i like and which i don't (maybe i can simplify
> by filtering out hosts?) ?
there's no "SYN" type flag on UDP. You can use the connection tracking
functionality of the 2.4 kernels to provide some sense of what's "related"
to "established" connections. This is probably the best way, but you'll
lose things like ICQ inbound file requests and other oddball UDP based
That said, if you have a linux based firewall (not sure if you've got a
seperate firewall, or have a directly connected box) between your inside
machine and the world, you can deny all UDP below 1024, and allow all UDP
above 1024, PROVIDED your linux based firewall is running NOTHING at all
that it shouldn't be. There are LOTS OF CAVEATS with that statement!
This would then rely on the connection forwarding table to have a valid
entry for UDP packets to be passed to your inside machine. This assures
that UDP services on your inside machine won't get hit, and that UDP
applications (that have originated an outbound stream) will get their
return packets. And since your linux based firewall isn't running
anything, there'd be nothing to receive all that wide open UDP traffic.
The above two paragraphs are inherently UNSAFE, but provided you know what
you're doing can be a quick and dirty method of being mostly safe, and
will dramatically increase the security for inside windows boxes, etc.
> 2. is udp that big of a deal? do i really care if my udp ports are open? some
> important services (for me) like dns depend on udp (like dns)
You can lockdown UDP return traffic to port 53 (domain, dns) pretty
safely. You'll need the connection tracking w/ FTP support to do non
PASSIVE ftp though. Provided you don't use ICQ's inbound file xfers
(which I'd argue against for the security concious anyway) or other
similar applications you shouldn't miss anything.
> 3. how do people normally deal with this?
1) deny all.
2) turn things on until things you NEED work.
3) repeat 2 as necessary.
that said, here's a snippet of iptables for 2.4 kernels INPUT ruleset in
the filter table.
$cmd -P INPUT DROP
$cmd -P FORWARD DROP
$cmd -P OUTPUT DROP
$cmd -F INPUT
$cmd -F FORWARD
$cmd -F OUTPUT
$cmd -A INPUT -p UDP -s X.X.X.X --sport 53 -j ACCEPT
$cmd -A INPUT -p UDP -s Y.Y.Y.Y --sport 53 -j ACCEPT
$cmd -A INPUT -p TCP -s Z.Z.Z.Z --dport 22 -j ACCEPT
$cmd -A INPUT -p TCP ! --syn --sport 43 -j ACCEPT
$cmd -A INPUT -p TCP ! --syn --sport 80 -j ACCEPT
$cmd -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
$cmd -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
$cmd -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
$cmd -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
$cmd -A INPUT -p UDP --dport 137:139 -j DROP
$cmd -A INPUT -p TCP --dport 135 -j DROP # unknown whacko thing
$cmd -A INPUT -j LOG
This is a server, which does a certain type of outbound service (for which
I deleted those rules). What you see is the only types of traffic it will
accept... return DNS traffic, return WHOIS, and return HTTP, and a
smattering of ICMP, and inbound ssh from a specified host.
Obvious stupidity for ports 135, 137-139 (windows file sharing) are
dropped explicitly, and everything else is logged. This is open to a log
attack at present, I should be using the "-m limit" options to limit hits
to the LOG rule.
(peer review of rulesets is a good thing... I'll happily take suggestions
My apologies for the detail... my biggest complaint when learning things
has always been a lack of detail -- I like detail!