- The True Issues
- Mitigating Organizational Risk
- Mitigating Agent-Forwarding Risk
- Mitigating Port-Forwarding Risk
- Final Ideas
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Mitigating Agent-Forwarding Risk
I wish I could describe an elegant security design for agent forwarding—I like it that much. But devices in untrusted zones must not be trusted. No matter how much people complain, SSH services running in untrusted zones must have agent forwarding disabled. If agent forwarding is enabled, the implementation will allow an intruder to connect to the stored authentication credentials and then use them to connect to other DMZ hosts (or even intranet hosts, if port forwarding has been allowed as well). Disable agent forwarding by default and allow it as needed. Don’t assume that the risk isn’t there if your platform’s software and online help don’t mention it. Specifically, disable it in the server’s configuration. It may be put in as a compatibility feature, just waiting for someone to activate it.
What about using an SSH feature that allows SSH to send a notification to your terminal when authentication credentials are used, via the X Window System? Of course, this option is limited to one distribution at this time. I’m not even sure that it would work to stop an intruder from using your credentials. But maybe this is the control to agent forwarding? Review the ssh-add man page. Meanwhile, let’s discuss the X Window System (we’ll refer to it as X11) and DMZ hosts.
X11 has many good points, but its security record has issues. Most people don’t understand the inverted relationship. As you use X11, the remote device writes to your X11 server. This server runs as root in UNIX and can run processes as root on your device (if the code needs updates). Many people disable access control to get X11 to work, and a few X11 emulators that run on Windows install with access control disabled. This technique allows hackers to plant loggers to your display and record keystrokes or make screen captures. Additionally, they can force pop-ups on you that harvest information such as SSH passphrases. I wouldn’t give a DMZ host X11 access to an internal device, especially if it’s done to enable a possible SSH security feature that exists with one SSH platform only.
Agent forwarding is a useful feature, but most vendors recommend against enabling it in all environments. Are intranets that trustworthy, given all the malicious insider activity? At some point, the mitigation shifts from banning/allowing agent forwarding right into detecting misuse of agent forwarding. For now, create a ban on the feature outside of the intranet. From there, you simply need a robust security architecture that can detect and respond to odd access events.