Hi!

Hi!

[Billie Joe]

Hi!


I have 3 IPs on Internet, and I want to put them behind my firewall
machine. So I have the question: Put all 3 IPs in the same network
card (with alias) or a card for each IP ?? What you suggest and why ??
Thanks


pS.: Consider that I have another NIC for my LAN.


BillieGDJoe

Re: Hi!

[Tib]

Hi there,

Thought I'd chip in since this used to be identical to how I had my system
setup. I had a block of 5 useable from my isp.

Whichever you are going to use as your actual firewall box IP (as opposed
to the machines you want to run behind it), you set as eth0 ip config.

After that you setup the other ip's as virtual interfaces on the same card
(eth0:1, eth0:2, etc). Set your internal IP nic to be eth1 and make sure
the routing table is set to go through it out to eth0 and the world. Have
your other internal IP boxes use eth1 as their gateway.

After that, you setup destniation nat'ing using something like this:

iptables -t nat -A PREROUTING -d $REAL-IP$ \
                -j DNAT --to-destination $INTERNAL-IP$

and

iptables -t nat -A POSTROUTING -s $INTERNAL-IP$ \
                -j SNAT --to-source $REAL-IP$

for each internal/ip pair you want to have mapped.

After you've done this - you're likely going to want to protect them from
certain types of traffic, since the basic INPUT rules won't cover it - put
anything you DON'T want to reach those hosts under the FORWARD ruleset as
drops.

That's it - you're set.

One item of note - be sure to put those snat/dnat rules into the table
BEFORE the catchall masquerading rule (if you use one) otherwise they will
hit the masquerade rule first and your traffic will not match in/out ip's
and things will bork up.

This is a setup I've used for a number of years, it's nice and clean and
gives good protection through the forward ruleset. If you cover your bases
right and practice safe net, things like zone alarm become unnecessary.

I blocked the following on forward and have done very well by it:

udp:
111
135
137
138
139
445
1026
1433

tcp:
21
57
79
80
111
135
137
138
139
443
445
1025
1026
1433
5000
31337

These will vary depending on your particular software usage and such - but
are a good start.

<EOL>
Tib

On Sat, 11 Jun 2005, Billie Joe wrote:

> Hi!
>
>
> I have 3 IPs on Internet, and I want to put them behind my firewall
> machine. So I have the question: Put all 3 IPs in the same network
> card (with alias) or a card for each IP ?? What you suggest and why ??
> Thanks
>
>
> pS.: Consider that I have another NIC for my LAN.
>
>
> BillieGDJoe
>

Re: Hi!

[Sadus .]

I usually block only in the INPUT chain, doesn't it protect my internal
network?
I only have SNATed the internal network to the external IP/

On Sat, 2005-06-11 at 12:16 -0500, Tib wrote:
> Hi there,
> 
> Thought I'd chip in since this used to be identical to how I had my system
> setup. I had a block of 5 useable from my isp.
> 
> Whichever you are going to use as your actual firewall box IP (as opposed
> to the machines you want to run behind it), you set as eth0 ip config.
> 
> After that you setup the other ip's as virtual interfaces on the same card
> (eth0:1, eth0:2, etc). Set your internal IP nic to be eth1 and make sure
> the routing table is set to go through it out to eth0 and the world. Have
> your other internal IP boxes use eth1 as their gateway.
> 
> After that, you setup destniation nat'ing using something like this:
> 
> iptables -t nat -A PREROUTING -d $REAL-IP$ \
>                 -j DNAT --to-destination $INTERNAL-IP$
> 
> and
> 
> iptables -t nat -A POSTROUTING -s $INTERNAL-IP$ \
>                 -j SNAT --to-source $REAL-IP$
> 
> for each internal/ip pair you want to have mapped.
> 
> After you've done this - you're likely going to want to protect them from
> certain types of traffic, since the basic INPUT rules won't cover it - put
> anything you DON'T want to reach those hosts under the FORWARD ruleset as
> drops.
> 
> That's it - you're set.
> 
> One item of note - be sure to put those snat/dnat rules into the table
> BEFORE the catchall masquerading rule (if you use one) otherwise they will
> hit the masquerade rule first and your traffic will not match in/out ip's
> and things will bork up.
> 
> This is a setup I've used for a number of years, it's nice and clean and
> gives good protection through the forward ruleset. If you cover your bases
> right and practice safe net, things like zone alarm become unnecessary.
> 
> I blocked the following on forward and have done very well by it:
> 
> udp:
> 111
> 135
> 137
> 138
> 139
> 445
> 1026
> 1433
> 
> tcp:
> 21
> 57
> 79
> 80
> 111
> 135
> 137
> 138
> 139
> 443
> 445
> 1025
> 1026
> 1433
> 5000
> 31337
> 
> These will vary depending on your particular software usage and such - but
> are a good start.
> 
> <EOL>
> Tib
> 
> On Sat, 11 Jun 2005, Billie Joe wrote:
> 
> > Hi!
> >
> >
> > I have 3 IPs on Internet, and I want to put them behind my firewall
> > machine. So I have the question: Put all 3 IPs in the same network
> > card (with alias) or a card for each IP ?? What you suggest and why ??
> > Thanks
> >
> >
> > pS.: Consider that I have another NIC for my LAN.
> >
> >
> > BillieGDJoe
> >
> 
-- 
Sadus . <sadus@swiftbin.net>
Swiftbin.net

Re: Hi!

[Tib]

If you are using snat/dnat to map internal IP's to the public realm, INPUT
will not block things that are being handled in this way - that is why the
FORWARD ruleset will also need entries in it, since that is explicitly
going to catch packets handled by snat/dnat.

<EOL>
Tib

On Sat, 11 Jun 2005, Sadus . wrote:

> I usually block only in the INPUT chain, doesn't it protect my internal
> network?
> I only have SNATed the internal network to the external IP/
>
> On Sat, 2005-06-11 at 12:16 -0500, Tib wrote:
> > Hi there,
> >
> > Thought I'd chip in since this used to be identical to how I had my system
> > setup. I had a block of 5 useable from my isp.
> >
> > Whichever you are going to use as your actual firewall box IP (as opposed
> > to the machines you want to run behind it), you set as eth0 ip config.
> >
> > After that you setup the other ip's as virtual interfaces on the same card
> > (eth0:1, eth0:2, etc). Set your internal IP nic to be eth1 and make sure
> > the routing table is set to go through it out to eth0 and the world. Have
> > your other internal IP boxes use eth1 as their gateway.
> >
> > After that, you setup destniation nat'ing using something like this:
> >
> > iptables -t nat -A PREROUTING -d $REAL-IP$ \
> >                 -j DNAT --to-destination $INTERNAL-IP$
> >
> > and
> >
> > iptables -t nat -A POSTROUTING -s $INTERNAL-IP$ \
> >                 -j SNAT --to-source $REAL-IP$
> >
> > for each internal/ip pair you want to have mapped.
> >
> > After you've done this - you're likely going to want to protect them from
> > certain types of traffic, since the basic INPUT rules won't cover it - put
> > anything you DON'T want to reach those hosts under the FORWARD ruleset as
> > drops.
> >
> > That's it - you're set.
> >
> > One item of note - be sure to put those snat/dnat rules into the table
> > BEFORE the catchall masquerading rule (if you use one) otherwise they will
> > hit the masquerade rule first and your traffic will not match in/out ip's
> > and things will bork up.
> >
> > This is a setup I've used for a number of years, it's nice and clean and
> > gives good protection through the forward ruleset. If you cover your bases
> > right and practice safe net, things like zone alarm become unnecessary.
> >
> > I blocked the following on forward and have done very well by it:
> >
> > udp:
> > 111
> > 135
> > 137
> > 138
> > 139
> > 445
> > 1026
> > 1433
> >
> > tcp:
> > 21
> > 57
> > 79
> > 80
> > 111
> > 135
> > 137
> > 138
> > 139
> > 443
> > 445
> > 1025
> > 1026
> > 1433
> > 5000
> > 31337
> >
> > These will vary depending on your particular software usage and such - but
> > are a good start.
> >
> > <EOL>
> > Tib
> >
> > On Sat, 11 Jun 2005, Billie Joe wrote:
> >
> > > Hi!
> > >
> > >
> > > I have 3 IPs on Internet, and I want to put them behind my firewall
> > > machine. So I have the question: Put all 3 IPs in the same network
> > > card (with alias) or a card for each IP ?? What you suggest and why ??
> > > Thanks
> > >
> > >
> > > pS.: Consider that I have another NIC for my LAN.
> > >
> > >
> > > BillieGDJoe
> > >
> >
>

Re: Hi!

[Tib]

Caveat to what I just said - if you are doing masquerading behind a single
IP, then you don't need to worry about the FORWARD ruleset. Only packets
associated with connections  that are being masqueraded will get sent on
to internal networks - unless you have specific ports that are translated
to internal services.

<EOL>
Tib

On Sat, 11 Jun 2005, Sadus . wrote:

> I usually block only in the INPUT chain, doesn't it protect my internal
> network?
> I only have SNATed the internal network to the external IP/
>
> On Sat, 2005-06-11 at 12:16 -0500, Tib wrote:
> > Hi there,
> >
> > Thought I'd chip in since this used to be identical to how I had my system
> > setup. I had a block of 5 useable from my isp.
> >
> > Whichever you are going to use as your actual firewall box IP (as opposed
> > to the machines you want to run behind it), you set as eth0 ip config.
> >
> > After that you setup the other ip's as virtual interfaces on the same card
> > (eth0:1, eth0:2, etc). Set your internal IP nic to be eth1 and make sure
> > the routing table is set to go through it out to eth0 and the world. Have
> > your other internal IP boxes use eth1 as their gateway.
> >
> > After that, you setup destniation nat'ing using something like this:
> >
> > iptables -t nat -A PREROUTING -d $REAL-IP$ \
> >                 -j DNAT --to-destination $INTERNAL-IP$
> >
> > and
> >
> > iptables -t nat -A POSTROUTING -s $INTERNAL-IP$ \
> >                 -j SNAT --to-source $REAL-IP$
> >
> > for each internal/ip pair you want to have mapped.
> >
> > After you've done this - you're likely going to want to protect them from
> > certain types of traffic, since the basic INPUT rules won't cover it - put
> > anything you DON'T want to reach those hosts under the FORWARD ruleset as
> > drops.
> >
> > That's it - you're set.
> >
> > One item of note - be sure to put those snat/dnat rules into the table
> > BEFORE the catchall masquerading rule (if you use one) otherwise they will
> > hit the masquerade rule first and your traffic will not match in/out ip's
> > and things will bork up.
> >
> > This is a setup I've used for a number of years, it's nice and clean and
> > gives good protection through the forward ruleset. If you cover your bases
> > right and practice safe net, things like zone alarm become unnecessary.
> >
> > I blocked the following on forward and have done very well by it:
> >
> > udp:
> > 111
> > 135
> > 137
> > 138
> > 139
> > 445
> > 1026
> > 1433
> >
> > tcp:
> > 21
> > 57
> > 79
> > 80
> > 111
> > 135
> > 137
> > 138
> > 139
> > 443
> > 445
> > 1025
> > 1026
> > 1433
> > 5000
> > 31337
> >
> > These will vary depending on your particular software usage and such - but
> > are a good start.
> >
> > <EOL>
> > Tib
> >
> > On Sat, 11 Jun 2005, Billie Joe wrote:
> >
> > > Hi!
> > >
> > >
> > > I have 3 IPs on Internet, and I want to put them behind my firewall
> > > machine. So I have the question: Put all 3 IPs in the same network
> > > card (with alias) or a card for each IP ?? What you suggest and why ??
> > > Thanks
> > >
> > >
> > > pS.: Consider that I have another NIC for my LAN.
> > >
> > >
> > > BillieGDJoe
> > >
> >
>

Re: Hi!

[Ian Laurie]

On 06/12/2005 04:22:52 AM, Tib wrote:
> 
> Caveat to what I just said - if you are doing masquerading behind a single
> IP, then you don't need to worry about the FORWARD ruleset. Only packets
> associated with connections  that are being masqueraded will get sent on
> to internal networks - unless you have specific ports that are translated
> to internal services.
> 
> <EOL>
> Tib

Actually that isn't quite correct.  With ip_forward on, network bridging is 
enabled. Running NAT does not disable the bridging function.  If a box on the 
outside port sends a packet addressed to a box on the inside port, using the 
firewall as its gateway, the packet will get through NAT.  NAT runs on top 
of the bridging function, so bridging still works, though only in one direction
since in the other direction packets will get NATed.

You need to specifically use rules in the firewall to stop unsolicited
packets from getting through, like ESTABLISHED/RELATED etc.

The idea that running NAT disables bridging is a common and dangerous
misconception.  Showing this isn't so is a simple experiment, and one
I have done many times to the astonishment of onlookers.

You can block packets addressed to the inside of a firewall by a rule in
your PREROUTING chain like so:

-A PREROUTING -i eth0 -d 10.1.1.0/24 -j DROP

Where 10.1.1.* is the inside range and eth0 is the outside port.  Basically
this DROPs anything appearing on the outside interface addressed to
something on the inside interface.

Technically though this rule is unnecessary if the rest of your firewall
is set up right, since you would ordinarily be using rules to ensure that
only response packets get back through the FORWARD chain.  For example:

-A FWD_INBOUND_TCPUDP -m state --state RELATED,ESTABLISHED -j ACCEPT

Ian

PS - Another misconception some have is that setting rp_filter stops this,
it doesn't, since rp_filter works on a packet's source IP, not destination
IP.  However, I for one would be in favor of another kernel flag that
*would* work on the destination IP.

Re: Hi!

[Tib]

> > Caveat to what I just said - if you are doing masquerading behind a single
> > IP, then you don't need to worry about the FORWARD ruleset. Only packets
> > associated with connections  that are being masqueraded will get sent on
> > to internal networks - unless you have specific ports that are translated
> > to internal services.
>
> Actually that isn't quite correct.  With ip_forward on, network bridging is
> enabled. Running NAT does not disable the bridging function.  If a box on the
> outside port sends a packet addressed to a box on the inside port, using the
> firewall as its gateway, the packet will get through NAT.  NAT runs on top
> of the bridging function, so bridging still works, though only in one direction
> since in the other direction packets will get NATed.

Actually, it is 100% correct. Masquerading is a broad spectrum SNAT that
will redirect return traffic associated with whatever it sends out back to
the originating internal host. So if some new connection comes in to the
external IP that isn't associated with any outbound connection, it hits
the firewall and falls flat - this is why modules like ip_conntrack_ftp
and ip_nat_ftp are necessary, and why dcc on irc clients tends to get
borked, the list goes on.

If he's running two real world ip's connected behind a firewall real world
ip - that's not masquerading, and that /would/ require a defensive
forward ruleset as the firewall itself is not accepting packets but
forwarding them to another host. Using snat/dnat the way I specified is
effectively the same, but allows there to be a private network behind the
firewall that can have as many hosts or other things as it wants without
having to deal with the constraints of getting more IP's from an isp.

Also - normal traffic from the outside world isn't going to be getting
sent directly to an inside private IP. If ANY sort of nat is going on, how
on earth are they going to know which private IP to send to? Such traffic
is only going to be used as a disruptive tactic on the firewall connection
itself. That's the whole point of private network blocks - NON-ROUTABLE.
To even get sent to the firewall from the outside interface you'd have to
have one of two situations:

1. A legitimate host on the same physical network as the firewall's
outside interface, using said outside interface as a gateway, and sending
traffic to those private ip's.

2. A mangled packet attack of some sort where the external interface is
bombarded with traffic that should be impossible considering that private
network addresses are non-routable.

For broadband homeusers, option 1 is going to not exist since customers
are either directly on the net with a real IP thanks to a dsl/cable modem
that bridges the connection and doesn't have its own IP, or who have a
dsl/cable router that gets it's own IP, runs a dhcp client to the inside
where the end-user gets an IP and from there gets masqueraded out behind
the IP of the router.

Option 2 however is a reality but a relatively low one because that sort
of traffic does not happen to your every day small network dsl user. I
recently had to deal with such an attack - 22Mb/s of traffic that should
not be possible slammed my external interface. Yup - one simple rule made
it all go away, but the point is that in 6 years of running said style
network, that's the only time I've encountered such traffic.

<EOL>
Tib

Re: Hi!

[Ian Laurie]

On 06/13/2005 10:26:35 AM, Tib wrote:
> > > Caveat to what I just said - if you are doing masquerading behind a 
> single
> > > IP, then you don't need to worry about the FORWARD ruleset. Only packets
> > > associated with connections  that are being masqueraded will get sent on
> > > to internal networks - unless you have specific ports that are 
> translated
> > > to internal services.
> >
> > Actually that isn't quite correct.  With ip_forward on, network bridging 
> is
> > enabled. Running NAT does not disable the bridging function.  If a box on 
> the
> > outside port sends a packet addressed to a box on the inside port, using 
> the
> > firewall as its gateway, the packet will get through NAT.  NAT runs on top
> > of the bridging function, so bridging still works, though only in one 
> direction
> > since in the other direction packets will get NATed.
> 
> Actually, it is 100% correct. Masquerading is a broad spectrum SNAT that
> will redirect return traffic associated with whatever it sends out back to
> the originating internal host. So if some new connection comes in to the
> external IP that isn't associated with any outbound connection, it hits
> the firewall and falls flat - this is why modules like ip_conntrack_ftp
> and ip_nat_ftp are necessary, and why dcc on irc clients tends to get
> borked, the list goes on.

Hi Tib,

We *may* be speaking at cross purposes.  I agree with what you have said but
I am also correct.  The issue is your statement "hits the firewall and falls 
flat".

Your original paragraph doesn't make it clear to a beginner that you are
pre-supposing that there is a real firewall in place that will enforce NAT.

My point, that is also 100% correct, is that having a NAT rule alone does not 
disable the bridging function.

The reality is that a lot of beginners "assume" that when they have NAT, their
internal addresses are unreachable from the outside and that simply isn't
the case with NAT alone (at least not with iptables under Linux).

That was the point I was making.  
As for the rest of your post, you are forgetting the wider purpose of routers/
firewalls.  For example, inside a company where you may have the
R&D department on one private address space, finance on another, etc., all 
isolated with routers.  In this scenario (which I work in) all you need to do 
is use the "route" command to tell your machine where to send packets, and 
suddenly private IP addresses are routable and *will* make it to the
firewall.  Further, you can specifically allow certain machines (like mine)
to get through..... despite NAT in operation for all other packets.

That is, I can ssh etc. into boxes that sit behind NAT.  I just wanted to make 
the point that NAT alone doesn't prevent this, which wasn't obvious from your 
post.

Ian

Re: Hi!

[Tib]

On Mon, 13 Jun 2005, Ian Laurie wrote:
> We *may* be speaking at cross purposes.  I agree with what you have said but
> I am also correct.  The issue is your statement "hits the firewall and falls
> flat".
>
> Your original paragraph doesn't make it clear to a beginner that you are
> pre-supposing that there is a real firewall in place that will enforce NAT.
>
> My point, that is also 100% correct, is that having a NAT rule alone does
> not disable the bridging function.
>
> The reality is that a lot of beginners "assume" that when they have NAT, their
> internal addresses are unreachable from the outside and that simply isn't
> the case with NAT alone (at least not with iptables under Linux).
>
> That was the point I was making.

The original question was regarding a person with 3 ip's and the best way
to make use of them on a network with a gateway host and two other hosts
that would be behind it.

I would be curious to hear how you can communicate to internal networks
from across the internet without knowledge of the ip-block being used on
said network behind a masqueraded host, and without the gateway/firewall
box using iptables being explicitly instructed to route traffic that it
receives on an external interface to the internal network - and have it
get back out properly. I have never known or seen such a thing to be
possible.

> As for the rest of your post, you are forgetting the wider purpose of
> routers/firewalls.  For example, inside a company where you may have the
> R&D department on one private address space, finance on another, etc., all
> isolated with routers.  In this scenario (which I work in) all you need to do
> is use the "route" command to tell your machine where to send packets, and
> suddenly private IP addresses are routable and *will* make it to the
> firewall.  Further, you can specifically allow certain machines (like mine)
> to get through..... despite NAT in operation for all other packets.
>
> That is, I can ssh etc. into boxes that sit behind NAT.  I just wanted to
> make the point that NAT alone doesn't prevent this, which wasn't obvious
> from your post.

But see - your work network (and mine as well) is designed explicitly to
enable traffic like that to flow between different physical segments. But
as we both just said - those are work networks that are designed with
dozens if not hudreds or thousands of hosts involved, and typically it is
the nat that specificly enables such things to happen. And again - anyone
without specific knowledge to the architecture of the system is going to
be guessing in the dark and have little to no chance of initiating proper
communication, forcing them to resort to disruption tactics like I
mentioned in situation #2 previously.

The general internet at large is not designed to route or respond to
private network traffic, if it did things would be very messy indeed on
the net.

So while such things /are/ possible in specific, explicit, application -
for the general newbie end-user as you put it, the setup I defined being
short, simple, and uncomplicated is going to both service and protect the
hosts involved as well as provide maximum flexibility for those hosts as
well.

I don't think we're talking at cross purposes really. We're both on target
but just in different frames of reference for the practical application of
networking involved.

<EOL>
Tib

FORWARD rules or not? (was: Re: Hi!)

[/dev/rob0]

On Sunday 12 June 2005 19:26, Tib wrote:
> > > Caveat to what I just said - if you are doing masquerading behind
> > > a single IP, then you don't need to worry about the FORWARD
> > > ruleset. Only packets associated with connections  that are being
> > > masqueraded will get sent on to internal networks - unless you
> > > have specific ports that are translated to internal services.
> >
> > Actually that isn't quite correct.  With ip_forward on, network
> > bridging is enabled. Running NAT does not disable the bridging
> > function.  If a box on the outside port sends a packet addressed to
> > a box on the inside port, using the firewall as its gateway, the
> > packet will get through NAT.  NAT runs on top of the bridging
> > function, so bridging still works, though only in one direction
> > since in the other direction packets will get NATed.
>
> Actually, it is 100% correct.

And you went on to show exceptions? I am confused. Perhaps so for 
differing values of 100%? :)

> Masquerading is a broad spectrum SNAT 
> that will redirect return traffic associated with whatever it sends
> out back to the originating internal host. So if some new connection
> comes in to the external IP that isn't associated with any outbound
> connection, it hits the firewall and falls flat - this is why modules

If there are no FORWARD rules and a policy of ACCEPT, and packets hit 
the external *interface* (not IP) with a destination IP in the internal 
network, please explain which rule in INPUT will cause those packets to 
fall flat. Source, somewhere else; destination, somewhere else: these 
will not hit the INPUT chain at all.

> Also - normal traffic from the outside world isn't going to be
> getting sent directly to an inside private IP.

Normal traffic, no. Attack traffic, maybe.

> If ANY sort of nat is
> going on, how on earth are they going to know which private IP to

Most home and small office LAN's can be found on 192.168.0.0/24 or 
192.168.1.0/24. And a real motivated attacker might have inside 
information. If none of the above, there's always nmap -sP ... .

> send to? Such traffic is only going to be used as a disruptive tactic
> on the firewall connection itself. That's the whole point of private
> network blocks - NON-ROUTABLE. To even get sent to the firewall from

Non-routable by RFC, but I wouldn't expect that to stop an attacker. :)

> the outside interface you'd have to have one of two situations:
>
> 1. A legitimate host on the same physical network as the firewall's
> outside interface, using said outside interface as a gateway, and
> sending traffic to those private ip's.

That would do it. On a home cable subnet this is not difficult to 
imagine ... a bored teenager with time and curiosity ...

In a business setting it could be a motivated competitor, or someone 
with malicious intent and access to the ISP. Could be a spammer!

> 2. A mangled packet attack of some sort where the external interface
> is bombarded with traffic that should be impossible considering that
> private network addresses are non-routable.
>
> For broadband homeusers, option 1 is going to not exist since
> customers are either directly on the net with a real IP thanks to a
> dsl/cable modem that bridges the connection and doesn't have its own

We hope. I prefer to put limits in FORWARD. Is there any good reason 
*not* to?
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: FORWARD rules or not? (was: Re: Hi!)

[Tib]

On Sun, 12 Jun 2005, /dev/rob0 wrote:
> > Actually, it is 100% correct.
>
> And you went on to show exceptions? I am confused. Perhaps so for
> differing values of 100%? :)

I don't recall showing any exceptions. I said that snat/dnat of real ip's
to internal ip's would respond the same as bridging and require a set of
forward rules to protect it.

> > Masquerading is a broad spectrum SNAT
> > that will redirect return traffic associated with whatever it sends
> > out back to the originating internal host. So if some new connection
> > comes in to the external IP that isn't associated with any outbound
> > connection, it hits the firewall and falls flat - this is why modules
>
> If there are no FORWARD rules and a policy of ACCEPT, and packets hit
> the external *interface* (not IP) with a destination IP in the internal
> network, please explain which rule in INPUT will cause those packets to
> fall flat. Source, somewhere else; destination, somewhere else: these
> will not hit the INPUT chain at all.

To hit the external interface at all, they have to be routed on a path
through that IP, correct? So how do you propose to put in an ip address of
192.168.1.X on your end, and have it magically communicate to a private
network behind 207.105.189.2? It won't. The only way to get traffic to the
internal network on a *masquerading* host is going to be for that traffic
to be in response to an original outgoing connection. In which case the
firewall host has to accept the traffic, then translate it. This is why
forward rules are unecessary for masquerading ip's but are needed for
snat/dnat pairs. One is the firewall thinking/processing - the other is it
just redirecting.

> > Also - normal traffic from the outside world isn't going to be
> > getting sent directly to an inside private IP.
>
> Normal traffic, no. Attack traffic, maybe.

And as I already said was true - you have to just tell iptables that any
traffic with a destination of a private network address on the external
interface is bogus and to drop it.

> > If ANY sort of nat is going on, how on earth are they going to know
> > which private IP to
>
> Most home and small office LAN's can be found on 192.168.0.0/24 or
> 192.168.1.0/24. And a real motivated attacker might have inside
> information. If none of the above, there's always nmap -sP ... .

And again - how is this going to help you? For masquerading you are going
to have to have an outbound connection to be initiated for you to respond
to so that any traffic you send back is interpreted as associated and
therefore passed on. Furthermore, you're going to have to determine which
of that outbound traffic is in relation to which internal host you want to
attack. Again I submit that such communication is impossible without the
iptables host being setup to explicitly allow it.

> > send to? Such traffic is only going to be used as a disruptive tactic
> > on the firewall connection itself. That's the whole point of private
> > network blocks - NON-ROUTABLE. To even get sent to the firewall from
>
> Non-routable by RFC, but I wouldn't expect that to stop an attacker. :)

It doesn't stop them from sending mangled packets, no, which is why the
above referenced rule is useful *in the event of such an attack*. I'm
curious how many people here have been? It took me six years to have it
happen.

> > the outside interface you'd have to have one of two situations:
> >
> > 1. A legitimate host on the same physical network as the firewall's
> > outside interface, using said outside interface as a gateway, and
> > sending traffic to those private ip's.
>
> That would do it. On a home cable subnet this is not difficult to
> imagine ... a bored teenager with time and curiosity ...
> In a business setting it could be a motivated competitor, or someone
> with malicious intent and access to the ISP. Could be a spammer!

Again though you'd have to have someone be aware of what IP block you're
using for your internal network - not feasible for a bored kid with
time/curiosity. If that same kid is running on a real ip and hits 'network
neighborhood' and discovers everyone else who is setup the same on his
cable-modem area... ... sorry - people who do that deserve their virii and
spam.

For the purposes of masquerading - not going to happen. And with snat/dnat
and some forward rules - also not going to happen.

> We hope. I prefer to put limits in FORWARD. Is there any good reason
> *not* to?

Depending on the situation of your network setup, they may simply be
unnecessary. A bunch of computers masquerading behind a single IP used by
the firewall host will simply not need forward rules as defense. If you
have any specific hosts or services setup under iptables to have dnat
configured for it - by all means use some well planned forward rules to
keep things safe.

I choose not to put anything up that is not in use, others may choose
differently. It's their choice, I was simply trying to put forward the
most basic and effective method for the original question here. How to
make good use of three real world IP's for a firewall host and boxes
behind it.

<EOL>
Tib

Re: FORWARD rules or not? (was: Re: Hi!)

[/dev/rob0]

On Sunday 12 June 2005 20:47, Tib wrote:
> On Sun, 12 Jun 2005, /dev/rob0 wrote:
> > > Actually, it is 100% correct.
> >
> > And you went on to show exceptions? I am confused. Perhaps so for
> > differing values of 100%? :)
>
> I don't recall showing any exceptions. I said that snat/dnat of real

Forget about NAT. NAT is a distraction. You're not understanding. Here 
is one of the exceptions you mentioned:

[flashback] On Sunday 12 June 2005 19:26, Tib wrote:
> To even get sent to the firewall from the outside interface you'd
> have to have one of two situations:
>
> 1. A legitimate host on the same physical network as the firewall's
> outside interface, using said outside interface as a gateway, and
> sending traffic to those private ip's.
[/flashback]

I don't know what you mean, "legitimate", but yes, hosts inside your 
ISP's router can use you as a gateway.

> > > connection comes in to the external IP that isn't associated with
> > > any outbound connection, it hits the firewall and falls flat -
> >
> > If there are no FORWARD rules and a policy of ACCEPT, and packets
> > hit the external *interface* (not IP) with a destination IP in the
> > internal network, please explain which rule in INPUT will cause
> > those packets to fall flat. Source, somewhere else; destination,
> > somewhere else: these will not hit the INPUT chain at all.

Once again: these packets bypass your INPUT rules.

> To hit the external interface at all, they have to be routed on a
> path through that IP, correct?

Or arp. Doesn't matter. They can find your IP easily enough, or 
depending on the kind of bridging, your MAC address. Even if it was 
routed using your external IP address, it is not going to hit your 
INPUT chain!

> So how do you propose to put in an ip 
> address of 192.168.1.X on your end, and have it magically communicate
> to a private network behind 207.105.189.2? It won't.

We weren't talking about me; we were talking about someone on your 
physical segment, or an attacker who has control of your upstream 
router.

> The only way to 
> get traffic to the internal network on a *masquerading* host is going
> to be for that traffic to be in response to an original outgoing
> connection.

Yes, *if* you have limits in FORWARD. Otherwise no.

> In which case the firewall host has to accept the 
> traffic, then translate it. This is why forward rules are unecessary
> for masquerading ip's but are needed for snat/dnat pairs. One is the
> firewall thinking/processing - the other is it just redirecting.

Try setting a DROP policy in FORWARD:
    iptables -P FORWARD DROP
and see if your MASQUERADE hosts can get out. Then do
    iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
and watch it work again.

> > > Also - normal traffic from the outside world isn't going to be
> > > getting sent directly to an inside private IP.
> >
> > Normal traffic, no. Attack traffic, maybe.
>
> And as I already said was true - you have to just tell iptables that
> any traffic with a destination of a private network address on the
> external interface is bogus and to drop it.

Have you yet understood that you *must* have rules in FORWARD if you 
wish to control forwarded traffic? You seem to have the "ipchains 
syndrome": thinking that anything coming in hits INPUT. Not so.

> > imagine ... a bored teenager with time and curiosity ...
> > In a business setting it could be a motivated competitor, or
> > someone with malicious intent and access to the ISP. Could be a
> > spammer!
>
> Again though you'd have to have someone be aware of what IP block
> you're using for your internal network - not feasible for a bored kid
> with time/curiosity. If that same kid is running on a real ip and
> hits 'network neighborhood' and discovers everyone else who is setup
> the same on his cable-modem area... ... sorry - people who do that
> deserve their virii and spam.

BTW those are the very machines which are used by spammers to send out 
their spew. Their insecurity == our spam.

> > We hope. I prefer to put limits in FORWARD. Is there any good
> > reason *not* to?
>
> Depending on the situation of your network setup, they may
> simply be unnecessary.

Unnecessary in terms of "will they foil any actual attacks?" perhaps. 
Logging turned off here so I wouldn't know if there are any attackers 
in my segment. Quite necessary in terms of providing peace of mind.

I trust my ISP to do their best. I don't think their best is very good, 
however! I wouldn't be at all surprised if their entire network was 
running on insecure equipment. If they get cracked, I won't.

> A bunch of computers masquerading behind a single IP 
> used by the firewall host will simply not need forward rules as
> defense.

Unless you want to protect against the attacks I described.

> I choose not to put anything up that is not in use, others may choose
> differently. It's their choice, I was simply trying to put forward

My philosophy of firewalling is to deny by default and make exceptions 
for the traffic I want.

iptables -N State
iptables -N AllowIn # hosts and services allowed access to this host
iptables -N AllowFwd # hosts and services allowed to forward
iptables -A State -m state --state INVALID -j DROP
iptables -A State -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -j State
iptables -A INPUT -j AllowIn
iptables -A FORWARD -j State
iptables -A FORWARD -j AllowFwd
# add stuff to AllowIn and AllowFwd as needed
iptables -P INPUT DROP
iptables -P FORWARD DROP

> the most basic and effective method for the original question here.
> How to make good use of three real world IP's for a firewall host and
> boxes behind it.

I'd put them on a DMZ interface and route to them. I would not do 
SNAT/DNAT in such a case. And yes, rules in FORWARD to protect them.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header