Onderwerp: Tutorial - SSH beveiliging/gebruik optimaliseren

Voor de mensen die er belang bij hebben, hieronder een simpele tutorial over het beveiligen van SSH gebruik op een DirectAdmin server (dedicated, vps, CentOs, DirectAdmin or not, have fun! ).

Deze tutorial is bij ons in de f.a.q. terug te vinden als: http://webcenter.mortydot.com/knowle...ayarticle&id=5

Hier op WHT is het mijn eerste tutorial. Heb je tips (opmaak of inhoudelijk) hou het graag opbouwend.

------------------------------------------------------------------------------------

In deze tutorial gaan we SSH beter beveiligen. SSH is de meest en best gebruikte wijze van remote beheer van een Linux systeem. Terecht, met SSH kunt u een machine geheel op afstand beheren, onderhouden, etc. Maar stel dat een kwaadwillende toegang krijgt tot SSH? Dan zijn de gevolgen niet te overzien. Normaliter word er bij SSH ter beveiliging gebruik gemaakt van een username en password.


Deze tutorial is getest met een CentOS 5 basic installatie, DirectAdmin en CSF.
1) Gebruik sterke wachtwoorden

Een van de zwakste punten bij wachtwoorden is altijd de gebruiker en de moeilijkheid van een wachtwoord. Let op dat bij DirectAdmin SSH gebruik het wachtwoord overeenkomt met het wachtwoord van de DirectAdmin user. Uiteraard geld voor een DirectAdmin wachtwoord de zelfde geadviseerde punten als een SSH wachtwoord (en ieder ander mogelijk wachtwoord):

• Minimaal 8 karakters/tekens
• Gebruik grote en kleine letters
• Mix getallen en letters door elkaar
• Gebruik speciale tekens (!@#$%^&*_+)

2) Beperkt SSH gebruikers

Stel dat een van uw DirectAdmin gebruikers zijn/haar inloggegevens in kwaadwillende handen vallen (of zij hebben zelf slechte intenties). Het laatste wat u wil is dat deze gebruiker met wat voor een rechten dan ook SSH toegang heeft tot uw server. Het is daarom sterk aan te raden om DirectAdmin users en resellers GEEN SSH toegang te geven. Bij gebruikers die dit wel wensen kunt u altijd zelf, individueel toegang geven. U kunt SSH toegang uitschakelen tijdens het aanmaken als optie van user en reseller hosting pakketten.

U kunt een lijst van toegestane SSH users terug vinden in /etc/ssh/sshd_config.

Normaliter staat onderaan deze config file een lijst met users die SSH toegang hebben. Als u verder niemand behalve uzelf toegang wil geven zal er enkel deze lijn staan:

Code:

AllowUsers root.

Na wijzigingen moet u sshd service herstarten met:

Code:

#service sshd restart

3) Standaard protocol 2

SSH heeft standaard op dit moment twee protocols om langs te communiceren. Protocol 1 is ouder en minder veilig. Wij gaan daarom protocol 2 als standaard instellen.

Bewerk /etc/ssh/sshd_config en zoek/wijzig de volgende regel op in /etc/ssh/sshd_config:

Code:

#Protocol 1,2
Protocol 2

Na wijzigen van het bestand herstart de sshd service:

Code:

# service sshd restart

4) Wijzig standaard ssh poort

Een andere belangrijke wijziging is het veranderen van de standaard SSH poort. In dit voorbeeld gaan we SSH van poort 22 naar poort 1022 veranderen. Let op dat bij deze wijziging u bij uw gebruikte SSH cliënt nu wel de nieuwe poort moet opgeven voor connecten!

Stap 1)

Eerst gaan we de firewall zodanig instellen dat op ook op de nieuwe poort geluisterd kan worden. Hoe is afhankelijk van uw gebruikte firewall. Gebruikt u CentOS dan zal deze hoogstwaarschijnlijk de 'setup' tool inbegrepen hebben. Servers met CSF kunnen dit vanuit het DirectAdmin CSF pagina instellen of via de CSF config file.

Setup wijze:

Code:

#setup

u kunt bij firewall en netwerk opties de toegestane poorten opgeven. Zorg ervoor dat poort 1022 niet meer geblokkeerd word. (1022:tcp kunt u bij custom ports toevoegen)

CSF Wijze:

Bij CSF zult u de ingaande en uitgaande poort moeten opgeven. Voeg de poort 1022 toe op de CSF config pagina. (zowel TCP_in als TCP_out).
Beschikt u niet over CSF dan is deze config file terug te vinden als: /etc/csf/csf.conf

Zoek naar TCP_in en TCP_out en voeg hier de poort 1022 toe.

Als het goed is heb je nu nu de nieuwe poort 1022 opengezet voor gebruil.

Stap 2)

Nadat de nieuwe poort 1022 openstaat voor buitenaf gaan we SSH configureren dat die ook daadwerkelijk op deze poort luistert.

Open de SSH config file: /etc/ssh/sshd_config en wijzig de volgende instellingen:

Code:

# Run ssh on a non-standard port:
Port 1022  #Change me

Na het opslaan van de config file zal SSH de volgende keer dat het gestart worden op de nieuwe poort luisteren.
SSH herstarten:

Code:

# service restart sshd

Stap 3)

Nu SSH op een nieuwe poort luistert (1022) moeten we mogelijk opnieuw connecten met de server.

Echter staat de oude poort nu nog wel open volgens de firewall. Verwijder deze poort zoals je gedaan hebt door een nieuwe poort toe te voegen (stap 1). Enkel nu voegen we geen poort 1022 toe, maar verwijderen we poort 22.

Optioneel, geen SSH root toegang

Beheert u uw server niet als root via SSH? Dan is het ook niet nodig om dit op afstand toe te staan. Wijzig het volgende in /etc/ssh/sshd_config:

Code:

# Prevent root logins:
PermitRootLogin no

Na het wijzigen moet u enkel nog SSH server herstarten

Code:

# service sshd restart

Op zich een leuke tutorial, maar wel heeeel erg basis. Ik vind niets over ssh-keys, en je hebt het over permitrootlogins als of dit een optie zou moeten zijn, mijn mening is dat die altijd op off moet staan.

Je kan altijd nog met iets als "su root" inloggen als root wanneer dit nodig is.

Verder misschien een idee om in het begin aan te geven wat je allemaal gaat behandelen, de punten, dan weet je wat je over kan slaan en niet.

Code:

AllowUsers root

Zou ik dus niet doen. Een aparte gebruiker maken en dan su root doen wanneer je echt rootaccess nodig zou hebben.

Oorspronkelijk geplaatst door Piwi-Web

Code:

AllowUsers root

Zou ik dus niet doen. Een aparte gebruiker maken en dan su root doen wanneer je echt rootaccess nodig zou hebben.

i agree! Regel 1 van elke linux beheerder zou toch moeten zijn dat rootlogin UIT staat! het liefst zelfs alleen specifieke users die mogen su'en of sudo'en.

dus, rootlogin uit, goede sudoers list. ssh eventueel op andere poort. users ipv een ww een key laten gebruikten. Dan ben je al een heel eind

of gaan we helemaal ruig doen en gaan we poortje 22 pas openzetten na dat je de goede poortjes ge'knocked hebt?

Oorspronkelijk geplaatst door Japje

of gaan we helemaal ruig doen en gaan we poortje 22 pas openzetten na dat je de goede poortjes ge'knocked hebt?

Hehe kan dat ook al?

Oorspronkelijk geplaatst door Piwi-Web

Hehe kan dat ook al?

zijn mooie iptables voor te vinden als je het leuk vind om er mee te spelen:

http://www.debian-administration.org/articles/268

Oorspronkelijk geplaatst door Japje

i agree! Regel 1 van elke linux beheerder zou toch moeten zijn dat rootlogin UIT staat! het liefst zelfs alleen specifieke users die mogen su'en of sudo'en.

Regel 1,2,3 zelfs :-) En regel 4,5,6 zijn keys ipv wachtwoorden.

Aan de andere kant wie promoot zulk gedrag als hij/zij een VPS of dedicated oplevert. Ik ben er in ieder geval nog niet veel tegen gekomen. In 99 van de 100 gevallen is het volgens mij toch direct inloggen op een VPS of een dedi met root. Okay wachtwoorden zijn misschien niet zo simpel, maar ze zijn vaak ook niet heel lang (meestal 8 karakters).

Iedereen bedankt voor de reacties zover.

Het idee erachter is inderdaad ook voor de beginnende beheerders. Zie helaas teveel dat mensen het bij een standaard installatie en die instellingen houden.

Zal even kijken of ik dit bij kan en mag werken hier op WHT .
Bedankt voor reacties tot zover! Hoor graag meer

Nog een tipje:

Voor servers waar alleen de beheerders via SSH naar binnen hoeven is het zinvol port 22 alleen voor specifieke IP's open te zetten op de firewall.

Oorspronkelijk geplaatst door davhog

Nog een tipje:

Voor servers waar alleen de beheerders via SSH naar binnen hoeven is het zinvol port 22 alleen voor specifieke IP's open te zetten op de firewall.

Lekker handig als je klanten via dhcp een ip lease krijgen bij hun ISP

Hier kunnen $users alleen via een VPN connectie inloggen via ssh op $doos

Oorspronkelijk geplaatst door mikeh

Lekker handig als je klanten via dhcp een ip lease krijgen bij hun ISP

Hier kunnen $users alleen via een VPN connectie inloggen via ssh op $doos

Davhog zei toch indien enkel beheerders toegang nodig hebben, dus ik zie niet in wat dit dan met klanten te zien heeft.

Ieder deftig bedrijf heeft toch op zijn minst een static ip op zijn adsl/kabel/... om juist beheer van remote switches/servers/routers/... uit te voeren. En indien ze het niet hebben gebruiken ze inderdaad VPN, dus ik zie persoonlijk niet in wat het probleem is om ssh te blokken op firewalls. Ik doe het persoonlijk ook voor services/servers waar ik enkel toegang op nodig heb.

@the-boss en @mikeh

Filtering op firewall niveau is inderdaad ook mogelijk. Heeft inderdaad ook nadelen. Ikzelf werk vanaf veel verschillende plekken dus mijn IP wisselt nogal.

Heb daarom een iets andere oplossing wat dicht in de buurt komt van hierboven. Met 10keer fout inloggen met SSH word het IP tijdelijk geblokkeerd. Bij vaker, permanent.

Alleen niet beschreven in deze tut, wou het basis houden :-)

Je zou ook via een andere server gewoon kunnen connecten maar dan moet je wel niet de keys gaan opslaan natuurlijk
Tenminste zo doe ik het als ik niet thuis ben (enkel één server + thuis IP heeft toegang)

Oorspronkelijk geplaatst door MortyDot

Alleen niet beschreven in deze tut, wou het basis houden :-)

is op zich goed, maar dan moet je wel beter aangeven dat dit ook ECHT basis is, en dat je server hiermee niet optimaal beveiligd is. Voor meer info, zie "advanced ssh security" ofzo :P

Dit is allemaal erg basic. Je kan beter een tutorial maken over het écht beveiligigen van SSH (en het hele rechten en gebruikers systeem erachter). Wachtwoorden zou ik bijvoorbeeld helemaal niet toelaten, maar beperken tot keys.

En mocht je meerdere servers beheren: beperk toegang tot 1 IP, wat dan weer een aparte server is speciaal om vanaf te SSH'en. Dan hoef je andere servers helemaal niet te exposen en heb je 1 server waar je extra je best voor doet om dicht te houden (bijvoorbeeld door er verder niets op te draaien behalve een SSH server).