Onderwerp: Onderzoekers waarschuwen voor toename ssh-aanvallen

Oorspronkelijk geplaatst door Yourwebhoster

Hangt er maar net van af hoe scherp je de firewall ingesteld hebt. brute force detectie moet je sowieso hebben, maar als het om een gedistribueerde aanval gaat (lees meerdere IP's die samenwerken) dan is de kans groot inderdaad dat de poort gevonden wordt. Maar zeg nou zelf, hoe vaak komt zo'n grote aanval voor?

En met port knocking zou je nog een stap verder gaan.

Zelf al stel je de firewall zo scherp mogelijk in dan nog zal je je eigen fixed ip van kantoor of whatever wel in de whitelist zetten, als de aanval dan via je eigen trusted netwerk plaats vindt ben je met je firewall niet veel meer. En hoe vaak gebeurt het dat een secretaresse/... een bijlage opent in een e-mail die ze niet zou mogen openen en een trojan of botnet installeert.

Kortom je beveiliging is maar zo sterk als je zwakste schakel en die heb je meestal niet zelf in de hand. Denk dat veel ook te maken heeft met laksheid van beheerder tegenwoordig door het gebruik van prebuilt packages en het standaard/blind volgen van een manual of setup file. Ik kan alleen voor mijzelf spreken maar toen ik nog met gentoo en bsd bezig was in de eind jaren 90 begin 2000 had ik veel meer aandacht voor wat er effectief op mijn server stond. Nu met CentOS/RHEL/SL, Ubuntu/Debian en ... denkt iedereen beheerder te zijn door even aptitude update/upgrade of yum update/upgrade of ... uit te voeren. Ik moet eerlijkheidshalve toegeven dat ik ook veel minder dingen zelf compile of eigen repos maak, maar iets wat ik nog steeds niet doe is het vertrouwen op default configs en het blind volgen van een manual.

Oorspronkelijk geplaatst door ®on

En vervolgens doodleuk zichzelf aanbiedt bij een eenmalige opdracht om de server van opdrachtgever te beveiligen. Je vraagt je dan serieus af welke plaat er voor zijn hoofd hangt.

In het kader van professionalisering zou WHT daar ook tegen mogen optreden, m.i.

Oorspronkelijk geplaatst door Wido

Een goede aanvaller vertraag je hoogstens met een minuut of 2 door je poort te veranderen.

Niet wanneer je een dummy op poort 22 zet die het laat lijken alsof het de echte SSH daemon is.

Nogmaals; ik zeg ook niet dat het veranderen van de SSH poort daadwerkelijk de beveiliging verhoogt, maar het maakt het toch wel weer net iets minder makkelijk voor een aanvaller.

Oorspronkelijk geplaatst door Apoc

Niet wanneer je een dummy op poort 22 zet die het laat lijken alsof het de echte SSH daemon is.

Nogmaals; ik zeg ook niet dat het veranderen van de SSH poort daadwerkelijk de beveiliging verhoogt, maar het maakt het toch wel weer net iets minder makkelijk voor een aanvaller.

Wat ik als belangrijkste voordeel zie is dat het de logruis enorm verlaagd, zodat je veel zinvoller zicht hebt op echte aanvalspogingen en afwijkingen van normale patronen kunt zien, als je besluit daar ook op te letten.

Gelaagde beveiliging is een prima idee, en een drempeltje (liever dan een portknock dan 'alleen maar' een andere port) tussen de zee van ssh scannertjes en de ssh daemon is dan een prima idee.

Jezelf heel veilig wanen _alleen maar_ vanwege een andere poort is natuurlijk dom.

Met het volgende vang je in ieder geval al een hoop op:
- Firewall: Dus niet iedereen access geven op SSH.
- Password login uit; inloggen met keys+passwd.
- Indien mogelijk: Een centrale log in server gebruiken.

SSH op een andere poort doe ik ook niet, hiermee voorkom je 'scanners' maar niet de serieuze hacks.

Welke maatregelen hebben wij zo al genomen op een aantal systemen (zijn we op de rest aan het uitrollen):
- Jumphost: check (2 jumphosts voor als er 1 uit ligt)
- Keys: check (vereist om op de jumphost in te loggen, vanaf de jumphost is middels keys weer op de rest in te loggen)
- Key per apparaat dat mag verbinden: check (laptop, desktop, tablet, mobiel krijgen elk een eigen private key. Als 1 apparaat mogelijk niet meer veilig is kan deze key makkelijk verwijderd worden)
- Centraal beheer public keys: check (let op: private keys staan niet centraal)
- Schema voor key-rotatie: check (conform schema keys vervangen)

Wat komt er nog bij:
- VPN tunnels
- Automatisering vervangen keys die enkel intern blijven (dus voor server-server verbindingen), wekelijks nieuwe keys
- Wachtwoorden op alle keys
- Controle of een public key niet "te oud" is en zodra dat het geval is deze automatisch verwijderen
- Om bepaalde systemen te bereiken 2 jumphosts nodig zijn
- SSH op een andere poort en op poort 22 iets draaien om rotzooi te vangen (dat draait dan overigens wel op een ander systeem, hiervoor zal met een vorm van port forwarding op de firewalls die overal voor staan worden gewerkt)

En misschien ook belangrijke aanname, iets is onveilig tot het tegendeel aannemelijk/bewezen is... 100% veiligheid bestaat niet.

Oorspronkelijk geplaatst door Mark17

Welke maatregelen hebben wij zo al genomen op een aantal systemen (zijn we op de rest aan het uitrollen):
- Jumphost: check (2 jumphosts voor als er 1 uit ligt)
- Keys: check (vereist om op de jumphost in te loggen, vanaf de jumphost is middels keys weer op de rest in te loggen)
- Key per apparaat dat mag verbinden: check (laptop, desktop, tablet, mobiel krijgen elk een eigen private key. Als 1 apparaat mogelijk niet meer veilig is kan deze key makkelijk verwijderd worden)
- Centraal beheer public keys: check (let op: private keys staan niet centraal)
- Schema voor key-rotatie: check (conform schema keys vervangen)

Wat komt er nog bij:
- VPN tunnels
- Automatisering vervangen keys die enkel intern blijven (dus voor server-server verbindingen), wekelijks nieuwe keys
- Wachtwoorden op alle keys
- Controle of een public key niet "te oud" is en zodra dat het geval is deze automatisch verwijderen
- Om bepaalde systemen te bereiken 2 jumphosts nodig zijn
- SSH op een andere poort en op poort 22 iets draaien om rotzooi te vangen (dat draait dan overigens wel op een ander systeem, hiervoor zal met een vorm van port forwarding op de firewalls die overal voor staan worden gewerkt)

Publiekelijk je security policies posten: check

Oorspronkelijk geplaatst door Apoc

Publiekelijk je security policies posten: check

je kunt in ieder geval niet zeggen dat hij last heeft van security by obscurity

Oorspronkelijk geplaatst door t.bloo

je kunt in ieder geval niet zeggen dat hij last heeft van security by obscurity

Security by obscurity hoort dan ook een bijkomend voordeel te zijn

Oorspronkelijk geplaatst door Apoc

Publiekelijk je security policies posten: check

Beetje ala de standaard crypto mechanismes... De techniek is open. Security valt of staat bij de sleutel(lengte....)

Verder vind ik persoonlijk wel extreem veel werk om poortje 22 te beschermen.

Ben ik nou te naïef als ik zeg dat het gebruik van goede logingegevens en een firewall waarin slechts een enkel ip-adres toegestaan wordt genoeg is?

waarom makkelijk doen als het moeilijk kan???

Oorspronkelijk geplaatst door crossplatform

Beetje ala de standaard crypto mechanismes... De techniek is open. Security valt of staat bij de sleutel(lengte....)

Uhm, nou nee, er komt wel 'iets' meer bij kijken dan de lengte van een sleutel. Daarnaast is het domweg onverstandig om een checklist te publiceren met stappen die een hacker zou moeten kunnen overwinnen om binnen te komen.

Oorspronkelijk geplaatst door crossplatform

Verder vind ik persoonlijk wel extreem veel werk om poortje 22 te beschermen.

Security wordt al snel als 'veel werk' gezien. Prima die houding.. je merkt vanzelf wel hoeveel werk het is om de consequenties van een hack af te handelen. Buiten dat; de genoemde stappen zijn voor een beetje beheerder in een paar minuten geregeld.

Oorspronkelijk geplaatst door marsipulami

Ben ik nou te naïef als ik zeg dat het gebruik van goede logingegevens en een firewall waarin slechts een enkel ip-adres toegestaan wordt genoeg is?

waarom makkelijk doen als het moeilijk kan???

Als je daar nog aan toe voegt dat de machine(s) die van dat betreffende IP adres gebruik kunnen maken, ook goed beveiligd zijn, dan zit je redelijk safe. Het probleem is echter dat er nogal wat situaties zijn waarin het onwenselijk is om maar vanaf 1 IP adres in te kunnen loggen.

Oorspronkelijk geplaatst door Apoc

U
Als je daar nog aan toe voegt dat de machine(s) die van dat betreffende IP adres gebruik kunnen maken, ook goed beveiligd zijn, dan zit je redelijk safe.

Moet dat niet altijd?? Met een key-pair ben je net zo kwetsbaar als je machines niet goed beveiligd zijn.

Oorspronkelijk geplaatst door marsipulami

Ben ik nou te naïef als ik zeg dat het gebruik van goede logingegevens en een firewall waarin slechts een enkel ip-adres toegestaan wordt genoeg is?

waarom makkelijk doen als het moeilijk kan???

Niet naief, maar je kijkt blijkbaar alleen naar gebruik door een beperkte doelgroep vanaf vaste locaties.
In dat geval is een ip filter + behoorlijke login policy prima.

Als je een grotere pool accounts hebt die van verschillende wisselende locaties kunnen komen wordt de uitdaging een stuk groter.

Oorspronkelijk geplaatst door marsipulami

Moet dat niet altijd?? Met een key-pair ben je net zo kwetsbaar als je machines niet goed beveiligd zijn.

Op het gebied van security is het maken van aannames dodelijk, en kan het dus inderdaad zeker geen kwaad om dat expliciet te noemen. Op veel van de machines waarmee ingelogd wordt op servers, draait allerlei software waarvan je niet zeker weet of deze wel veilig zijn (waarmee de machine dus per definitie onveilig is).