Re: HEAD's UP: possible 0day SSH exploit in the wild
Bernd Eckenfels schrieb:
In article <[🔎] f971bab40907080937v33884e78nce8291d34140f3de@mail.gmail.com> you wrote:
Besides I dont think you can force both, its only one stage in ssh protocol.
But your login shell could ask for the password via Terminal. Maybe with pam..
I think, you can, when you are hacking the source code of the server,
but i'm not into the source code ...
If you try to connect with an invalid key, the server can fall back to
password authentication. This works transparently on the clients i use.
So you possibly can change the code of the server in this way:
- remember if there was a valid authentication by key, but deny it
- if there is a valid password authentication, only accept it, when you
remembered a valid key auth
I would not suggest this. It is confusing for the user. And in my
opinion, there are better solutions:
- let the server listen on another port
- use fail2ban
- put a fail2ban minefield around the other port
- drop invalid packets
- use port knocking
Yes, there are pros and cons.
I dont know a good port knocking server. The ones i testet had static
keys, what you don't want.
Better would be dynamic keys, maybe with first a knocking sequence by
time and later by password with answers on port knock daemon.
You could distribute working portknocking clients to your customers.
If you have windows customers, you can distribute putty-configurations
as reg-files.
Possibly this works with winscp to. At least you can take over
putty-configs to winscp in a rather hidden menu-button on the very first
startwindow.
http://en.wikipedia.org/wiki/Port_knocking
As an alternative to port knocking, you could use web based knocking,
which is more difficult to set up.
With knocking in general you lock the syn-packages on your ssh-port and
unlock it for a certain time, after receiving a valid knock-sequence an
another port-range.
However you set up. Keep one important thing in mind:
Try to manage your system in a way, that if an atacker cracked the
access of one customer, he can't affect changes on other customers.
That is not an easy task on ordinary web servers.
You always have customers, that are not sensible to security. And even
if your customers are smart, but have in spite of a cracked system, the
malware could record both there passwords and the passphrase of the
encrypted private key ...
If the malware was smart, it coul even get between you and the terminal
window, install it's own public key on the server and try to hide this
action from your cutomers by clearing the screen and closing the
connection. So just keep insecure customers from having influence on
your system or other customers.
Greeting,
Guntram
--
Guntram Trebs
freier Programmierer und Administrator
gt@trebs.net
+49 (30) 42 80 61 55
+49 (178) 686 77 55
Reply to: