Mail Server Behind IPTABLES

Mail Server Behind IPTABLES

[Ajen Diwakar]

Hi All

I am new to IPTABLES usage. I have linux(RH) 9.0.
The external IP address eth1 is 202.62.x.x
The internal ip address is 10.0.0.4

My mail server IP address is 10.0.0.10

How do I setup my iptables so that the mail to my record get transfred
to the mail server.

Any assistance will be appreciated.

Re: Mail Server Behind IPTABLES

[George Alexandru Dragoi]

iptables -t nat -A PREROUTING -i eth1 -d 202.62.x.x -p tcp --dport 25
-j DNAT --to 10.0.0.10

On Wed, 1 Sep 2004 13:01:10 +1200, Ajen Diwakar <ajen@nsl.com.fj> wrote:
> Hi All
> 
> I am new to IPTABLES usage. I have linux(RH) 9.0.
> The external IP address eth1 is 202.62.x.x
> The internal ip address is 10.0.0.4
> 
> My mail server IP address is 10.0.0.10
> 
> How do I setup my iptables so that the mail to my record get transfred
> to the mail server.
> 
> Any assistance will be appreciated.
> 
> 


-- 
Bla bla

Policy Misunderstanding: RTFM Guidance Requested.

[Mike]

I have a linux box acting as router/firewall for my home network.
It runs Gentoo Linux, kernel 2.4.26 and iptables 1.2.10.
eth0 -> Internet
eth1 -> Lan

I thought I had seen others on this list discuss starting with a
completely closed router that denies all traffic - INPUT, OUTPUT, and
FORWARD; filter, nat, and mangle.  Yet, when I reset my firewall
Policies to initially DROP all INPUT, OUTPUT, and FORWARD traffic, and
then append these policies with filter or nat rules, the policies
still overrule and stop all traffic.

I've read the man page a few times and have found a few tutuorials on
the net, but I'm still missing the fundamental understanding of how
policies do/do not affect iptables rules.

Can I get an RTFM push in the right direction on this subject.
Thanks for your time and patience.

Mike

Maybe I should post the firewall so you can see there are no glaring
errors in my syntax:

ENABLE_FORWARDING_IPv4="yes"

IPTABLES=/sbin/iptables
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

$DEPMOD -a
$MODPROBE ip_tables
$MODPROBE ip_conntrack
$MODPROBE ip_conntrack_ftp
$MODPROBE ip_conntrack_irc
$MODPROBE iptable_nat
$MODPROBE ip_nat_ftp

echo "   Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward

echo "   Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr

echo "   Flushing any pre-existing filter rules or conditions."
$IPTABLES -t filter -F
$IPTABLES -t nat -F
$IPTABLES -t mangle -F

echo "   Set the filter/nat/mangle packet Matching Table Policy."
$IPTABLES -t filter -P INPUT DROP
$IPTABLES -t filter -P OUTPUT DROP
$IPTABLES -t filter -P FORWARD DROP
$IPTABLES -t nat -P PREROUTING DROP
$IPTABLES -t nat -P POSTROUTING DROP
$IPTABLES -t nat -P OUTPUT DROP
$IPTABLES -t mangle -P INPUT DROP
$IPTABLES -t mangle -P OUTPUT DROP
$IPTABLES -t mangle -P FORWARD DROP
$IPTABLES -t mangle -P PREROUTING DROP
$IPTABLES -t mangle -P POSTROUTING DROP

echo "   INPUT/OUTPUT Rules for Routerbox."
$IPTABLES -t filter -A INPUT -j ACCEPT
$IPTABLES -t filter -A OUTPUT -j ACCEPT

echo "   FORWARD Rules for data allowed IN and OUT of the LAN."
$IPTABLES -t filter -A FORWARD -i eth0 -o eth1 -m state --state
ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -t filter -A FORWARD -i eth0 -o eth1 -m state --state NEW -j ACCEPT


echo "   Allowing HTTP and SSH Access."
$IPTABLES -t filter -A INPUT -p tcp -i eth0 --dport 22 -m state
--state NEW -j ACCEPT
$IPTABLES -t filter -A INPUT -p tcp -i eth0 --dport 80 -m state
--state NEW -j ACCEPT

echo "   Enabling NAT MASQUERADE."
$IPTABLES -t nat -A POSTROUTING -o eth0 -j MASQUERADE

echo "   Prevent remote machines from spoofing internal IP addresses."
$IPTABLES -t filter -A INPUT -i eth0 -s 199.201.13.0/24 -j REJECT

echo "   Do not respond to remote Pings."
$IPTABLES -t filter -A INPUT -p icmp --icmp-type echo-request -j DROP

RE: Policy Misunderstanding: RTFM Guidance Requested.

[Deepak Seshadri]

Hi Mike,

If the default policy on your mangle & Nat chain is set to DROP & if you
have no rules to classify traffic in these tables, all your packets will get
dropped here. They will not make it to the FILTER table.

In your commands, first you have set the default policy to DROP on all
chains in the filter table. Then you have set policies to accept all the
traffic in the INPUT & OUTPUT chains. I do not get this. If you are aiming
to accept all packets in the INPUT & OUTPUT chain you might as well set the
default policy in these chains to ACCEPT.

My suggestion would be to set the default policy on the chains in mangle &
Nat to ACCEPT.
Set the default policy on the chains in filter to DROP.

I will email you a diagram on the packet flow inside the kernel. Probably
that would make things easier in understanding where each chain exists
inside the kernel.

Regards,
Deepak


Deepak Seshadri

-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Mike
Sent: Wednesday, September 01, 2004 7:55 AM
To: netfilter@lists.netfilter.org
Subject: Policy Misunderstanding: RTFM Guidance Requested.

I have a linux box acting as router/firewall for my home network.
It runs Gentoo Linux, kernel 2.4.26 and iptables 1.2.10.
eth0 -> Internet
eth1 -> Lan

I thought I had seen others on this list discuss starting with a
completely closed router that denies all traffic - INPUT, OUTPUT, and
FORWARD; filter, nat, and mangle.  Yet, when I reset my firewall
Policies to initially DROP all INPUT, OUTPUT, and FORWARD traffic, and
then append these policies with filter or nat rules, the policies
still overrule and stop all traffic.

I've read the man page a few times and have found a few tutuorials on
the net, but I'm still missing the fundamental understanding of how
policies do/do not affect iptables rules.

Can I get an RTFM push in the right direction on this subject.
Thanks for your time and patience.

Mike

Maybe I should post the firewall so you can see there are no glaring
errors in my syntax:

ENABLE_FORWARDING_IPv4="yes"

IPTABLES=/sbin/iptables
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

$DEPMOD -a
$MODPROBE ip_tables
$MODPROBE ip_conntrack
$MODPROBE ip_conntrack_ftp
$MODPROBE ip_conntrack_irc
$MODPROBE iptable_nat
$MODPROBE ip_nat_ftp

echo "   Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward

echo "   Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr

echo "   Flushing any pre-existing filter rules or conditions."
$IPTABLES -t filter -F
$IPTABLES -t nat -F
$IPTABLES -t mangle -F

echo "   Set the filter/nat/mangle packet Matching Table Policy."
$IPTABLES -t filter -P INPUT DROP
$IPTABLES -t filter -P OUTPUT DROP
$IPTABLES -t filter -P FORWARD DROP
$IPTABLES -t nat -P PREROUTING DROP
$IPTABLES -t nat -P POSTROUTING DROP
$IPTABLES -t nat -P OUTPUT DROP
$IPTABLES -t mangle -P INPUT DROP
$IPTABLES -t mangle -P OUTPUT DROP
$IPTABLES -t mangle -P FORWARD DROP
$IPTABLES -t mangle -P PREROUTING DROP
$IPTABLES -t mangle -P POSTROUTING DROP

echo "   INPUT/OUTPUT Rules for Routerbox."
$IPTABLES -t filter -A INPUT -j ACCEPT
$IPTABLES -t filter -A OUTPUT -j ACCEPT

echo "   FORWARD Rules for data allowed IN and OUT of the LAN."
$IPTABLES -t filter -A FORWARD -i eth0 -o eth1 -m state --state
ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -t filter -A FORWARD -i eth0 -o eth1 -m state --state NEW -j
ACCEPT


echo "   Allowing HTTP and SSH Access."
$IPTABLES -t filter -A INPUT -p tcp -i eth0 --dport 22 -m state
--state NEW -j ACCEPT
$IPTABLES -t filter -A INPUT -p tcp -i eth0 --dport 80 -m state
--state NEW -j ACCEPT

echo "   Enabling NAT MASQUERADE."
$IPTABLES -t nat -A POSTROUTING -o eth0 -j MASQUERADE

echo "   Prevent remote machines from spoofing internal IP addresses."
$IPTABLES -t filter -A INPUT -i eth0 -s 199.201.13.0/24 -j REJECT

echo "   Do not respond to remote Pings."
$IPTABLES -t filter -A INPUT -p icmp --icmp-type echo-request -j DROP

Re: Policy Misunderstanding: RTFM Guidance Requested.

[Mike]

Hi Deepak,

Thank you for your response.

On Wed, 1 Sep 2004 09:27:22 -0400, Deepak Seshadri
<dseshadri@broadbandmaritime.com> wrote:
> 
> If the default policy on your mangle & Nat chain is set to DROP & if you
> have no rules to classify traffic in these tables, all your packets will get
> dropped here. They will not make it to the FILTER table.

This is a good point and shows where maybe I am starting to MIS-understand.  

1.  Can appended rules override default polices? 
2.  Do you need to include appended rules to parts of the iptables
chain that you are not using, or else all the packets will get
dropped?  For example, do you have to set Mangle rules even if you are
not using any Mangling but have set a DROP policy for mangling.

> 
> In your commands, first you have set the default policy to DROP on all
> chains in the filter table. Then you have set policies to accept all the
> traffic in the INPUT & OUTPUT chains. I do not get this. If you are aiming
> to accept all packets in the INPUT & OUTPUT chain you might as well set the
> default policy in these chains to ACCEPT.

I understand your point here.  I used those -j ACCPT rules because
everything else has failed so far to override the DROP policy, so that
was a last resort desperately trying to get some packets through the
routerbox.  I really don't want to accept everything blindly on the
INPUT and OUTPUT of the routerbox.  I would actually like to set
INPUT/OUTPUT rules that only allow traffic on a few different ports
for web browsing, ssh access, and network samba; close everything
else.


> I will email you a diagram on the packet flow inside the kernel. Probably
> that would make things easier in understanding where each chain exists
> inside the kernel.
> 

Hey now, thanks for the diagram.  This is pretty cool stuff.  I need a
few months to figure it all out though.  :-)

Please write back on the other issues above if you have a chance.
Hope to hear from you.

Thanks,

Mike

Re: Policy Misunderstanding: RTFM Guidance Requested.

[Jason Opperisano]

On Wed, 2004-09-01 at 11:46, Mike wrote:
> Hi Deepak,
> 
> Thank you for your response.
> 
> On Wed, 1 Sep 2004 09:27:22 -0400, Deepak Seshadri
> <dseshadri@broadbandmaritime.com> wrote:
> > 
> > If the default policy on your mangle & Nat chain is set to DROP & if you
> > have no rules to classify traffic in these tables, all your packets will get
> > dropped here. They will not make it to the FILTER table.
> 
> This is a good point and shows where maybe I am starting to MIS-understand.  
> 
> 1.  Can appended rules override default polices? 

yes--for example:

iptables -P INPUT DROP
iptables -A INPUT -j ACCEPT

will accept all traffic in the INPUT chain.  the POLICY of a chain is
only enforced when a packet reaches the last rule in that chain and
hasn't matched any rules.

> 2.  Do you need to include appended rules to parts of the iptables
> chain that you are not using, or else all the packets will get
> dropped?  For example, do you have to set Mangle rules even if you are
> not using any Mangling but have set a DROP policy for mangling.

if you set the policies of the mangle chains to DROP and then do not
append any rules, you can be pretty sure that no traffic will get
through.

i'd recommend against starting your netfilter adventure by setting the
policies of nat & mangle chains to DROP.  it will make it a very short
trip...

-j

-- 
Jason Opperisano <opie@817west.com>

Re: Policy Misunderstanding: RTFM Guidance Requested.

[Mike]

Jason,

Thanks for your response.
I definitely appreciate the help.

On Wed, 01 Sep 2004 12:50:58 -0400, Jason Opperisano <opie@817west.com> wrote:
> > 1.  Can appended rules override default polices?
> 
> yes--for example:
> 
> iptables -P INPUT DROP
> iptables -A INPUT -j ACCEPT

Excellent.  Now I'm clear on this point.

 > if you set the policies of the mangle chains to DROP and then do not
> append any rules, you can be pretty sure that no traffic will get
> through.
> 
> i'd recommend against starting your netfilter adventure by setting the
> policies of nat & mangle chains to DROP.  it will make it a very short
> trip...
> 

This is starting to get clearer after reading some of Adreasson's
tutorial and following the flow of packets traversing the tables.  It
looks like 'mangle' is right there at the beginning of every table
transaction, so my mangle Policy is pre-empting everything else.

Best regards.

Mike

RE: Policy Misunderstanding: RTFM Guidance Requested.

[Deepak Seshadri]

Hi Mike,
Sorry for the late reply. I have been busy since morning.
I see that some of your questions have been answered by Jason & Alistair.
Let me first answer your 2nd question:
 - If you are not using a "chain" for setting up rules but set the default
policy to "drop" and if a packet traverses that chain then it will be
dropped. Hence by putting rules, I classify packets that I want to allow.
The rest will be dropped by default. 

I guess your 1st question is answered now: Yes, rules appended will override
the default policies.

This is how I would write the policies to achieve your goal:

Default policy for chains in Mangle & Nat tables to ACCEPT.
Default policy for chains in filter table to DROP.

Open dports ports 80 & 22 on the INPUT, FORWARD & OUTPUT chains.
Enable stateful firewall rules on these chains.
ACCEPT only NEW packets.

I do not know the port # for samba services.

Hey, I am glad the diagram worked out for ya.
Hope this helps.
Take care,

Deepak Seshadri


-----Original Message-----
From: Mike [mailto:1100100@gmail.com] 
Sent: Wednesday, September 01, 2004 11:46 AM
To: Deepak Seshadri
Cc: netfilter@lists.netfilter.org
Subject: Re: Policy Misunderstanding: RTFM Guidance Requested.

Hi Deepak,

Thank you for your response.

On Wed, 1 Sep 2004 09:27:22 -0400, Deepak Seshadri
<dseshadri@broadbandmaritime.com> wrote:
> 
> If the default policy on your mangle & Nat chain is set to DROP & if you
> have no rules to classify traffic in these tables, all your packets will
get
> dropped here. They will not make it to the FILTER table.

This is a good point and shows where maybe I am starting to MIS-understand.


1.  Can appended rules override default polices? 
2.  Do you need to include appended rules to parts of the iptables
chain that you are not using, or else all the packets will get
dropped?  For example, do you have to set Mangle rules even if you are
not using any Mangling but have set a DROP policy for mangling.

> 
> In your commands, first you have set the default policy to DROP on all
> chains in the filter table. Then you have set policies to accept all the
> traffic in the INPUT & OUTPUT chains. I do not get this. If you are aiming
> to accept all packets in the INPUT & OUTPUT chain you might as well set
the
> default policy in these chains to ACCEPT.

I understand your point here.  I used those -j ACCPT rules because
everything else has failed so far to override the DROP policy, so that
was a last resort desperately trying to get some packets through the
routerbox.  I really don't want to accept everything blindly on the
INPUT and OUTPUT of the routerbox.  I would actually like to set
INPUT/OUTPUT rules that only allow traffic on a few different ports
for web browsing, ssh access, and network samba; close everything
else.


> I will email you a diagram on the packet flow inside the kernel. Probably
> that would make things easier in understanding where each chain exists
> inside the kernel.
> 

Hey now, thanks for the diagram.  This is pretty cool stuff.  I need a
few months to figure it all out though.  :-)

Please write back on the other issues above if you have a chance.
Hope to hear from you.

Thanks,

Mike

Re: Policy Misunderstanding: RTFM Guidance Requested.

[Mike]

On Wed, 1 Sep 2004 09:27:22 -0400, Deepak Seshadri
<dseshadri@broadbandmaritime.com> wrote:
> 
> Hi Mike,
> 
> I will email you a diagram on the packet flow inside the kernel. Probably
> that would make things easier in understanding where each chain exists
> inside the kernel.
> 
> Regards,
> Deepak

Deepak,

The light is coming in slowly.  :-)
I am now able to follow the diagram you sent by reading along in the
Andreasson Iptables Tutorial 1.1.19.

Very cool stuff.

Mike

Re: Policy Misunderstanding: RTFM Guidance Requested.

[Alistair Tonner]

On September 1, 2004 07:54 am, Mike wrote:
> I have a linux box acting as router/firewall for my home network.
> It runs Gentoo Linux, kernel 2.4.26 and iptables 1.2.10.

	Yumm ...Gentoo -- good stuff

> I thought I had seen others on this list discuss starting with a
> completely closed router that denies all traffic - INPUT, OUTPUT, and
> FORWARD; filter, nat, and mangle.  Yet, when I reset my firewall
> Policies to initially DROP all INPUT, OUTPUT, and FORWARD traffic, and
> then append these policies with filter or nat rules, the policies
> still overrule and stop all traffic.

	Set POLICY for INPUT OUTPUT and FORWARD to DROP in filter only.
	If you start setting the POLICY for nat and mangle tables to DROP, things
	will misbehave badly.  And be hard to debug. -- there are those that 
	disagree, and have success doing things like this but in general and
	for a home router, it is in many folks eyes a (tm) Really Bad Thing (tm).

>
> I've read the man page a few times and have found a few tutuorials on
> the net, but I'm still missing the fundamental understanding of how
> policies do/do not affect iptables rules.
>
> Can I get an RTFM push in the right direction on this subject.
> Thanks for your time and patience.

	There is a wonderful fellow named Oskar Andreasson who has written a 
wonderful set of tutorials, and even provides some elemental scripts as 
guidelines 
	http://iptables-tutorial.frozentux.net/

	Read and enjoy

	(comments inline)
>
> Mike
>
> Maybe I should post the firewall so you can see there are no glaring
> errors in my syntax:
>
> ENABLE_FORWARDING_IPv4="yes"

>
> IPTABLES=/sbin/iptables
> DEPMOD=/sbin/depmod
> MODPROBE=/sbin/modprobe
>
> $DEPMOD -a
> $MODPROBE ip_tables
> $MODPROBE ip_conntrack
> $MODPROBE ip_conntrack_ftp
> $MODPROBE ip_conntrack_irc
> $MODPROBE iptable_nat
> $MODPROBE ip_nat_ftp
>
> echo "   Enabling forwarding.."
> echo "1" > /proc/sys/net/ipv4/ip_forward

	Urk
	  Do this at the *end* of the script. -- just a good habit to NOT turn on 
forwarding until all the rules are loaded to handle it.

>
> echo "   Enabling DynamicAddr.."
> echo "1" > /proc/sys/net/ipv4/ip_dynaddr
>
> echo "   Flushing any pre-existing filter rules or conditions."
> $IPTABLES -t filter -F
> $IPTABLES -t nat -F
> $IPTABLES -t mangle -F
>
> echo "   Set the filter/nat/mangle packet Matching Table Policy."
> $IPTABLES -t filter -P INPUT DROP
> $IPTABLES -t filter -P OUTPUT DROP
> $IPTABLES -t filter -P FORWARD DROP

The above are a (tm) Good Thing (tm)

> $IPTABLES -t nat -P PREROUTING DROP
> $IPTABLES -t nat -P POSTROUTING DROP
> $IPTABLES -t nat -P OUTPUT DROP
> $IPTABLES -t mangle -P INPUT DROP
> $IPTABLES -t mangle -P OUTPUT DROP
> $IPTABLES -t mangle -P FORWARD DROP
> $IPTABLES -t mangle -P PREROUTING DROP
> $IPTABLES -t mangle -P POSTROUTING DROP

In general the above are a (tm) Really Bad Thing (tm)

>
> echo "   INPUT/OUTPUT Rules for Routerbox."
> $IPTABLES -t filter -A INPUT -j ACCEPT
> $IPTABLES -t filter -A OUTPUT -j ACCEPT

Uhhh ... I hope these are only here because yer having problems -- 
   These above two rules are a (tm) Really Bad Thing (tm)
	(they basically allow everything in and out -- *ouch*)
>
> echo "   FORWARD Rules for data allowed IN and OUT of the LAN."
> $IPTABLES -t filter -A FORWARD -i eth0 -o eth1 -m state --state
> ESTABLISHED,RELATED -j ACCEPT

Repeat the above rule for filter INPUT 

> $IPTABLES -t filter -A FORWARD -i eth0 -o eth1 -m state --state NEW -j
> ACCEPT

The above rule is a (tm) Really Bad Thing (tm)
	(basically allows everything into yer lan *ouch*)
>
>
> echo "   Allowing HTTP and SSH Access."
> $IPTABLES -t filter -A INPUT -p tcp -i eth0 --dport 22 -m state
> --state NEW -j ACCEPT
> $IPTABLES -t filter -A INPUT -p tcp -i eth0 --dport 80 -m state
> --state NEW -j ACCEPT
>
> echo "   Enabling NAT MASQUERADE."
> $IPTABLES -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>
> echo "   Prevent remote machines from spoofing internal IP addresses."
> $IPTABLES -t filter -A INPUT -i eth0 -s 199.201.13.0/24 -j REJECT
>
> echo "   Do not respond to remote Pings."
> $IPTABLES -t filter -A INPUT -p icmp --icmp-type echo-request -j DROP
Umm .. You *might* want to set this to deny ping requests from the outside, 
rather than dropping them all .. .unless you don't trust users on the inside. 
*grin*


	Alistair Tonner

Re: Policy Misunderstanding: RTFM Guidance Requested.

[Mike]

Hi Alistair,

Thanks for the reply.  I appreciate you taking a look and providing comments.
I want to ask you about some of these "Really Bad Thing"(s)

> > It runs Gentoo Linux, kernel 2.4.26 and iptables 1.2.10.
> 
>         Yumm ...Gentoo -- good stuff

Definitely yes.  I switched from Slackware which I will always be fond
of, but Gentoo has so much to offer.  I'll leave it there because one
could write for days about portage and optimizations.

> 
> > I thought I had seen others on this list discuss starting with a
> > completely closed router that denies all traffic - INPUT, OUTPUT, and
> > FORWARD; filter, nat, and mangle.

>         Set POLICY for INPUT OUTPUT and FORWARD to DROP in filter only.
>         If you start setting the POLICY for nat and mangle tables to DROP, things
>         will misbehave badly.  And be hard to debug. -- there are those that
>         disagree, and have success doing things like this but in general and
>         for a home router, it is in many folks eyes a (tm) Really Bad Thing (tm).

This comment pricks up my ears/eyes.  Why is this so, and do you have
links to discussions on this topic.

>         There is a wonderful fellow named Oskar Andreasson who has written a
> wonderful set of tutorials, and even provides some elemental scripts as
> guidelines
>         http://iptables-tutorial.frozentux.net/
> 
>         Read and enjoy

Thanks for pointer.  I've got a Firefox tab open to it right now. 
Looks very good.  Now let's see if I can absorb it.

> >
> > echo "   Enabling forwarding.."
> > echo "1" > /proc/sys/net/ipv4/ip_forward
> 
>         Urk
>           Do this at the *end* of the script. -- just a good habit to NOT turn on
> forwarding until all the rules are loaded to handle it.

That sounds like a very good idea to me.  Noted for edit this evening.

> >
> > echo "   Set the filter/nat/mangle packet Matching Table Policy."
> > $IPTABLES -t filter -P INPUT DROP
> > $IPTABLES -t filter -P OUTPUT DROP
> > $IPTABLES -t filter -P FORWARD DROP
> 
> The above are a (tm) Good Thing (tm)

Yes, this is the kind of thing that I want - start from complete
lockdown, and then open only one thing at a time until I can do
everything that I want on the network and maintain everything else in
lockdown.

> 
> > $IPTABLES -t nat -P PREROUTING DROP
> > $IPTABLES -t nat -P POSTROUTING DROP
> > $IPTABLES -t nat -P OUTPUT DROP
> > $IPTABLES -t mangle -P INPUT DROP
> > $IPTABLES -t mangle -P OUTPUT DROP
> > $IPTABLES -t mangle -P FORWARD DROP
> > $IPTABLES -t mangle -P PREROUTING DROP
> > $IPTABLES -t mangle -P POSTROUTING DROP
> 
> In general the above are a (tm) Really Bad Thing (tm)

As previously requested above, why are these policies bad/unworkable?
Any info. and links discussing these iptables fundamentals would be
greatly valued.

> >
> > echo "   INPUT/OUTPUT Rules for Routerbox."
> > $IPTABLES -t filter -A INPUT -j ACCEPT
> > $IPTABLES -t filter -A OUTPUT -j ACCEPT
> 
> Uhhh ... I hope these are only here because yer having problems --
>    These above two rules are a (tm) Really Bad Thing (tm)
>         (they basically allow everything in and out -- *ouch*)

You got it.  This is the rule of a man willing to submit his machines
to a world of hostility in a desperate attempt to get
some-packet/any-packet  through the routerbox.

> >
> > echo "   FORWARD Rules for data allowed IN and OUT of the LAN."
> > $IPTABLES -t filter -A FORWARD -i eth0 -o eth1 -m state --state
> > ESTABLISHED,RELATED -j ACCEPT
> 
> Repeat the above rule for filter INPUT

Ahh, I see what you are getting at.  Will do.

> 
> > $IPTABLES -t filter -A FORWARD -i eth0 -o eth1 -m state --state NEW -j
> > ACCEPT
> 
> The above rule is a (tm) Really Bad Thing (tm)
>         (basically allows everything into yer lan *ouch*)

Indeed, you are witnessing further desperation after hours of
scratching my head and muttering to myself.  :-)


> >
> > echo "   Do not respond to remote Pings."
> > $IPTABLES -t filter -A INPUT -p icmp --icmp-type echo-request -j DROP
> Umm .. You *might* want to set this to deny ping requests from the outside,
> rather than dropping them all .. .unless you don't trust users on the inside.
> *grin*

I'm not quite sure I follow here.  How does this affect users behind
the firewall on the home LAN.

Thanks again for your thoughtful response.
I'd hope you can spare some further time to respond.

Mike

Re: Policy Misunderstanding: RTFM Guidance Requested.

[Alistair Tonner]

On September 1, 2004 12:20 pm, Mike wrote:
> Hi Alistair,
>

	<SNIPPAGE>

>
> This comment pricks up my ears/eyes.  Why is this so, and do you have
> links to discussions on this topic.

	Prowl back through the lists -- there are several discussions on the issue.
	In the case of large scale firewalls there may be some call for using 
	mangle and nat to do filtering but its not really a good idea, since you then 
	need to build rules to let things through mangle and nat.
>
> >         There is a wonderful fellow named Oskar Andreasson who has
> > written a wonderful set of tutorials, and even provides some elemental
> > scripts as guidelines
> >         http://iptables-tutorial.frozentux.net/
> >
> >         Read and enjoy
>
> Thanks for pointer.  I've got a Firefox tab open to it right now.
> Looks very good.  Now let's see if I can absorb it.
>
> > > echo "   Enabling forwarding.."
> > > echo "1" > /proc/sys/net/ipv4/ip_forward
> >
> >         Urk
> >           Do this at the *end* of the script. -- just a good habit to NOT
> > turn on forwarding until all the rules are loaded to handle it.
>
> That sounds like a very good idea to me.  Noted for edit this evening.
>
> > > echo "   Set the filter/nat/mangle packet Matching Table Policy."
> > > $IPTABLES -t filter -P INPUT DROP
> > > $IPTABLES -t filter -P OUTPUT DROP
> > > $IPTABLES -t filter -P FORWARD DROP
> >
> > The above are a (tm) Good Thing (tm)
>
> Yes, this is the kind of thing that I want - start from complete
> lockdown, and then open only one thing at a time until I can do
> everything that I want on the network and maintain everything else in
> lockdown.
>
> > > $IPTABLES -t nat -P PREROUTING DROP
> > > $IPTABLES -t nat -P POSTROUTING DROP
> > > $IPTABLES -t nat -P OUTPUT DROP
> > > $IPTABLES -t mangle -P INPUT DROP
> > > $IPTABLES -t mangle -P OUTPUT DROP
> > > $IPTABLES -t mangle -P FORWARD DROP
> > > $IPTABLES -t mangle -P PREROUTING DROP
> > > $IPTABLES -t mangle -P POSTROUTING DROP
> >
> > In general the above are a (tm) Really Bad Thing (tm)
>
> As previously requested above, why are these policies bad/unworkable?
> Any info. and links discussing these iptables fundamentals would be
> greatly valued.

	You now have to put in ACCEPT rules to get things through.  This gets 
complicated by the fact that functionality changes in mangle and nat.   
Better to let things through the mangle and nat tables, and do filtering in 
the filter table.  There have been folks who like to drop things in the 
mangle and nat tables, but setting actual DROP policies makes life very 
difficult.

> > > echo "   INPUT/OUTPUT Rules for Routerbox."
> > > $IPTABLES -t filter -A INPUT -j ACCEPT
> > > $IPTABLES -t filter -A OUTPUT -j ACCEPT
> >
> > Uhhh ... I hope these are only here because yer having problems --
> >    These above two rules are a (tm) Really Bad Thing (tm)
> >         (they basically allow everything in and out -- *ouch*)
>
> You got it.  This is the rule of a man willing to submit his machines
> to a world of hostility in a desperate attempt to get
> some-packet/any-packet  through the routerbox.
>
> > > echo "   FORWARD Rules for data allowed IN and OUT of the LAN."
> > > $IPTABLES -t filter -A FORWARD -i eth0 -o eth1 -m state --state
> > > ESTABLISHED,RELATED -j ACCEPT
> >
> > Repeat the above rule for filter INPUT
>
> Ahh, I see what you are getting at.  Will do.
>
> > > $IPTABLES -t filter -A FORWARD -i eth0 -o eth1 -m state --state NEW -j
> > > ACCEPT
> >
> > The above rule is a (tm) Really Bad Thing (tm)
> >         (basically allows everything into yer lan *ouch*)
>
> Indeed, you are witnessing further desperation after hours of
> scratching my head and muttering to myself.  :-)
>
> > > echo "   Do not respond to remote Pings."
> > > $IPTABLES -t filter -A INPUT -p icmp --icmp-type echo-request -j DROP
> >
> > Umm .. You *might* want to set this to deny ping requests from the
> > outside, rather than dropping them all .. .unless you don't trust users
> > on the inside. *grin*
>
> I'm not quite sure I follow here.  How does this affect users behind
> the firewall on the home LAN.

	There is no definition of the SOURCE that you want to drop ICMP echorequests 
from.  Thus this rule drops all ping echorequests.
	iptables -t filter -A INPUT -p icmp -i [internet pipe device] -icmp-type \ 
echo-request -j DROP  
 	will allow your LAN users to ping the box, but prevent pings from the 
internet from getting in.

	Really and truely -- Oskar's tutorials are great and easy to read... and even 
the sample firewalls there are decent enough to start with for a newbie.


	Alistair Tonner

>
> Thanks again for your thoughtful response.
> I'd hope you can spare some further time to respond.
>
> Mike

Re: Policy Misunderstanding: RTFM Guidance Requested.

[Mike]

> Better to let things through the mangle and nat tables, and do filtering in
> the filter table.  There have been folks who like to drop things in the
> mangle and nat tables, but setting actual DROP policies makes life very
> difficult.

This seems like sound advice after what I've been through.  Maybe the
folks in The Matrix can bend the laws of physics with relative ease,
but for myself, I can barely achieve 'dude' status.  I think I'll
ACCEPT mangle and nat, and get some sleep tonight.  :-)

>         There is no definition of the SOURCE that you want to drop ICMP echorequests
> from.  Thus this rule drops all ping echorequests.
>         iptables -t filter -A INPUT -p icmp -i [internet pipe device] -icmp-type \
> echo-request -j DROP
>         will allow your LAN users to ping the box, but prevent pings from the
> internet from getting in.

Oh I see.  By stating specifically the internet-facing device, you
make it possible for LAN clients to ping the box through the gateway
NIC - eth1, while the rule blocks all the other echo requests.

>         Really and truely -- Oskar's tutorials are great and easy to read... and even
> the sample firewalls there are decent enough to start with for a newbie.
> 
I definitely feel more secure about working on my firewall knowing
that this reference material is around.  It's packed.

Thanks again, Alistair.
It's great to have your assistance.

Mike

Re: Policy Misunderstanding: RTFM Guidance Requested.

[Jason Opperisano]

On Wed, 2004-09-01 at 07:54, Mike wrote:
> I thought I had seen others on this list discuss starting with a
> completely closed router that denies all traffic - INPUT, OUTPUT, and
> FORWARD; filter, nat, and mangle.

yes, you have.  i don't personally agree with this (with respect to nat
& mangle).

> echo "   Set the filter/nat/mangle packet Matching Table Policy."
> $IPTABLES -t filter -P INPUT DROP
> $IPTABLES -t filter -P OUTPUT DROP
> $IPTABLES -t filter -P FORWARD DROP

good, good...

> $IPTABLES -t nat -P PREROUTING DROP
> $IPTABLES -t nat -P POSTROUTING DROP
> $IPTABLES -t nat -P OUTPUT DROP
> $IPTABLES -t mangle -P INPUT DROP
> $IPTABLES -t mangle -P OUTPUT DROP
> $IPTABLES -t mangle -P FORWARD DROP
> $IPTABLES -t mangle -P PREROUTING DROP
> $IPTABLES -t mangle -P POSTROUTING DROP

bad...  you will be in a world of hurt trying to get anything to work
with the policies of every nat & mangle chain set to drop.

filter in the filter table
nat in the nat table
mangle in the mangle table

the ultimate FM:
  http://iptables-tutorial.frozentux.net/iptables-tutorial.html

-j

-- 
Jason Opperisano <opie@817west.com>

Re: Mail Server Behind IPTABLES

[Alistair Tonner]

On August 31, 2004 09:01 pm, Ajen Diwakar wrote:
> Hi All
>
> I am new to IPTABLES usage. I have linux(RH) 9.0.
> The external IP address eth1 is 202.62.x.x
> The internal ip address is 10.0.0.4
>
> My mail server IP address is 10.0.0.10
>
> How do I setup my iptables so that the mail to my record get transfred
> to the mail server.
>
> Any assistance will be appreciated.

	iptables -t nat -A PREROUTING -p TCP -i {internet device} -d 202.62.x.x  \ 
--dport 25 -j DNAT -to 10.0.0.10

	iptables -A FORWARD -p TCP -i {internet device} -d 10.0.0.10 --dport 25  \
-j ACCEPT

	(assuming FORWARD -P DROP )


	Alistair Tonner

Re: Mail Server Behind IPTABLES

[Alistair Tonner]

	CC;ed the list for consistency.

	See inline below

On September 1, 2004 12:02 pm, Matevz wrote:
> Na 1094050244, 2004-09-01 ob 16:50, je Alistair Tonner napisal(a):
> > On August 31, 2004 09:01 pm, Ajen Diwakar wrote:
> > > Hi All
> > >
> > > I am new to IPTABLES usage. I have linux(RH) 9.0.
> > > The external IP address eth1 is 202.62.x.x
> > > The internal ip address is 10.0.0.4
> > >
> > > My mail server IP address is 10.0.0.10
> > >
> > > How do I setup my iptables so that the mail to my record get transfred
> > > to the mail server.
> > >
> > > Any assistance will be appreciated.
> >
> > 	iptables -t nat -A PREROUTING -p TCP -i {internet device} -d 202.62.x.x 
> > \ --dport 25 -j DNAT -to 10.0.0.10
> >
> > 	iptables -A FORWARD -p TCP -i {internet device} -d 10.0.0.10 --dport 25 
> > \ -j ACCEPT
> >
> > 	(assuming FORWARD -P DROP )
> >
> >
> > 	Alistair Tonner
>
> Hi,
>
> I using this for a while and i have a problem.
> For connctions from outside works just fine, but if i want to access
> from my LAN dont work.

	Because your LAN clients attempt to connect to [publlc IP of mailserver], get 
connected by reroute through firewall.  Mailserver see's connection from 
[LANIP] of client and replies *direct* to [LANIP] client.  Client knows NOT 
of LANIP of mailserver and does not consider the connection valid.

	iptables -I PREROUTING -p TCP -i [LAN device] -d [PUBLIC IP mailserver]  \ 
--dport 25 -j DNAT -to 10.0.0.10
	iptables -A FORWARD -p TCP -i [LAN device] -d 10.0.0.10 -s [LAN SEGMENT]   \ 
--dport 25  -j ACCEPT
	iptables -I POSTROUTING -p TCP -i [LAN device] -d 10.0.0.10 -s [LAN SEGMENT]\
 --dport 25 -j SNAT -to 10.0.0.4

	This makes the connection at the mailserver think your firewall is 
connecting.  Weird, but NOW the replies from the mailserver go back through 
the firewall, and the client will accept the connection as valid.

	A slightly better way to do this is split DNS that tells the clients on the 
LAN to use the LAN ip of the mailserver.  -- a different topic.

	Possibly you want to do the same for port 110 from inside the LAN/??


>
> I have also tried without -i.
>
> And i was tried this with adding one new rule so it was like -i [eth
> witch is conncted to LAN]
>
> In all cases sharing of internet connction stops working.

	iptables -P FORWARD DROP
	
	iptables -A FORWARD -s [LAN_SEGMENT] -i [LAN_DEVICE] -d 0.0.0.0 -j ACCEPT
	iptables -A FORWARD -d [LAN_SEGMENT] -m state --state RELATED,ESTABLISHED  \
-j ACCEPT

	
	iptables -A POSTROUTING  -o [INTERNET_DEVICE] -j MASQUERADE 
	or
	iptables -A POSTROUTING -o [INTERNET_DEVICE] -j SNAT -to [internet address]


	keep in mind that you might want to review the ORDER in which the rules 
load .... it can be critical as to what gets processed when

iptables -Lnvx 
iptables -Lnvx -t nat
iptables -Lnvx -t mangle.



	Alistair Tonner

Re: Mail Server Behind IPTABLES

[Matevz]

Na 1094056052, 2004-09-01 ob 18:27, je Alistair Tonner napisal(a):
> 	CC;ed the list for consistency.
> 
> 	See inline below
> 
> On September 1, 2004 12:02 pm, Matevz wrote:
> > Na 1094050244, 2004-09-01 ob 16:50, je Alistair Tonner napisal(a):
> > > On August 31, 2004 09:01 pm, Ajen Diwakar wrote:
> > > > Hi All
> > > >
> > > > I am new to IPTABLES usage. I have linux(RH) 9.0.
> > > > The external IP address eth1 is 202.62.x.x
> > > > The internal ip address is 10.0.0.4
> > > >
> > > > My mail server IP address is 10.0.0.10
> > > >
> > > > How do I setup my iptables so that the mail to my record get transfred
> > > > to the mail server.
> > > >
> > > > Any assistance will be appreciated.
> > >
> > > 	iptables -t nat -A PREROUTING -p TCP -i {internet device} -d 202.62.x.x 
> > > \ --dport 25 -j DNAT -to 10.0.0.10
> > >
> > > 	iptables -A FORWARD -p TCP -i {internet device} -d 10.0.0.10 --dport 25 
> > > \ -j ACCEPT
> > >
> > > 	(assuming FORWARD -P DROP )
> > >
> > >
> > > 	Alistair Tonner
> >
> > Hi,
> >
> > I using this for a while and i have a problem.
> > For connctions from outside works just fine, but if i want to access
> > from my LAN dont work.
> 
> 	Because your LAN clients attempt to connect to [publlc IP of mailserver], get 
> connected by reroute through firewall.  Mailserver see's connection from 
> [LANIP] of client and replies *direct* to [LANIP] client.  Client knows NOT 
> of LANIP of mailserver and does not consider the connection valid.
> 
> 	iptables -I PREROUTING -p TCP -i [LAN device] -d [PUBLIC IP mailserver]  \ 
> --dport 25 -j DNAT -to 10.0.0.10
> 	iptables -A FORWARD -p TCP -i [LAN device] -d 10.0.0.10 -s [LAN SEGMENT]   \ 
> --dport 25  -j ACCEPT
> 	iptables -I POSTROUTING -p TCP -i [LAN device] -d 10.0.0.10 -s [LAN SEGMENT]\
>  --dport 25 -j SNAT -to 10.0.0.4
> 
> 	This makes the connection at the mailserver think your firewall is 
> connecting.  Weird, but NOW the replies from the mailserver go back through 
> the firewall, and the client will accept the connection as valid.
> 
> 	A slightly better way to do this is split DNS that tells the clients on the 
> LAN to use the LAN ip of the mailserver.  -- a different topic.
> 
> 	Possibly you want to do the same for port 110 from inside the LAN/??
> 
> 
> >
> > I have also tried without -i.
> >
> > And i was tried this with adding one new rule so it was like -i [eth
> > witch is conncted to LAN]
> >
> > In all cases sharing of internet connction stops working.
> 
> 	iptables -P FORWARD DROP
> 	
> 	iptables -A FORWARD -s [LAN_SEGMENT] -i [LAN_DEVICE] -d 0.0.0.0 -j ACCEPT
> 	iptables -A FORWARD -d [LAN_SEGMENT] -m state --state RELATED,ESTABLISHED  \
> -j ACCEPT
> 
> 	
> 	iptables -A POSTROUTING  -o [INTERNET_DEVICE] -j MASQUERADE 
> 	or
> 	iptables -A POSTROUTING -o [INTERNET_DEVICE] -j SNAT -to [internet address]
> 
> 
> 	keep in mind that you might want to review the ORDER in which the rules 
> load .... it can be critical as to what gets processed when
> 
> iptables -Lnvx 
> iptables -Lnvx -t nat
> iptables -Lnvx -t mangle.
> 
> 
> 
> 	Alistair Tonner

Thank you for ansver, but i think i will give up on this.

iptables -I POSTROUTING -p tcp -i eth0 -d 192.168.2.1 --dport 25 -j SNAT
-to 192.168.2.2

than i get this:

Bad argument `192.168.2.2'



-- 
Lep pozdrav,
Matevz
matevz@sloweb.net

Re: Mail Server Behind IPTABLES

[Jason Opperisano]

On Wed, 2004-09-01 at 14:12, Matevz wrote:
> Thank you for ansver, but i think i will give up on this.
> 
> iptables -I POSTROUTING -p tcp -i eth0 -d 192.168.2.1 --dport 25 -j SNAT
> -to 192.168.2.2
> 
> than i get this:
> 
> Bad argument `192.168.2.2'

there's no POSTROUTING chain in the filter table--you need to specify
either "-t nat" or "-t mangle" as those are the tables that have such a
chain.  you also cannot use "-i" in POSTROUTING.  the SNAT target is
valid in the POSTROUTING chain of the nat table:

        iptables -t nat -I POSTROUTING -p tcp -o eth0 \
          -d 192.168.2.1 --dport 25 \
          -j SNAT --to-destination 192.168.2.2

is correct, syntax-wise.  whether it accomplishes what you want;
functionality-wise, is another question...

-j

-- 
Jason Opperisano <opie@817west.com>

Re: Mail Server Behind IPTABLES

[Jason Opperisano]

On Wed, 2004-09-01 at 14:19, Jason Opperisano wrote:
> 
>         iptables -t nat -I POSTROUTING -p tcp -o eth0 \
>           -d 192.168.2.1 --dport 25 \
>           -j SNAT --to-destination 192.168.2.2
> 
> is correct, syntax-wise.  whether it accomplishes what you want;
> functionality-wise, is another question...
> 
> -j

damn copy & paste...  of course "--to-destination" makes no sense with
SNAT either:

        iptables -t nat -I POSTROUTING -p tcp -o eth0 \
          -d 192.168.2.1 --dport 25 \
          -j SNAT --to-source 192.168.2.2

-j

=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
I was in Vegas last week. I was at the roulette table, having a lengthy
argument about what I considered an Odd number. -- Steven Wright
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

Re: Mail Server Behind IPTABLES

[Alistair Tonner]

On September 1, 2004 02:12 pm, Matevz wrote:
	> Na 1094056052, 2004-09-01 ob 18:27, je Alistair Tonner napisal(a):
<SNIPPAGE>

> > 	iptables -P FORWARD DROP
> >
> > 	iptables -A FORWARD -s [LAN_SEGMENT] -i [LAN_DEVICE] -d 0.0.0.0 -j
> > ACCEPT iptables -A FORWARD -d [LAN_SEGMENT] -m state --state
> > RELATED,ESTABLISHED  \ -j ACCEPT
> >
> >
> > 	iptables -A POSTROUTING  -o [INTERNET_DEVICE] -j MASQUERADE
> > 	or
> > 	iptables -A POSTROUTING -o [INTERNET_DEVICE] -j SNAT -to [internet
> > address]
> >
> >
> > 	keep in mind that you might want to review the ORDER in which the rules
> > load .... it can be critical as to what gets processed when
> >
> > iptables -Lnvx
> > iptables -Lnvx -t nat
> > iptables -Lnvx -t mangle.
> >
> >
> >
> > 	Alistair Tonner
>
> Thank you for ansver, but i think i will give up on this.
>
> iptables -I POSTROUTING -p tcp -i eth0 -d 192.168.2.1 --dport 25 -j SNAT
> -to 192.168.2.2
>
> than i get this:
>
> Bad argument `192.168.2.2'


	Okay ---- @swat=me for not double checking my syntax

	iptables -I POSTROUTING -p tcp -i eth0 -d 192.168.168.2.1 --dport 25 -j SNAT   
--to-source 192.168.2.2


	Alistair Tonner