Onderwerp: Tutorial - SSH beveiliging/gebruik optimaliseren

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/knowle...ayarticle&id=5

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

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.

Oorspronkelijk geplaatst door The-BosS

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 ?

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.

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.

Ik heb juist de PermitRootLogin staan op:

Code:

PermitRootLogin without-password

Weinig mensen die dat gebruiken zo te merken.

Oorspronkelijk geplaatst door systemdeveloper

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?

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.

Oorspronkelijk geplaatst door Piwi-Web

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.

Oorspronkelijk geplaatst door Pur

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

Oorspronkelijk geplaatst door Pur

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.

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...

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.

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!

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.