PDA

Bekijk Volledige Versie : Tutorial - SSH beveiliging/gebruik optimaliseren



MortyDot
21/12/09, 15:15
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! :p).

Deze tutorial is bij ons in de f.a.q. terug te vinden als: http://webcenter.mortydot.com/knowledgebase.php?action=displayarticle&id=5

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

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

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:


AllowUsers root.
Na wijzigingen moet u sshd service herstarten met:
#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:


#Protocol 1,2
Protocol 2 Na wijzigen van het bestand herstart de sshd service:


# service sshd restart4) 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:



#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:


# 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:


# service restart sshdStap 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:


# Prevent root logins:
PermitRootLogin no Na het wijzigen moet u enkel nog SSH server herstarten


# service sshd restart

marsipulami
21/12/09, 15:32
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.

Piwi-Web
21/12/09, 15:59
AllowUsers root
Zou ik dus niet doen. Een aparte gebruiker maken en dan su root doen wanneer je echt rootaccess nodig zou hebben.

Japje
21/12/09, 16:06
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? ;)

Piwi-Web
21/12/09, 16:24
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? :p

Japje
21/12/09, 16:33
Hehe kan dat ook al? :p

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

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

Pur
21/12/09, 17:04
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).

MortyDot
21/12/09, 17:48
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 :lovewht:.
Bedankt voor reacties tot zover! Hoor graag meer :p

davhog
21/12/09, 20:21
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.

mikeh
22/12/09, 10:05
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 :double fuck:

The-BosS
22/12/09, 10:12
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 :double fuck:

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.

MortyDot
22/12/09, 12:09
@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 :-)

Piwi-Web
22/12/09, 12:38
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)

marsipulami
22/12/09, 16:45
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

XBL
22/12/09, 17:04
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).

MortyDot
22/12/09, 18:13
Het basis staat genoemd in de eerste regel :-)

Maar ik heb nog een paar van jullie punten toegevoegd. Voor extra mogelijkheden schrijf ik later wel een. De nieuwe versie is al bijgewerkt:
http://webcenter.mortydot.com/knowledgebase.php?action=displayarticle&id=5

Heb een moderator gevraagd of ik/hij het topic kan/mag bijwerken.

The-BosS
22/12/09, 18:28
Een andere tip indien je klanten ssh toegang wil geven is bvb een custom shell gebruiken die enkel functies heeft die jij wilt dat de gebruikers mogen/kunnen gebruiken. En als je het echt extreem wil kan je ook de omgeving van de gebruiker chrooted draaien en de ulimits aanpassen zodat de gebruiker niet allemaal je server resources kan (misbruiken)gebruiken. Maar dan gaan we al naar het meer advanced ipv basic.

mikeh
24/12/09, 16:13
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.

En jij werkt zeker nooit vanuit de trein, thuis of bij de klant op kantor ?:innocent:

De oplossing, een stepstone waar je alleen met ssh-keys in kunt loggen (lees man pages over hoe je dat kunt realiseren) en van daaruit via een soort van protected vlan / vpn achtig spul naar $klant/$doos kunt connect. :O

systemdeveloper
24/12/09, 18:54
Klanten hebben niks te zoeken op ssh en zelf via openbare netwerken of lijntjes van de klant moet je geen servers gaan beheren (imho).

Uiteraard kun je wel ssh-keys e.d. gaan gebruiken, maar voor je het weet slingeren die ook weer ergens rond op een vergeten usbstick, een snelkoppeling bij een klant oid.

Je kunt eens kijken naar one time passwords (OTP/Kerebos, net zoals een TAN code dus eigenlijk). In dat geval maakt het niet eens uit of iemand je password sniffed. Nieuwe OTP lijsten genereer je dan op persoonlijk verzoek van de klant indien nodig.

Of je gebruikt een sms service om tijdelijk een ipadres open te zetten of je maakt de logins time-limited ingeval je bv. altijd van 7-8 in de trein zit.

Het gebruiken van een goed lang password met vreemde tekens is overigens beter dan alle andere opties.
Bedenk je...waarom zou een hacker zich moeite gaan doen voor je ssh als ie net zo goed je directadmin login, plesk login, ftp, onbeveiligde formulieren e.d. kan gaan gebruiken?
De kans dat iemand zijn ftp password wordt gepikt door een virus is 1000 keer groter dan een ssh password van 10 tekens dat geraden wordt.

lmp
24/12/09, 19:20
Ik heb juist de PermitRootLogin staan op:

PermitRootLogin without-password
Weinig mensen die dat gebruiken zo te merken.

Pur
25/12/09, 00:11
en zelf via openbare netwerken of lijntjes van de klant moet je geen servers gaan beheren (imho).

Want? Je kan toch prima op lokatie werken op je eigen laptop of even wat herstellen via je mobiel zonder dat je loopt te klooien met USB sticks met Putty oid?

Piwi-Web
25/12/09, 00:26
Je kan zoveel maar je moet het jezelf ook niet te moeilijk gaan maken. Een hacker gaat zich echt geen moeite doen als je root uit hebt staan of ssh op een andere poort hebt draaien (want daar checken ze meestal op). Dan zoekt hij namelijk wel een andere weg waar hij naar binnen komt (brakke scripts o.i.d. zoals systemdeveloper zegt).
De meeste zooi op de server wordt namelijk nog altijd gedaan door brakke scripts van klanten.

Pur
25/12/09, 00:38
Je kan zoveel maar je moet het jezelf ook niet te moeilijk gaan maken. Een hacker gaat zich echt geen moeite doen als je root uit hebt staan of ssh op een andere poort hebt draaien (want daar checken ze meestal op).


Je hebt ook nog de script kiddies die een 1001 namen proberen in de hoop binnen te komen ook al gebruik je alleen keys en laat je maar 1 username toe.



Dan zoekt hij namelijk wel een andere weg waar hij naar binnen komt (brakke scripts o.i.d. zoals systemdeveloper zegt).
De meeste zooi op de server wordt namelijk nog altijd gedaan door brakke scripts van klanten.

Uhm op niet elke server draait DirectAdmin en daarmee 'meuk' van klanten hoor :-)

Ik ben het verder wel eens dat je het niet moet gaan overdrijven door middel van 2 keer lang kloppen 3 keer kort kloppen en 1 keer fluiten.

Evengoed hebben wij de firewall van ons generieke platform alleen open staan voor bekende IP adressen. Daarnaast hebben we dan nog 2 servers die dienst doen als stepping stone server voor het geval iemand op een niet bekende lokatie zit / mobiel aan het werk is.

Piwi-Web
25/12/09, 00:44
Evengoed hebben wij de firewall van ons generieke platform alleen open staan voor bekende IP adressen. Daarnaast hebben we dan nog 2 servers die dienst doen als stepping stone server voor het geval iemand op een niet bekende lokatie zit / mobiel aan het werk is.

Hebben we hier ook en dat vindt ik persoonlijk voldoende :)

systemdeveloper
25/12/09, 00:57
Want? Je kan toch prima op lokatie werken op je eigen laptop of even wat herstellen via je mobiel zonder dat je loopt te klooien met USB sticks met Putty oid?
Oh, dat kan uiteraard. Ik dacht meer aan 'even' inloggen via het netwerk van de klant of openbare wifi netwerken, pc's van klanten e.d.

Robain
11/04/10, 23:31
Ik begrijp niet goed waarom iedereen gaat zeggen "root login uit, en dan su". Da's toch nutteloos? We leven niet meer in 1998 waar men met oudere versies van het protocol de eerste pakketten en zo ging sniffen om een root passwd te bemachtigen...

SSH is veilig, indien op verstandige wijze gebruikt...

marsipulami
11/04/10, 23:36
Het daar ook niet om het "sniffen" van pakketen, maar om bruteforce attacks. Wanneer ze dan een password kraken hebben ze nog 1 te gaan om als root bezig te gaan.
Tegen dit tijd kan je het al gefixed hebben.

Robain
11/04/10, 23:45
Dat is dan uiteraard het "verstandige" van de zaak... Een wachtwoord dat niet binnen afzienbare tijd te bruteforcen is, in combinatie met een 24u block na 10 inlogpogingen lijkt mij in veel gevallen toch voldoende?

Ik ga volledig akkoord, als je er de mogelijkheid toe hebt, dat het uiteraard best is enkel bepaalde ips toe te laten op firewall-niveau.

Echter, toegang gaan beperken tot 1 server, die je dan als tussenstap gebruikt, lijkt me toch ook niet ideaal. Als die server eruit gaat, heb je gelijk geen toegang meer tot je hele batterij servers...

Het gebruik van keys lijkt mij toch ook wat gevaren in te houden? Stel dat jouw pc gehacked wordt, of je laptop wordt gestolen, of ... Een wachtwoord gaan ze zo snel niet bemachtigen, uiteraard opnieuw op voorwaarde dat dit wachtwoord goed gekozen en uniek voor die server is.

Vind dit een interessante discussie! Ik ben een vrij onervaren sysadmin, dus hoor graag andere meningen!

Blacky
12/04/10, 02:25
Ik kiep zelf altijd SSH op protocol 2, daarna op een aparte poort en via CSF/LFD beperk ik de login tot mijn eigen ip adres.
Poort 22 laat ik gewoon open staan in de firewall als honeypot en daar worden dan de bruteforcers vanzelf op gebanned.

@MortyDot:
Mocht je hier nog lezen, haal de tekst dan eens door een spellchecker voor de zekerheid, staat wat professioneler:

3.Standaart protocol 2
4.Wijzig standaart SSH poort
Standaard hoort toch echt met een d geschreven te worden op het eind.;)