Re: Combined Internal/External DNAT question

Re: Combined Internal/External DNAT question

[Taylor, Grant]

> My problem still remains however Grant. I would have to create another DNAT rule to match each existing *real* public DNAT rule that currently exists to DNAT traffic from the Internet.  Do you have any further ideas for me? Given that a packet can have both the src and dst IP address rewritten in it's one trip through iptables, it seems to me that it should be possible for two rewrites to happen at once. My thinking it perhaps breaking the nat table into several chains?  Any other suggestions, you've been most helpful so far.


The only other thing that comes to mind would be to use iphash (IP)sets of destination IP addresses on your original DNAT rules.  This would cause your iptables rule to match based on the destination of your external IP of your firewall OR your external IP of your DSL modem (/router) and DNAT the traffic to the real server on your 2nd internal subnet.  Here is an example rule for what you would need:

iptables -t nat -A PREROUTING -m set --set My_IP_Set dst -j DNAT --to-destination <relevant.internal.server>:<tcpservice>

To support this rule you would need to do the following (likely before you issued the above rule):

ipset -N My_IP_Set iphash
ipset -A My_IP_Set 10.0.0.1
ipset -A My_IP_Set <Public IP>

As stated before this should cause your one iptables rule to match packets that are destined to any IP in the ip set "My_IP_Set" and DNAT said packets to the <relevant.internal.server>:<tcpservice>.  I know that this is not the multiple passes through the iptables chains like you were asking for, but I think it will provide a solution comparable  to the result that you were after.  Rather than have a rule that will alter traffic such that it will be caught by another rule and then altered again why not have a rule that will catch either type of traffic.



Grant. . . .

Re: Combined Internal/External DNAT question

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 16 May 2005, Taylor, Grant wrote:

>> My problem still remains however Grant. I would have to create another 
>> DNAT rule to match each existing *real* public DNAT rule that currently 
>> exists to DNAT traffic from the Internet.  Do you have any further ideas 
>> for me? Given that a packet can have both the src and dst IP address 
>> rewritten in it's one trip through iptables, it seems to me that it should 
>> be possible for two rewrites to happen at once. My thinking it perhaps 
>> breaking the nat table into several chains?  Any other suggestions, you've 
>> been most helpful so far.
>
>
> The only other thing that comes to mind would be to use iphash (IP)sets of 
> destination IP addresses on your original DNAT rules.  This would cause your 
> iptables rule to match based on the destination of your external IP of your 
> firewall OR your external IP of your DSL modem (/router) and DNAT the traffic 
> to the real server on your 2nd internal subnet.  Here is an example rule for 
> what you would need:
>
> iptables -t nat -A PREROUTING -m set --set My_IP_Set dst -j DNAT 
> --to-destination <relevant.internal.server>:<tcpservice>
>
> To support this rule you would need to do the following (likely before you 
> issued the above rule):
>
> ipset -N My_IP_Set iphash
> ipset -A My_IP_Set 10.0.0.1
> ipset -A My_IP_Set <Public IP>
>
> As stated before this should cause your one iptables rule to match packets 
> that are destined to any IP in the ip set "My_IP_Set" and DNAT said packets 
> to the <relevant.internal.server>:<tcpservice>.  I know that this is not the 
> multiple passes through the iptables chains like you were asking for, but I 
> think it will provide a solution comparable  to the result that you were 
> after.  Rather than have a rule that will alter traffic such that it will be 
> caught by another rule and then altered again why not have a rule that will 
> catch either type of traffic.
>

Actually, if this does not help the original poster, it may work in my 
issues in the thread on "okay I admit confusion here..."

I think my best solution is one to one nat of public addresses to internal 
private addresses.  Means I have to put some post/pre routing rules in 
place and I might beable to shorten that all up with IP hashes as you are 
suggesting here.  But, all in all I think that sure beats bridging 
interfaces and dealing with trying to firewall at layer2...


Thanks,


Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCiPQzst+vzJSwZikRAtEWAKCy8I6X6s5EwnsIWNPw5Kmo/pyO5wCdHFe4
c4qm+DWsr0VvOtqZxHdGyFU=
=xH0c
-----END PGP SIGNATURE-----

Re: Combined Internal/External DNAT question

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


an interesting tidbit from the iptables man pages suggests that their is a 
built in facility for this one to one nat thingie I'm looking into here;

    NETMAP
        This  target allows you to statically map a whole network of 
addresses onto another network of addresses.
        It can only be used from rules in the nat table.

        --to address[/mask]
               Network address to map to.  The resulting address will be 
constructed in the  following  way:  All
               'one'  bits  in the mask are filled in from the new 
`address'.  All bits that are zero in the mask
               are filled in from the original address.


If I read this correctly, it appears to build the hash tables of addresses 
for one eh?

Thanks,

Ron DuFresne

On Mon, 16 May 2005, R. DuFresne wrote:

> --[PinePGP]--------------------------------------------------[begin]--
> On Mon, 16 May 2005, Taylor, Grant wrote:
>
>>> My problem still remains however Grant. I would have to create another
>>> DNAT rule to match each existing *real* public DNAT rule that currently
>>> exists to DNAT traffic from the Internet.  Do you have any further ideas
>>> for me? Given that a packet can have both the src and dst IP address
>>> rewritten in it's one trip through iptables, it seems to me that it 
>>> should
>>> be possible for two rewrites to happen at once. My thinking it perhaps
>>> breaking the nat table into several chains?  Any other suggestions, 
>>> you've
>>> been most helpful so far.
>> 
>> 
>> The only other thing that comes to mind would be to use iphash (IP)sets of
>> destination IP addresses on your original DNAT rules.  This would cause 
>> your
>> iptables rule to match based on the destination of your external IP of 
>> your
>> firewall OR your external IP of your DSL modem (/router) and DNAT the 
>> traffic
>> to the real server on your 2nd internal subnet.  Here is an example rule 
>> for
>> what you would need:
>> 
>> iptables -t nat -A PREROUTING -m set --set My_IP_Set dst -j DNAT
>> --to-destination <relevant.internal.server>:<tcpservice>
>> 
>> To support this rule you would need to do the following (likely before you
>> issued the above rule):
>> 
>> ipset -N My_IP_Set iphash
>> ipset -A My_IP_Set 10.0.0.1
>> ipset -A My_IP_Set <Public IP>
>> 
>> As stated before this should cause your one iptables rule to match packets
>> that are destined to any IP in the ip set "My_IP_Set" and DNAT said 
>> packets
>> to the <relevant.internal.server>:<tcpservice>.  I know that this is not 
>> the
>> multiple passes through the iptables chains like you were asking for, but 
>> I
>> think it will provide a solution comparable  to the result that you were
>> after.  Rather than have a rule that will alter traffic such that it will 
>> be
>> caught by another rule and then altered again why not have a rule that 
>> will
>> catch either type of traffic.
>> 
>
> Actually, if this does not help the original poster, it may work in my
> issues in the thread on "okay I admit confusion here..."
>
> I think my best solution is one to one nat of public addresses to internal
> private addresses.  Means I have to put some post/pre routing rules in
> place and I might beable to shorten that all up with IP hashes as you are
> suggesting here.  But, all in all I think that sure beats bridging
> interfaces and dealing with trying to firewall at layer2...
>
>
> Thanks,
>
>
> Ron DuFresne
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>        admin & senior security consultant:  sysinfo.com
>                        http://sysinfo.com
> Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629
>
> ...We waste time looking for the perfect lover
> instead of creating the perfect love.
>
>                -Tom Robbins <Still Life With Woodpecker>
> --[PinePGP]-----------------------------------------------------------
> gpg: Signature made Mon 16 May 2005 03:27:47 PM EDT using DSA key ID 94B06629
> gpg: Good signature from "dufresne <dufresne@sysinfo.com>"
> --[PinePGP]----------------------------------------------------[end]--
>

- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCiPmWst+vzJSwZikRAnNJAKDH9bP49JIBtFn1wK5Xbre/CHoNlgCffM0s
fQET0waj7L4hdtx/EbPmaZY=
=0jZG
-----END PGP SIGNATURE-----

Re: Combined Internal/External DNAT question

[Taylor, Grant]

> an interesting tidbit from the iptables man pages suggests that their is 
> a built in facility for this one to one nat thingie I'm looking into here;
> 
> NETMAP
>        This  target allows you to statically map a whole network of addresses onto another network of addresses.
>        It can only be used from rules in the nat table.
> 
>        --to address[/mask]
>               Network address to map to.  The resulting address will be constructed in the  following  way:  All
>               'one'  bits  in the mask are filled in from the new `address'.  All bits that are zero in the mask
>               are filled in from the original address.
> 
> If I read this correctly, it appears to build the hash tables of 
> addresses for one eh?

As I understand it the NETMAP target is used to do NATing on a large range ((sub)network) of IPs in on rule.  Thus you could directly translate 192.168.0.1 <-> 172.16.0.1, 192.168.0.2 <-> 172.16.0.2, 192.168.0.n <-> 172.16.0.n, etc.

As far as your situation are you really wanting each computer on your network to have a globally routable IP?  If not then you do not need / want to look at NETMAP.



Grant. . . .

filtering in which rules?

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Jason et. al.,


I wacthed the discusion today on leaving filtering to the filter chain and 
leave nat to nat and routing to the pre/post chains.  But, when one reads 
other documentation and it has paramaters to iptables like this;


iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -t nat -P PREROUTING DROP
iptables -t nat -P POSTROUTING DROP


It g9ives one the impression that matters of filtering and decision making 
for a packet are not as carved in stone as implied in the discusion today. 
Jason makes some great points about complexity of rulesets and trying to 
maintain that accross a number of firewalls overtime.  But, that seems to 
implay that others have adopted complexity and feel fine with all it 
brings to the maintainace table.  Unless I'm reading the DROP defaults 
for the pre/post routing above.  So for clarification one more time, 
should one read these docs with a grain of salt and alter acordingly, 
perhaps placing a default ACCEPT in the pre/post chanins and then doing 
what filtering is required in the 'proper' filter chains for clarity? 
I direct this to Jason in particular, though Grant as well as others may 
wish to input again <cause Jason and Grant seem to know their stuff when 
it comes to iptables>.

Thanks,


Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCjoC/st+vzJSwZikRAocaAJ9wlJa4uwnTYyYFAxeRJjEpLHqo7ACfb4dR
j/zKrKKllOtVUarUlaztXq0=
=kaXx
-----END PGP SIGNATURE-----

Re: filtering in which rules?

[Daniel Lopes]

R. DuFresne schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Jason et. al.,
> 
> 
> I wacthed the discusion today on leaving filtering to the filter chain 
> and leave nat to nat and routing to the pre/post chains.  But, when one 
> reads other documentation and it has paramaters to iptables like this;
> 
> 
> iptables -P INPUT DROP
> iptables -P FORWARD DROP
> iptables -P OUTPUT ACCEPT
> iptables -t nat -P PREROUTING DROP
> iptables -t nat -P POSTROUTING DROP
> 
> 
> It g9ives one the impression that matters of filtering and decision 
> making for a packet are not as carved in stone as implied in the 
> discusion today. Jason makes some great points about complexity of 
> rulesets and trying to maintain that accross a number of firewalls 
> overtime.  But, that seems to implay that others have adopted complexity 
> and feel fine with all it brings to the maintainace table.  Unless I'm 
> reading the DROP defaults for the pre/post routing above.  So for 
> clarification one more time, should one read these docs with a grain of 
> salt and alter acordingly, perhaps placing a default ACCEPT in the 
> pre/post chanins and then doing what filtering is required in the 
> 'proper' filter chains for clarity? I direct this to Jason in 
> particular, though Grant as well as others may wish to input again 
> <cause Jason and Grant seem to know their stuff when it comes to iptables>.
> 
> Thanks,
> 
> 
> Ron DuFresne

Hmm I do filtering, mangling and natting in the appropriate tables for 
better arrangement and because afaik some things can only be done in the 
responsible tables. For example the outgoing interface shouldn´t be 
known in the PREROUTING chain of the nat table unless iptables uses it´s 
own routing algorithm for finding it out or a hook to the existing one I 
don´t really know.
I think it´s difficult to find a way so that the filtering will be 
effective. For example should DROP be as soon as possible so the packet 
won´t traverse all needed chains.
e.g.:
 > iptables -P INPUT DROP
 > iptables -P FORWARD DROP
 > iptables -P OUTPUT ACCEPT
 > iptables -t nat -P PREROUTING DROP
 > iptables -t nat -P POSTROUTING DROP
Let´s assume a packet destined to the machine no forwarding necessary.
If you don´t want that packet (no ACCEPT rules in the nat PREROUTING for 
that type) it will be dropped.
With this set
 > iptables -P INPUT DROP
 > iptables -P FORWARD DROP
 > iptables -P OUTPUT ACCEPT
 > iptables -t nat -P PREROUTING ACCEPT
 > iptables -t nat -P POSTROUTING ACCEPT
the packet also would have to traverse the INPUT chain until it would be 
dropped.
Only as an example.
I also think positioning the rules in an order within the chains 
depeding on the frequency you expect a packet has an effect on 
effectiveness. The deeper you have to traverse a chain the more time it 
takes to handle the packet. For alot of packets it can have an effect.

Re: filtering in which rules?

[Taylor, Grant]

> I wacthed the discusion today on leaving filtering to the filter chain 
> and leave nat to nat and routing to the pre/post chains.  But, when one 
> reads other documentation and it has paramaters to iptables like this;
> 
> iptables -P INPUT DROP
> iptables -P FORWARD DROP
> iptables -P OUTPUT ACCEPT
> iptables -t nat -P PREROUTING DROP
> iptables -t nat -P POSTROUTING DROP
> 
> It gives one the impression that matters of filtering and decision 
> making for a packet are not as carved in stone as implied in the 
> discusion today. Jason makes some great points about complexity of 
> rulesets and trying to maintain that accross a number of firewalls 
> overtime.  But, that seems to implay that others have adopted complexity 
> and feel fine with all it brings to the maintainace table.  Unless I'm 
> reading the DROP defaults for the pre/post routing above.  So for 
> clarification one more time, should one read these docs with a grain of 
> salt and alter acordingly, perhaps placing a default ACCEPT in the 
> pre/post chanins and then doing what filtering is required in the 
> 'proper' filter chains for clarity? I direct this to Jason in 
> particular, though Grant as well as others may wish to input again 
> <cause Jason and Grant seem to know their stuff when it comes to iptables>.

I think that what Jason is trying to allude to is akin to stock Ford Crown Victorias you and I can by at our local car dealership vs. the Fleet Ford Crown Victoria that the police so love to use.  I have been told (and tend to believe) that the stock CV is faster and more maneuverable than the fleet version.  However the fleet version is meant to be on the road far far more hours than the non fleet and they are also meant to be MUCH more maintainable.  The idea behind this analogy and my statement is that the IPTables firewalls that Jason is referring to would be more of the fleet variety, something you might use in place of the Cisco 2501 routers that are on the remote end of so many T1, they standardized, maintainable, easily configurable and upgradeable to any average Cisco person that walks on site.  Where as more of the uber secure IPTables firewalls that are described in many of th
 ose documents are what you might find in side of an R & D department that is worried about
 industrial espionage and thus have much more secure firewalls.  I suspect that many of the firewalls that Jason is working on are simple and effective with out too many bells and whistles, something that will be robust and secure.  More of the firewalls that I work on are more of the R & D department type (routing / load balancing across 8 cable modems from the same provider with 8 sequential IPs all of which have the same upstream GW) firewalls where it will be me or a select few of my piers that will work on them.  The more bells and whistles that you put in to a system the more complicated you make it for others to maintain when you are hit by the Greyhound Buss on your way in to the office after your morning bagel.  With this in mind the simple and robust solution would be to do all your filtering in the filter table (as that is what it is meant for) where people will look first to 
 resolve problems.  Once you have the filter table set up the way that you want it you coul
d optionally choose to also set up filtering in the nat, mangle, and raw tables to be absolutely sure that no one will get past your firewall.  However this is probably and quite likely overkill for most situation.  One reason that does come to mind to filter in the mangle table would be if you continually received a LOT of one specific type of packet that you knew you would never need that was causing undo load on your firewall to process on the IP routing layer, thus you could / should filter it out in the mangle layer before IP even decides if it needs to route it.  Below is a short list of points as to why to filter in the filter table:

  1)  All packets (that are not DROPed prior) traverse the INPUT / FORWARD and / or OUTPUT chains in the filter table.
  2)  Not all packets traverse the PREROUTING, POSTROUTING, OUTPUT chains in the nat table, just NEW connections.
  3)  The nat, mangle, and raw table are really sort of like tools to do specific things that can not (should not) be done in the filter table.
  4)  The filter table is where people expect to see filtering rules and thus will look.  Often (as Jason pointed out) some rules that are not in the filter table will be overlooked when diagnosing problems.
  5)  More advanced features, i.e. SSH_Brute_Force test, selectively REJECTing vs DROPing Ident (Auth) requests, etc. are more specialized and thus are more troublesome to diagnose and thus are not often needed on most of your firewalls / routers.
  6)  Many edge routers that pass large amounts of traffic do not need the complexity of these filters and thus do not have them, this is reserved for the R & D departmental level routers / firewalls.

Ok, I think I'm done ranting now.



Grant. . . .

Re: filtering in which rules?

[Jason Opperisano]

On Fri, May 20, 2005 at 08:28:43PM -0400, R. DuFresne wrote:
> I wacthed the discusion today on leaving filtering to the filter chain and 
> leave nat to nat and routing to the pre/post chains.  But, when one reads 
> other documentation and it has paramaters to iptables like this;

my problem is that the reasoning behind why people do this stuff never
adds up to a logical argument, IMHO.

> iptables -P INPUT DROP
> iptables -P FORWARD DROP
> iptables -P OUTPUT ACCEPT

so we're going for super-tight, NSA-levels of security; yet we leave the
policy of OUTPUT to ACCEPT.  i don't buy it.

> iptables -t nat -P PREROUTING DROP

i'll buy the argument that there are packets so nasty that we want to
drop them as soon as possible.  fine--"as soon as possible" translates
to mangle:PREROUTING, not nat:PREROUTING.  also, applying a filter rule
or a DROP policy in nat assumes that these naughty, naughty packets will
always be the first packet in a new connection.  this is simply just
silly.

i *do* filter in mangle:PREROUTING...all the wacked-out tcp flag combos
that shouldn't appear in the wild get dropped in my mangle:PREROUTING
chain.  reasons:

  - we want to drop these as soon as possible.
  - we gain economies of scale in that whether the packet is ultimately
    destined for INPUT or FORWARD it gets dropped by just one rule here
  - we make no assumption that these packets are NEW, so we don't want
    them to get ACCEPTed by our ESTABLISHED rule that starts both
    filter:INPUT and filter:FORWARD

> iptables -t nat -P POSTROUTING DROP

so we've had no less than 3 opportunities to drop this packet, but we
need to wait until nat:POSTROUTING to catch it?  not buying it.  i would
argue the only real-world situation someone would set nat:POSTROUTING to
DROP, is when they have *no* filter rules at all, and they basically
are saying--i want to SNAT/MASQ packets from my internal network
subnet and then drop anything else.  kinda like a 1-line firewall
for non-firewall-types.  that's fine, but i'm going to be a big meanie
and say these people are not relevant to conversation at hand--which i
believe to be "best practices for netfilter firewall rule design."

firewalls should exhibit 3 characteristics in my opinion:

  - speed
  - security
  - stability

contrary to grant's crown vic / cisco 2501 analogy; i have actually
arrived at my opinions by building firewalls with very high throughput
requirements, very high security requirements, in very complicated network
environments.  let's take an extreme case where we set all policies of
all chains to DROP.  if i want to allow a communication flow through
this gateway, i would need to add 6 rules:

  mangle:PREROUTING
  nat:PREROUTING
  mangle:FORWARD
  filter:FORWARD
  nat:POSTROUTING
  mangle:POSTROUTING

now does checking packet 6 times create a more secure gateway than if i
only created one rule in filter:FORWARD?  i would argue that the minuscule
security gain (i'm giving the benefit of the doubt that there is one)
is vastly out-weighed by the significant performance hit and the insane
increase in maintainability/troubleshooting effort created.  anyone here
ever make typos?  i sure do.  you give me 6 chances at making a simple
mistake or overlooking one detail, i bet i will more than zero percent of
the time.  now how much productivity do we want to lose because of this.
i guess this all comes down to something we hear a lot in the security
field these days:

  Keep It Simple Stupid

Bruce Schneier harps constantly on the fact that the complexity and
security of a system are inversely proportional.  i happen to agree with
him 1000%.

i s'pose i've prattled on long enough at this point.  again--these are
all just my opinions, i'm not suggesting that this is the one true way
to do things, or that other ways are wrong or inferior.  just what i've
come to think over the past decade building firewalls for a living.

-j

--
"Meg: I made flag girl!
 Stewie: Oh, you made flag girl. Great.
 Stewie: Now you can be somewhere else when the boys don't call."
        --Family Guy