SSHD veilig maken (controle)

[Zware Unit]

Sinds een tijdje heb ik een OpenBSD server draaien in een testomgeving. Nu ben ik op zoek hoe ik de sshd server zo veilig mogelijk maak.

hieronder het sshd_config bestand:
------------------------------------------------------------------------------------------------
# $OpenBSD: sshd_config,v 1.59 2002/09/25 11:17:16 markus Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

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

# Logging
#obsoletes QuietMode and FascistLogging
SyslogFacility AUTH
LogLevel INFO

# Authentication:

LoginGraceTime 120
PermitRootLogin yes (keuze die ik heb gemaakt!!!!)
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# rhosts authentication should not be used
#RhostsAuthentication no
# 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/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
PermitEmptyPasswords no

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

# Kerberos options
KerberosAuthentication no
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

#AFSTokenPassing no

# Kerberos TGT Passing only works with the AFS kaserver
#KerberosTgtPassing no

#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
KeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
Compression yes

#MaxStartups 10
# no default banner path
#Banner /some/path
#VerifyReverseMapping no

# override default of no subsystems
Subsystem sftp /usr/libexec/sftp-server
---------------------------------------------------------------------------------------------------
Wat moet ik aanpassen om de veiligheid te verbeteren, of wie heeft er een duidelijke how-to (heb gezocht) van het configuratiebestand voor mij?

[2P]

De standaard instellingen zijn veilig.

Het enigste wat ik zou veranderen is de PermitRootLogin op "No".
Maar blijkbaar wil je die graag op "Yes" hebben

[Leon]

even een vraagje wat hier ook mee te maken heeft:

staat Privilege Separation standaard aan tegenwoordig of moet je dat specifiek aanzetten

[2P]

Leon schreef op 01 december 2002 @ 03:08:
even een vraagje wat hier ook mee te maken heeft:

staat Privilege Separation standaard aan tegenwoordig of moet je dat specifiek aanzetten

Die staat vanaf 3.4 standaard aan.

[Wasp]

man sshd_config

[Verwijderd]

Vervang '#Protocol 2,1' door 'Protocol 2' zodat je gebruikers alleen ssh2 kunnen gebruiken, ssh1 is zo veilig niet meer. Alle moderne ssh-clients kunnen zowel ssh1 als ssh2 dus dat is geen probleem meer.

[Verwijderd]

man sshd_config -> check deze flags:
AllowUsers (alleen users die 't mogen erin pleuren)
ListenAddress (alleen op IP's luisteren waar 't op nodig is en naar localhost SSHen is betrekkelijk nutteloos)
Banner (disclaimer erin dat 't gelogged wordt en dat access alleen toegesaan is voor system personel oid)
UsePrivilegeSeparation (aan laten staan!)

Mocht-ie extern luisteren:
man pf.conf
firewall alle traffic op port 22 eruit en zeg dat alleen bepaalde IP's mogen SSHen.

Mocht je SSHen vanaf een bak die je niet vertrouwt (trojanned SSH!) gebruik dan S/Key

[Verwijderd]

Een duidelijke aanrader is het opnieuw en handmatig compilen van je SSH deamon. Circulerende exploits maken gebruik van offsets die gemaakt zijn voor (en getest zijn op) standaard RPM's (zoals die op rpmfind.net) te vinden zijn.

Mocht je de kennis hiervoor niet in huis hebben of lijkt je het niet de moeite waard zet dan in je ssh_config alle optie's uit die je niet gebruikt. Zoals misschien wel:

RSAAuthentication
PubkeyAuthentication
KerberosAuthentication
KerberosOrLocalPasswd
KerberosTicketCleanup
en het sftp subsystem

De code hiervoor word dan ook niet geladen en eventuele bugs erin zijn niet op jou van toepassing.

success

[Verwijderd]

Verwijderd schreef op 01 december 2002 @ 23:03:
Een duidelijke aanrader is het opnieuw en handmatig compilen van je SSH deamon. Circulerende exploits maken gebruik van offsets die gemaakt zijn voor (en getest zijn op) standaard RPM's (zoals die op rpmfind.net) te vinden zijn.

Zou je dat wat verder uit kunnen leggen, want zoals ik het nu lees krijg ik het idee dat volgens jouw zelf gecompileerde versies veiliger zijn dan RPM's. Of heb je het over oudere versies van openssh?

[Verwijderd]

Inderdaad, alle exploits die geschreven worden voor bepaalde bugs zijn geoptimaliseerd voor alle 'standaard' versie's van deze packages. Als voorbeeld neem ik de CRC32 bug in OpenSSH 1.2.27-31 (en verder). De eerst circulerende exploit hadden vooraf geimplementeerd offsets voor de default RPM's van Redhat. Enkele weken later verschenen er versie's met targets van andere distro's en wat standaard implementatie's van andere OS's (F-Secure, Cisco etc). Pas enkele maanden na dato waren er versie's met honderden verschillende offsets voor honderden verschillende (door steeds iemand anders gecompile'de) versie nummers.

Je hebt wat minder kans om meegenomen te worden in de grote massa, mensen die ./scan 0.0.0.0 - 255.255.255.255 --portje=22 lopen bij jou dan tegen een muur aan omdat de offsets niet overeenkomen met de standaard RPM die duizenden mensen gebruiken. Jij als kleine gebruiker bent het dan niet waard een paar uur op de zitten bruteforcen.

groeten

[Verwijderd]

Verwijderd schreef op 02 December 2002 @ 09:53:
Inderdaad, alle exploits die geschreven worden voor bepaalde bugs zijn geoptimaliseerd voor alle 'standaard' versie's van deze packages. Als voorbeeld neem ik de CRC32 bug in OpenSSH 1.2.27-31 (en verder). De eerst circulerende exploit hadden vooraf geimplementeerd offsets voor de default RPM's van Redhat. Enkele weken later verschenen er versie's met targets van andere distro's en wat standaard implementatie's van andere OS's (F-Secure, Cisco etc). Pas enkele maanden na dato waren er versie's met honderden verschillende offsets voor honderden verschillende (door steeds iemand anders gecompile'de) versie nummers.

Hmm, ok, je hebt het dus inderdaad over oude versies zoals ik al verwachte. Hoewel je in dit specifieke voorbeeld gelijk hebt is het natuurlijk nooit slim om een oude versie van openssh met een welbekende bug te draaien. Dat is vragen om problemen zelfs als je een zelf gecompileerde versie draait. Bovendien had je dan waarschijnlijk als je zelf had gecompiled de backdoor draaien die recenter in het configure script van openssh zat.

Kortom software up to date houden is absoluut noodzakelijk, maar om nu maar gelijk te verkondigen dat zelf gecompileerde versies veiliger zijn vind ik een beetje kort door de bocht.

[Verwijderd]

tuurlijk moet je up-to-date blijven, heb nooit het tegendeel beweert. Maar het zelf opnieuwe compilen (in binarie of rpm vorm) in tegenstelling tot rpm -Uvh rpmetjevanrpmfind.net houd je uit de 'grote stroom' waar de meeste wormen/autorooters/exploits voor geschreven worden.

Niet iedereen heeft die 99% zekerheid nodig maar voor degene die net dat procentje meer willen is het een aanrader.

met vriendlijke groet, joep

[Verwijderd]

Verwijderd schreef op 02 december 2002 @ 12:43:
met vriendlijke groet, joep

Trouwens welkom op GOT

Wij tweakers doen elkaar permanent de groeten. Het is dus niet nodig om steeds ruimteverspillende "greetz [user]" of iets dergelijks onder je posts te plakken. Als je per se zoiets wilt kun je daar je signature voor gebruiken.

[Verwijderd]

Haha, dank je Ik zal er aan denken ....

[Verwijderd]

In het kader van obfuscation is het ook nog een idee om de version identifier van je openssh aan te passen (wat je ziet als je telnet <eenhost> 22 doet). Standaard staat deze op SSH-x.y-OpenSSH-a.b.c.

Open version.h, en je kunt alles behalve SSH-x.y editen. Mijn "standaard" string is "SSH-2.0-Hi_there_:P"

(En voor diegene die het nog niet geroepen hadden, als je sshd gelinked is met tcpwrappers kun je /etc/hosts.{allow|deny} nog editen, en als je ssh gecompiled is met PAM, stel ik eens voor dat je de howto's daarvan doorleest )

[ Voor 42% gewijzigd door Verwijderd op 02-12-2002 13:37 ]

[Verwijderd]

Verwijderd schreef op 02 december 2002 @ 13:33:

Open version.h, en je kunt alles behalve SSH-x.y editen. Mijn "standaard" string is "SSH-2.0-Hi_there_:P"

Had ik eerst ook. Dit breaked toch een aantal zaken. Weet niet meer precies wat, helaas, maar ik heb wel besloten het weer terug te zetten.

[2P]

Verwijderd schreef op 02 December 2002 @ 13:33:
Open version.h, en je kunt alles behalve SSH-x.y editen. Mijn "standaard" string is "SSH-2.0-Hi_there_:P"

Dat moet je dus nooit doen.

De banner maakt deel uit van het SSH protocol en vertelt welke versies aanvaardbaar zijn voor de clients en op welke manier de server met de client communiceert. De banner is nodig omdat vele SSH implementaties zich anders gedragen.

Het veranderen/verbergen ervan is "security by obscurity"... je kan beter je tijd besteden aan het up2date houden van SSH

[ Voor 4% gewijzigd door 2P op 02-12-2002 19:14 ]

[miniBSD]

Ik zou de optie voor het chroot'en van gebruikers nemen:

http://sourceforge.net/projects/chrootssh/
http://mail.incredimail.com/howto/openssh/

en de optie voor ssh-1 uitzetten.

[Verwijderd]

miniBSD schreef op 02 december 2002 @ 19:33:

http://sourceforge.net/projects/chrootssh/.

"This Project Has Not Released Any Files". Hmm.

Ik vond dit project wel interessant:
http://www.math.ualberta.ca/imaging/snfs

Secure NFS: NFS over SSH. Maar nog niet geprobeerd.

[Zware Unit]

Zijn er Sites die checken (gratis) of je SSH deamon save is?

Verder hoe kan ik het voor een gebruiker onduidelijk maken welke server er achter een poort draait. Dus dat een script moeite heeft met het ontdekken van de versie die ik gebruik!

[Zware Unit]

heb via securityspace.com nogmaals een test gedaan en nu geeft hij aan dat de ssh deamon nu wel goed staat ingesteld. Protocol versie 1 geeft hij inderdaad aan als een gevaar. Nu hij alleen nog maar protocol 2 accepteerd is hij wel secure

Heb het zelf ook nog effe gechecked met putty (protocol 1 dan) en dan geeft hij inderdaad aan dat de server alleen protocol 2 accepteerd!

Prima.


Heb nog een vraagje:
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

wat moet ik hiermee doen. Heb hem nu op de RSA_KEY staan namelijk. Wat is het verschil? heeft iemand hier ervaring mee?

[Verwijderd]

Waarom zou je zo'n bedrijf vertrouwen om dat te analyseren -en daarbij je email adres weggeven voor spam-? Gebruik je eigen gezonde verstand: leer je meer van en biedt meer zekerheid. Je hebt de manuals van SSH. Je hebt sites die er uitleg over geven. Je hebt Google. Dat het wat meer tijd kost heeft wel positieve gevolgen voor je eigen ervaring, intelligentie mbt. SSH security. De volgende keer loop je weer naar die site toe terwijl je 't zelf ook had kunnen doen dmv. eerdere ervaringen.

[Verwijderd]

Ik denk dat je altijd twee verschillende situatie's in je hoofd moet houden:

1) een situatie waarbij er nog te updaten valt
2) een situatie waarbij je helemaal up-to-date bent

In eerste instantie ga je ervanuit de als er geen nieuwe updates beschikbaar zijn, dan het product perfect veilig is en je niets kan gebeuren. In deze perfecte situatie zou dus je dus geen extra maatregelen hoeven te treffen om je te onderscheiden van de rest. Omdat iedereen toch up-to-date is.

In de tweede situatie kan heb je de nieuwste updates van ssh op je machine staan maar moet je erwel van uit gaan dan het OpenSSH core team op de hoogte is van alle bugs? Ik denk van niet, vele bugs zijn weken, soms wel maanden eerder bekent bij die gene die kwaad willen. Wat extra maatregelen om ervoor de zorgen dat jij niet een van gelukkige bent die megenomen word in de massa van een grote scan op poortje 22 zouden dus niet misstaan.

Vergeet niet dat in de tijd van de bugs in wuftpd 2.4.0/2.6.0 en de ssh CRC32 bug honderd duizenden hosts al binnen gedrongen waren voordat er ook maar iets van een patch beschikbaar kwam.

- Het draaien op een andere poort als 22
- Het afschermen van ip's
- Het aanpassen van je banner (mits je client hierdoor nog goed functioneerd)
- Het gebruiken van keys
- Het gebruiken van de mogenlijkheden van de Pluggable Authentication Modules
- Misschien wel gebruik maken van OPIE

Probeer je in ieder geval te onderscheiden uit de grote massa, want die zijn leuk voor die die er op uit zijn om 200.000 machine's toe te kunnen voegen aan het 'stacheldraht' ...

[avatar]

al eens gekeken naar Systrace onder openbsd? daarmee kun je heel nauwkeurig instellen welke systemcalls je binarie wel en niet mag uitvoeren.

Kijk een op
http://blafasel.org/~floh//he/
Daar bouwen ze een repository voor een aantal standaard systrace policies.

[Verwijderd]

2P schreef op 02 december 2002 @ 19:14:
[...]

Dat moet je dus nooit doen.

De banner maakt deel uit van het SSH protocol en vertelt welke versies aanvaardbaar zijn voor de clients en op welke manier de server met de client communiceert. De banner is nodig omdat vele SSH implementaties zich anders gedragen.

Het veranderen/verbergen ervan is "security by obscurity"... je kan beter je tijd besteden aan het up2date houden van SSH

eerrmmm, alleen de eerste 7/8 bytes van deze string zijn significant. Deze bepalen welk protocol (1, 1.99 of 2) er gebruikt word. De rest van de string is een vendor identifier. Nadat de client heeft gelezen welk protocol de ssh server gebruikt, word er een crypto handshake gedaan.
Zelf heb ik op verscheidene unix/kloon platformen ({f|o}bsd, irix, solaris en lnx) deze string aangepast, en totaal nog geen enkel probleem tegengekomen. Zelfs niet met windows clients Uiteraard dien je ook je services te updaten, maar dat spreekt voor zich.
De reden dat ik deze string aanpas, is dat behalve de ssh client/server, ook (bijna) alle ssh exploits naar deze string kijken. Sommige platformen zijn ook aan de hand van deze string te identificeren (denk freebsd en debian), dus zie ik eigenlijk geen reden om het niet te doen...

[Zware Unit]

Hoe kan ik het beste deze string aanpassen?

[serkoon]

In sshd_config: VersionAddendum <blaat>

Weet wel dat je hierdoor beheer wel eens kunt bemoeilijken, net zo goed als kiddies niet meer kunnen zien welke precieze versie (onder fbsd staat daar een datum in) je sshd heeft, je kunt het zelf ook niet meer remote zien. Verder zie ik zelf ook geen probleem

[Verwijderd]

Mijn standaard Debian package van openssh accepteert "VersionAddendum" niet in zijn sshd_config file. Moet ik bij het compilen een optie voor meegeven of moet dit gewoon standaard werken?

[DiedX]

Idem hier. Debian 3.0...

[DDX]

hmms hier ook niet (srpm van openssh.org)

Starting sshd:/etc/ssh/sshd_config: line 94: Bad configuration option: VersionAddendum
/etc/ssh/sshd_config: terminating, 1 bad configuration options

ook niets over te vinden in man sshd_config ?

ook misschien verstandig om uit te zetten :

Subsystem sftp /usr/libexec/openssh/sftp-server

(staat volgens mij vaak standaard aan)
ftp'en doe je maar lekker met proftpd (over ssh)
dan is er tenminste ook keurig logfile en config opties

[2P]

VersionAddendum is een FreeBSD-only feature.

vries335 schreef op 09 december 2002 @ 22:25:
Hoe kan ik het beste deze string aanpassen?

Niet...

Maar als je het toch zo graag wil: check in de source voor de file version.h en pas het naar wens aan (op eigen risico!).

[Verwijderd]

http://www.onlamp.com/pub...11/28/FreeBSD_Basics.html

[Verwijderd]

2P schreef op 10 december 2002 @ 00:43:
VersionAddendum is een FreeBSD-only feature.
Niet...

Maar als je het toch zo graag wil: check in de source voor de file version.h en pas het naar wens aan (op eigen risico!).

Nou begin ik toch nieuwschierig te worden, wat zijn dan volgens jou de risico's van het aanpassen van deze string?

[ Voor 14% gewijzigd door Verwijderd op 10-12-2002 12:06 ]

[2P]

Verwijderd schreef op 10 December 2002 @ 12:05:
[...]


Nou begin ik toch nieuwschierig te worden, wat zijn dan volgens jou de risico's van het aanpassen van deze string?

Een niet (goed) werkende SSHd...

[Verwijderd]

Zoals? Wat werkt er niet dan? Worden er opeens minder encryptie algoritmen gebruikt? Wat breekt er precies?

<dit is dus geen flame oid, gewoon interesse, sinds dat ik hier dus nog nooit probs mee heb gehad, en het daarom nogal raar vind dat je deze wijziging afkeurt>

[ Voor 14% gewijzigd door Verwijderd op 10-12-2002 13:30 ]

[Zware Unit]

Het kan in ieder geval geen kwaam om sftp-server uit te zetten. Gebruik inderdaad ook ProftpD met ssh

[2P]

Verwijderd schreef op 10 December 2002 @ 13:30:
Zoals? Wat werkt er niet dan? Worden er opeens minder encryptie algoritmen gebruikt? Wat breekt er precies?

Toen ik dit probeerde had ik slechts een heel klein stukje van de string weggehaald (OpenSSH versie geloof ik). Als resultaat kreeg ik een sshd waar ik niet op kon inloggen. Nu is dit wel een tijdje geleden en op een vrij oude openssh versie (2.9 ofzo).
Misschien kan het tegenwoordig wel zonder problemen worden aangepast, maar ik denk dat oudere clients er wel problemen mee hebben.

Dus, dat het bij jou gewoon werkt kan best, maar ik had er zelf niet een al te beste ervaring mee

[Verwijderd]

vries335 schreef op 10 December 2002 @ 20:59:
Het kan in ieder geval geen kwaam om sftp-server uit te zetten. Gebruik inderdaad ook ProftpD met ssh

Moet jij weten.... via sftp is het encryted.

[Verwijderd]

Sterker nog, op precies dezelfde manier (met dezelfde crypto backend) als waneer je sftp gebruikt. Hmz, mischien maar een benchmark doen thuis

[Verwijderd]

Verwijderd schreef op 11 December 2002 @ 12:01:
Sterker nog, op precies dezelfde manier (met dezelfde crypto backend) als waneer je sftp gebruikt. Hmz, mischien maar een benchmark doen thuis

Klopt. Toch zijn er wel redenen om FTP te gebruiken. Bijv. PureFTPd kun je toch anders instellen dan OpenSSH. Zo heeft PureFTPd LDAP support. Voor OpenSSH zijn daar patches voor, accoord, maar die werkt zeker niet zo goed als de PureFTPd support. Zo kun je met PureFTPd het password in de LDAP DB zetten. Daarnaast support PureFTPd een boel DB's terwijl afaik OpenSSH alleen een patch heeft voor LDAP database.

Ik noem even PureFTPd als voorbeeld hetzelfde geld voor ProFTPd bovendien is dit slechts een voorbeeld. Tegenovergestelde is ook waar: OpenSSH heeft features die FTPd's niet hebben. Mogelijke tussenoplossing: FTP via SSL aanbieden.

[ Voor 6% gewijzigd door Verwijderd op 11-12-2002 12:20 ]

[Verwijderd]

Mee eens, hetgeen waar het mij om ging, is of ftp+ssh sneller is dan sftp (of scp)....

[Verwijderd]

Verwijderd schreef op 11 December 2002 @ 12:42:
Mee eens, hetgeen waar het mij om ging, is of ftp+ssh sneller is dan sftp (of scp)....

Verschilt uiteraard per bak. Misschien heb je hier iets aan:
http://marc.theaimsgroup....v&w=2&r=1&s=benchmark&q=b