The second approach to escalating privileges we discussed was to hijack a process running with a higher level of privileges. This is essentially the same thing we discussed doing to the webserver, except that, once we are on the target host, we have more processes to attack, because we are not limited to servers listening on ports. Once again, keeping software patched is an important part of defending against this kind of attack. Another is to minimize the system's use of programs that run with a high level of privilege, so that there are fewer candidates for processes to highjack. This idea will come back again later.
The inner firewall limits access from the DMZ to the internal network. For example, the inner firewall my not allow ssh traffic (port 22) from the dmz into the inner network. This would've foiled the attack strategy in our scenario. USNA employs this, in fact. You can, for example, ssh from rona.cs.usna.edu to www.usna.edu, but you cannot ssh from www.usna.edu to rona. If you have an account on www.usna.edu (which the instructors do), you can try it. Hosts inside the DMZ usually do nothing but provide their service. This allows adminstrators to remove many programs and files that would normally be on a host, further limiting the options of an attacker that gains access to that host.
web, and the webserver runs as a process owned by that user, a successful attacker would have no special privilges on the system. If, on the other hand, the webserver process is owned by the administrator account, a successful attacker has unlimited access on the host. Other steps can limit the privileges and access of the server even further. OS's allow processes to be sandboxed, which means that the set of files and services accessible by and even visible to the process is severely limited.
|Defense in Depth
||Management and Monitoring
||Network Access Control
||Intrusion Detection Systems (IDS)
||Intrusion Prevention Systems (IPS)
|Demilitarized Zones (DMZ)
||Virtual Private Networks (VPN)