Squid will work for reverse proxying, but only as long as all of your internal webservers are running on port 80 (as I understood it a few years ago when I first started trying to implement such a solution, this may have changed). Apache's reverse proxy can be much more fine-tuned to accomodate any setup.
For example, you can have www.yourdomain.com point to one webserver, but www.yourdomain.com/newdirectory/ point to another webserver, and www.yourdomain.com/random/ point to yet another machine, even a different port (if you have a webserver running on port 8000, for example). If combined with mod_rewrite, you can get even more fine-grained and versatile variation.
On top of this, it can help secure your internal servers even further by providing an SSL frontend to non-SSL enable servers (clients connect to 443 on the proxy, which pulls from port 80 on the internal machine).
Finally, you can add mod_security to your Apache server which acts similarly to MS's URLScan tool to help filter out malicious requests.
Discussion on:
View:
Show:
"Most high-end reverse proxies run a proprietary operating system and are immune to Web server attacks"
Whatever it is that makes you believe that something is immune to attack, you need to pick it up, examine it for what it is, and then toss it out. That whole line about things being immune to attack because they run "our hardened proprietary operating system" is a flat-out lie.
Take the attitude that "I shouldn't worry about it because it's hardened" is the first step to getting hacked. This is what any renowned security group will tell you. Don't buy the BS from the proxy manufacturers about being immune to attack.
Another point: "And in the event of a successful hack, the black hat will only have access to information involved in a single transaction, rather than to the internal trusted database"
Sure, he'd have access to that single transaction. But wouldn't he also be able to initiate transactions if he's owns the box? Yes, he would. If he owned the box, he could sit there all day and blast the webservers with various port 80 attacks.
Attack the web server in the DMZ and hack it. Install tools to infect the admins when they SSH or telnet to it; are you running up-to-date clients?
Not to say that it's as easy as 1 2 3, but there is a path back to the LAN if a WAN is physically connected to it. Don't even think about resting on security because "my server is immune to attacks."
Bottom line: Security is something where you never say "it's impervious to attack." And once you do say that, you get hacked. So don't say it and stay alert.
Whatever it is that makes you believe that something is immune to attack, you need to pick it up, examine it for what it is, and then toss it out. That whole line about things being immune to attack because they run "our hardened proprietary operating system" is a flat-out lie.
Take the attitude that "I shouldn't worry about it because it's hardened" is the first step to getting hacked. This is what any renowned security group will tell you. Don't buy the BS from the proxy manufacturers about being immune to attack.
Another point: "And in the event of a successful hack, the black hat will only have access to information involved in a single transaction, rather than to the internal trusted database"
Sure, he'd have access to that single transaction. But wouldn't he also be able to initiate transactions if he's owns the box? Yes, he would. If he owned the box, he could sit there all day and blast the webservers with various port 80 attacks.
Attack the web server in the DMZ and hack it. Install tools to infect the admins when they SSH or telnet to it; are you running up-to-date clients?
Not to say that it's as easy as 1 2 3, but there is a path back to the LAN if a WAN is physically connected to it. Don't even think about resting on security because "my server is immune to attacks."
Bottom line: Security is something where you never say "it's impervious to attack." And once you do say that, you get hacked. So don't say it and stay alert.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
