netfilter iptables and firewall

Hello,
I didn't work with iptables since more than 4 years and i was agreably
surprise by the new function provided with iptables,

I'm currently using a computer with linux to do a Bridge Firewall, as
my company have limited ressources i have put together some other
service on it (apache, dansguardian).
it give them a fairly secure network and should only allow some people
to access internet.

Still i found some problem in my firewall where some people were still
ablle to use web and messenger even with the set of rules i have put on
it.

Here is my Forward rules and if any of you had a tips on it, it would
be must wellcome:

iptables -P FORWARD ACCEPT

iptables -A FORWARD -j Icmp_Related_And_New -p icmp
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit
--limit 1/s -j ACCEPT
iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
--dport 25
iptables -A FORWARD -j LOG -p tcp -s $LOCALNET -d 202.72.104.1
--dport 110
iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET dport
110
iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
--dport 22
iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
--dport 53
iptables -A FORWARD -j ACCEPT -p udp -s $LOCALNET -d $INTERNET
--dport 53
iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
--dport 443
iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
--dport 6667
iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
--dport 8383
iptables -A FORWARD -j r_drop

iptables -A r_drop -p tcp --dport 135:139 -j DROP
iptables -A r_drop -p udp --dport 135:139 -j DROP
iptables -A r_drop -p tcp --dport 445 -j DROP
iptables -A r_drop -p tcp --dport 1433:1434 -j DROP
iptables -A r_drop -j LOG
iptables -A r_drop -j DROP

iptables -A Icmp_Related_And_New -p icmp --icmp-type
destination-unreachable -m state --state RELATED -j ACCEPT
iptables -A Icmp_Related_And_New -p icmp --icmp-type source-quench
-m state --state RELATED -j ACCEPT
iptables -A Icmp_Related_And_New -p icmp --icmp-type
parameter-problem -m state --state RELATED -j ACCEPT
iptables -A Icmp_Related_And_New -p icmp --icmp-type time-exceeded
-m state --state RELATED -j ACCEPT
iptables -A Icmp_Related_And_New -p icmp --icmp-type echo-reply -m
state --state ESTABLISHED -j ACCEPT
iptables -A Icmp_Related_And_New -p icmp --icmp-type echo-request -m
limit --limit 1/s -j ACCEPT
iptables -A Icmp_Related_And_New -j LOG
iptables -A Icmp_Related_And_New -j DROP

Thanks,

Re: netfilter iptables and firewall

EldarXP wrote:
> I'm currently using a computer with linux to do a Bridge Firewall, as
> my company have limited ressources i have put together some other
> service on it (apache, dansguardian).
> it give them a fairly secure network and should only allow some people
> to access internet.
>
> Still i found some problem in my firewall where some people were still
> ablle to use web and messenger even with the set of rules i have put on
> it.

What people? From where? To where? Which messenger?

> Here is my Forward rules and if any of you had a tips on it, it would
> be must wellcome:
>
> iptables -P FORWARD ACCEPT

Never EVER set the default policy to ACCEPT.

> iptables -A FORWARD -j Icmp_Related_And_New -p icmp
> iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit \
> --limit 1/s -j ACCEPT
> iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT

Why are you limiting this? You do realize that this is a DoS condition,
don't you?

> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET \
> --dport 25
> iptables -A FORWARD -j LOG -p tcp -s $LOCALNET -d 202.72.104.1 \
> --dport 110

Why are you logging this?

> iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET \
> --dport 110
> iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET \
> --dport 22
> iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET \
> --dport 53
> iptables -A FORWARD -j ACCEPT -p udp -s $LOCALNET -d $INTERNET \
> --dport 53
> iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET \
> --dport 443
> iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET \
> --dport 6667
> iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET \
> --dport 8383

You should use stateful filtering here, too.

> iptables -A FORWARD -j r_drop
>
> iptables -A r_drop -p tcp --dport 135:139 -j DROP
> iptables -A r_drop -p udp --dport 135:139 -j DROP
> iptables -A r_drop -p tcp --dport 445 -j DROP
> iptables -A r_drop -p tcp --dport 1433:1434 -j DROP
> iptables -A r_drop -j LOG
> iptables -A r_drop -j DROP
>
> iptables -A Icmp_Related_And_New -p icmp --icmp-type \
> destination-unreachable -m state --state RELATED -j ACCEPT
> iptables -A Icmp_Related_And_New -p icmp --icmp-type \
> source-quench -m state --state RELATED -j ACCEPT
> iptables -A Icmp_Related_And_New -p icmp --icmp-type \
> parameter-problem -m state --state RELATED -j ACCEPT
> iptables -A Icmp_Related_And_New -p icmp --icmp-type \
> time-exceeded -m state --state RELATED -j ACCEPT
> iptables -A Icmp_Related_And_New -p icmp --icmp-type \
> echo-reply -m state --state ESTABLISHED -j ACCEPT
> iptables -A Icmp_Related_And_New -p icmp --icmp-type \
> echo-request -m limit --limit 1/s -j ACCEPT

A limit of 1/s seems a bit low to me.

> iptables -A Icmp_Related_And_New -j LOG
> iptables -A Icmp_Related_And_New -j DROP

This probably doesn't solve your problem, but simplifies your ruleset a
little:

iptables -P FORWARD DROP

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p icmp -j Icmp_Related_And_New
iptables -A FORWARD -j r_drop
iptables -A FORWARD -p tcp -s $LOCALNET -d 202.72.104.1 --dport 110 -j LOG
iptables -A FORWARD -p tcp -s $LOCALNET -d $INTERNET -m multiport \
--dport 22,25,53,443,6667,8383 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p udp -s $LOCALNET -d $INTERNET --dport 53 \
-m state --state NEW -j ACCEPT
# use REJECT rather than DROP
iptables -A FORWARD -p tcp -m limit --limit 10/s --limit-burst 10 \
-j REJECT --reject-with tcp-reset
iptables -A FORWARD -p udp -m limit --limit 10/s --limit-burst 10 \
-j REJECT --reject-with icmp-port-unreachable
iptables -A FORWARD -j LOG

iptables -A r_drop -p tcp --dport 135:139 -j DROP
iptables -A r_drop -p udp --dport 135:139 -j DROP
iptables -A r_drop -p tcp --dport 445 -j DROP
iptables -A r_drop -p tcp --dport 1433:1434 -j DROP

iptables -A Icmp_Related_And_New -p icmp --icmp-type destination-unreachable \
-m state --state RELATED -j ACCEPT
iptables -A Icmp_Related_And_New -p icmp --icmp-type source-quench \
-m state --state RELATED -j ACCEPT
iptables -A Icmp_Related_And_New -p icmp --icmp-type parameter-problem \
-m state --state RELATED -j ACCEPT
iptables -A Icmp_Related_And_New -p icmp --icmp-type time-exceeded \
-m state --state RELATED -j ACCEPT
iptables -A Icmp_Related_And_New -p icmp --icmp-type echo-reply \
-m state --state ESTABLISHED -j ACCEPT
iptables -A Icmp_Related_And_New -p icmp --icmp-type echo-request \
-m state --state NEW -m limit --limit 20/s -j ACCEPT

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: netfilter iptables and firewall

On 24 Oct 2006, in the Usenet newsgroup comp.security.firewalls, in article
<1161680624.249954.282620@i42g2000cwa.googlegroups.com>, EldarXP wrote:

>I'm currently using a computer with linux to do a Bridge Firewall, as
>my company have limited ressources i have put together some other
>service on it (apache, dansguardian).
>it give them a fairly secure network and should only allow some people
>to access internet.

"some people" - but none of your rules limit to individual addresses.
Of course, if your LAN is running DHCP because it's to much trouble to
set the boxes to static addresses, then you can't allow "some" people
to access the Internet unless everything is done through an authenticated
proxy, in which case your rules should block ALL access to/from the world
except via that proxy. HOWEVER - you should not depend on your firewall
to _replace_ written policy.

>Still i found some problem in my firewall where some people were still
>ablle to use web and messenger even with the set of rules i have put on
>it.

See that a _written_ policy detailing allowed Internet use is in place.
Depending on your jurisdiction, there may or may not be legal implications.
You _probably_ should consult with your company's legal advisor to be sure.

Temporarily, jack up the logging, so that you are logging all NEW
and ESTABLISHED connections (all you need it headers), for a month or
so. Use common scripting tools to sort out source and destination IPs,
and destination port numbers. Who is talking to who, and why? Is such
traffic beneficial, or tolerable? If you don't understand scripting, see
the "Bash-Prog-Intro-HOWTO" (should be on your system in /usr/share/HOWTO)
and "Advanced Bash-Scripting Guide" (version 4.1 was released two weeks
ago - try http://tldp.org/guides.html). When we did this (using tcpdump
because the firewall logging of the era wasn't very good), we wound up with
a log of roughly 350 Megabytes. It two two people _less_than_two_days_ to
ID every site, showing about 200 "holes" that had to be created through
our "block everything by default" firewall.

> iptables -P FORWARD ACCEPT

If it's not explicitly in the rules, allow ??? WTF?!? In the comments below,
I'm assuming $INTERNET means 0.0.0.0/0 or literally, the entire world.

> iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
>--dport 25

Some mail admins don't like to accept mail from systems not designated
as mail servers. Allow the mail to be forwarded to a smarthost, and sent
on from there only.

> iptables -A FORWARD -j LOG -p tcp -s $LOCALNET -d 202.72.104.1
>--dport 110
> iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET dport
>110

Log stuff to a specific destination, but allow to anywhere? Seems reversed.

> iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
>--dport 22

Allow _all_ SSH outbound???

> iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
>--dport 443

Allow _all_ https outbound???

> iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
>--dport 6667

And the reason your employees need IRC to do their jobs is what exactly?

> iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
>--dport 8383

What's 8383/tcp, and why is it needed?

> iptables -A FORWARD -j r_drop

I don't have to deal with windoze, but I'd drop INPUT and OUTPUT as well,
as nothing runs on my firewall box except the firewall, and the ordinary
users (much less the entire world) has no reason to be connecting to that
box.

> iptables -A Icmp_Related_And_New -p icmp --icmp-type
>destination-unreachable -m state --state RELATED -j ACCEPT

OK

> iptables -A Icmp_Related_And_New -p icmp --icmp-type source-quench
>-m state --state RELATED -j ACCEPT

Stretching - I rarely see a source-quench.

> iptables -A Icmp_Related_And_New -p icmp --icmp-type
>parameter-problem -m state --state RELATED -j ACCEPT

I can't recall the last time I saw one of those

> iptables -A Icmp_Related_And_New -p icmp --icmp-type time-exceeded
>-m state --state RELATED -j ACCEPT

In the modern Internet, the only time you see this is in traceroute.

> iptables -A Icmp_Related_And_New -p icmp --icmp-type echo-reply -m
>state --state ESTABLISHED -j ACCEPT
> iptables -A Icmp_Related_And_New -p icmp --icmp-type echo-request -m
>limit --limit 1/s -j ACCEPT

We allow ICMP Echo request outbound, and ICMP Echo reply inbound only.

Old guy

Re: netfilter iptables and firewall

Ansgar -59cobalt- Wiechers wrote:
> This probably doesn't solve your problem, but simplifies your ruleset a
> little:
>
> iptables -P FORWARD DROP
>
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A FORWARD -p icmp -j Icmp_Related_And_New
> iptables -A FORWARD -j r_drop
> iptables -A FORWARD -p tcp -s $LOCALNET -d 202.72.104.1 --dport 110 -j LOG
> iptables -A FORWARD -p tcp -s $LOCALNET -d $INTERNET -m multiport \
> --dport 22,25,53,443,6667,8383 -m state --state NEW -j ACCEPT
> iptables -A FORWARD -p udp -s $LOCALNET -d $INTERNET --dport 53 \
> -m state --state NEW -j ACCEPT
> # use REJECT rather than DROP
> iptables -A FORWARD -p tcp -m limit --limit 10/s --limit-burst 10 \
> -j REJECT --reject-with tcp-reset
> iptables -A FORWARD -p udp -m limit --limit 10/s --limit-burst 10 \
> -j REJECT --reject-with icmp-port-unreachable
> iptables -A FORWARD -j LOG
>
> iptables -A r_drop -p tcp --dport 135:139 -j DROP
> iptables -A r_drop -p udp --dport 135:139 -j DROP
> iptables -A r_drop -p tcp --dport 445 -j DROP
> iptables -A r_drop -p tcp --dport 1433:1434 -j DROP
>
> iptables -A Icmp_Related_And_New -p icmp --icmp-type destination-unreachable \
> -m state --state RELATED -j ACCEPT
> iptables -A Icmp_Related_And_New -p icmp --icmp-type source-quench \
> -m state --state RELATED -j ACCEPT
> iptables -A Icmp_Related_And_New -p icmp --icmp-type parameter-problem \
> -m state --state RELATED -j ACCEPT
> iptables -A Icmp_Related_And_New -p icmp --icmp-type time-exceeded \
> -m state --state RELATED -j ACCEPT
> iptables -A Icmp_Related_And_New -p icmp --icmp-type echo-reply \
> -m state --state ESTABLISHED -j ACCEPT
> iptables -A Icmp_Related_And_New -p icmp --icmp-type echo-request \
> -m state --state NEW -m limit --limit 20/s -j ACCEPT

First i would like to thank you for your help, true it's look like a
bit more easy to read it like this.

Still i'm a bit confuse here shouldnt't we put the rules with limit on
top of the rules?

I would like also to explain a bit more let say that my network is a
bit like this
hosts->firewall->router->internet
so most of the hosts who use the proxy is fine and are efectively
limited
now if they remove the proxy and access the apache server on the bridge
and then go to yahoo.com they have a full access to internet :_) and
more sometimes they manage to use yahoo messenger wich is the point why
i put this firewalll...
only way i manage to block it was to drop or reject the port for http
and yahoo (5000-5100)
i also put a preroute rules to redirect them to the proxy but it's not
working as the server need them to be identified...

Also i made a mistake on the mail, i forgot the ! in front of the
destination

Re: netfilter iptables and firewall

Moe Trin wrote:
> On 24 Oct 2006, in the Usenet newsgroup comp.security.firewalls, in article
> <1161680624.249954.282620@i42g2000cwa.googlegroups.com>, EldarXP wrote:
>
> >I'm currently using a computer with linux to do a Bridge Firewall, as
> >my company have limited ressources i have put together some other
> >service on it (apache, dansguardian).
> >it give them a fairly secure network and should only allow some people
> >to access internet.
>
> "some people" - but none of your rules limit to individual addresses.
> Of course, if your LAN is running DHCP because it's to much trouble to
> set the boxes to static addresses, then you can't allow "some" people
> to access the Internet unless everything is done through an authenticated
> proxy, in which case your rules should block ALL access to/from the world
> except via that proxy. HOWEVER - you should not depend on your firewall
> to _replace_ written policy.
>
> >Still i found some problem in my firewall where some people were still
> >ablle to use web and messenger even with the set of rules i have put on
> >it.
>
> See that a _written_ policy detailing allowed Internet use is in place.
> Depending on your jurisdiction, there may or may not be legal implications.
> You _probably_ should consult with your company's legal advisor to be sure.
>
> Temporarily, jack up the logging, so that you are logging all NEW
> and ESTABLISHED connections (all you need it headers), for a month or
> so. Use common scripting tools to sort out source and destination IPs,
> and destination port numbers. Who is talking to who, and why? Is such
> traffic beneficial, or tolerable? If you don't understand scripting, see
> the "Bash-Prog-Intro-HOWTO" (should be on your system in /usr/share/HOWTO)
> and "Advanced Bash-Scripting Guide" (version 4.1 was released two weeks
> ago - try http://tldp.org/guides.html). When we did this (using tcpdump
> because the firewall logging of the era wasn't very good), we wound up with
> a log of roughly 350 Megabytes. It two two people _less_than_two_days_ to
> ID every site, showing about 200 "holes" that had to be created through
> our "block everything by default" firewall.
>
> > iptables -P FORWARD ACCEPT
>
> If it's not explicitly in the rules, allow ??? WTF?!? In the comments below,
> I'm assuming $INTERNET means 0.0.0.0/0 or literally, the entire world.
>
> > iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
> >--dport 25
>
> Some mail admins don't like to accept mail from systems not designated
> as mail servers. Allow the mail to be forwarded to a smarthost, and sent
> on from there only.
>
> > iptables -A FORWARD -j LOG -p tcp -s $LOCALNET -d 202.72.104.1
> >--dport 110
> > iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET dport
> >110
>
> Log stuff to a specific destination, but allow to anywhere? Seems reversed.
Oups forget the ! in front of the destination
still i won't be in this country and i know the support would be quite
difficult so i just prefer to allow them access to any smtp server (i
would prefer to block it but then who will change the rules to match
the new destination...)


> > iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
> >--dport 22
>
> Allow _all_ SSH outbound???
Might be right i can remove this i'm the only one to use ssh.

> > iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
> >--dport 443
>
> Allow _all_ https outbound???

> > iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
> >--dport 6667
>
> And the reason your employees need IRC to do their jobs is what exactly?
hum that was for me :)

> > iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
> >--dport 8383
>
> What's 8383/tcp, and why is it needed?
arg this one i would prefer to remove it but they got an application on
this port wich need to access their intranet...

> > iptables -A FORWARD -j r_drop
>
> I don't have to deal with windoze, but I'd drop INPUT and OUTPUT as well,
> as nothing runs on my firewall box except the firewall, and the ordinary
> users (much less the entire world) has no reason to be connecting to that
> box.

hum i will folow the example in the first post for my input and output
seem good for me.

> > iptables -A Icmp_Related_And_New -p icmp --icmp-type
> >destination-unreachable -m state --state RELATED -j ACCEPT
>
> OK
>
> > iptables -A Icmp_Related_And_New -p icmp --icmp-type source-quench
> >-m state --state RELATED -j ACCEPT
>
> Stretching - I rarely see a source-quench.
>
> > iptables -A Icmp_Related_And_New -p icmp --icmp-type
> >parameter-problem -m state --state RELATED -j ACCEPT
>
> I can't recall the last time I saw one of those
>
> > iptables -A Icmp_Related_And_New -p icmp --icmp-type time-exceeded
> >-m state --state RELATED -j ACCEPT
>
> In the modern Internet, the only time you see this is in traceroute.
>
> > iptables -A Icmp_Related_And_New -p icmp --icmp-type echo-reply -m
> >state --state ESTABLISHED -j ACCEPT
> > iptables -A Icmp_Related_And_New -p icmp --icmp-type echo-request -m
> >limit --limit 1/s -j ACCEPT
>
> We allow ICMP Echo request outbound, and ICMP Echo reply inbound only.
>
Hum ok i will just remove them

> Old guy

Re: netfilter iptables and firewall

EldarXP wrote:
> Ansgar -59cobalt- Wiechers wrote:
>> This probably doesn't solve your problem, but simplifies your ruleset a
>> little:
>>
>> iptables -P FORWARD DROP
>>
>> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>> iptables -A FORWARD -p icmp -j Icmp_Related_And_New
>> iptables -A FORWARD -j r_drop
>> iptables -A FORWARD -p tcp -s $LOCALNET -d 202.72.104.1 --dport 110 -j LOG
>> iptables -A FORWARD -p tcp -s $LOCALNET -d $INTERNET -m multiport \
>> --dport 22,25,53,443,6667,8383 -m state --state NEW -j ACCEPT
>> iptables -A FORWARD -p udp -s $LOCALNET -d $INTERNET --dport 53 \
>> -m state --state NEW -j ACCEPT
>> # use REJECT rather than DROP
>> iptables -A FORWARD -p tcp -m limit --limit 10/s --limit-burst 10 \
>> -j REJECT --reject-with tcp-reset
>> iptables -A FORWARD -p udp -m limit --limit 10/s --limit-burst 10 \
>> -j REJECT --reject-with icmp-port-unreachable
>> iptables -A FORWARD -j LOG
>>
>> iptables -A r_drop -p tcp --dport 135:139 -j DROP
>> iptables -A r_drop -p udp --dport 135:139 -j DROP
>> iptables -A r_drop -p tcp --dport 445 -j DROP
>> iptables -A r_drop -p tcp --dport 1433:1434 -j DROP
>>
>> iptables -A Icmp_Related_And_New -p icmp --icmp-type destination-unreachable \
>> -m state --state RELATED -j ACCEPT
>> iptables -A Icmp_Related_And_New -p icmp --icmp-type source-quench \
>> -m state --state RELATED -j ACCEPT
>> iptables -A Icmp_Related_And_New -p icmp --icmp-type parameter-problem \
>> -m state --state RELATED -j ACCEPT
>> iptables -A Icmp_Related_And_New -p icmp --icmp-type time-exceeded \
>> -m state --state RELATED -j ACCEPT
>> iptables -A Icmp_Related_And_New -p icmp --icmp-type echo-reply \
>> -m state --state ESTABLISHED -j ACCEPT
>> iptables -A Icmp_Related_And_New -p icmp --icmp-type echo-request \
>> -m state --state NEW -m limit --limit 20/s -j ACCEPT
>
> First i would like to thank you for your help, true it's look like a
> bit more easy to read it like this.
>
> Still i'm a bit confuse here shouldnt't we put the rules with limit on
> top of the rules?

There are only three rules that make use of the limit module: the two
REJECT rules, and the rule limiting echo-requests. The former two need
to be at the end of the FORWARD chain, and for the latter it doesn't
matter where in the Icmp_Related_And_New chain it is.

You seem to lack understanding of how the chains in netfilter work. The
three rule-blocks that are quoted above set rules in three different
chains. The second and third blocks set rules in user-defined chains
into which the second and third rule in the FORWARD chain (first block)
branch. A packet that has gone through a user-defined chain and not
matched a rule in it is returned to the "parent" chain.

> I would like also to explain a bit more let say that my network is a
> bit like this
> hosts->firewall->router->internet
> so most of the hosts who use the proxy is fine and are efectively
> limited now if they remove the proxy and access the apache server on
> the bridge and then go to yahoo.com they have a full access to
> internet :_) and more sometimes they manage to use yahoo messenger
> wich is the point why i put this firewalll...
> only way i manage to block it was to drop or reject the port for http
> and yahoo (5000-5100)
> i also put a preroute rules to redirect them to the proxy but it's not
> working as the server need them to be identified...

So what you really want is a transparent proxy. I haven't done this
myself, but IIRC you need to mark packets to get it to work.

http://tldp.org/HOWTO/TransparentProxy.html

> Also i made a mistake on the mail, i forgot the ! in front of the
> destination

You mean the logging rule? That still doesn't explain why you want to
log it.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: netfilter iptables and firewall

EldarXP wrote:
> Moe Trin wrote:
>>> iptables -A Icmp_Related_And_New -p icmp --icmp-type echo-reply -m
>>>state --state ESTABLISHED -j ACCEPT
>>> iptables -A Icmp_Related_And_New -p icmp --icmp-type echo-request -m
>>>limit --limit 1/s -j ACCEPT
>>
>> We allow ICMP Echo request outbound, and ICMP Echo reply inbound only.
>
> Hum ok i will just remove them

I'd strongly recommend against that unless you have a very good reason
to do it. ICMP is needed whenever you have to troubleshoot IP problems.
You should rather add type 3 (destination-unreachable) to the list of
allowed packets.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: netfilter iptables and firewall

On 24 Oct 2006, in the Usenet newsgroup comp.security.firewalls, in article
<1161749127.177688.216230@f16g2000cwb.googlegroups.com>, EldarXP wrote:
>
>Moe Trin wrote:
>> EldarXP wrote:

>>> iptables -A FORWARD -j LOG -p tcp -s $LOCALNET -d 202.72.104.1
>>>--dport 110
>>> iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET dport
>>>110
>>
>> Log stuff to a specific destination, but allow to anywhere? Seems reversed.

>Oups forget the ! in front of the destination
>still i won't be in this country and i know the support would be quite
>difficult so i just prefer to allow them access to any smtp server (i
>would prefer to block it but then who will change the rules to match
>the new destination...)

This is port 110 - "Post Office Protocol v3" or RFC1939. This is where
the users connect to collect their individual mail. It's downstream of
the SMTP protocols (RFC0821 and/or RFC2821). Depending on your layout,
this _should_ be a fixed server behind your firewall, or at worst, the
pop-server of your ISP. Your users shouldn't need to be connecting to
"other" pop servers.

>>> iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
>>>--dport 22
>>
>> Allow _all_ SSH outbound???

>Might be right i can remove this i'm the only one to use ssh.

You're allowing everyone access to everywhere. Hardly very secure.

>> And the reason your employees need IRC to do their jobs is what exactly?

>hum that was for me :)

Same thing - you are allowing everyone access to everywhere.

>>> iptables -A FORWARD -j ACCEPT -p tcp -s $LOCALNET -d $INTERNET
>>>--dport 8383
>>
>> What's 8383/tcp, and why is it needed?

>arg this one i would prefer to remove it but they got an application on
>this port wich need to access their intranet...

Accessing _their_ intranet - you've got the directions wrong. You also
should recommend changing the port number, as 8383-8385 is used for a
web mail application that has no place in a business environment.

>hum i will folow the example in the first post for my input and output
>seem good for me.

Rusty Russell of Samba.org (author of the netfiltering code) has a number
of "unofficial" HOWTOs at http://www.iptables.org/documentation/HOWTO/

[TXT] NAT-HOWTO.txt 17-Oct-2004 14:34 25K
[TXT] netfilter-double-nat-HOWTO.txt 17-Oct-2004 14:34 9.4K
[TXT] netfilter-extensions-HOWTO.txt 17-Oct-2004 14:34 79K
[TXT] netfilter-hacking-HOWTO.txt 17-Oct-2004 14:35 84K
[TXT] networking-concepts-HOWTO.txt 17-Oct-2004 14:34 28K
[TXT] packet-filtering-HOWTO.txt 17-Oct-2004 14:34 52K

(also available in HTML, Postscript, and SGML at the same directory), and
there are several of the official Linux Documentation Project HOWTOs as
well - see

-rw-rw-r-- 1 gferg ldp 271987 Oct 17 12:54 HOWTO-INDEX
-rw-rw-r-- 1 gferg linux 96946 Oct 17 12:54 INDEX
-rw-rw-r-- 1 gferg ldp 708351 Nov 14 2005 IP-Masquerade-HOWTO
-rw-rw-r-- 1 gferg ldp 17605 Jul 21 2004 Masquerading-Simple-HOWTO
-rw-rw-r-- 1 gferg ldp 155096 Jan 23 2004 Security-HOWTO
-rw-rw-r-- 1 gferg ldp 278012 Jul 23 2002 Security-Quickstart-HOWTO

>> We allow ICMP Echo request outbound, and ICMP Echo reply inbound only.
>
>Hum ok i will just remove them

Several years ago, the (US) National Security Agency had a web page with
recommendations for firewall rules (now 404s) that was derived from page
89 of the (then current) Cisco Security Guide. Briefly, they said

deny icmp any any echo
deny icmp any any redirect
deny icmp any any mask-request
permit icmp any
(allow pings where needed obviously)

Translated, that is block Type 8, 5, 17. I disagree, suggesting that you
allow 0, 3, and 11 INBOUND, 3, and 8 OUTBOUND, while denying all else. YMMV.

Old guy

Re: netfilter iptables and firewall

Moe Trin wrote:
> Several years ago, the (US) National Security Agency had a web page
> with recommendations for firewall rules (now 404s) that was derived
> from page 89 of the (then current) Cisco Security Guide. Briefly, they
> said
>
> deny icmp any any echo
> deny icmp any any redirect
> deny icmp any any mask-request
> permit icmp any
> (allow pings where needed obviously)
>
> Translated, that is block Type 8, 5, 17. I disagree, suggesting that
> you allow 0, 3, and 11 INBOUND, 3, and 8 OUTBOUND, while denying all
> else. YMMV.

I concur largely. However, I still don't see a good reason to not allow
types 4 and 12 inbound as well.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: netfilter iptables and firewall

Post removed (X-No-Archive: yes)

Re: netfilter iptables and firewall

On Wed, 25 Oct 2006, in the Usenet newsgroup comp.security.firewalls, in
article , Leythos wrote:

>In article <4qa7hhFm37clU1@individual.net>, usenet-2006@planetcobalt.net
>says...
>> Moe Trin wrote:

[Cisco ICMP recommendations via NSA]

>>> Translated, that is block Type 8, 5, 17. I disagree, suggesting that
>>> you allow 0, 3, and 11 INBOUND, 3, and 8 OUTBOUND, while denying all
>>> else. YMMV.

>> I concur largely. However, I still don't see a good reason to not allow
>> types 4 and 12 inbound as well.

4 0 Source Quench
12 Parameter Problem
0 Pointer indicates the error
1 Missing a Required Option (RFC1108)
2 Bad Length

Both of those have been used for denial of service _far_ more often than
used for their "intended" purpose. RFC1108 _rarely_ applies

1108 U.S. Department of Defense Security Options for the Internet
Protocol. S. Kent. November 1991. (Format: TXT=41791 bytes)
(Obsoletes RFC1038) (Status: HISTORIC)

>Because the general/first rule of security is to not allow anything that
>has no reason on your network.

Agreed

>ICMP (any) is not needed between the LAN/WAN interface in most cases.

Well, you do qualify that - but I stand by my suggestion noted above. If
you actually look at ftp://ftp.iana.org/assignments/icmp-parameters (and
if you use IPv6, the very different '/assignments/icmpv6-parameters'),
there are 28 ICMPv4 types (30 ICMPv6 types). Just for giggles, during the
month of March 2006, I ran a packet sniffer on our primary link to the
world, snarfing _only_ ICMP packets. Type 3 accounted for ~86.2% (roughly
506k), Type 8 was about 13.2% (~79k), type 0 ~0.5% (~3k) and type 11 the
remainder. My notes remark that there were less than 100 others (well
under 0.02%), mainly type 5 and a single (apparently unsolicited) type 4.
I was a bit surprised that the inbound pings were so low (at home, they
were roughly a third, with the others reduces proportionally). I had
previously run this test in March or April of 2003, and while I don't have
the notes, I recall that type 8s were the majority - perhaps related to
a worm that was active at the time.

Old guy

Re: netfilter iptables and firewall

Moe Trin wrote:
> On Wed, 25 Oct 2006, Leythos wrote:
>> usenet-2006@planetcobalt.net says...
>>> Moe Trin wrote:
>
> [Cisco ICMP recommendations via NSA]
>
>>>> Translated, that is block Type 8, 5, 17. I disagree, suggesting
>>>> that you allow 0, 3, and 11 INBOUND, 3, and 8 OUTBOUND, while
>>>> denying all else. YMMV.
>>>
>>> I concur largely. However, I still don't see a good reason to not
>>> allow types 4 and 12 inbound as well.
>
> 4 0 Source Quench
> 12 Parameter Problem
> 0 Pointer indicates the error
> 1 Missing a Required Option (RFC1108)
> 2 Bad Length
>
> Both of those have been used for denial of service _far_ more often
> than used for their "intended" purpose.

Could you provide some more details on what kind of DoS, and in which
scenarios they were used?

> RFC1108 _rarely_ applies
>
> 1108 U.S. Department of Defense Security Options for the Internet
> Protocol. S. Kent. November 1991. (Format: TXT=41791 bytes)
> (Obsoletes RFC1038) (Status: HISTORIC)

Even though the applicability of RFC 1108 is questionable, there are
still the codes 0 and 2 which AFAICS are not subject to RFC 1108.

>> Because the general/first rule of security is to not allow anything
>> that has no reason on your network.
>
> Agreed

Ah, but they do have a reason, as specified in RFC 792. Don't get me
wrong, there's nothing wrong with blocking them at the border when you
are certain noone will ever need to receive these messages from outside
the network in question, but *be* certain about it in the first place.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich