Forum Discussion
CirrusRouting of DMZ F5 traffic to internal F5 traffic
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.
CumulonimbusAs 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.
