Re: Hi!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux