Vraag Hoe een SSH-server uitharden?


Welke maatregelen kan / moet ik nemen om ervoor te zorgen dat de beveiliging rond mijn SSH-server absoluut ondoordringbaar is?

Dit zal vanaf het begin community wiki zijn, dus laten we zien wat mensen doen om hun servers te beveiligen.


119


oorsprong


Absolute ondoordringbaarheid vereist het uitschakelen van de doos. - Thorbjørn Ravn Andersen
Wat als u Wake-on-LAN hebt? - rebus
Het probleem zou het LAN-gedeelte zijn ... Wake-on-LAN-pakketten worden niet gerouteerd, dus zou u toegang moeten hebben tot een machine binnen het LAN om het WOL-pakket te verzenden ... - LassePoulsen
Voor sleutelverificatie kunt u de Ciphers beperken tot de cijfers die u echt nodig hebt.


antwoorden:


Gebruik publieke / private sleutelparen voor authenticatie in plaats van wachtwoorden.

  1. Genereer een wachtwoordzin-beveiligde SSH-sleutel voor elke computer die toegang moet hebben tot de server:

    ssh-keygen

  2. Sta openbare SSH-toegang toe vanaf de toegestane computers:

    Kopieer de inhoud van ~/.ssh/id_rsa.pub van elke computer in individuele regels van ~/.ssh/authorized_keys op de server of uitvoeren ssh-copy-id [server IP address] op elke computer waaraan u toegang verleent (u moet het serverwachtwoord achter de prompt invoeren).

  3. Schakel wachtwoord SSH-toegang uit:

    Open /etc/ssh/sshd_config, zoek de regel die zegt #PasswordAuthentication yes, en verander het in PasswordAuthentication no. Start de SSH-serverdaemon opnieuw om de wijziging toe te passen (sudo service ssh restart).

Nu is de enige mogelijke manier om SSH in de server te zetten, een sleutel te gebruiken die overeenkomt met een regel in ~/.ssh/authorized_keys. Met behulp van deze methode, ik Maak je niet druk om brute force-aanvallen, want zelfs als ze mijn wachtwoord raden, wordt het geweigerd. Bruut forceren van een publiek / privaat sleutelpaar is onmogelijk met de technologie van vandaag.


100



-1: Over het algemeen wordt toegang verleend aan individuele niet-computers. Het maken van een sleutel voor elke potentiële clientcomputer die verbinding maakt met de server is onredelijk. Uw laatste verklaring is niet correct, op basis van uw suggestie en omdat u niet hebt voorgesteld om een ​​wachtwoordzin in te stellen voor de toegang tot de SSH-server door de privésleutels die toegang hebben / compromitteren van een van de clientsystemen. SSH-sleutelauthenticatie wordt aanbevolen, maar de privésleutels moeten correct worden beschermd en deze moet op individuele basis worden gebruikt, niet op een gedistribueerde manier zoals beschreven. - João Pinto
"In het algemeen wordt toegang verleend aan individuele niet-computers, waardoor het maken van een sleutel voor elke potentiële clientcomputer die verbinding maakt met de server onredelijk is." Er zijn veel opties en het beschrijven van het veilig overbrengen van een privésleutel naar elke client lijkt buiten het bestek van deze vraag . Ik presenteer niet alle opties, alleen een eenvoudige optie waarvan ik denk dat mensen ze kunnen begrijpen. "... moet op individuele basis worden gebruikt, niet op een gedistribueerde manier zoals beschreven" Dit lijkt in tegenspraak met uw eerdere verklaring en ik heb niets beschreven als gedistribueerd. - Asa Ayers
"onmogelijk" is misschien een beetje overdrijven. - Thorbjørn Ravn Andersen
Dit is de reden waarom ik "onmogelijk" zeg. Niemand heeft zo veel computers zo snel, zo veel of zo veel tijd. "Stel je voor dat een computer zo groot is als een zandkorrel die toetsen kan toetsen aan sommige versleutelde gegevens. Stel je ook voor dat een sleutel kan worden getest in de hoeveelheid tijd die het kost om het over te steken. zo veel dat als je de aarde ermee zou bedekken, ze de hele planeet zouden bedekken tot een hoogte van 1 meter. "Het cluster computers zou in 1000 jaar gemiddeld een 128-bits sleutel kraken." - Asa Ayers


Ik zou voorstellen:

  • Gebruik makend van fail2ban om inlogpogingen met brute force te voorkomen.

  • Logboekregistratie als root via SSH uitschakelen. Dit betekent dat een aanvaller zowel de gebruikersnaam als het wachtwoord moet achterhalen om een ​​aanval moeilijker te maken.

    Toevoegen PermitRootLogin no aan jouw /etc/ssh/sshd_config.

  • Beperking van de gebruikers die SSH naar de server kunnen. Ofwel per groep of alleen specifieke gebruikers.

    Toevoegen AllowGroups group1 group2 of AllowUsers user1 user2 om te beperken wie SSH naar de server kan.


67



De AllowUsers en AllowGroups accepteert geen komma , als een scheidingsteken. Zorg ervoor dat je dit niet op afstand probeert. Ik blijf steeds buitengesloten van mijn NAS door dit verkeerd te doen. - artless noise
Altijd valideren jouw sshd config is correct voordat je sshd herstart, om te voorkomen dat je jezelf uit de machine sluit. Zien deze blog voor meer informatie - gewoon uitvoeren sshd -T na een config-wijziging voor het opnieuw opstarten van de main sshd. Ook, een SSH-sessie geopend hebben op de machine wanneer u de configuratie wijzigt, en sluit dit niet totdat u de configuratie zoals vermeld hebt gevalideerd en misschien een test SSH login hebt gedaan. - RichVel


Andere antwoorden bieden beveiliging, maar er is één ding dat u kunt doen waardoor uw logs stiller worden en het minder waarschijnlijk wordt dat uw account wordt geblokkeerd:

Verplaats de server van poort 22 naar een andere. Ofwel bij uw gateway of op de server.

Het verhoogt de veiligheid niet, maar betekent wel dat alle willekeurige internet-scanners je logbestanden niet overbelasten.


22



Voor degenen die in veiligheid geloven door obscuriteit (en.wikipedia.org/wiki/Security_through_obscurity) het is logisch om een ​​andere poort te gebruiken. Ik doe het niet .. - LassePoulsen
Het gaat niet om Security Through Obscurity (hoewel de obscuriteit een marginaal positief effect kan hebben). Het gaat om het verminderen van het achtergrondgeluid van eindeloze brute force-pogingen. U kunt uw logbestanden voor toegangsfouten niet op bruikbare wijze controleren als deze vol zijn met automatische aanvallen; fail2ban verlaagt het volume niet genoeg gezien het aantal aanvallers en de prevalentie van gedistribueerde (botnet) en gesmoorde aanvallen. Met ssh op een ongewone poort, jij weten Aanvallen die je ziet in de logs komen van een echte aanvaller die geïnteresseerd is in jouw box. Ik raad het ten zeerste aan. - bobince
Omdat je internetdiensten als shodan kunt opvragen voor webgerichte ssh-servers, of als nmap en banner-opname worden gebruikt, is het wijzigen van de standaardpoort vrijwel zinloos. ik zou dit afraden. - SLow Loris
Shodan grijpt niet alle 65k-poorten, dus het overschakelen naar een hoge poort zal het waarschijnlijk van hun scans verwijderen. Ook als u naar een willekeurige hoge poort gaat, zal de aanvaller waarschijnlijk 65K TCP-scans (erg luidruchtig) moeten uitvoeren om uw service te vinden om deze aan te vallen. Beide zijn overwinningen vanuit een beveiligingsperspectief, dus een verhuizing naar een hoge haven is over het algemeen een goed plan. Een andere is dat door naar een hoge poort te gaan, je een beter idee kunt hebben dat iemand die je aanvalt, je systemen specifiek target, in tegenstelling tot alleen algemene achtergrondgeluiden op internet. - Rоry McCune


Maak de client-IP's van de sshd-blokkering die niet de juiste login-informatie hebben opgeleverd "DenyHØsts"kan dit werk behoorlijk effectief doen, ik heb dit geïnstalleerd op al mijn Linux-boxen die op de een of andere manier bereikbaar zijn van de grote buitenwereld.

Dit zorgt ervoor dat force-attacks op de SSHD niet effectief zijn, maar onthoud (!) Dat je op deze manier jezelf kunt afsluiten als je je wachtwoord bent vergeten. Dit kan een probleem zijn op een externe server waartoe u geen toegang hebt.


21



Is er een optie als 10 mislukte inlogpogingen voordat het ip-adres wordt verbannen? - sayantankhan


Schakel authenticatie met twee factoren in met HOTP of TOTP. Deze is beschikbaar vanaf 13.10 uur.

Dit omvat het gebruik van openbare-sleutelauthenticatie via wachtwoordverificatie zoals in een ander antwoord hier, maar vereist ook dat de gebruiker bewijst dat hij zijn second-factor-apparaat naast zijn privésleutel heeft.

Overzicht:

  1. sudo apt-get install libpam-google-authenticator

  2. Laat elke gebruiker het google-authenticator opdracht, die genereert ~/.google-authenticatoren helpt hen bij het configureren van hun tweefactor-apparaten (bijvoorbeeld de Google Authenticator Android-app).

  3. Bewerk /etc/ssh/sshd_config En instellen:

    ChallengeResponseAuthentication yes
    PasswordAuthentication no
    AuthenticationMethods publickey,keyboard-interactive
    
  4. Rennen sudo service ssh reload om uw wijzigingen op te halen /etc/ssh/sshd_config.

  5. Bewerk /etc/pam.d/sshd en vervang de lijn:

    @include common-auth
    

    met:

    auth required pam_google_authenticator.so
    

Meer informatie over verschillende configuratie-opties is mijn blogbericht van vorig jaar: Betere two-factor ssh-authenticatie op Ubuntu.


21





Hier is één eenvoudig ding om te doen: installeren ufw (de "ongecompliceerde firewall") en gebruik deze om inkomende verbindingen te beoordelen.

Typ vanaf de opdrachtprompt:

$ sudo ufw limit OpenSSH 

Als ufw is niet geïnstalleerd, doe dit en probeer het opnieuw:

$ sudo aptitude install ufw 

Veel aanvallers zullen proberen je SSH-server te gebruiken om wachtwoorden brute dwingen. Hierdoor zijn er slechts om de 30 seconden zes verbindingen mogelijk vanaf hetzelfde IP-adres.


19



+1 Het gebruik van limiet kan goed zijn. Moet echter opmerken dat ik problemen heb ondervonden bij het gebruik van de ingebouwde sftp-server, omdat dit ook de verbindingen voor dit beperkt. - Mark Davidson
@Mark - goed punt, maar klinkt dat niet als een slecht geschreven SFTP-client? Waarom zouden ze opnieuw verbinding blijven maken met de SSH-poort als ze gewoon meer SSH-kanalen kunnen openen? - mpontillo


Als ik wat extra beveiliging wil of toegang moet hebben tot SSH-servers diep in sommige bedrijfsnetwerken die ik heb opgezet a verborgen service door gebruik te maken van de anonimiseringssoftware Tor.

  1. Installeer Tor en stel de SSH-server zelf in.
  2. Zorg ervoor dat sshd alleen naar luistert localhost.
  3. Open /etc/tor/torrc. set HiddenServiceDir /var/lib/tor/ssh en HiddenServicePort 22 127.0.0.1:22.
  4. Kijk naar var/lib/tor/ssh/hostname. Er is een naam zoals d6frsudqtx123vxf.onion. Dit is het adres van de verborgen service.
  5. Open $HOME/.ssh/config en voeg enkele regels toe:

    Host myhost
    HostName d6frsudqtx123vxf.onion
    ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
    

Verder heb ik Tor nodig bij mijn lokale host. Als het is geïnstalleerd, kan ik het invoeren ssh myhost en SSH opent een verbinding via Tor. De SSH-server aan de andere kant opent zijn poort alleen op localhost. Niemand kan het dus verbinden via "normaal internet".


12



Beveiliging door geavanceerde obscuriteit, maar zeer interessant. - Johannes


Er is een Debian-administratieartikel over dit onderwerp. Het behandelt de standaard SSH-serverconfiguratie en ook firewallregels. Dit kan ook van belang zijn voor het verharden van een SSH-server.

Zie daar het artikel: SSH-toegang veilig houden.


8



Een beetje laat, maar alsjeblieft, als je vragen beantwoordt, kopieer de belangrijke delen van een link zodat als de link vervalt de informatie er nog steeds is. - umop aplsdn
Goed idee. Hoewel ik een periode heb met veel minder tijd om deel te nemen. Mijn antwoord is een "community-wiki", dus voel je vrij om de link-informatie toe te voegen als je tijd hebt. - Huygens


Mijn aanpak van SSH-verharding is ... complex. De volgende items hebben betrekking op hoe ik het doe, van de meest rand van mijn netwerk (en) tot de servers zelf.

  1. Grensfiltering van verkeer via IDS / IPS met bekende servicescanners en handtekeningen in de blokkeerlijst.  Ik bereik dit met Snort via mijn border-firewall (dit is mijn aanpak, een pfSense-apparaat). Soms kan ik dit echter niet doen, zoals met mijn VPS's.

  2. Firewall- / netwerkfiltering van de SSH-poort (en).  Ik sta het expliciet alleen toe dat bepaalde systemen mijn SSH-servers bereiken. Dit wordt gedaan via een pfSense-firewall aan de rand van mijn netwerk of de firewalls op elke server die expliciet worden geconfigureerd. Er zijn echter gevallen waarin ik dit niet kan doen (wat bijna nooit het geval is, behalve in privétesten voor testtesten of in laboratoria met beveiligingstests waarbij de firewalls niet helpen om dingen te testen).

  3. In combinatie met mijn pfSense of een grensfirewall NAT op het interne netwerk en los van het internet en de systemen, Toegang via VPN tot servers. Ik moet VPN invoeren in mijn netwerken om bij de servers te komen, omdat er geen poorten zijn die op het internet zijn gericht. Dit werkt zeker niet voor al mijn VPS's, maar in combinatie met # 2, kan ik één VPS de 'gateway' maken door VPN op die server in te stellen en vervolgens IP's aan de andere boxen toestaan. Op die manier weet ik precies wat SSH kan of niet kan - mijn enige box die de VPN is. (Of, in mijn thuisnetwerk achter pfSense, mijn VPN-verbinding, en ik ben de enige met VPN-toegang).

  4. Waar # 3 niet te doen is, fail2ban, geconfigureerd om na 4 mislukte pogingen te blokkeren en de IP's een uur of langer te blokkeren is een goede bescherming tegen mensen die constant aanvallen met bruteforcing - blokkeer em automatisch bij de firewall met fail2ban en meh. Het configureren van fail2ban is echter een pijn ...

  5. Port-verduistering door de SSH-poort te wijzigen.  Echter, dit is NIET een goed idee om te doen zonder aanvullende veiligheidsmaatregelen - de mantra van 'Security through Obscurity' is al in veel gevallen weerlegd en betwist. Ik heb dit gedaan in combinatie met IDS / IPS en netwerkfiltering, maar het is nog steeds een ZEER arm ding om alleen te doen.

  6. MANDATORY Two-Factor Authentication, via De authenticatieoplossingen van Duo Security voor twee factoren.  Elk van mijn SSH-servers heeft Duo erop geconfigureerd, zodat er zelfs 2VO-prompts kunnen binnenkomen en ik elke toegang moet bevestigen. (Dit is de ultieme handige functie - omdat zelfs als iemand mijn wachtwoordzin heeft of inbreekt, ze niet voorbij de Duo PAM-plug-ins kunnen komen). Dit is een van de grootste beveiligingen op mijn SSH-servers tegen ongeautoriseerde toegang - elke gebruikerslogin MOET een vastgelegde gebruiker in Duo binden en aangezien ik een beperkende set heb, kunnen er geen nieuwe gebruikers in het systeem worden geregistreerd.

Mijn twee cent voor het beveiligen van SSH. Of, althans, mijn gedachten over nadering.


6





Misschien wilt u de FreeOTP-app van RedHat afrekenen in plaats van Google Authenticator te gebruiken. Soms blokkeren ze je bij het bijwerken van de app! ;-)

Als u andere hardwaretokens wilt gebruiken zoals een Yubikey of een eToken PASS of NG of als u veel gebruikers of veel servers hebt, wilt u mogelijk een opensource-authenticatie-backend met twee factoren gebruiken.

De laatste tijd schreef ik een howto hierover.


1





Ik heb hier een kleine tutorial over geschreven. Kortom, u moet PKI gebruiken en mijn zelfstudie laat ook zien hoe u Two-Factor Authentication kunt gebruiken voor nog meer veiligheid. Zelfs als je geen van deze dingen gebruikt, zijn er ook enkele weetjes over het beveiligen van de server door zwakke cipher-suites en andere basics te verwijderen. https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/ 


0