Re: Idea to secure ssh [was: howto block ssh brute-force]
Neal Murphy wrote: The point is to reduce brute-forace attacks to the point of nearly total ineffectiveness. I use OpenSSH public/private key authentication to achieve this. Based on needs one could also use two factor authentication (e.g. one time password tokens) or even a combination of methods. These are standard tools you can use to defeat the "weak" password solution. It is always better to eliminate problems at their root, which in that case are accounts with weak passwords. The point is to obscure the ssh server from everyone, including those who are authorized to access it remotely. I only see you add an obscuring (and encrypting) shield around your service. I'd say that implementing such a "complex" solution will bring more problems than it will solve (another layer to debug ;) ). I would rather go the KISS way: key auth, non standard ports, fail2ban. As an admin I would rather stick with a hardened SSH gateway, using strong authentication and "end user education", than adding an UDP layer. Another example: We have to run a CVS server that is reachable from the outside, so that some external devs can upload their changes. I got two SSH instances running on that box, one on port 22 that is only reachable from our internal network and one on a non standard port reachable worldwide. The worldwide SSH only accepts logins for a certain group of CVS users, key authentication is enforced and a restricted shell is used that only allows CVS. Up to now (running for approx one year) no automated SSH attack was logged on the non standard port. Full port scans with service identification are seldom and if so, indicate a more detemined attacker. Regards, Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Idea to secure ssh [was: howto block ssh brute-force]
On Mon, Mar 13, 2006 at 11:06:38PM -0500, Neal Murphy wrote:
The point is to obscure the ssh server from everyone, including those who are
authorized to access it remotely. The point is to reduce brute-forace attacks
to the point of nearly total ineffectiveness.
No more so than simply configuring ssh with decent passwords or public
key auth. These "brute force attacks" are succeeding with passwords like
"password" or "guest", not "[EMAIL PROTECTED](". IMO, it's a lot more
sensible to spend a little time preventing obviously poor system
configuration than to erect complicated workarounds for same.
You seem to have this belief that someone contacting an ssh server is,
in itself, bad. That's silly. At any rate, you seem enamoured of your
scheme. Have fun with it, but don't expect it to take of.
Are you saying that anyone can generate a data packet that will correctly
decode with *my* public key?
It doesn't matter for an attack aimed at your decryption routine.
Assuming that there are, and will never be, any vulnerability in the
crypto itself you've done nothing more than reimplement ssh's public key
auth in a byzantine fashion.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Idea to secure ssh [was: howto block ssh brute-force]
Neal Murphy said: > The point is to obscure the ssh server from everyone, including those who > are authorized to access it remotely. You're right, this is just the old idea of "security by obscurity". > The point is to reduce brute-forace attacks to the point of nearly total > ineffectiveness. The point is to require a small amount of > pre-authentication before the server acknowledges the client's attempt > to connect. How small can any _reliable_ authentication protocol be? Either it's at risk by brute-force or by denial-of-service. Michel -- $ rpm -q --whatrequires linux no package requires linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Idea to secure ssh [was: howto block ssh brute-force]
On Monday 13 March 2006 20:07, Michael Stone wrote: > On Mon, Mar 13, 2006 at 03:03:24PM -0500, Neal Murphy wrote: > >The idea is to present information to the server that only the server can > >decrypt, and that, in theory, only the authorized user could have > > generated. > > Much like an authentication system. What's the point of all this over > just authenticating via ssh? Sounds like a ridiculously complicated and > error-prone method to reduce log entries. And realistically you'd want > to log attempts to brute force this mechanism, right? The point is to obscure the ssh server from everyone, including those who are authorized to access it remotely. The point is to reduce brute-forace attacks to the point of nearly total ineffectiveness. The point is to require a small amount of pre-authentication before the server acknowledges the client's attempt to connect. And because UDP packets are allowed, the server can log brute-force attempts and firewall off attackers long before they have a chance of hitting the right combination that lets them in. Consider someone like Helen Keller. You could shout at her, sign at her, sempahore her forever and she would never acknowledge you. Only by touching her would you get her attention. Yet if she didn't recognize the touch, she still needn't acknowledge you. When you visit someone's home, do you knock on random parts of the house? I'm betting you typically knock on the door or ring the doorbell, because those are the obvious civilized ways of gaining access to the home. Similarly with current ssh servers, the obvious place to knock is its door: the well-known port 22; it's also the obvious place to find a lock to pick. Even changing the port to something else isn't that good, because a port scan will eventually find the port, just as walking around an ordinary house will make the location of its door obvious. > >Yes, allowing UDP packets in is, in a sense, an open port, but it's a > > one-way port. UDP packets have a fixed maximum size and the information > > carried in the packet is trivial in nature; UDP packets are generally > > benign. It's a given that anyone who knows the server's public key can > > generate an encrypted packet, but only an authorized user can correctly > > generate the encrypted parts inside the encrypted packet. > > No, anyone can generate encrypted parts. IMHO, there's not much chance > that the decryption routines in your magic udp parser are going to be > less vulnerable than those in openssh itself. Having "two layers of > Having "two layers of encryption" in this context is fairly pointless. > Why not use three layers, or four? What analysis demonstrates a > demonstrable return for that second layer, weighed against the cost of > this kooky mechanism? If you really need multiple encryption layers, do > it right and use an existing standard like ipsec rather than inventing a > convoluted "secret method". Are you saying that anyone can generate a data packet that will correctly decode with *my* public key? That anyone can generate a data packet that can be decoded with a server's private key using something other than the server's public key? I was under the impression that the probability of anyone being able to create either half of a key-pair that will work with an existing other-half was pert near zero. If ssh's key-pair encryption scheme is that weak, ssh needs to be retired. Based on the strength of ssh's key-pair scheme, I concluded that the data encrypted with the user's private key is reasonable assurance that the data came from the the true source, not a forger. The reason for encrypting the whole packet with the server's public key is to prevent eavesdropping, benign or malicious. Thus the dual encryption is not pointless. The point of this pre-authentication is to allow the server to decide whether or not to talk to the client before any packets are sent to the client. Remember, connecting to an ssh server involves setting up a TCP connection, which involves bidirectional packet transmission before any ssh protocol data are transferred. UDP eliminates that initial bidirectional transmission. Integrating the firewall into the process almost completely prevents unwanted ssh traffic. N -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Idea to secure ssh [was: howto block ssh brute-force]
On Mon, Mar 13, 2006 at 03:03:24PM -0500, Neal Murphy wrote: The idea is to present information to the server that only the server can decrypt, and that, in theory, only the authorized user could have generated. Much like an authentication system. What's the point of all this over just authenticating via ssh? Sounds like a ridiculously complicated and error-prone method to reduce log entries. And realistically you'd want to log attempts to brute force this mechanism, right? Yes, allowing UDP packets in is, in a sense, an open port, but it's a one-way port. UDP packets have a fixed maximum size and the information carried in the packet is trivial in nature; UDP packets are generally benign. It's a given that anyone who knows the server's public key can generate an encrypted packet, but only an authorized user can correctly generate the encrypted parts inside the encrypted packet. No, anyone can generate encrypted parts. IMHO, there's not much chance that the decryption routines in your magic udp parser are going to be less vulnerable than those in openssh itself. Having "two layers of Having "two layers of encryption" in this context is fairly pointless. Why not use three layers, or four? What analysis demonstrates a demonstrable return for that second layer, weighed against the cost of this kooky mechanism? If you really need multiple encryption layers, do it right and use an existing standard like ipsec rather than inventing a convoluted "secret method". Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Idea to secure ssh [was: howto block ssh brute-force]
On Monday 13 March 2006 09:38, [EMAIL PROTECTED] wrote: > On Mon, Mar 13, 2006 at 03:19:30AM -0500, Neal Murphy wrote: > > It seems kind-of counterproductive to set up SSH for secure access, then > > advertise to the universe that it's there. Thus my idea: > > > > Consider: > > - sshd listens on a pre-shared UDP port for 'a knock on the door', > > specifically a client requesting access. > > - using the server's pre-shared public key, the client has encrypted a > > packet that contains the user id in plaintext and the user's hostname > > encrypted with the user's private key. > If you don't put in a timestamp and require the server to reject > packets with badly out-of-sync timestamps, you are vulnerable to > a replay attack here. And leaving the user id in plaintext means > that a packet sniffer can gather valid hostnames, so now any > machine can construct a valid packet. I was afraid my description would be less than clear. The timestamp is a good point, but you missed the double encryption. Perhaps this will be clearer: - the client builds a packet that contains the user id in plaintext, and the hostname, IP address and a timestamp encrypted with the user's private key. - the client then encrypts the packet with the server's public key and sends it to the server's UDP port. The idea is to present information to the server that only the server can decrypt, and that, in theory, only the authorized user could have generated. When the server receives the UDP packet, it decrypts it using its private key, and then decrypts the hostname, IP address and timestamp using the user's public key. Only if the user has allowed the hostname, the IP address specified matches the address on the received packet, and the timestamp is current, will the server then let the user in. And at this point, the user still has to go through the normal SSH connection and authentication process. > > - if the server can decrypt the packet, decrypt the hostname and match > > the userid to the hostname, it would then request that iptables allow > > that client host to access the normal SSH TCP port. > A basic question of security: if everyone did it, would we be > more or less secure? > > In this case, if everyone used this scheme, we wouldn't be any > more or less secure. We would be more secure, because the server will only listen to clients until and unless they authenticate themselves. The server can selectively stop listening to bothersome forgers. Hostname/IP addr spoofing won't work unless the forger has obtained the correct matching username and private key. If you aren't authorized to access a system, you'll never know if the system allows remote access, because the server will never speak to you. > > My idea is akin to a monastery that has no visible way in or out. If > If that's all you want, port-knocking is a simpler, easier > solution. If all I wanted was security-through-obscurity, I wouldn't have bothered communicating my thoughts. However, as I said, I want to integrate security-through-obscurity, security-through-encryption, security-through-authentication and security-through-firewalling. Port-knocking (as defined in wikipedia) doesn't necessarily have authentication built in. As a tangible example, I can observe someone using a secret knock, then duplicate that knock. I may not get in on the first try, but the knock causes the guard to open the little viewport to see who's there. My scheme requires a degree of authentication before the viewport is opened. Yes, allowing UDP packets in is, in a sense, an open port, but it's a one-way port. UDP packets have a fixed maximum size and the information carried in the packet is trivial in nature; UDP packets are generally benign. It's a given that anyone who knows the server's public key can generate an encrypted packet, but only an authorized user can correctly generate the encrypted parts inside the encrypted packet. > > Does this scenario make any sense at all? It is a minimal amount of extra > > processing, yet would tighten security dramatically. But it would require > I'm sorry, it doesn't tighten security specifically, and... It does, but you missed the two layers of encryption. > > integrating sshd with iptables. Perhaps an iptables daemon is required, > > as > this makes it non-portable to other OS. Quite true. But I'd've thought that, when security is a concern, the rule would be security first, portability second. Other OSen that don't have firewalls just can't be secured as well as OSen with firewalls, can they? > > I'd also like to have sendmail be able to tell iptables to lock known > > spammers out of the system completely: no access whatever; even better > > would be to have a multicast feed from trusted RBL maintainers to keep > > known spammers locked out to begin with. > It's probably better to have a standard method for applications > to request additions to a blacklist. Why don't y
Re: Idea to secure ssh [was: howto block ssh brute-force]
On Mon, Mar 13, 2006 at 03:19:30AM -0500, Neal Murphy wrote: > It seems kind-of counterproductive to set up SSH for secure access, then > advertise to the universe that it's there. Thus my idea: > > Consider: > - sshd listens on a pre-shared UDP port for 'a knock on the door', > specifically a client requesting access. > - using the server's pre-shared public key, the client has encrypted a > packet that contains the user id in plaintext and the user's hostname > encrypted with the user's private key. If you don't put in a timestamp and require the server to reject packets with badly out-of-sync timestamps, you are vulnerable to a replay attack here. And leaving the user id in plaintext means that a packet sniffer can gather valid hostnames, so now any machine can construct a valid packet. > - if the server can decrypt the packet, decrypt the hostname and match the > userid to the hostname, it would then request that iptables allow that > client host to access the normal SSH TCP port. > - the client would wait a short period of time (perhaps a second), then try > to access the normal TCP sshd port. Perhaps it can try three times in 10 > seconds before giving up. > - as an added measure, if the daemon notices a brute-force attack in > progress, it can request iptables to drop the attacker's UDP packets > on the floor, too. > > The main advantage to this is that anyone trying to improperly access the > system via SSH would never know if the system is actually running an SSH > daemon - its port is firewalled off, and the daemon's only response to the > UDP packet is either to let the client host in through the firewall, or not > let the client in. A basic question of security: if everyone did it, would we be more or less secure? In this case, if everyone used this scheme, we wouldn't be any more or less secure. > My idea is akin to a monastery that has no visible way in or out. If someone > wants in, he has to know where to knock, using the Super Secret Squirrel > coded knock. Then he has to wait a bit before he tries to pass his > credentials and hand through the wall. If he still passes muster (ID is OK > and his fingerprints match), he is then allowed to pass through the wall. If > he doesn't know the coded knock to begin with, he'll pass right by the > monastery, never seeing it. If that's all you want, port-knocking is a simpler, easier solution. > Does this scenario make any sense at all? It is a minimal amount of extra > processing, yet would tighten security dramatically. But it would require I'm sorry, it doesn't tighten security specifically, and... > integrating sshd with iptables. Perhaps an iptables daemon is required, as this makes it non-portable to other OS. > I'd also like to have sendmail be able to tell iptables to lock known > spammers out of the system completely: no access whatever; even better would > be to have a multicast feed from trusted RBL maintainers to keep known > spammers locked out to begin with. It's probably better to have a standard method for applications to request additions to a blacklist. Why don't you work on that? -dsr- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Idea to secure ssh [was: howto block ssh brute-force]
Hi Guys, > [...] I use fail2ban and I'm very happy with it. Just my 2 cents, regards, johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Idea to secure ssh [was: howto block ssh brute-force]
* Neal Murphy <[EMAIL PROTECTED]> [2006-03-13 03:19 -0500]: > Consider: [...] Sounds like putting http://ingles.homeunix.org/software/ost/ into ssh(d). Nicolas -- http://www.rachinsky.de/nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Idea to secure ssh [was: howto block ssh brute-force]
On Mon, Mar 13, 2006 at 03:19:30AM -0500, Neal Murphy wrote: [...] > My idea is akin to a monastery that has no visible way in or out. If someone > wants in, he has to know where to knock, using the Super Secret Squirrel > coded knock. Then he has to wait a bit before he tries to pass his > credentials and hand through the wall. If he still passes muster (ID is OK > and his fingerprints match), he is then allowed to pass through the wall. If > he doesn't know the coded knock to begin with, he'll pass right by the > monastery, never seeing it. [...] This is basically port knocking: http://en.wikipedia.org/wiki/Port_knocking -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
