[ssh2] Verbindingen beveiligen

[The Specialist]

Op mijn werk zijn we bezig met het online zetten van ons huidige klanten systeem. Hiertoe hebben we een oude ongebruikte server ingericht met Debian Linux v3.1 r0a Sarge, en nog enkele paketten zoals apache etc.

Uiteraard willen we de boel eerst lokaal testen. Deze server hangt in de serverruimte en dient dus vanaf afstand (binnen het LAN) benaderd te worden voor configuratie etc. Dit doen we via SSH.
Nu heb ik al vaker gehoord van het afschermen van verbindingen middels RSA sleutels etc, maar het wordt me er niet duidelijker op. Ik heb reeds vele websites afgestruind op zoek naar nuttige informatie wat betreft het opzetten van de server met behulp van sleutel verificatie, zodat alleen de gebruikers met de juiste sleutel in kunnen loggen, ook al hebben ze een gebruikersnaam met wachtwoord.
De websites die ik heb gevonden springen na de 1e inleidende alinea al gelijk in het diepe en worden dus voor een sshd-leek vrijwel onbegrijpelijk.
Is er iemand die mij kort en duidelijk uit kan leggen hoe ik mijn ssh-server (sshd) moet beveiligen met keys zodat alleen degene met de correcte key in kan loggen?

Kopie van sshd_config:

code:

# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Change to yes to enable tunnelled clear text passwords
PasswordAuthentication no


# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no

# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
KeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

Subsystem   sftp    /usr/lib/sftp-server

UsePAM yes

[ Voor 45% gewijzigd door The Specialist op 01-11-2006 14:59 ]

[DemonTPx]

Is een correcte combinatie van username en password niet genoeg dan? Verder zou je kunnen kijken naar whitelisting. En zou ik standaard PermitRootLogin op false zetten.

[The Specialist]

DemonTPx schreef op woensdag 01 november 2006 @ 14:57:
Is een correcte combinatie van username en password niet genoeg dan? Verder zou je kunnen kijken naar whitelisting. En zou ik standaard PermitRootLogin op false zetten.

In principe wel, maar zodra hij aan internet hangt en ook vanaf afstand beheerd moet kunnen worden wil ik dat toegang zo goed mogelijk beveiligd is. Uiteraard is toegang vanaf internet met SSH alleen mogelijk gedurende de testfase, hierna zal hij alleen nog via het LAN bereikbaar zijn met SSH.

[Verwijderd]

The Specialist schreef op woensdag 01 november 2006 @ 15:01:
[...]

In principe wel, maar zodra hij aan internet hangt en ook vanaf afstand beheerd moet kunnen worden wil ik dat toegang zo goed mogelijk beveiligd is. Uiteraard is toegang vanaf internet met SSH alleen mogelijk gedurende de testfase, hierna zal hij alleen nog via het LAN bereikbaar zijn met SSH.

Als je het helemaal veilig wil, gebruik dan ook de tcpwrapper functionaliteit van sshd, door in /etc/hosts.allow te specificeren welke hosts allemaal toegang tot sshd mogen krijgen, de rest dropt ie gewoon zonder zelfs maar mee te communiceren.

Voorbeeld van /etc/hosts.allow:

code:

ALL : 127.0.0.1 : allow
sshd: 12.23.45.150 : allow
sshd : 83.0.0. : allow
ALL : ALL : deny

[Verwijderd]

Afgezien van de AllowUser en AllowGroup statements in sshd_config moet je het volgende doen om keys te genereren:

code:

user@client$ ssh-keygen -b 1024 -t dsa -f ~/.ssh/een_naam_voor_je_key
< 2 x wachtwoord invullen >
user@client$ scp ~/.ssh/een_naam_voor_je_key.pub user@server:
user@client$ ssh user@server
user@server$ mkdir .ssh
user@server$ mv een_naam_voor_je_key.pub .ssh/authorized_keys
user@server$ chmod -R go-rwx .ssh

Hierna log je uit, en kun je dmv onderstaande statement inloggen dmv ssh keys:

code:

ssh -i ~/.ssh/een_naam_voor_je_key user@server

[Verwijderd]

* andere poort kiezen dan 22 (security through obscurity, zeker niet op rekenen als enige maatregel)
* enkel protocol 2 toelaten
* UsePrivilegeSeparation yes
* PermitRootLogin no
* LoginGraceTime 30s
* MaxAuthTries 2
* AllowUsers gebruikersnaam
* Compression delayed
* MaxStartups 3
* met pubkey/private key werken, liefst RSA (op die manier kan een gebruiker enkel inloggen als hij/zij de key heeft EN het paswoord weet, en hoeft je paswoord ook niet over het netwerk te vliegen. zorg wel voor een sterk paswoord, 8+ karakters, case sensitive, met getallen en symbolen).
* sudo gebruiken
* meer linux kennis opdoen voor je met een publieke server gaat werken...

[ Voor 23% gewijzigd door Verwijderd op 01-11-2006 16:34 ]

[DiedX]

Volgens mij wil TS alleen maar weten hoe je password-authenticatie uit kan zetten.

Check in sshd.conf de directive PasswordAuthentication. Zet deze uit, NADAT je eerder bent ingelogd met bovenstaande methoden. Have fun

[Verwijderd]

Port 22 kun je gewoon laten staan, want security by obscurity is geheel geen beveiliging. Een simpele scanner is al in staat om de 'nieuwe' port binnen een no-time te vinden. De toepassing van de RSA-keys en sterkte passwords is redelijk voldoende voor een SSH-verbinding.

[Verwijderd]

Verwijderd schreef op woensdag 01 november 2006 @ 19:53:
Port 22 kun je gewoon laten staan, want security by obscurity is geheel geen beveiliging. Een simpele scanner is al in staat om de 'nieuwe' port binnen een no-time te vinden. De toepassing van de RSA-keys en sterkte passwords is redelijk voldoende voor een SSH-verbinding.

Als je ff goed gelezen had, zie je dat ik security by obscurity vermeld.
Het is idd geen vorm van beveiliging opzich, maar het is wel een klein extra laagje, zodat je bijvoorbeeld al niet elke dag 800 brute force pogingen op je sshd hebt.
Die kan je ook oplossen natuurlijk, maar dat terzijde.
Elk klein beetje dat je de boze wolf voor de voeten kan leggen is mooi meegenomen, imho.

[ Voor 6% gewijzigd door Verwijderd op 01-11-2006 20:24 ]

[nzyme]

toch moet het veranderen van de default poort niet helemaal afgedaan worden als nog-net-niet-zinloos, want de hackers/crackers scannen gewoon een hele range af op 1 poort. Als je dan ipv p22 p99 gebruikt voor ssh zal je dus niet op de scanresults komen. Bingo, "veilig" dus. Het is pas echt zinloos wanneer men een directe scan op je ip af zal vuren, maar dat is dan weer af te vangen dmv scanlogd. Die zal je keurig mailen wanneer er een poortscan plaats vindt.

Om dan nog even ontopic te reageren: iptables gebruiken om alleen een bepaald ip toegang te geven tot de ssh poort lijkt me naast "permitrootlogin false" de eerste maatregel die je moet treffen.

[DiedX]

nzyme schreef op woensdag 01 november 2006 @ 20:40:
Om dan nog even ontopic te reageren: iptables gebruiken om alleen een bepaald ip toegang te geven tot de ssh poort lijkt me naast "permitrootlogin false" de eerste maatregel die je moet treffen.

True,

Ik vind de security-by-obscurity een tikkie overbodig. Het grootste gedeelte van scans zal je van geroote servers zien, welke vervolgens misbruikt worden om te scannen. Het zal niet de eerste keer zijn dat iemand de user temp met wachtwoord temp heeft aangemaakt, met destraseuse gevolgen.

Ik heb zelf een fail2ban (oid) draaien, waarbij je na 5 keer aankloppen via de wrappers geband wordt. De permitrootlogin false is een eis

Het liefst ook een goede firewall, maar soms kan je daarin niet poort 22 blocken vanwege praktische redenen. Ik ben een tegenstander van de SSH-Pubkey methode (zonder passwords), omdat je dan niet altijd in kan loggen (of je moet o-ver-al je laptop naar toe slepen). Dan investeer ik liever in goede software om web-exploits te voorkomen.

[The Specialist]

Ik had natuurlijk nog niet vermeld dat mijn client een Windows machine met putty is. De eerder genoemde mogelijkheden om een rsa-key te maken wordt dus een beetje moeilijk. Kan ik deze handeling (op scp na wellicht) uitvoeren ook op de serverzijde?

[Verwijderd]

The Specialist schreef op woensdag 01 november 2006 @ 21:17:
Ik had natuurlijk nog niet vermeld dat mijn client een Windows machine met putty is. De eerder genoemde mogelijkheden om een rsa-key te maken wordt dus een beetje moeilijk. Kan ik deze handeling (op scp na wellicht) uitvoeren ook op de serverzijde?

Putty wordt geleverd met een hele hoop tools om keys aan te maken en uit te wisselen.
PuTTYgen, Pageant: http://www.chiark.greenend.org.uk/~sgtatham/putty/

[DemonTPx]

Ik kwam net dit tegen: http://thinkhole.org/wp/2...eps-to-a-more-secure-ssh/