iptables udp and output

Greetings,

I got Two machines : one is W2K one is linux.

My linux machine runs iptables. and I'm fed up with the chatty windows so ->

iptables -p udp -m --multiports-match --sports 137,138,139 -j DROP
iptables -p tcp -m --multiports-match --sports 137,138,139 -j DROP

The netbios broadcast of the w2k is not dropped by my linux : why ??

Question 2 :

I want to filter output :
is
iptables -P OUTPUT DROP
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

enough ?


thanks for your input, in the meanwhile, I'll continue googling
archive's groups

charly wrote:

> Greetings,
>
> I got Two machines : one is W2K one is linux.
>
> My linux machine runs iptables. and I'm fed up with the chatty windows so
> ->
>
> iptables -p udp -m --multiports-match --sports 137,138,139 -j DROP
> iptables -p tcp -m --multiports-match --sports 137,138,139 -j DROP

Don't you mean:
iptables -A INPUT -p tcp --sport 137:139 -j DROP
iptables -A INPUT -p udp --sport 137:139 -j DROP

>
> The netbios broadcast of the w2k is not dropped by my linux : why ??
>
> Question 2 :
>
> I want to filter output :
> is
> iptables -P OUTPUT DROP
> iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>
> enough ?

For a normal state machine it's like this:

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A INPUT -p ! icmp -m state \
--state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p ! icmp -m state \
--state ESTABLISHED,RELATED -j ACCEPT


>
>
> thanks for your input, in the meanwhile, I'll continue googling
> archive's groups

--
The world is not octal despite DEC.

> Don't you mean:
> iptables -A INPUT -p tcp --sport 137:139 -j DROP
> iptables -A INPUT -p udp --sport 137:139 -j DROP
yes, thanx !

I post my script here for comments and remarks before testing it tonight :
IPTABLES="/usr/local/iptables-1.2.9/iptables"
INSMOD="/sbin/insmod"
INTERNET_SERVICES="25,110,119"
LOCAL_SERVICES="20,21,22"

# Modules to load
$INSMOD ip_tables
$INSMOD ip_conntrack
$INSMOD ip_conntrack_ftp
$INSMOD ipt_state
$INSMOD iptable_nat
$INSMOD ipt_MASQUERADE


$IPTABLES -F
$IPTABLES -F INPUT
$IPTABLES -F OUTPUT
$IPTABLES -F FORWARD
$IPTABLES -F -t mangle
$IPTABLES -F -t nat

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
#$IPTABLES -P FORWARD ACCEPT


#-----------------------------
# INPUT RULES
#-----------------------------
$IPTABLES -A INPUT -o lo -j ACCEPT

# Drop ALL attempted port scans
$IPTABLES -A INPUT -m psd -j DROP

# ping falls dead
$IPTABLES -A INPUT -p icmp -j DROP

$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -p tcp --match multiport --sports $INTERNET_SERVICES
-j ACCEPT
$IPTABLES -A INPUT -p tcp --match multiport --dports $LOCAL_SERVICES -j
ACCEPT

# Stop W2K Chatter
$IPTABLES -A INPUT -p tcp --sport 137:139 -j DROP
$IPTABLES -A INPUT -p udp --sport 137:139 -j DROP

#Allow incoming DNS traffic
$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT

#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


#-----------------------------
# OUTPUT RULES
#-----------------------------
$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

# No ping answer allowed
$IPTABLES -A OUTPUT -p icmp -j DROP

charly wrote:

>> Don't you mean:
>> iptables -A INPUT -p tcp --sport 137:139 -j DROP
>> iptables -A INPUT -p udp --sport 137:139 -j DROP
> yes, thanx !
>
> I post my script here for comments and remarks before testing it tonight :
> IPTABLES="/usr/local/iptables-1.2.9/iptables"

Forget "make install"?

> INSMOD="/sbin/insmod"
> INTERNET_SERVICES="25,110,119"
> LOCAL_SERVICES="20,21,22"
>
> # Modules to load
> $INSMOD ip_tables
> $INSMOD ip_conntrack
> $INSMOD ip_conntrack_ftp
> $INSMOD ipt_state
> $INSMOD iptable_nat
> $INSMOD ipt_MASQUERADE

Not necessary: your machine will load the modules it needs as it needs them.

>
>
> $IPTABLES -F
> $IPTABLES -F INPUT
> $IPTABLES -F OUTPUT
> $IPTABLES -F FORWARD
> $IPTABLES -F -t mangle
> $IPTABLES -F -t nat

Not necessary:
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z

>
> $IPTABLES -P INPUT DROP
> $IPTABLES -P OUTPUT DROP
> #$IPTABLES -P FORWARD ACCEPT

No, it should be drop forwarded unless you need to forward packets, and even
then the policy should always be DROP or REJECT unless you have other
needs.

>
>
> #-----------------------------
> # INPUT RULES
> #-----------------------------
> $IPTABLES -A INPUT -o lo -j ACCEPT

Uh, actually this is better:
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT

>
> # Drop ALL attempted port scans
> $IPTABLES -A INPUT -m psd -j DROP

Good idea.
Try this one too:
$IPTABLES -A INPUT -f -j DROP

Most vulnerabilities for windows machines are based on packet fragmentation
reassembly, and by just dropping all fragmented packets, it helps a lot.
I've dropped fragmented packets since 2000 with NPF, then with IPTables.

>
> # ping falls dead
> $IPTABLES -A INPUT -p icmp -j DROP

Why? Ping can be a nice tool to help troubleshoot the network with. You
can just limit it if you're scared:
$IPTABLES -A INPUT -p icmp -m limit --limit 3/minute -j ACCEPT

Even then, you're dropping ALL icmp, and there are other things your network
needs from ICMP. A better way to do it would be to include it in your
state machine:
$IPTABLES -A INPUT -p icmp -m state --state INVALID -j DROP
$IPTABLES -A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED,RELATED \
-j ACCEPT

Also, you could just add a blanket statement to drop all invalid state
packets:
$IPTABLES -A INPUT -i eth0 -m state --state INVALID -j DROP

>
> $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

What? No -p ! icmp ?
You should exclude icmp from that part, because icmp functions differently.

> $IPTABLES -A INPUT -p tcp --match multiport --sports $INTERNET_SERVICES
> -j ACCEPT
> $IPTABLES -A INPUT -p tcp --match multiport --dports $LOCAL_SERVICES -j
> ACCEPT

The state machine should work well enough for that, but if you insist...
If those are incoming connection requests, you could specify that they're
SYN packets by adding --syn after -p tcp:
$IPTABLES -A INPUT -p tcp --syn -m multiport --sports ...

>
> # Stop W2K Chatter
> $IPTABLES -A INPUT -p tcp --sport 137:139 -j DROP
> $IPTABLES -A INPUT -p udp --sport 137:139 -j DROP

Should not be necessary: if you have no incoming state NEW and no incoming
ports 137:139 specified, these should get dropped. However, you can
manually drop them ...
I'd recommend dropping 135:139 and 445 for Netbios... Win2000/xp use port
445 more often ...

>
> #Allow incoming DNS traffic
> $IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT

DNS traffic is UDP. To prevent DNS spoofing/poisoning, you can specify
where the DNS should come from (since you should only communicate DNS with
the DNS servers your ISP uses):

$IPTABLES -A INPUT -p udp -s 24.240.225.10 --sport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p udp -d 24.240.225.10 --dport 53 -j ACCEPT

BTW: for non-loopback stuff, you can be more specific on ALL rules by adding
"-i eth0" for INPUT and "-o eth0" for output.
Also, when specifying ports, remember it's source port (--sport) for INPUT
and destination port (--dport) for OUTPUT.
I suggest you download and install ethereal, and watch your network and see
how it acts.

>
> #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

Uh, wait. You just shut off all that traffic above, and now you're
accepting it? Dude, get a clue.

>
>
> #-----------------------------
> # OUTPUT RULES
> #-----------------------------
> $IPTABLES -A OUTPUT -o lo -j ACCEPT

This should be up with the loopback input rule.

> $IPTABLES -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

No, you can safely use --state NEW,ESTABLISHED,RELATED here, just specify
that the output interface is "-o eth0"

> $IPTABLES -A OUTPUT -m state --state NEW -m owner --uid-owner charly -j
> ACCEPT

What if root wants to ping the network while troubleshooting? What about
things that run suid root? I think that, if it's a single user machine,
specifying the owner is pointless.

>
> # No ping answer allowed
> $IPTABLES -A OUTPUT -p icmp -j DROP

Again, I don't see why you limit ping by blocking all icmp. If you want to
enable/disable ping, You can enable the good types (0 for request and 8 for
reply) and disable the bad types if you'd like, but other types are needed
for normal networking (i.e. networking by the rules in the RFC/IEEE
standard), such as type 3 "destination unreachable".
Go to www.netfilter.org and go to the iptables tutorial -- read and learn.

--
Living in LA is like not having a date on Saturday night.
-- Candice Bergen

thank you very much for your comments, all modifications are done...

Well yes, I forgot make install but I don't really care :)
I rarely use ping, that's why I blocked it altogether :)
didn't manage to install ethereal on linux, used /usr/sbin/tcpdump
instead (works well BTW).

I never specified -i/o eth0 because there is only one card installed,
should I ?

What if root wants to ping the network while troubleshooting? What
about things that run suid root? I think that, if it's a single user
machine, specifying the owner is pointless.

I thought that if an account got compromised, then I could at last lock
him up in the host : your opinion ?
as for root, yes, I use root for troubleshooting so I had better let him
use the network :)

Go to www.netfilter.org and go to the iptables tutorial -- read and learn.
Been there already, read as well but wow, what a bunch of info : I need
a lot lot more practice :)

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

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

> Didn't your distro include iptables? Or was there some reason you needed
> to compile from source?
Yes but got a newer version but forgot make install :)

>>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?
> Hu, not really : I think i've messed up there :) the goal si to be able to reach then in the output chain
>
>>LOCAL_SERVICES="20,21,22"
>
>
> For FTP, the outbound 20/tcp connection would be "--state RELATED", so
> you should not have to specify 20.
> Okay :)
>
>>$INSMOD ipt_MASQUERADE
>
>
> I didn't see you doing any masquerading below.
> Nope, I do not : i'll remove that one :)
>
>>$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.
>
> okay

>>$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-
> thx for the looop
>
>>$IPTABLES -P INPUT DROP
>>$IPTABLES -P OUTPUT DROP
>
>
> Most people probably do not need to do filtering on OUTPUT. Why not
> ACCEPT?
> I prefer to control what is allowed to get out, just in case I got trojanned
>
>>#$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.
> did so after help form neosadist
>
>># 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.
> Moved it as and got a little more specific with icmp flags
>
>>$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).
> yep, it did line wrap


> 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.
> ftp and ssh are supposed to be open on my machine
>
>># 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.
> thx for the explanation
>
>>#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?
> yes, But i specified the dns ip in my new version :)
>
>>#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.
> No no : I messed that on : removed it !! Sorry...

> 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".
of course, I realized later : thx again

The broadcast traffic is necessary.
>
> You certainly do NOT want to accept SMB traffic from the Internet.
> NO, of course
>
>>$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?
> I added it for root as well
>

Many thx for your comments !

On Wed, 14 Jan 2004 14:47:03 +0100, charly thoughtfully wrote:

>> Don't you mean:
>> iptables -A INPUT -p tcp --sport 137:139 -j DROP
>> iptables -A INPUT -p udp --sport 137:139 -j DROP
> yes, thanx !
>
> I post my script here for comments and remarks before testing it tonight :
> IPTABLES="/usr/local/iptables-1.2.9/iptables"
> INSMOD="/sbin/insmod"
> INTERNET_SERVICES="25,110,119"
> LOCAL_SERVICES="20,21,22"
>
> # Modules to load
> $INSMOD ip_tables
> $INSMOD ip_conntrack
> $INSMOD ip_conntrack_ftp
> $INSMOD ipt_state
> $INSMOD iptable_nat
> $INSMOD ipt_MASQUERADE
>
>
> $IPTABLES -F
> $IPTABLES -F INPUT
> $IPTABLES -F OUTPUT
> $IPTABLES -F FORWARD
> $IPTABLES -F -t mangle
> $IPTABLES -F -t nat
>
> $IPTABLES -P INPUT DROP
> $IPTABLES -P OUTPUT DROP
> #$IPTABLES -P FORWARD ACCEPT

I think I would ACCEPT policy for OUTPUT
and DROP policy for FORWARD. Of course
you're dropping all traffic unless you explicitly
accept it in your rules.

>
>
> #-----------------------------
> # INPUT RULES
> #-----------------------------
> $IPTABLES -A INPUT -o lo -j ACCEPT
>
> # Drop ALL attempted port scans
> $IPTABLES -A INPUT -m psd -j DROP
>
> # ping falls dead
> $IPTABLES -A INPUT -p icmp -j DROP
>
> $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> $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 think the 2 multiport commands above will accept $INTERNET_SERVICES
and $LOCAL_SERVICES of any state from everywhere on any device.
Wouldn't you want a $LOCAL_NET=192.168.0.0/24 ?

>
> # Stop W2K Chatter
> $IPTABLES -A INPUT -p tcp --sport 137:139 -j DROP
> $IPTABLES -A INPUT -p udp --sport 137:139 -j DROP


>
> #Allow incoming DNS traffic
> $IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
>

Which protocol does DNS come on and from who?

> #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
>

I thought you dropped port 137,138 from above, not to mention the drop
policy.

>
> #-----------------------------
> # OUTPUT RULES
> #-----------------------------
> $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
>
Who is charly? What about owners news, smtp, pop3, smbd/nmbd?
You're not sending port 137,138 due to policy so nmbd/smbd won't work.

> # No ping answer allowed
> $IPTABLES -A OUTPUT -p icmp -j DROP

ICMP is too important a feature to block. Some ISPs use icmp to heartbeat
the line for connectivity, no icmp then no dhcp or dns. How will you test
basic (access layer) connectivity? Telnet tests the application
layers, ie, user program connection. Applies to INPUT as well because
you'd need to accept some ICMP if sending ICMP you can specify types of
acceptable ICMP.

GL

--
------------------------------------------------------
Linux registered user #302812
using Fedora Core 1 kernel 2.4.22-1.2115.nptl
------------------------------------------------------

In article <400578c5$0$29076$636a55ce@news.free.fr>, charly wrote:
>>>INTERNET_SERVICES="25,110,119"
>>
>> SMTP, POP3 and NNTP ... open to the outside?
> Hu, not really : I think i've messed up there :) the goal si to be
> able to reach then in the output chain

If your machine is running no servers at all, providing NO services to
the outside world, you should not have ANY of these open ports. There is
a short and simple example which does just that in the Packet-Filtering-
HOWTO at www.netfilter.org. Start with that example, and build on as
needed.

>> Most people probably do not need to do filtering on OUTPUT. Why not
>> ACCEPT?
> I prefer to control what is allowed to get out, just in case I got trojanned

Fine in theory, but you're not likely to gain any real security from
this, and you WILL lose a lot of functionality. You cannot send any mail
using your MTA, for one thing. The one account you're allowing out is
the one most likely to be compromised, of course. And IMO that's not a
reasonable fear on GNU/Linux anyway.

>> 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.
> ftp and ssh are supposed to be open on my machine

Open to whom? If you want to "ftp localhost" (for whatever odd reason)
the "-i lo -j ACCEPT" rule covers that (assuming of course that you are
running a FTP daemon.)

You had both your $INTERNET_SERVICES and $LOCAL_SERVICES open to the
world. To me the variable names imply that the former set should be open
to the world and that the latter should be restricted to local machines.
Then you mentioned in reply that you're doing this for a standalone box,
with a single network connection.

>> You're running a DNS server for your domain? Are you sure you want this
> yes, But i specified the dns ip in my new version :)

Sorry, but the explanation is even less clear than before. :) Are you
talking about your ISP's nameserver IP? If so you'll be getting your
DNS query replies in under your RELATED,ESTABLISHED rule. The rule you
posted lets anyone in the world connect to a DNS server on your machine,
if in fact you are running one, which is what I was asking.

>> really need output filtering?
> I added it for root as well

Depending on your MTA (and if you use it?) you would still not be able
to send mail. I had assumed you're running a MTA because you did open
SMTP in the script you posted. I use postfix, and that's the name of the
user who would try to make connections to foreign SMTP servers.

Letting root out ... I still don't see any security benefit, and you're
still going to have usability issues. IIRC I read that some packet types
can't be traced to a process owner, and those are dropped.

Again I suggest giving up the output filtering. I only use it at
customer sites where the bosses are trying to prevent unmotivated
employess from having Internet access. :) You WANT to have Internet
access, yourself!
--
/dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
or put "not-spam" or "/dev/rob0" in Subject header to reply