SSH Fingerprint is veranderd + rare chinese IP's

[MiliaanR]

Ik ben sinds kort weer een beetje bezig met websites, en ik heb daarvoor een Ubuntu 18.04 VM draaien bij PCExtreme. Toen ik vandaag via Putty mijn SSH verbinding opende kreeg ik in eens de melding dat de RSA2 Fingerprint niet overeenkwam met die van mijn vroeger, dus…

STRESS! Eerste gedachte is natuurlijk ben ik gehackt? Maar hoe kom je daar achter… Dus even gegoogeld. Kwam ik op deze website: https://bash-prompt.net/guides/server-hacked/. Gedaan wat daar staat natuurlijk.
- Niemand anders is ingelogd, ook niet in het verleden.
- Command history is net zo als ik hem heb achter gelaten.
- lsof -i geeft wel rare IP adressen!

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Alle IP-adressen komen vanuit China en worden ook gereport als abusing.

Dus ja, wat denken jullie ervan?
Het is toch zeer apart dat mijn Fingerprint zomaar verandert. Wat ik echter gisteren wel heb gedaan is een snapshot gemaakt en daarna niet meer geSSH'ed. En gisteren was ook wel apart dat mijn VM zomaar uit stond...

[CurlyMo]

Ik mis in die tutorial een check in je /var/log/auth.log:

code:

grep 'sshd' /var/log/auth.log

Daarin zie je welke inlogpogingen er op je SSH verbinding zijn gedaan, en welke succesvol waren. Als je geen succesvolle logins ziet, anders dan die van jezelf, dan is er waarschijnlijk niet via SSH ingelogd.

[Lethalis]

Je schrijft dat de VM uit stond. Heeft deze na het opnieuw opstarten eventueel een ander IP adres gekregen?

[CurlyMo]

Overigens, hoe log je in via SSH? Met een privé sleutel of alleen met een gebruikersnaam + wachtwoord?

[Chilly_Willy]

Lijkt mij verstandig om iig fail2ban met SSH jail te installeren of nog beter poort 22 alleen vanaf je eigen ip openstellen. En uiteraard inloggen met password uitschakelen en alleen via public keys en sterke ciphers gebruiken.

Hier wat config voor je /etc/ssh/sshd_config

code:

# Ciphers
KexAlgorithms [e-mail],ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers [e-mail],[e-mail],[e-mail],aes256-ctr,aes192-ctr,aes128-ctr
MACs [e-mail],[e-mail],[e-mail],hmac-sha2-512,hmac-sha2-256,[e-mail]

PasswordAuthentication no
PubkeyAuthentication yes

[ Voor 71% gewijzigd door Chilly_Willy op 10-09-2018 17:12 ]

[MiliaanR]

Bedankt voor de snelle reply's allemaal!

CurlyMo schreef op maandag 10 september 2018 @ 17:03:
Ik mis in die tutorial een check in je /var/log/auth.log:

code:

grep 'sshd' /var/log/auth.log

Daarin zie je welke inlogpogingen er op je SSH verbinding zijn gedaan, en welke succesvol waren. Als je geen succesvolle logins ziet, anders dan die van jezelf, dan is er waarschijnlijk niet via SSH ingelogd.

Ik heb dit net even gedaan, nouja, log bestanden (2) even gedownload enne, ze zijn nog al groot. Mijn Webstorm wil eentje niet helemaal openen omdat die te groot is! Meer dan een 100.000 invoeren zijn er...
Blijkbaar stond de VM nog niet online of hij werd al bestookt!

Ik moest hiervoor natuurlijk even mijn VM weer aan doen, en toen stond deze lijn ook in de log:

Sep 10 17:05:49 Festivallen2 chpasswd[729]: pam_unix(chpasswd:chauthtok): password changed for root

Vond ik redelijk opvallend maar ik weet ook niet of dit normaal is.

Lethalis schreef op maandag 10 september 2018 @ 17:04:
Je schrijft dat de VM uit stond. Heeft deze na het opnieuw opstarten eventueel een ander IP adres gekregen?

Ja klopt, maar het IP-adres is gelijk gebleven.

CurlyMo schreef op maandag 10 september 2018 @ 17:07:
Overigens, hoe log je in via SSH? Met een privé sleutel of alleen met een gebruikersnaam + wachtwoord?

Privésleutel die een sterk wachtwoord heeft.

Chilly_Willy schreef op maandag 10 september 2018 @ 17:07:
Lijkt mij verstandig om iig fail2ban met SSH jail te installeren of nog beter poort 22 alleen vanaf je eigen ip openstellen. En uiteraard inloggen met password uitschakelen en alleen via public keys en sterke ciphers gebruiken.

Hier wat config voor je /etc/ssh/sshd_config

code:

# Ciphers
KexAlgorithms [e-mail],ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers [e-mail],[e-mail],[e-mail],aes256-ctr,aes192-ctr,aes128-ctr
MACs [e-mail],[e-mail],[e-mail],hmac-sha2-512,hmac-sha2-256,[e-mail]

PasswordAuthentication no
PubkeyAuthentication yes

Bedankt voor de tip, ik ga der nu meteen mee bezig Chilly_Willy!

[CurlyMo]

MiliaanR schreef op maandag 10 september 2018 @ 17:21:
Blijkbaar stond de VM nog niet online of hij werd al bestookt!

Log nogmaals in en zorg ervoor dat je eventjes alle ip adressen blokkeert buiten de jouwe:

code:

# /etc/hosts.allow
sshd: 1.2.3.0/255.255.255.0

# /etc/hosts.deny
ALL: ALL

Dat zolang je nog niet weet waar het probleem zit.

Ik heb dit net even gedaan, nouja, log bestanden (2) even gedownload enne, ze zijn nog al groot. Mijn Webstorm wil eentje niet helemaal openen omdat die te groot is! Meer dan een 100.000 invoeren zijn er...

Je kan dat grep commando toch wel draaien?

Ik moest hiervoor natuurlijk even mijn VM weer aan doen, en toen stond deze lijn ook in de log:

Sep 10 17:05:49 Festivallen2 chpasswd[729]: pam_unix(chpasswd:chauthtok): password changed for root

Als je niet zelf op die datum je wachtwoord hebt veranderd dan is het foute boel. Maar voordat je verder gaat zul je eerst je machine bruut moeten beveiligen. Bijvoorbeeld door een harde white- en blacklist.

Privésleutel die een sterk wachtwoord heeft.

Check eerst zo even of ze wel via SSH binnengekomen zijn of via een andere weg. Dat staat dus in je auth.log.

Kern is hier of je ook hebt ingesteld dat je alleen met een sleutel mag inloggen, of dat je ook met een sleutel mag inloggen.

[ Voor 5% gewijzigd door CurlyMo op 10-09-2018 17:52 ]

[Hero of Time]

En bovenal, omdat het root wachtwoord blijkbaar is verandert (dat is zéér ongebruikelijk!) moet je nu er niets meer vertrouwen. Je sshd_config had allang de regel moeten hebben dat root niet mag inloggen, iig niet met wachtwoord. Dus hoewel jij met een passphrase beveiligde key je machine benadert, kan root met wachtwoord alsnog wagenwijd open staan.

Wat heb/had je er allemaal op draaien? Wat was van buitenaf bereikbaar? Elk item is een doelwit die je dus moet beveiligen.

[MiliaanR]

CurlyMo schreef op maandag 10 september 2018 @ 17:50:
[...]

1. Log nogmaals in en zorg ervoor dat je eventjes alle ip adressen blokkeert buiten de jouwe:

[...]

2. Je kan dat grep commando toch wel draaien?

[...]

3. Als je niet zelf op die datum je wachtwoord hebt veranderd dan is het foute boel. Maar voordat je verder gaat zul je eerst je machine bruut moeten beveiligen. Bijvoorbeeld door een harde white- en blacklist.


[...]

4. Check eerst zo even of ze wel via SSH binnengekomen zijn of via een andere weg. Dat staat dus in je auth.log.

5. Kern is hier of je ook hebt ingesteld dat je alleen met een sleutel mag inloggen, of dat je ook met een sleutel mag inloggen.

1. Dit heb ik nu gedaan en getest met VPN en het werkt! Bedankt voor de tip! Stellen jullie normaal in dat dit altijd via een VPN moet? Het lijkt me zo lullig als je ISP je IP verandert en je komt er niet meer!
2. Jawel, maar grep pakt bij mij grofweg 100 regels ofzo.. Met nano is mij wel gewoon gelukt.
3. Ja dat was dus heel apart, dat is het moment dat ik inlogde via SSH (staat er één regel onder en zelfde tijdstip) en dan staat er zo'n rare melding?
4. Helemaal schoon, geen SSH inlogging die niet van mij zijn en er zijn ook geen andere inlog pogingen door heen gekomen.
5. Dat is dus wel appart want toen ik die /etc/ssh/sshd_config heb aangepast stond

code:

PasswordAuthentication yes

ipv op nee. En publickeyauth stond er niet eens in?

Hero of Time schreef op maandag 10 september 2018 @ 18:54:
En bovenal, omdat het root wachtwoord blijkbaar is verandert (dat is zéér ongebruikelijk!) moet je nu er niets meer vertrouwen. Je sshd_config had allang de regel moeten hebben dat root niet mag inloggen, iig niet met wachtwoord. Dus hoewel jij met een passphrase beveiligde key je machine benadert, kan root met wachtwoord alsnog wagenwijd open staan.

Wat heb/had je er allemaal op draaien? Wat was van buitenaf bereikbaar? Elk item is een doelwit die je dus moet beveiligen.

Ik kom er moeilijk achter of dit nou wel open stond, er zijn geen inlogpoging er door heen gekomen die gewoon op een andere manier er in proberen te komen, maar toen ik die /etc/ssh/sshd_config heb aangepast stond

code:

PasswordAuthentication yes

ipv op nee. En publickeyauth stond er niet eens in?

Ik was net lekker bezig om mijn Magento webshopje een beetje lekker te laten draaien

[CurlyMo]

MiliaanR schreef op maandag 10 september 2018 @ 22:08:
[...]
1. Dit heb ik nu gedaan en getest met VPN en het werkt! Bedankt voor de tip! Stellen jullie normaal in dat dit altijd via een VPN moet? Het lijkt me zo lullig als je ISP je IP verandert en je komt er niet meer!

Dit is niet wat ik voorstelde, maar goed. Dit is ook een optie. Voor dat laatste geval kan je zelf iets scripten i.c.m. ddns.

Ik stel in dat je alleen met een sleutel in kan loggen als root en niks anders. Niet met een wachtwoord. Daarnaast draait er fail2ban. Als er meerdere admins actief zijn op de server dan mogen die alleen onder hun eigen account inloggen en moeten ze gebruik maken van sudo voor admin activiteiten. Zo kan je in de logs altijd zien wie wat gedaan heeft.

2. Jawel, maar grep pakt bij mij grofweg 100 regels ofzo.. Met nano is mij wel gewoon gelukt.

Dan zet je die output toch weer in een bestand?

code:

grep 'SSH' /var/log/auth.log > /tmp/output

Scheelt een hoop laad tijd voor nano.

5. Dat is dus wel appart want toen ik die /etc/ssh/sshd_config heb aangepast stond

code:

PasswordAuthentication yes

ipv op nee. En publickeyauth stond er niet eens in?

Dat is dus het probleem. Het kan bijna niet dat je niks in je logs ziet. Want elke publieke server is wel doelwit van brute force pogingen. En het lijkt nu gelukt te zijn via brute force.

Ik was net lekker bezig om mijn Magento webshopje een beetje lekker te laten draaien

Volgens mij heb je niet de kennis om zelf een webserver te hosten. Dus doe jezelf en ons een plezier en ga naar een hosting provider die er wel verstand van heeft. Je bent u een lopende schietschijf voor hackers. Deze gevallen is o.a. hoe botnet's kunnen draaien.

[Thralas]

MiliaanR schreef op maandag 10 september 2018 @ 22:08:
1. Dit heb ik nu gedaan en getest met VPN en het werkt! Bedankt voor de tip! Stellen jullie normaal in dat dit altijd via een VPN moet? Het lijkt me zo lullig als je ISP je IP verandert en je komt er niet meer!

VPN? Gooi je thuisadres erin, uitzonderingen daargelaten is die héél erg statisch. Worst case scenario heeft PCExtreme vast wel een VNC-achtige console.

Of vergeet IP-blokkades, zie onder.

3. Ja dat was dus heel apart, dat is het moment dat ik inlogde via SSH (staat er één regel onder en zelfde tijdstip) en dan staat er zo'n rare melding?
4. Helemaal schoon, geen SSH inlogging die niet van mij zijn en er zijn ook geen andere inlog pogingen door heen gekomen.

Zal dan eerder te maken hebben met een cloudplatform dat je wachtwoord opnieuw set dan dat er werkelijk iets aan de hand is - tenzij je rootwachtwoord '12345' was. Zie ook de timestamp.

Zoek er wel een verklaring bij, en ga na waarom je host keys (lijken) te zijn gewijzigd. Stel dat er wél een Chinees op je server zou zitten, dan waren eerder bitcoins aan het minen - je hostkeys wijzigen is dan wel het laatste wat er zou gebeuren.

5. Dat is dus wel appart want toen ik die /etc/ssh/sshd_config heb aangepast stond

code:

PasswordAuthentication yes

ipv op nee. En publickeyauth stond er niet eens in?

PasswordAuthentication yes is uiteraard een default, anders kun je geen sleutel instellen op een zinnige manier.

Wat je vooral moet doen is password auth nu disablen, dan kun je IP-restricties ook vergeten als je twijfelt of je een statisch adres kunt garanderen.

Met password auth aan is er altijd wel een Chinees druk bezig z'n dictionary voor te lezen (zie ook de ESTABLISHEDs uit je TS), zonder disconnecten ze meteen weer omdat er niets te bruteforcen valt. Dat stelt qua logs echt he-le-maal niets voor.

[ Voor 7% gewijzigd door Thralas op 10-09-2018 22:34 ]

[Hero of Time]

Die site is dus compromised en hierdoor is sshd_config aangepast. Dat jij dan in de audit.log niets ziet is ook een teken dat ze volledige toegang hebben. Want het is een peulenschil om je eigen inlog entry eruit te knikkeren. Of zelfs eruit te houden middels filtering e.d.

@CurlyMo, ik zou dus nooit direct met root inloggen via SSH. Je neemt een gebruiker die sudo mag uitvoeren, alleen met public key op SSH er bij kan en een goed wachtwoord om sudo te beveiligen. Als het even kan zelfs 2-factor (ja, dat is mogelijk maar maakt het ook een stuk complexer).

[CurlyMo]

Hero of Time schreef op maandag 10 september 2018 @ 22:26:
@CurlyMo, ik zou dus nooit direct met root inloggen via SSH. Je neemt een gebruiker die sudo mag uitvoeren, alleen met public key op SSH er bij kan en een goed wachtwoord om sudo te beveiligen. Als het even kan zelfs 2-factor (ja, dat is mogelijk maar maakt het ook een stuk complexer).

Op privé servers die alleen in eigen beheer zijn log ik wel direct op root in via ssh keys. De kans dat dat fout gaat mits goed ingesteld is verwaarloosbaar.

[Hero of Time]

CurlyMo schreef op maandag 10 september 2018 @ 22:29:
[...]

Op privé servers die alleen in eigen beheer zijn log ik wel direct op root in via ssh keys. De kans dat dat fout gaat mits goed ingesteld is verwaarloosbaar.

Volledig intern en met geen mogelijkheid van buiten benaderbaar zie ik het nog door de vingers, maar voor de rest is het gewoon vragen om problemen. Waarom denk je dat de default bij Red Hat is dat je niet met root over SSH in mag loggen? Sterker nog, de default van openssh is juist dat je met wachtwoord er niet in mag, alleen met keys.

Puur voor tracability log ik niet direct in met root, maar met named accounts (ieder z'n eigen, geen shared).

[CurlyMo]

Hero of Time schreef op maandag 10 september 2018 @ 22:34:
[...]
Sterker nog, de default van openssh is juist dat je met wachtwoord er niet in mag, alleen met keys.

Dat doe ik dan ook niet. Alleen via een sleutel. Met ook een IP whitelist. Fail2ban.

[Thralas]

Hero of Time schreef op maandag 10 september 2018 @ 22:34:
Waarom denk je dat de default bij Red Hat is dat je niet met root over SSH in mag loggen?

Ik denk dat je Red Hat met Ubuntu verwart. Bij een vanilla CentOS (en dus Red Hat) kun je gewoon als root inloggen.

Sterker nog, de default van openssh is juist dat je met wachtwoord er niet in mag, alleen met keys.

Nou...

Ubuntu verscheept volgens mij wel PermitRootLogin prohibit-password, zo uit 't hoofd.

Puur voor tracability log ik niet direct in met root, maar met named accounts (ieder z'n eigen, geen shared).

Dat is een prima argument voor een gedeelde server.

[CurlyMo]

Wat nog beter is, is om via PCExtreme de firewall compleet dicht te gooien en even via een webbased VNC of terminal in te loggen. Dan weet je zeker dat er niemand meer bij kan.

[eric.1]

Niet lullig bedoeld, maar denk eens na over een volledig managed oplossing (waarbij de hoster dus o.a. de beveiliging en basisconfiguratie op zich neemt). Kost meer, maar dit kan je als webshop ook niet hebben toch?

Zoals ik het nu lees stonden zelfs de hele basale configs volledig verkeerd.

Geen idee of je al klanten had en betaal- en/of facturatiegegevens ergens had staan o.i.d., anders mag(/moet) je daar ook nog een melding van maken volgens mij .

[MiliaanR]

Opzich is er niet heel veel aan de hand hoor ik had alleen net mijn Magento draaien en het uiterlijk een beetje aan gepast. Omdat ik ooit ook een VPS bij GCP heb gehad waarbij de beveiliging volgens mij van het begin al direct best prima was geregeld ging ik er vanuit dat dit bij PCExtreme ook zo zou zijn, niet dus!
Ik ben nu bezig met een nieuwe VPS te creëeren waarbij de basis wel goed is geregeld (zover de guide's zeggen igg).
De oude server laat ik nog even draaien, denken jullie dat ik ook veilig de inhoud www/html kan over kopieren of moet ik alles even met de hand terug zetten?

Goed leer moment wel, eerst alles goed regelen anders kan je alles weg moeten doen!

[The_Worst]

Als de server gehackt is dan moet je alles als onveilig beschouwen.

[CurlyMo]

MiliaanR schreef op maandag 10 september 2018 @ 23:49:
Omdat ik ooit ook een VPS bij GCP heb gehad waarbij de beveiliging volgens mij van het begin al direct best prima was geregeld ging ik er vanuit dat dit bij PCExtreme ook zo zou zijn, niet dus!

Dat zou heel raar zijn, want het hele idee van een VPS is nu juist dat je zelf 100% controle hebt over je installatie, dus ook beveiliging. Ik denk dat je bij GCP vooral geluk hebt gehad. Het enige wat zo'n bedrijf doet is een periodieke check of de basis beveiliging op orde is en zo niet, dan krijg je een waarschuwing en daarna je VPS wordt dichtgezet, mits je het niet oplost.

Ik ben nu bezig met een nieuwe VPS te creëeren waarbij de basis wel goed is geregeld (zover de guide's zeggen igg).

Wat heb je met een VPS te winnen over een managed oplossing?

De oude server laat ik nog even draaien, denken jullie dat ik ook veilig de inhoud www/html kan over kopieren of moet ik alles even met de hand terug zetten?

Nee, zoals aangegeven is alles verdacht. Je zult dus alles ook moeten controleren.

[ Voor 5% gewijzigd door CurlyMo op 11-09-2018 07:21 ]

[Hero of Time]

Thralas schreef op maandag 10 september 2018 @ 22:41:
[...]

Ik denk dat je Red Hat met Ubuntu verwart. Bij een vanilla CentOS (en dus Red Hat) kun je gewoon als root inloggen.

Zou kunnen, maar ik maak dan ook altijd een extra gebruiker aan bij CentOS installaties en stel geen wachtwoord in voor root, waardoor je daar niet interactief mee kan inloggen.

[...]

Nou...

Ubuntu verscheept volgens mij wel PermitRootLogin prohibit-password, zo uit 't hoofd.

Kijk bij je link eens naar regel 32. Ik gebruik zelf Debian, Ubuntu neemt die default over en openssh heeft al prohibit-password als default. Dus, wat ik zeg klopt ook gewoon. Heb tenslotte de man-page ernaast gehad.

[...]

Dat is een prima argument voor een gedeelde server.

Ook zonder zou ik het doen. Juist om root zo veel mogelijk dicht te zetten om dit soort ongein te voorkomen.

[Lethalis]

MiliaanR schreef op maandag 10 september 2018 @ 23:49:
Opzich is er niet heel veel aan de hand hoor ik had alleen net mijn Magento draaien en het uiterlijk een beetje aan gepast. Omdat ik ooit ook een VPS bij GCP heb gehad waarbij de beveiliging volgens mij van het begin al direct best prima was geregeld ging ik er vanuit dat dit bij PCExtreme ook zo zou zijn, niet dus!

Je hele probleem is waarschijnlijk Magento

In het kader van beveiliging kijk je in principe altijd naar een attack surface. Dat wil zeggen dat alle diensten die benaderbaar zijn, een potentieel gevaar vormen.

Dit kan dus zijn:
- OpenSSH
- Apache met PHP en alle webapplicaties die daarop draaien
- MySQL

Enzovoorts.

Naar mijn mening moet je dan dus op zijn minst ervoor zorgen dat alleen HTTP open staat naar buiten toe en dat je SSH alleen via een key kunt benaderen (dus geen wachtwoorden, root etc toestaan).

Zorg je er vervolgens voor dat je regelmatig updates installeert, dan zit je op systeemniveau relatief safe.

Het grootste probleem echter - en ook de reden waarom veel webservers gehackt worden - zijn die webapplicaties. Je bent namelijk veel minder geneigd om die steeds bij te werken en mensen maken ook fouten in de configuratie daarvan. Het zou niet de eerste keer zijn dat een hacker via een PHP webapplicatie ervoor zorgt dat hij commando's kan uitvoeren op een Linux server.

Om de beveiliging daarvan beheersbaar te maken, wordt er tegenwoordig veel gewerkt met container oplossingen zoals Docker, waarbij elke applicatie in zijn eigen geïsoleerde bubbel draait.

Sloopt iemand jouw Magento omgeving? Dan zet je die even terug, terwijl de rest van jouw systeem nog in orde is. En nog leuker: je kan via Docker eenvoudig upgraden naar de nieuwste versie.

Natuurlijk zou in theorie iemand gebruik kunnen maken van namespace vulnerabilities in de Linux kernel om vanuit de container op de host te komen, maar die kans is vele malen kleiner dan dat iemand een PHP webapplicatie hackt

Kortom, anno nu is het veel eenvoudiger om met containerized applicaties te werken om de boel eenvoudig en beheersbaar te houden.

Alles direct op de host draaien is vragen om problemen als je niet weet wat je doet

PS
Zoek voor de fun eens op "Magento remote code execution"

[HollowGamer]

Sinds ik poort 22 jaren geleden veranderd heb in één ander getal zijn er nagenoeg geen aanvallen meer geweest. Zodra ik het weer omzet is het raak met scripts die proberen in te loggen (zonder succes, kan enkel met keys).

Fail2ban is zeker aan te raden, maar er is zoveel meer. Kijk ook even naar de Arch Linux Security wiki pagina.

[XyritZz]

Lethalis schreef op dinsdag 11 september 2018 @ 08:32:
[...]

Kortom, anno nu is het veel eenvoudiger om met containerized applicaties te werken om de boel eenvoudig en beheersbaar te houden.

[...]

Ik zeg niet dat het slecht advies is, maar je moet er wel verstand van hebben om dit goed op te zetten. Velen hebben dat niet, en dan komen ze niet verder dan een setup script voor Docker ergens van een website plukken en dat copy pasten.

Dan zit je in je live draaiende omgeving met een architectuur/structuur waar je zelf geen verstand van hebt, en waar je geen inzicht in hebt wat nu precies hoe en waar draait. Dat is ook geen recept voor een veilig bestaan van je magento shop.

Voor nu zou ik zeggen; server als gehackt/verloren beschouwen en gewoon een nieuwe server opzetten. Daarin de tips van dit topic opvolgen en de server compleet dicht timmeren, daarna een schone magento installatie opzetten van de nieuwste versie en via een migratie alleen de data die je nog nodig hebt uit je oude database overzetten.

[Lethalis]

HollowGamer schreef op dinsdag 11 september 2018 @ 08:42:
Sinds ik poort 22 jaren geleden veranderd heb in één ander getal zijn er nagenoeg geen aanvallen meer geweest. Zodra ik het weer omzet is het raak met scripts die proberen in te loggen (zonder succes, kan enkel met keys).

Ondanks het hele security by obscurity verhaal, is dit toch goed advies. Om de simpele reden dat de meeste scripts van aanvallers maar een paar verschillende portnummers proberen.

XyritZz schreef op dinsdag 11 september 2018 @ 08:43:
Ik zeg niet dat het slecht advies is, maar je moet er wel verstand van hebben om dit goed op te zetten. Velen hebben dat niet, en dan komen ze niet verder dan een setup script voor Docker ergens van een website plukken en dat copy pasten.

Mja, maar dan kun je dus beter terugvallen op het andere advies hier in dit topic, namelijk een compleet managed oplossing waarbij hij zelf niks meer doet

Een (Linux) server beheren kost tijd en als je je daar niet in verdiept, gaat het sowieso vroeg of laat een keer mis.

Zo ken ik ook mensen die hun Synology NAS beschikbaar hadden gemaakt op het internet

[Hero of Time]

XyritZz schreef op dinsdag 11 september 2018 @ 08:43:
Voor nu zou ik zeggen; server als gehackt/verloren beschouwen en gewoon een nieuwe server opzetten. Daarin de tips van dit topic opvolgen en de server compleet dicht timmeren, daarna een schone magento installatie opzetten van de nieuwste versie en via een migratie alleen de data die je nog nodig hebt uit je oude database overzetten.

Die database migreren zou ik dan weer niet doen. Er is hier namelijk eerder een topic geweest van een ander CMS systeem dat gehackt was en daar was zelfs in de database nare javascript te vinden die dus zo toegevoegd zou worden op de pagina's. Dat moet je echt niet willen. Je bent dan meer tijd kwijt aan het napluizen van je data op integriteit dan dat je alles opnieuw opzet.

[HollowGamer]

Lethalis schreef op dinsdag 11 september 2018 @ 08:48:
[..]

Mja, maar dan kun je dus beter terugvallen op het andere advies hier in dit topic, namelijk een compleet managed oplossing waarbij hij zelf niks meer doet

Een (Linux) server beheren kost tijd en als je je daar niet in verdiept, gaat het sowieso vroeg of laat een keer mis.

Zo ken ik ook mensen die hun Synology NAS beschikbaar hadden gemaakt op het internet

Ben het helemaal met je eens, genoeg bedrijven en particulieren die dit ook niet op orde hebben en een VPS gewoon openstaat/geen security updates meer hebben gehad.

Een managed VPS kan btw. ook worden gehackt, niet zozeer het CP, maar een script kan net zo goed inbreken op een CMS. Het is gewoon niet uit te sluiten, daarom moet je regelmatig scans doen en vooral veel werken met versiebeheer.

Helaas zijn die Synology NAS'en (andere overigens ook) heel eenvoudig open te zetten. Het gaat allemaal via UPnP en zonder enige vorm van kennis.

Hero of Time schreef op dinsdag 11 september 2018 @ 09:28:
[...]

Die database migreren zou ik dan weer niet doen. Er is hier namelijk eerder een topic geweest van een ander CMS systeem dat gehackt was en daar was zelfs in de database nare javascript te vinden die dus zo toegevoegd zou worden op de pagina's. Dat moet je echt niet willen. Je bent dan meer tijd kwijt aan het napluizen van je data op integriteit dan dat je alles opnieuw opzet.

Daar bestaan weer scripts voor als ik mij niet vergist, deze halen zoveel mogelijk zooi eruit en kijken of iets verdacht is. Als het maar één paar pagina's zijn is dat geen probleem, maar bij een hele boel wordt het al een ander verhaal.

Een betere optie is (database + data) exports/snapshots maken, die kun je dan terugzetten. Met iets als borg kan je dan ook checken welke changes zijn gemaakt.

[ Voor 47% gewijzigd door HollowGamer op 11-09-2018 09:45 ]

[Hero of Time]

@HollowGamer, TS gaf aan dat hij het net pas had opgezet, er draait nog niks in. Opnieuw beginnen is dan makkelijker.

[MiliaanR]

De oude server heb ik in lock down gedaan dus alleen mijn eigen IP kan die benaderen.
Dit zijn de dingen die ik allemaal op mijn nieuwe server heb gedaan. Lijkt dit veilig?

code:

Apt update
Apt upgrade

nano etc/ssh/sshd_config
Change the following: 
Change Port to 43**8
#Ciphers and keying
KexAlgorithms [e-mail],ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers [e-mail],[e-mail],[e-mail],aes256-ctr,aes192-ctr,aes128-ctr
MACs [e-mail],[e-mail],[e-mail],hmac-sha2-512,hmac-sha2-256,[e-mail]
PermitRootLogin prohibit-password
PubkeyAuthentication yes
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no

Reboot.

Ufw allow 43**8
ufw allow http
ufw allow https

Apt install jail2ban
cp /etc/fail2ban/fail2ban.conf /etc/fail2ban/fail2ban.local
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
nano jail.local
uncomment #[sshd] & # enable = true
find enabled = false -> change to enabled = true
Change port number under [sshd]

[CurlyMo]

MiliaanR schreef op dinsdag 11 september 2018 @ 13:45:
De oude server heb ik in lock down gedaan dus alleen mijn eigen IP kan die benaderen.
Dit zijn de dingen die ik allemaal op mijn nieuwe server heb gedaan. Lijkt dit veilig?

code:

Verhaal

Heb je zelf als eens een basis penetratie test gedaan?

- Kan je inloggen zonder wachtwoord en ook met alleen wachtwoord?
- Kan je andere poorten bereiken?
- Hoe vaak kan je verbinding maken met je server voordat je IP geblokkeerd wordt?
- Weet je wat je moet doen als je eigen IP geblokkeerd wordt?
- Weet je überhaupt wel wat je nu hebt ingesteld? Dus weet je niet alleen dat het werkt, maar ook hoe en waarom?
- Heb je een noodplan als je weer gehacked wordt? Bijv. versioned backups.
Enz.