Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 2 subscribers
  • Views 3281 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DNAT Rule Ordering Problem

danielrm26
Greetings,

I am having trouble getting multiple DNAT rules to act the way I want them to.

I have a few services in my DMZ that I want to explicitly forward traffic to - this all works perfectly.  I also have an IDS box in the same DMZ (on a hub) that I want to be able to see ALL traffic. So, what I was hoping to do is first forward all specific public traffic to the appropriate host in the DMZ, and then forward  everything else to the second 'internal' firewall so that all traffic would be seen by my IDS.

The problem is that this doesn't work.  If I enable a DNAT rule at the 'bottom' of the stack that says ANY-->WAN_ADDRESS-->INT_FIREWALL, it  goes by that rule first  and ignores my other predefined rules for the DMZ traffic.

How can I get it to do my DMZ rules first and then do my 'if not those --> all other to internal firewall' rule?

Any thoughts would be appreciated.


This thread was automatically locked due to age.
Parents
  • 0
    danielrm26,

    it is very uncommon to route packets to an IDS monitor.
    I assume your DMZ is located between the two firewalls.
    If all devices are connected to a real hub no extra routing 
    (DNATting) would be nescessary because all packets
     are on the wire and readable for all connected devices!

    read you
    o|iver
  • 0 in reply to oliver.desch
    > it is very uncommon to route packets to an IDS monitor.

    I am not routing  to the IDS - I am routing  past the IDS and to my internal firewall (using a hub) so that my IDS will see all traffic.

    > If all devices are connected to a real hub no extra routing (DNATting) would be nescessary because all packets are on the wire and readable for all connected devices!

    Well, the packets have to make it to the segment where the hub is, otherwise the IDS on that segment won't see them.  Any traffic that is dropped, won't, so if NAT kills off everything but a couple port forwards to the DMZ for public traffic, nothing else will even make it back to the IDS.   

    My goal is to have my IDS see everything hitting my WAN address, so, after forwarding all my public traffic to my DMZ, I have to forward  everything else to my internal firewall so that it goes past my IDS which is in the DMZ (on a hub).

    Do you see what I mean?
Reply
  • 0 in reply to oliver.desch
    > it is very uncommon to route packets to an IDS monitor.

    I am not routing  to the IDS - I am routing  past the IDS and to my internal firewall (using a hub) so that my IDS will see all traffic.

    > If all devices are connected to a real hub no extra routing (DNATting) would be nescessary because all packets are on the wire and readable for all connected devices!

    Well, the packets have to make it to the segment where the hub is, otherwise the IDS on that segment won't see them.  Any traffic that is dropped, won't, so if NAT kills off everything but a couple port forwards to the DMZ for public traffic, nothing else will even make it back to the IDS.   

    My goal is to have my IDS see everything hitting my WAN address, so, after forwarding all my public traffic to my DMZ, I have to forward  everything else to my internal firewall so that it goes past my IDS which is in the DMZ (on a hub).

    Do you see what I mean?
Children
  • 0 in reply to danielrm26
    Perhaps I am not reading this correctly, but I will take a stab at it anyways.

    In my configuration, I also have IDS running, and my configuration is a little different.

    code:
                           ----------
                           -Internet-
                           ----------
                               |
                               |
               SNORT----------HUB
                 |             |
                 |             |
                 |          ASTARO-------DMZ (ftp, www)
                 |             |
                 |------------HUB
                               |
                           Internal Network
    (before anyone beats up on me for dual-homing the SNORT box, the external-facing interface is in promiscuous mode, and has no external address)

    In this case, the Snort sniffing interface sits BEFORE the ASL box, and catches the raw traffic, which is what I think it is you are looking for.  By using a MySQL database, and something like ACID, you can take the raw results (from the outside of the ASL box), and get good, comprehensive reports.  Do you think that would help your situation?

    HTH,

    Bob
  • 0 in reply to Orcusomega
    Thanks for the post, man.

    Actually, the problem with me doing that is that my Astaro box is handling my Internet connection.  My snort box is going to be BEHIND my first Astaro box, so it is already subject to the filtering done by that firewall.  What I need is for that first Astaro box to forward everything back to my INTERNAL Astaro box, so that in passing the hub it will be seen by the snort machine.

    As for your dual homing, that is exactly what I was planning on doing.   [:)]on.

    Comments?
  • 0 in reply to danielrm26
    A snort box with the NIC in promiscuous mode does not need an IP address, so even if ASL handles your incoming connection, the snort box will just "evesdrop" on the wire as packets go to the ASL box in this configuration... it's really nice.
  • 0 in reply to Roland Gaspar
    Originally posted by danielrm26:
    Thanks for the post, man.

    Actually, the problem with me doing that is that my Astaro box is handling my Internet connection.  My snort box is going to be BEHIND my first Astaro box, so it is already subject to the filtering done by that firewall.  What I need is for that first Astaro box to forward everything back to my INTERNAL Astaro box, so that in passing the hub it will be seen by the snort machine.

    As for your dual homing, that is exactly what I was planning on doing.    [:)]on.

    Comments?
    Quick question: Are you using a cable modem, or what?

    Reason I ask is that as long as your connection to your ASL box is ethernet, throw a hub in between, and wala, you have an access point for Snort..

    just my 2 cents..

    bob
  • 0 in reply to Orcusomega
    Ok, I am obviously not being clear here, since both everyone seems to be missing my point; let me try to illustrate.

    If I have a DMZ with one Astaro box up front, a hub in the middle, and a second Astaro box behind it, and I try to use a Snort box on the hub in the middle, it is only going to see what passed the first Astaro box.  If the first Astaro box is only passing certain traffic back (via the packet filter and DNAT), then that is the only traffic that Snort will see.  The Snort box in the DMZ WON'T see everything that the WAN interface sees unless I send everything to that segment with a DNAT rule on the first Astaro box.

    Do you see what I mean?  If you re-read my first posts you should see what I mean now.  Sorry for being so unclear.
  • 0 in reply to danielrm26
    I get it... I get it... you could multi-home your snort box (as opposed to dual-homing it)... but I don't understand why you chose to use 2 ASL boxen instead of just 1 with the DMZ functions...
  • 0 in reply to Roland Gaspar
    What DMZ functions are you alluding to?  DMZs genreally come in two forms: a multi-homed firewall with one NIC going out to a less trusted network, and two firewalls in series with the DMZ in the middle.  The latter configuration is preffered, and that is what I have.

    What do you mean by DMZ functions?
  • 0 in reply to danielrm26
    it was a long day when I posted that, by "DMZ functions" I meant to say that ASL with multiple NICs, some of which, when ruled correctly, would make DMZ-like setups and administration simpler one one machine than many cascaded ASLs.
  • 0 in reply to Roland Gaspar
    Hello danielrm26,
    what should be the funktion of your 1st ASL-Box (that with the Internetconnection) what i understand you only will use it as a router and to terminate the pppoe from your isp. if you make a trafficforwarding for everything crossing the first ASL wich sense is there to use a firewall for this. and the thing with the IDS why would you let everything cross the first ASL the only thing you will reach is that your IDS will see the same as if you connect it via a hub before your first ASL Box.?.?.

    greets
    firebear
  • 0 in reply to firebear_01
    The purpose of this configuration would be to monitor everything hitting my WAN connection, and you are correct in that it would also make my first firewall largely pointless. 

    The issue is that I would like to be able to do this if I want to.  I would like to have the option to have all traffic DNAT'd to my second internal firewall if I would like to, so that my Snort box in the DMZ could see all traffic hitting the WAN.  In all honesty, I wouldn't keep it in that configuration for long; I just want to be able to if I want to.

    A better configuration is to let Snort sit in the DMZ, but to only pass the traffic back that is destined for the public servers in the DMZ.  This way Snort can watch that traffic alone, and not everything hitting the external interface of the first firewall, and I am probably going to end up doing that (with a dual homed Snort box) as my final configuration.

    Anyway, that is the reason - I just want to try it.

     [:)]
     
     [size="1"][ 01 January 2003, 19:53: Message edited by: danielrm26 ][/size]