Re: iptables udp and output
From: /dev/rob0 (rob0_at_gmx.co.uk)
Date: 01/14/04
- Next message: John Wingate: "Re: Please help,,,execute chmod QR?= o-r / by mistake as a root user."
- Previous message: T: "Re: Please help,,,execute chmod –R o-r / by mistake as a root user."
- In reply to: /dev/rob0: "Re: iptables udp and output"
- Next in thread: charly: "Re: iptables udp and output"
- Reply: charly: "Re: iptables udp and output"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 14 Jan 2004 08:23:45 -0800
In article <slrnc0apmj.ikv.rob0@linuxbox.linux.box>, /dev/rob0 wrote:
Oops, I messed up my "#v" marks. Please ignore the above-referenced
post. Here's the same thing, corrected:
In article <4005484b$0$29096$636a55ce@news.free.fr>, charly wrote:
> IPTABLES="/usr/local/iptables-1.2.9/iptables"
Didn't your distro include iptables? Or was there some reason you needed
to compile from source?
> INSMOD="/sbin/insmod"
Try modprobe(8) instead.
> # Modules to load
> $INSMOD ip_tables
With a typical kernel with KMOD enabled, this would be the only module
you might have to explicitly load.
> INTERNET_SERVICES="25,110,119"
SMTP, POP3 and NNTP ... open to the outside?
> LOCAL_SERVICES="20,21,22"
For FTP, the outbound 20/tcp connection would be "--state RELATED", so
you should not have to specify 20.
> $INSMOD ipt_MASQUERADE
I didn't see you doing any masquerading below.
> $IPTABLES -F
> $IPTABLES -F INPUT
> $IPTABLES -F OUTPUT
> $IPTABLES -F FORWARD
The first of these lines already flushed the entire filter table with
the implied "-t filter". The others were redundant.
> $IPTABLES -F -t mangle
> $IPTABLES -F -t nat
I didn't see you doing anything in the nat or mangle tables. The script
should flush them anyway, I suppose; and although you're not using any
user chains (which you should BTW) you ought to add "iptables -X" for
each of the 3 tables. I do mine in a nested "for" loop:
#v+
for TABLE in filter mangle nat ; do
for ACT in F X ; do
$IPTABLES -t $TABLE -$ACT
done
done
#v-
> $IPTABLES -P INPUT DROP
> $IPTABLES -P OUTPUT DROP
Most people probably do not need to do filtering on OUTPUT. Why not
ACCEPT?
> #$IPTABLES -P FORWARD ACCEPT
Even if you're not acting as a router, it does not hurt to set a policy
for FORWARD. I would use DROP.
> # Drop ALL attempted port scans
> $IPTABLES -A INPUT -m psd -j DROP
Ah, this must be why you compiled from source. :) Does this do anything
that typical stateful inspection doesn't do? And why before the state
rule?
> # ping falls dead
> $IPTABLES -A INPUT -p icmp -j DROP
This is definitely NOT a good idea, coming before your state rule. You
will lose important ICMP RELATED packets. Check the different ICMP
types; you do not want to block them all. Just cut this line, and you
still won't be pingable.
> $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Yes. Some say you should have a "--state INVALID -j DROP" before this.
Whether or not that's necessary, I don't know, but it does not hurt.
> $IPTABLES -A INPUT -p tcp --match multiport --sports $INTERNET_SERVICES
> -j ACCEPT
> $IPTABLES -A INPUT -p tcp --match multiport --dports $LOCAL_SERVICES -j
> ACCEPT
I guess your news client put in the line wrap. Otherwise you need to
escape the line end with a "\" (backslash).
Your variable names are misleading ... there is no distinction between
$INTERNET_SERVICES and $LOCAL_SERVICES. So you're also opening FTP and
SSH to the world.
> # Stop W2K Chatter
> $IPTABLES -A INPUT -p tcp --sport 137:139 -j DROP
> $IPTABLES -A INPUT -p udp --sport 137:139 -j DROP
Not needed. These will hit the DROP policy. This is a holdover from
ipchains firewalls, where you had to specify what you wanted to block.
Typically in iptables, you specify what you want to open.
> #Allow incoming DNS traffic
> $IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
You're running a DNS server for your domain? Are you sure you want this
here?
> #Allow incoming NMBD/SMB traffic
> $IPTABLES -A INPUT -p udp --dport 137 -i eth0 -j ACCEPT
> $IPTABLES -A INPUT -p udp --dport 138 -i eth0 -j ACCEPT
Now I'm confused. Let's step back. What's your network configuration?
Going from the other rules I had guessed this was for a standalone Linux
machine connecting to the Internet. Is there a LAN connection as well?
in that case you need to distinguish between the interfaces.
BTW these rules are too late. You have already DROPped these packets
above. And IIUC you can't have smbd/nmbd working without what you call
the "chatter". The broadcast traffic is necessary.
You certainly do NOT want to accept SMB traffic from the Internet.
> $IPTABLES -A OUTPUT -o lo -j ACCEPT
> $IPTABLES -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> $IPTABLES -A OUTPUT -m state --state NEW -m owner --uid-owner charly -j
> ACCEPT
This should give user "charly" a mostly functioning OUTPUT, but do you
really need output filtering?
> # No ping answer allowed
> $IPTABLES -A OUTPUT -p icmp -j DROP
Sorry, but a ping echo-reply would be RELATED or ESTABLISHED.
-- /dev/rob0 - preferred_email=i$((28*28+28))@softhome.net or put "not-spam" or "/dev/rob0" in Subject header to reply
- Next message: John Wingate: "Re: Please help,,,execute chmod QR?= o-r / by mistake as a root user."
- Previous message: T: "Re: Please help,,,execute chmod –R o-r / by mistake as a root user."
- In reply to: /dev/rob0: "Re: iptables udp and output"
- Next in thread: charly: "Re: iptables udp and output"
- Reply: charly: "Re: iptables udp and output"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
