Forum Discussion

mpete32_168869's avatar
mpete32_168869
Icon for Cirrus rankCirrus
Oct 28, 2014
Solved

Routing of DMZ F5 traffic to internal F5 traffic

I have a design / functionality question. I have a DMZ server that I'll be bringing into our internal network but will be fronting it will the F5 appliance in our DMZ. The question I has is two fold... (1) Would it be good practice to have the traffic coming from the DMZ F5 to the internal F5 and then to the backend vs? (2) Because I have to enter firewall rules for each server that we are bringing inside and fronting with the F5, would it be good practice to simply setup one set of ACLS to allow the DMZ and Internal f5's to talk with each other and then edit the firewall acl with a new port each time we add new functionalty?

 

APM
application delivery
deployment
design
devops
iRules
security
  • mimlo_61970's avatar
    mimlo_61970
    Oct 28, 2014

    I wouldn't consider it best practice, but people have their own opinions. Ask yourself this, would you open a rule up from the Internet direct to an internal server? If not, what protection do you think the F5 is adding to this connection to make your scenario better? Assuming you are just talking about LTM, it is working as a proxy and terminating the connection, but for the most part it will pass all application traffic, including application attacks/exploits, right through to your internal server.

     

    As far as routing and firewall rules, that is configuration dependent, but I don't think you can just create a rule allowing DMZ F5 to talk to internal F5. Your traffic will go through the external F5 and have some source IP(defined by if SNAT is enabled, what snat pool you use, or automap) to a destination of the internal virtual server. I imagine you will need a separate rule for each VS you want to work this way.

     

7 Replies

Sort By
  • mimlo_61970's avatar
    mimlo_61970
    Icon for Cumulonimbus rankCumulonimbus
    Oct 28, 2014

    I wouldn't consider it best practice, but people have their own opinions. Ask yourself this, would you open a rule up from the Internet direct to an internal server? If not, what protection do you think the F5 is adding to this connection to make your scenario better? Assuming you are just talking about LTM, it is working as a proxy and terminating the connection, but for the most part it will pass all application traffic, including application attacks/exploits, right through to your internal server.

     

    As far as routing and firewall rules, that is configuration dependent, but I don't think you can just create a rule allowing DMZ F5 to talk to internal F5. Your traffic will go through the external F5 and have some source IP(defined by if SNAT is enabled, what snat pool you use, or automap) to a destination of the internal virtual server. I imagine you will need a separate rule for each VS you want to work this way.

     

    • mpete32_168869's avatar
      mpete32_168869
      Icon for Cirrus rankCirrus
      Dec 12, 2014
      That's technically what we're attempting to do is to use the DMZ F5 as a proxy eliminating having to place any servers in the DMZ.
    • mimlo_61970's avatar
      mimlo_61970
      Icon for Cumulonimbus rankCumulonimbus
      Dec 12, 2014
      I wouldn't advise it. Take SCHANNEL attack for example. No one ever really said if F5 stopped it, but I would assume if it did they would have been shouting from the rooftops that they could solve the problem. So now you have an exploit that goes right through your F5 and onto the backend server, executing an arbitrary command on a server on your internal network.
  • Arie's avatar
    Arie
    Icon for Altostratus rankAltostratus
    Oct 28, 2014

    I agree with @mimlo that your configuration wouldn't be best practice nor provide the best security architecture.

     

    Having said that, you could use Route Domains on the BIG-IP as part of the solution. That would provide an additional layer of security and potentially keep you from having to configure each server individually on the firewall.

     

  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Oct 29, 2014

    It would be rare I'd open up an INTERNAL server just by access from BigIP (LTM). To mitigate, I'd make sure that it was well protected... By strong auth, APM and ASM etc. (Which are designed to allow secure access inbound).

     

    If not, then I wouldn't like to do it...

     

    H

     

  • mimlo_61970's avatar
    mimlo_61970
    Icon for Cumulonimbus rankCumulonimbus
    Oct 29, 2014

    As an example of why this is bad, consider a recent exploit, shellshock. If you were running a Linux webserver using CGI that was vulnerable, an LTM would happily pass the exploit through. The example I used to test internally was a specially crafted cookie containing the exploit that setup a reverse ssh session. In the above scenario, that would give the attacker a shell on your internal server. Yes there are irules to stop shellshock, and asm will now block it, but day 0 none of that was there, and sometimes things are being exploited in the wild before they are disclosed and patched.

     

    Like Hamish said, I do this under only one set of circumstances, APM handling authentication and ASM as a frontline defense. Most solutions are for unauthenticated traffic ruling out APM, which means the server goes in the DMZ.

     

  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Oct 30, 2014

    Some simple rules I like to (At least try to) follow.

     

    1. All inbound connectivity must terminate at the DMZ
    2. There is a change of protocol between DMZ and internal (i.e. Not just a simple proxy onwards).
    3. No data in the DMZ
    4. No accessing shared drives from DMZ back to internal
    5. No interactive inbound connectivity from DMZ to internal
    6. No interactive inbound connectivity from external to DMZ
    7. Obviously things that are DESIGNED to allow inbound interactive connectivity break some of these. e.g. RAS via APM. But that should be protected via STRONG authentication. e.g. two-factor like securID
    8. Accepting inbound files from users is dangerous. Quarantine & verify accordingly.

    There's more of course...

     

    H