Slashdot Mirror
Overconfidence in SSH Protection
nitsudima writes to mention a post on the Informit site about the common misunderstandings surrounding SSH, and how well-intentioned admins may be creating holes in their own security by using it. From the article: "In UNIX, all things are files. To send network traffic, UNIX writes the traffic to the network device file. In this case, the connection to Box A (and that private key used for authentication) is a socket file. This file will shuttle the authentication traffic between Box A and Box P. So what's the risk? Maybe the hacker can't get a copy of the private key through the socket file, but something better (from his/her view) can be done. If the hacker has root on Box D, he or she can point a private copy of the agent forwarding software to that socket file and thereby point the authentication process to the administrator's credentials--the ones kept on the 'safe' intranet. What are the chances that the administrator has configured access to all the DMZ servers he controls?"
The article illustrated one very convoluted way to break your DMZ security, but failed to make the simple statement: don't trust anyone, not even root, on your DMZ hosts. Allow SSH logins into the DMZ, and allow the DMZ to pull files from private network patching servers, such as apt repositories, but don't allow anyone to SSH from the DMZ to the intranet. Assume the DMZ is cracked wide open and keystroke logging. No one is going to get past the DMZ by watching you type 'apt-get install squid' but they will by watching you type 'ssh root@creditcarddb.int' and then the root password.
... you can packet sniff the authentication process all day long and you won't get someone's private key.
Anyone who tunnels from the DMZ to a trusted host which can execute commands on a sensitive server can't see the forest for the trees. You've learned how to use SSH and tunnel, but you're lacking some basic common sense.
Also, I don't see what good a socket catching the authentication will do
That whole article seemed a bit of voodoo itself. Many incongruous statements, like "If the hacker has root on Box D, he or she can point a private copy of the agent forwarding software to that socket file and thereby point the authentication process to the administrator's credentials--the ones kept on the "safe" intranet."
What does that mean, exactly? You direct the authentication process to a socket file and point the process to the admin's credentials? If the socket is on the DMZ host, and the credentials are on the private network host, how can you point the authentication process to those credentials?
Maybe I'm stupid, but the article didn't seem to make a lot of sense.
Here's a summary for you:
User A on box foo:
foo> ssh-agent xterm
foo> ssh-add
* enters their pass key *
User A can now ssh to any box that has their public key in box:$HOME/.ssh/authorized_keys
User B (evul hacker with root on box foo):
foo# SSH_AGENT_PID=XXXX; export SSH_AGENT_PID
foo# SSH_AUTH_SOCK=/tmp/ssh-YYYY/ZZZZ; export SSH_AUTH_SOCK
User B now can ssh to any box that User A can, as above.
(where XXXX, YYYY, and ZZZZ are determined by evul hacker)
Actually...
_ command_allow_rsync",no-port-forwarding,no-X11-for warding,no-agent-forwarding,no-pty ssh-rsa AA...= backup_key
/etc/ssh/sshd_config
= 13084357
h tml [kernel.org] called pam_abl
Rather than assume anyone^H^H^H^H^H^Heveryone on slashdot has any brains when it comes to Securing SSH let me give you some tips I/Other people have
Restricted ssh shell for scp/sftp http://sublimation.org/scponly/
Patch to lock out IPs brute forcing passwords http://ethernet.org/~brian/src/timelox/
Can add restrictions to authorized_keys file
from="hostipaddress",command="/usr/local/sbin/ssh
Securing sshd in
Protocol 2
PermitRootLogin without-password
PasswordAuthentication no
ChallengeResponseAuthentication no
ClientAliveInterval 60
ClientAliveCountMax 30
The first line says to stop using the old, lower security ssh protocol-1.
The second line is a hedge that says never allow root logins using the unix password -- always use some other authentication.
The third line says don't allow skey authentication. It is a good idea to turn this off if you aren't using skey at this time. (Skey implements a series of non-reusable, one-time passwords. If you were using it you would know.)
The fourth and fifth lines simply make sure that any connection to a client that doesn't respond at least once each half hour gets closed. After editing the sshd file, restart sshd or reboot for the changes to take effect.
31-12-2004: new rate-limiting feature in -current. This would block hosts that exceed 10 connections per 60 seconds.
pass in on $ext_if proto tcp to $ext_if port ssh flags S/SA \
keep state (max-src-conn-rate 10/60, overload )
block in on $ext_if proto tcp from to $ext_if port ssh
Also my previous post to do with limiting user connections to SSH during the scarey SSH port scanning days of not so long ago...
http://it.slashdot.org/comments.pl?sid=156058&cid
Repeated here for your convenience:
Ways around SSH Brute forcing (Score:1)
by meridian (16189) on 11:06 AM July 17th, 2005 (#13084357)
(http://www.thief.net/)
There are esentially three ways to fix this problem.
The first is to patch sshd which is probably the least preferable way as you would need to continually keep patching with each upgrade. But this seems effective allowing you to exec a system command such as iptables.
http://ethernet.org/~brian/src/timelox/ [ethernet.org]
The second is to use iptables to limit connection attempts from an IP address. One problem with this is people who use scp alot may quickly rack up that connection limit.
Here is a recent example from the iptables mailing list
iptables -A INPUT -p tcp --dport 22 -s ! $My_Home_Firewall_IP -m state --state NEW -m recent --name SSH --set --rsource -j SSH_BF
iptables -A SSH_BF -m recent ! --rcheck --seconds 60 --hitcount 3 --name SSH --rsource -j RETURN
iptables -A SSH_BF -j LOG --log-prefix "SSH Brute Force Attempt: "
iptables -A SSH_BF -p tcp -j DROP
The best in my opinion is a pam module found at http://www.kernel.org/pub/linux/libs/pam/modules.
This does not have the problem of the IPTables method that may mistake multiple fast scps etc as an attack attempt, and will not require coninutal repatching of the kernel such as the timelox patches.
meridian at tha.net
Why the developers of ssh have an option to forbid agent forwarding. Isn't it off by default? I cite from "man ssh":
>>>
Agent forwarding should be enabled with caution. Users with the
ability to bypass file permissions on the remote host (for the
agent's Unix-domain socket) can access the local agent through
the forwarded connection. An attacker cannot obtain key material
from the agent, however they can perform operations on the keys
that enable them to authenticate using the identities loaded into
the agent.
So wha is slashdot running an article about something where there is an explicit one-paragraph long waring in the man page of program at the option in question.
Yes, no doutbt there are a lot of idiots around, who without understanding,do things which require semantics which leads to a security leak (there is abolutely no way if you want to initiate authenticatication from processes on a machine to avoid root to do the same - as log as you are not asked on the agent's side each time before authentication;
The article is about a common misconfiguration with regard to agent forwarding. The DMZ hosts aren't supposed to be safe, that's why they're in the DMZ and not in the intranet. The admin must assume that root on these machines is compromised. Consequently he doesn't store his private keys on any of the DMZ machines. But what many overlook, possibly because they don't use the feature, is agent forwarding. Once the admin has logged into a compromised DMZ host, access to his credentials is extended to the DMZ host by that ominous socket. The file itself never leaves the admin's computer, but if agent forwarding is enabled, root on the DMZ host can now point other hosts on the intranet to the authentication facility on the admin's computer. This misconfiguration enables the attacker to hop from the DMZ to the intranet. The correct way to avoid this is to disable agent forwarding (on the admin's computer, not just on the DMZ hosts, of course).
A few versions ago OpenSSH added a -c "Require confirmation to sign using identities" to ssh-add to take care of this. Or using something like SSHKeychain on OS X so it'll ask for confirmation for multi-hop auth, but not for connections direct from your trusted machine.
No, it's not really a man in the middle attack.
It's more of a credential hijacking scenario where
the attacker waits for you to authenticate with
the compromised machine, forward your credentials
to that machine, and then the attacker uses those
credentials to reach other machines that honor those
credentials.
This would be more like you signing in, walking
away from your computer, and someone else walkup up
to the computer and doing stuff as you except that
they get to act as you while you're still acting
as you.
Did that help?
*sigh* back to work...