Laptop gehackt (SSH Ubuntu Jaunty)

[gertvdijk]

Vanavond ontdekte ik op mijn laptop een hoge CPU load en ik vroeg me af waar dit vandaan kwam. Top gaf mij een output die erg verdacht was. Een accountje dat ik gebruik om dingen te testen die ik niet in mijn eigen user environment wil draaien had tientallen processen openstaan waarvan een find proces dat de CPU en disk zwaar belastte.

Laat ik eerst even de situatie schetsen zoals die nu al een maandje of drie is:

• laptop met Ubuntu 9.04, met 1 'serieus' user account en 1 'test' account (met slap wachtwoord).
• Dat test account heeft zeer beperkte rechten (geen sudo - niet in groep 'admin'!)
• de /home/gert 'serieuze' user homedir was 'drwx------', i.t.t. default Ubuntu.
• alle security updates gedraaid
• SSH draait zonder aanpassingen
• Internetverbinding staat open most of the time (100/100 Mbit)
• ik was in de veronderstelling dat ik fail2ban draaide en ik alleen mijn serieuze account toegang had gegeven in sshd_config (AllowUsers). Blijkbaar was dat beide niet het geval.
• Ik draai nog 2.6.28-11, omdat ik met -12 en -13 in de jaunty-proposed repo problemen heb met VirtualBox.
• Wekelijks draai ik volledige backups van het / filesystem d.m.v. rdiff-backup dus ik backup ook binaries.

Vandaag was mijn laptop online tot ongeveer 12.20u en is pas weer begin van de avond weer aan het internet gehangen.

Wat mijn eerste onderzoekje heeft opgeleverd:

• /var/log/auth.log (en gerotate files) laat mij zien dat er voor het eerst succesvol is ingelogd vanochtend om 6u. en er wat is gebeurd dat ik niet helemaal begrijp.
  

  Jun 18 06:36:51 gert-laptop sshd[16083]: Accepted password for test from 173.15.x.x port 24256 ssh2
  Jun 18 06:36:51 gert-laptop sshd[16083]: pam_unix(sshd:session): session opened for user test by (uid=0)
  Jun 18 06:36:51 gert-laptop dbus-daemon: Rejected send message, 1 matched rules; type="method_call", sender=":1.4757" ([red]uid=1000[/red] pid=1987 comm="/usr/lib/indicator-applet/indicator-applet --oaf-a") interface="org.freedesktop.DBus.Properties" member="Get" error name="(unset)" requested_reply=0 destination=":1.4905" (uid=0 pid=16083 comm="sshd: test [priv]"))
  Jun 18 08:01:02 gert-laptop sshd[16083]: pam_unix(sshd:session): session closed for user test

  
  Let op uid=1000. Dat is het UID van user gert, niet van user test... Wat heeft die dbus-daemon log voor implicaties gehad of wat probeerde de bot/hacker?
• Vanavond is hij weer verder gegaan onder een ander IP en wijzigde hij het wachtwoord:
  

  Jun 18 21:50:40 gert-laptop sshd[3772]: Accepted password for test from 81.203.x.x port 2417 ssh2
  Jun 18 21:50:40 gert-laptop sshd[3772]: pam_unix(sshd:session): session opened for user test by (uid=0)
  Jun 18 21:50:40 gert-laptop dbus-daemon: Rejected send message, 1 matched rules; type="method_call", sender=":1.5578" ([red]uid=1000[/] pid=23762 comm="/usr/lib/indicator-applet/indicator-applet --oaf-a") interface="org.freedesktop.DBus.Properties" member="Get" error name="(unset)" requested_reply=0 destination=":1.5689" (uid=0 pid=3772 comm="sshd: test [priv]"))
  Jun 18 21:51:58 gert-laptop passwd[3854]: pam_unix(passwd:chauthtok): password changed for test
  Jun 18 22:53:32 gert-laptop sshd[3772]: pam_unix(sshd:session): session closed for user test

• In syslog zie ik de volgende onheilspellende logs:
  

  Jun 18 21:18:27 gert-laptop kernel: [505111.104073] CE: hpet increasing min_delta_ns to 33750 nsec
  Jun 18 21:18:27 gert-laptop kernel: [505111.104186] CE: hpet increasing min_delta_ns to 50624 nsec
  Jun 18 22:12:43 gert-laptop kernel: [508367.306102] atack[5446]: segfault at 0 ip 0000000008048e33 sp 00000000ffbadc60 error 4 in atack[8048000+c0000]
  Jun 18 22:12:43 gert-laptop kernel: [508367.345849] atack[5524]: segfault at 0 ip 0000000008048e33 sp 00000000ffbadc60 error 4 in atack[8048000+c0000]
  Jun 18 22:12:43 gert-laptop kernel: [508367.351134] atack[5516]: segfault at 0 ip 0000000008048e33 sp 00000000ffbadc60 error 4 in atack[8048000+c0000]
  Jun 18 22:12:43 gert-laptop kernel: [508367.379476] atack[5532]: segfault at 0 ip 0000000008048e33 sp 00000000ffbadc60 error 4 in atack[8048000+c0000]
  Jun 18 22:12:43 gert-laptop kernel: [508367.381049] atack[5505]: segfault at 0 ip 0000000008048e33 sp 00000000ffbadc60 error 4 in atack[8048000+c0000]
  Jun 18 22:12:43 gert-laptop kernel: [508367.406808] atack[5506]: segfault at 0 ip 0000000008048e33 sp 00000000ffbadc60 error 4 in atack[8048000+c0000]
  Jun 18 22:12:43 gert-laptop kernel: [508367.408992] atack[5453]: segfault at 0 ip 0000000008048e33 sp 00000000ffbadc60 error 4 in atack[8048000+c0000]
  Jun 18 22:12:43 gert-laptop kernel: [508367.423671] atack[5457]: segfault at 0 ip 0000000008048e33 sp 00000000ffbadc60 error 4 in atack[8048000+c0000]
  Jun 18 22:12:43 gert-laptop kernel: [508367.426600] atack[5469]: segfault at fffffffd ip 00000000080a3377 sp 00000000ffbadc30 error 4 in atack[8048000+c0000]
  Jun 18 22:12:48 gert-laptop kernel: [508372.315855] __ratelimit: 74 callbacks suppressed

  
  en dit gaat nog zo even door... Tien minuten na die laatste melding heb ik mijn PPPoE verbinding verbroken en binnen tientallen seconden erna waren alle processen van de test user verdwenen.
• Er zijn geen binaries of andere rare files geplaatst in /home/test
• Ook niet in /home/test/.ssh
• Bash_history laten ook alleen mijn commando's zien.
• Er draaien geen processen meer van de test user voor zover ik kan zien met ps en top.

Wat ik helaas niet weet:

• Of er veel traffic is geweest (met 100Mbit upload kan dat makkelijk in een paar uur). Ik heb mijn verbinding verbroken voordat ik keek wat de statistics van de interface waren.
• Of de 'atack' regels in mijn logs een falende kernel exploit weergeven of juist een slagende poging kunnen betekenen.
• Wat is 'atack' überhaupt?

Voorzichtige conclusies:

• Gezien de tijd tussen de 'accepted password' en 'password changed' (1m18s) vermoed ik dat het om human-access gaat en niet een bot.
• Er is geen persoonlijke informatie buitgemaakt, gezien de beperkte rechten van de test user. Dit mits er geen kernel exploit is geslaagd.
• Omdat ik de 'kwade' processen nog kon zien draaien zijn mijn binaries niet overschreven met 'bogus' binaries. Ik kan eenvoudig checken of de binaries zijn overschreven (ik heb backups), maar het zijn er iets teveel om dit 'ff' te doen. Daarnaast moet ik dit doen middels een Live CD omgeving, omdat je in principe niks kan vertrouwen met de huidige draaiende kernel.
• De hacker heeft de logs niet gewist (had eenvoudig gekund - alle sshd vermeldingen verwijderen), wat duidt op slechts een userspace hack. Dit en het puntje erboven versterkt mijn vermoeden dat de kernel root exploit niet is gelukt.

Op dit moment ben ik heel blij dat ik mijn ssh-keys en GPG key allemaal heb beveiligd met een passphrase. Indien op straat zou dat toegang tot tientallen systemen geven, waarvan meeste ook root access... met alle systemen mooi op een rijtje in mijn ~/.ssh/config

Wat nu verder?

• Herinstallatie én alle keys revoken? (paranoid?)
• Alleen herinstalleren?
• Of kan ik ervan uitgaan dat er geen root exploit succesvol is geweest? En daarmee voldoende om de test user te verwijderen.

Een herinstallatie kost nou eenmaal wat meer tijd dan alleen mijn /home terugzetten na herinstallatie, gezien de grote hoeveelheid dingen die er system-wide op zijn geconfigureerd waar veel tijd/aandacht in is gestoken. Denk aan Apache, Moinmoin, etc. voor offline development en ook installatie van wat exotische hardware (Wacom bluetooth tablet).

Wat je me niet hoeft te vertellen/vragen:

• Dat de hacker via SSH is binnengekomen.
• Wat SSH op mijn laptop doet,
• Waarom mijn laptop niet achter een router/firewall hangt
• Dat het een slap gebruikersnaam/wachtwoord combinatie was en dat dat dom is
• Dat je SSH kan afschermen met AllowUsers
• Dat er pakketten zijn als fail2ban om de brute force attacks tegen te gaan
• Dat SSH toegang in de firewall beperkt kan worden tot specifiek IPs
• Dat je SSH ook op een alternatieve poort kan draaien.

Dat was gewoon dom, terwijl ik wel beter weet. Alle andere systemen die ik beheer/heb zijn wel goed afgeschermd. Mijn laptop is zo'n voorbeeld waarmee ik onterecht wat laks ben omgegaan.

Deze hack vind ik mega interessant om te gaan onderzoeken, maar tegelijkertijd heb ik relatief weinig tijd ervoor (tentamens).

edit: ik ben me ervan bewust dat dit topic wellicht beter geplaatst had kunnen worden in BV, maar ik acht dit onderzoek/impact analysis nauwer gerelateerd aan NOS.

[ Voor 9% gewijzigd door gertvdijk op 19-06-2009 00:52 ]

[pauldegroot]

Hé Gert.

Ik kan je geen adviezen geven maar leuke en duidelijke eerste post om te lezen!
Succes!

[bobsquad]

Ik zie dat hij toevallig via SSH toegang heeft gekregen. Heb dit zelf een tijdje ook over het hoofd gezien thuis bij een hardware firewall. Het enigste wat ik zo zie is dat hij toegang probeert te krijgen over het systeem. Voor de rest zou ik SSH zo veel mogelijk afschermen. Zelf heb ik in mijn firewall connect from any uitgeschakeld en alleen netwerken waar ik achter zit op allow gezet.

[mace]

heeft test sudo rechten? Aangezien je met sudo su kan su-en naar een andere user, maar dan hoef je het wachtwoord van die user niet in te voeren maar alleen je eigen wachtwoord.

Afhankelijk van je configuratie kan je dus elke willekeurige user (en dus ook root) worden met sudo su.

[VisionMaster]

Zo te zien is de misbruiker binnengekomen via je open SSH verbinding en het account naampje 'test' zit in veel standaard lijstjes van account namen om te proberen (net als backup, root en andere namen).

Alle delen van het file system waar 'test' schrijf rechten heeft zou ik als verloren beschouwen en misbruikt. Check of je je eigen home-dir niet ook te open hebt staan.

Met apt of aptitude zou je een verify kunnen draaien op je pakketten. Met redhat gebruik ik het rpm --verify <een pakket> commando om te verifieren of de binary nog hetzelfde is als bij de installatie/update en dat de file permissies onverandert zijn.

Als je het wilt onderzoeken moet je alles behouden en een volledige disk image maken. Zo niet, dan zou ik alle bestanden van dat account als 'tampert' beschouwen en kunnen in principe allemaal narigheid met zich mee brengen.

De aller veiligste oplossing is om je hele machine van scratch op nieuw te installeren. Er kunnen rootkits geinstalleerd zijn of andere dingen die net buiten de greep van je file system en tools blijven. Ik zou zelf al mijn keys revoken als ik ze op die machine had staan. Zeker als dat voor services is geweest, maar simpelweg alle keys moet je bechouwen als verloren.

[gertvdijk]

@bobsquad en mace: zie mijn updated post.
@VisionMaster: Mijn gevoel zegt dat het de hacker niet gelukt is om root te worden en dat hij geen toegang heeft gekregen tot mijn precious /home/gert. Toch ben ik met je eens dat het 't beste is als ik een volledige reinstall doe. Tijd voor onderzoek én herinstallatie heb ik al helemaal niet, helaas. Een disk image maken is ook nog eens een klein beetje lastiger dan doorgaans, aangezien alle behalve mijn /boot bestaat uit een LUKS encrypted partitie. Het revoken en opnieuw verspreiden van mijn keys is een redelijk uitgebreid klusje die ik dan maar voor lief moet nemen, vrees ik.
@TRRoads: voegde ik pas na de post van mace toe.

Waar ik op dit moment geïnteresseerd naar ben is voornamelijk de implicaties van die dbus-daemon met uid=1000 met sshd test (testuser uid=1001!). En de 'atack' regels in mijn syslog.

[ Voor 29% gewijzigd door gertvdijk op 19-06-2009 00:42 ]

[Anoniem: 178962]

mace schreef op vrijdag 19 juni 2009 @ 00:23:
heeft test sudo rechten? Aangezien je met sudo su kan su-en naar een andere user, maar dan hoef je het wachtwoord van die user niet in te voeren maar alleen je eigen wachtwoord.

Afhankelijk van je configuratie kan je dus elke willekeurige user (en dus ook root) worden met sudo su.

Zegt ie in z'n TS, heeft ie niet.

[Stacheldraht]

Gert die segfault meldingen in zijn waarschijnlijk afkomstig van een ssh brute force attack, met andere woorden men heeft vanaf jouw laptop andere hosts aangevallen Zie ook deze post:

http://nileshbansal.blogs.../06/ssh-brute-attack.html

Btw neem eens grondig een kijkje in /tmp en /var/tmp

[ Voor 10% gewijzigd door Stacheldraht op 19-06-2009 06:53 ]

[user109731]

gertvdijk schreef op vrijdag 19 juni 2009 @ 00:37:
Waar ik op dit moment geïnteresseerd naar ben is voornamelijk de implicaties van die dbus-daemon met uid=1000 met sshd test (testuser uid=1001!). En de 'atack' regels in mijn syslog.

Over die dbus-daemon berichten: die zie je op exact hetzelfde tijdstip als de login, en ik krijg het bericht ook als ik in Gnome ingelogd ben (weet niet zeker of dat nodig is) en ik log in met een ander account via SSH. Die kun je waarschijnlijk negeren

Aan het bericht te zien is het de indicator-applet van Gnome die iets probeert te versturen/ontvangen, waar dbus-daemon het niet mee eens is.

[benoni]

gertvdijk schreef op vrijdag 19 juni 2009 @ 00:02:

• Er zijn geen binaries of andere rare files geplaatst in /home/test
• Ook niet in /home/test/.ssh

Wat ik helaas niet weet:

• Of de 'atack' regels in mijn logs een falende kernel exploit weergeven of juist een slagende poging kunnen betekenen.
• Wat is 'atack' überhaupt?

Ik gok erop dat 'atack' het tooltje is wat gebruikt wordt voor de ssh cracks. Het hoeft op zich niet zichtbaar te zijn als je met het find-commando zoekt. Het kan zijn dat het wordt overgekopieerd, dan gestart en meteen verwijderd. Dan blijft het bestand geopend zonder vindbaar te zijn. Probeer even lsof of ps

[gertvdijk]

Stacheldraht schreef op vrijdag 19 juni 2009 @ 06:48:
Gert die segfault meldingen in zijn waarschijnlijk afkomstig van een ssh brute force attack, met andere woorden men heeft vanaf jouw laptop andere hosts aangevallen Zie ook deze post:

http://nileshbansal.blogs.../06/ssh-brute-attack.html

Dat klinkt erg plausibel.

Stacheldraht schreef op vrijdag 19 juni 2009 @ 06:48:
Btw neem eens grondig een kijkje in /tmp en /var/tmp

Niets bijzonders.

benoni schreef op vrijdag 19 juni 2009 @ 10:06:
Ik gok erop dat 'atack' het tooltje is wat gebruikt wordt voor de ssh cracks. Het hoeft op zich niet zichtbaar te zijn als je met het find-commando zoekt. Het kan zijn dat het wordt overgekopieerd, dan gestart en meteen verwijderd. Dan blijft het bestand geopend zonder vindbaar te zijn. Probeer even lsof of ps

Ik heb het gevonden met locate! Maar met een zeer vreemd pad, waar ik niet naar kan cd'en:

/home/test/  /spaniol
/home/test/  /spaniol.tar
/home/test/  /spaniol/121.1.find.22
[...]
/home/test/  /spaniol/74.105.find.22
/home/test/  /spaniol/atack
/home/test/  /spaniol/auto
/home/test/  /spaniol/data.conf
/home/test/  /spaniol/find
/home/test/  /spaniol/ip.conf
/home/test/  /spaniol/start
/home/test/  /spaniol/unix
/home/test/  /spaniol/vuln.txt

Wat zijn die / / ? spaties dus.
Anyway, een locate op spaniol geeft geen andere interessante locaties.

Maar ik zie die ' /spaniol' directory niet met ls! Toch gelukt root exploit?

Haha een data.conf met hele dictionary van gn/ww. Nou dit is het iig.

Ook leuk:

root@gert-laptop:/home/test/  /spaniol# cat unix 
#!/bin/bash
if [ $# != 1 ]; then
        echo " Folosim : $0 \[b class]"
        exit;
fi


echo "------------------------------------------------------------------------"
echo "#####    Spargerea anumitor sisteme se plateste cu inchisoarea!    #####"
echo "##          Special Scanner made by <Spaniol> Good Luck!!!            ##"
echo "##### Copyright 2006-2007 * You can Wait or go & Drink a Martini :)#####"
echo "------------------------------------------------------------------------"
./find $1 22

sleep 10
cat $1.find.22 |sort |uniq > ip.conf
oopsnr2=`grep -c . ip.conf`
echo "#--------------------------------------------------"
echo "#~  Bulannn doar $oopsnr2 pizde ai luat la Scan?! ~"
echo "---------------------------------------------------"
echo "# Hai Sa Le Da'm Pe Pizda!!! "
./atack 100
rm -rf$1.find.22 ip.conf
echo " Nu cred ma!!!Nu cred!!!Hristoase :)) Scan Finished on $1 ... !"

Minder leuke ontdekking is dat er een hele lijst bij zit met geslaagde pogingen. gn/ww/IP

[ Voor 27% gewijzigd door gertvdijk op 19-06-2009 12:08 ]

[Seth4Chaos]

gertvdijk schreef op vrijdag 19 juni 2009 @ 11:48:
Maar ik zie die ' /spaniol' directory niet met ls! Toch gelukt root exploit?

zie je hem niet in /home/test of niet in "/home/test/ /". in /home/test zie je namelijk gewoon 3 (of meer) spaties, en dat 'zie je niet met het blote oog' althans het valt niet op.

Minder leuke ontdekking is dat er een hele lijst bij zit met geslaagde pogingen. gn/ww/IP

minder leuk? altijd handig toch wat extra accountjes

[dion_b]

Yay, het waren Romenen die binnendrongen, danwel overige lui die gebruik maakten van Romeense tools. Die eerste "Spargerea" regel waarschuwt dat het inbreken op bepaalde systemen celstraf riskeert

Edit:
Even die IPs waar de attacks vandaan kwamen bekeken. De eerste zit in een enorme (/12 ofzo) Comcast range in US, de tweede is een /16 van CableEuropa, een Spaanse ISP. Vermoedelijk zijn dat ook niets anders dan gecompromisede bakken.

[ Voor 38% gewijzigd door dion_b op 19-06-2009 12:38 ]

[DrClaw]

ls -la om wat meer directories te zien, waaronder de 'hidden' ones.

lsof -i (moet je misschien installeren) om te zien welke processen allemaal luisteren op bepaalde ports. ik heb ooit een linuxbak moeten ontluizen, die een process hider had geinstalleerd. die haalde dus de gemene programmaatjes uit de ps tree.

[mace]

DrClaw schreef op vrijdag 19 juni 2009 @ 12:43:
lsof -i (moet je misschien installeren) om te zien welke processen allemaal luisteren op bepaalde ports.

Is dat niet gewoon net zoiets als netstat -p ?

[Wolfboy]

mace schreef op vrijdag 19 juni 2009 @ 12:46:
[...]

Is dat niet gewoon net zoiets als netstat -p ?

Ja
Al heeft lsof nog meer features die erg handig kunnen zijn

[gertvdijk]

Seth4Chaos schreef op vrijdag 19 juni 2009 @ 12:32:
zie je hem niet in /home/test of niet in "/home/test/ /". in /home/test zie je namelijk gewoon 3 (of meer) spaties, en dat 'zie je niet met het blote oog' althans het valt niet op.

Ik zie de directory met de naam van twee spaties echt niet als ik

ls -al /home/test/

doe. Ik kan dan wel cd'en d.m.v.

cd \ \ 

Is het een 'feature' dat je directories die bestaan uit spaties niet zichtbaar zijn met ls?

dion_b schreef op vrijdag 19 juni 2009 @ 12:35:
Yay, het waren Romenen die binnendrongen, danwel overige lui die gebruik maakten van Romeense tools. Die eerste "Spargerea" regel waarschuwt dat het inbreken op bepaalde systemen celstraf riskeert

LOL.

dion_b schreef op vrijdag 19 juni 2009 @ 12:35:
Even die IPs waar de attacks vandaan kwamen bekeken. De eerste zit in een enorme (/12 ofzo) Comcast range in US, de tweede is een /16 van CableEuropa, een Spaanse ISP. Vermoedelijk zijn dat ook niets anders dan gecompromisede bakken.

Dat had ik ook al opgezocht. Interessanter vond ik dat poort 22 dicht staat op dat Spaanse IP (ook vanaf andere IPs). Op die bak verwacht je namelijk wel dat dat open staat als die bak op eenzelfde manier is gehackt. Bovendien werd er vanaf dat IP het wachtwoord gewijzigd in human-speed. Daarom denk ik dat er een mens achter dat IP zat op dat moment.

DrClaw schreef op vrijdag 19 juni 2009 @ 12:43:
ls -la om wat meer directories te zien, waaronder de 'hidden' ones.

Ik ben geen groentje meer.

DrClaw schreef op vrijdag 19 juni 2009 @ 12:43:
lsof -i (moet je misschien installeren) om te zien welke processen allemaal luisteren op bepaalde ports. ik heb ooit een linuxbak moeten ontluizen, die een process hider had geinstalleerd. die haalde dus de gemene programmaatjes uit de ps tree.

Goede tip voor de volgende keer. Heeft weinig zin meer nu.

Nu ik de PPPoE verbinding op mijn desktop heb aangezet heb ik nog geen attempt gezien om met 'test' in te loggen. Ik kijk dat nog even aan, zodat ik daarvan het IP kan vergelijken.

Overigens is de accountnaam niet 'test'. Die heb ik overal search&replaced. In werkelijkheid was het een gewone naam met een gewoon slap wachtwoord. Pas dus, zou ik zeggen.

update: ik ben er ook achter waarom ik hem niet *dacht* te zien met ls. Probeer zelf maar eens een directory te maken:

mkdir \ \ 
ls -al

En zie waarom ik hem ook niet zag.

[ Voor 3% gewijzigd door gertvdijk op 19-06-2009 14:14 ]

[DrClaw]

vaak denken ze ook lollig te zijn en een directory ... te noemen.

'find . | more' helpt dan wel bij het zoeken. maareh, als je bak compromised is, dan herinstalleer ik liever die bak. 1x hadden ze bij mij mooi enkele programma's in sbin aangepast, en dat zijn dan toch je root tools.

[iMars]

gertvdijk schreef op vrijdag 19 juni 2009 @ 13:17:


Dat had ik ook al opgezocht. Interessanter vond ik dat poort 22 dicht staat op dat Spaanse IP (ook vanaf andere IPs). Op die bak verwacht je namelijk wel dat dat open staat als die bak op eenzelfde manier is gehackt. Bovendien werd er vanaf dat IP het wachtwoord gewijzigd in human-speed. Daarom denk ik dat er een mens achter dat IP zat op dat moment.

vi /etc/ssh/sshd_config

Zoek naar:

#Port 22

Haal '#' weg, zet daar bijvoorbeeld 22222 neer, saven, sluiten, sshd herstarten en je ssh poort is van 22 naar 22222 gegaan

Op al mijn linux bakken draait SSH op een andere port, maakt het moeilijker voor scripts.

[Stacheldraht]

Het hele probleem met dit soort dingen is dat het gebruik van SSH door middel van wachtwoorden tegenwoordig niet meer kan. En ik weet het op tweakers denkt men laat Stacheldracht maar lullen maar het is wel zo punt.

Verder is Gert een heel ervaren en kundige Linux/Unix gebruiker en het is absoluut geen schande wat hem is overkomen maar misschien is het toch een mooi leer moment voor de toekomst.

[Stacheldraht]

Btw over het aanmaken van vreselijk directorynamen gesproken. Als je iemand echt heel erg wil pesten is dit een leuke: mkdir '-'

[Wolfboy]

Stacheldraht schreef op vrijdag 19 juni 2009 @ 20:12:
Btw over het aanmaken van vreselijk directorynamen gesproken. Als je iemand echt heel erg wil pesten is dit een leuke: mkdir '-'

Nog leuker, "touch -- -rf", als je dan "rm *" doet dan maakt je shell er netjes "rm -rf ..." van.
Als je die nog combineert met "touch '*'" dan heb je zeker de meeste beginners te pakken

Imho moeten servers alleen maar via private keys te bereiken zijn, of met een ip whitelist als een private key geen eenvoudige optie is.

[Rainmaker]

Wolfboy schreef op vrijdag 19 juni 2009 @ 20:22:
[...]
Nog leuker, "touch -- -rf", als je dan "rm *" doet dan maakt je shell er netjes "rm -rf ..." van.
Als je die nog combineert met "touch '*'" dan heb je zeker de meeste beginners te pakken

Imho moeten servers alleen maar via private keys te bereiken zijn, of met een ip whitelist als een private key geen eenvoudige optie is.

Daar hadden ze mij een jaar of 5 geleden mee te pakken

Ik kom regelmatig "rare" directories tegen, zoals directories met ASCII characters erin.

En het is niet echt een feature van bash dat ie die niet laat zien, ze zijn gewoon moeilijk te spotten. ls -l maakt m iets makkelijker:

code:

Medusa ~ # ls -l 
totaal 661744
drwxr-xr-x 2 root root      4096 apr  6 04:08 boot
-rw-r--r-- 1 root root 315359232 jun 19 07:59 brasero.iso
-rw-r--r-- 1 root root       120 jun 19 08:09 brasero.toc
-rw-r--r-- 1 root root 362240928 jun 19 08:09 brasero.toc.bin
-rw-r--r-- 1 root root       408 apr  8 03:12 grub.cfg
-rw------- 1 root root       146 mei 10 13:10 nohup.out
Medusa ~ # mkdir \ \ 
Medusa ~ # ls -l 
totaal 661748
drwxr-xr-x 2 root root      4096 jun 20 03:00   
drwxr-xr-x 2 root root      4096 apr  6 04:08 boot
-rw-r--r-- 1 root root 315359232 jun 19 07:59 brasero.iso
-rw-r--r-- 1 root root       120 jun 19 08:09 brasero.toc
-rw-r--r-- 1 root root 362240928 jun 19 08:09 brasero.toc.bin
-rw-r--r-- 1 root root       408 apr  8 03:12 grub.cfg
-rw------- 1 root root       146 mei 10 13:10 nohup.out
Medusa ~ #

De bovenste dus

[MartinMeijerink]

Je moet toch echt alles opnieuw installeren, en alle wachtwoorden en keys veranderen, en dan ervoor zorgen dat voortaan niemand via ssh kan inloggen (ook root niet!), behalve 'gert', in /etc/security/access.conf zet je daarvoor het volgende:

code:

-:ALL EXCEPT gert:ALL

wel moet je hiervoor ook ff in /etc/pam.d/ssh het volgende toevoegen:

code:

account  required     pam_access.so

[MartinMeijerink]

Stacheldraht schreef op vrijdag 19 juni 2009 @ 20:00:
Het hele probleem met dit soort dingen is dat het gebruik van SSH door middel van wachtwoorden tegenwoordig niet meer kan. En ik weet het op tweakers denkt men laat Stacheldracht maar lullen maar het is wel zo punt.

Waarom geen ssh dmv wachtwoorden dan? Leg eens uit...

[Wolfboy]

MartinMeijerink schreef op zaterdag 20 juni 2009 @ 11:52:
[...]
Waarom geen ssh dmv wachtwoorden dan? Leg eens uit...

Wachtwoorden geven de mogelijkheid tot brute-force aanvallen en zijn dus afhankelijk van hoe sterk de wachtwoorden zijn die je gebruikers hebben gekozen. Bij een private key authenticatie systeem moeten ze eerst de private key te pakken krijgen en daarna het wachtwoord er nog eens bij kraken. Zelfs al lukt dat, of is er een vermoeden dat de private key uitgelekt is. Dan is het vrij eenvoudig om die private key te blokkeren en een nieuwe aan te maken.

[Stacheldraht]

Eigenlijk zou dit default in /etc/sshd_config moeten zijn:

PasswordAuthentication no
PermitRootLogin without-password

En de default voor adduser zou moeten zijn:

--disabled-password

Maar helaas dat is vast allemaal te ingewikkeld voor de meeste gebruikers

[Puch-Maxi]

Ik zou root login via ssh sowieso niet toestaan.

[user109731]

Ik wil overal (uni, werk, laptop, buitenland, etc.) thuis kunnen inloggen, daarom heb ik het nu zo ingesteld dat alleen mijn user via SSH erin mag en gebruik ik een sterk wachtwoord (> 12 tekens, inclusief hoofdletters, cijfers en vreemde tekens).

Waar slaan jullie de SSH keys op in zo'n geval? Op een stick die je altijd bij je hebt?
Is dat niet heel onhandig?

[34749]

JanDM schreef op zaterdag 20 juni 2009 @ 15:35:
Ik wil overal (uni, werk, laptop, buitenland, etc.) thuis kunnen inloggen, daarom heb ik het nu zo ingesteld dat alleen mijn user via SSH erin mag en gebruik ik een sterk wachtwoord (> 12 tekens, inclusief hoofdletters, cijfers en vreemde tekens).

Waar slaan jullie de SSH keys op in zo'n geval? Op een stick die je altijd bij je hebt?
Is dat niet heel onhandig?

Op een beveiligde USB stick inderdaad.

Persoonlijk heb ik zelf SSH niet eens aan de buitenkant van me netwerk hangen. Eerst op VPN (IPSEC) en daarna kan ik SSH gebruiken naar verschillende bakken. Misschien is dat overkill, maar SSH is nu eenmaal een geliefd target bij hackers (en nog meer geliefd bij fools with tools zoals script kiddos).

Ik vind het niet zon hele hoge prijs voor de veiligheid die ik daarmee verkrijg en ik kan ook gewoon overal ter wereld inloggen.

[Stacheldraht]

JanDM schreef op zaterdag 20 juni 2009 @ 15:35:
Is dat niet heel onhandig?

Je hebt hebt superkleine USB sticks tegenwoordig, desnoods hang je hem aan je sleutelbos. Heb je nog een leuke sleutelhanger ook. Overigens als je meerdere servers binnen hetzelfde netwerk via ssh wilt benaderen is een ssh jumpbox echt een aanrader. Ik gebruik dus zoiets dagelijks

code:

thuis (key 1) - wan -> ssh jumpbox (key 2) - lan -> servers

[MoiZie]

Hehe, naar aanleiding van dit topic heb ik een leuke middag gehad. Ik heb nu volgens mij een (redelijk) beveiligde openssh server, met geen wachtwoorden, je kan er alleen inkomen als een public ssh key in 1 of ander bestand staat. En dan moet je nog een wachtwoord intypen voor dat bestand (die per key verschillend is, dus per client verschillend).

[Puch-Maxi]

Stacheldraht schreef op zaterdag 20 juni 2009 @ 16:16:
[...]
Je hebt hebt superkleine USB sticks tegenwoordig, desnoods hang je hem aan je sleutelbos. Heb je nog een leuke sleutelhanger ook. Overigens als je meerdere servers binnen hetzelfde netwerk via ssh wilt benaderen is een ssh jumpbox echt een aanrader. Ik gebruik dus zoiets dagelijks

code:

thuis (key 1) - wan -> ssh jumpbox (key 2) - lan -> servers

Als ik het goed begrijp: Je connectie vanaf huis met je "ssh jumbox" en vervolgens naar je servers.
Ik heb ff gezocht en gevonden
Je jumpbox is zeg maar een veilige haven, waarvandaan je weer verder kunt connecten.
Hoe heb jij dit gerealiseerd?

[jan99999]

Ik zou toch de ip nummers die naar binnen mogen beperken.

[remco_k]

VisionMaster schreef op vrijdag 19 juni 2009 @ 00:24:
Met apt of aptitude zou je een verify kunnen draaien op je pakketten. Met redhat gebruik ik het rpm --verify <een pakket> commando om te verifieren of de binary nog hetzelfde is als bij de installatie/update en dat de file permissies onverandert zijn.

En dan maar hopen dat apt, aptitude en rpm niet waren aangepast...
Die moet je dus eerst met de hand even checken, je _moet_ voor jezelf even een solide basis vaststellen. En zelfs dat checken met de hand is niet helemaal betrouwbaar.

jan99999 schreef op zaterdag 20 juni 2009 @ 20:00:
Ik zou toch de ip nummers die naar binnen mogen beperken.

Ja, dat kan en heb ik b.v. gedaan. Waan je in deze situatie alleen niet 100% veilig. Het is een aardige drempel, maar er kan nog steeds overheen worden gestapt.

Maar als je goed leest, dan lees je dat sommige mensen hierboven overal vandaan in willen kunnen loggen. En dan is dit niet zo'n heel goed idee, omdat ze dan die vrijheid kwijt zijn.

Tot slot nog voor de TS:
Sjappoo voor je topicstart. Sommige tweakers kunnen hier een voorbeeld aan nemen.
Ik denk dat je er goed aan doet om preventief te herinstalleren en je keys aan te passen.
Kies je daar niet voor, dan zou je kunnen hebben dat je *denkt* dat het wel goed is, maar helemaal zeker weten, doe je het niet...

[ Voor 48% gewijzigd door remco_k op 20-06-2009 20:33 ]

[Boudewijn]

JanDM schreef op zaterdag 20 juni 2009 @ 15:35:
Ik wil overal (uni, werk, laptop, buitenland, etc.) thuis kunnen inloggen, daarom heb ik het nu zo ingesteld dat alleen mijn user via SSH erin mag en gebruik ik een sterk wachtwoord (> 12 tekens, inclusief hoofdletters, cijfers en vreemde tekens).

Waar slaan jullie de SSH keys op in zo'n geval? Op een stick die je altijd bij je hebt?
Is dat niet heel onhandig?

Op mijn laptop doie ik altijd bij me heb .

[ Voor 84% gewijzigd door Boudewijn op 20-06-2009 20:47 ]

[Boudewijn]

remco_k schreef op zaterdag 20 juni 2009 @ 20:28:
[...]

En dan maar hopen dat apt, aptitude en rpm niet waren aangepast...
Die moet je dus eerst met de hand even checken, je _moet_ voor jezelf even een solide basis vaststellen. En zelfs dat checken met de hand is niet helemaal betrouwbaar.

Eitje, even met een livecd booten .

[GiantLeap]

SSH Jumpbox, is dat niet net zoiets als een SSH Tunnel (in putty bv)? Het lijkt er namelijk wel erg op.

[Boudewijn]

Mja je ssh't toch gewoon naar 1 doos die extern bereikbaar is en start daar ssh naar een 2e machine?

[gertvdijk]

MartinMeijerink schreef op zaterdag 20 juni 2009 @ 11:49:
Je moet toch echt alles opnieuw installeren, en alle wachtwoorden en keys veranderen, en dan ervoor zorgen dat voortaan niemand via ssh kan inloggen (ook root niet!), behalve 'gert', in /etc/security/access.conf zet je daarvoor het volgende:

code:

-:ALL EXCEPT gert:ALL

wel moet je hiervoor ook ff in /etc/pam.d/ssh het volgende toevoegen:

code:

account  required     pam_access.so

Wat is het verschil met een AllowUsers gert regel in sshd_config?

webmail schreef op vrijdag 19 juni 2009 @ 16:16:
<andere poort verhaal>

Tuurlijk kan je SSH op een andere poort gaan draaien, maar dat is imo security through obscurity. Niet echt iets waar je vanop aankan.

MoiZie schreef op zaterdag 20 juni 2009 @ 17:43:
Hehe, naar aanleiding van dit topic heb ik een leuke middag gehad. Ik heb nu volgens mij een (redelijk) beveiligde openssh server, met geen wachtwoorden, je kan er alleen inkomen als een public ssh key in 1 of ander bestand staat. En dan moet je nog een wachtwoord intypen voor dat bestand (die per key verschillend is, dus per client verschillend).

Dan heb je de key nog eens beveiligd (encryted) met een password. Dat heb ik ook gedaan. Dat scheelt ontzettend als iemand je keys compromised, want hij heeft niks aan die key alleen. (ja weer bruteforcen)
Overigens hoef je niet voor elke host een andere key te gebruiken. Je kan het prima met 1 doen. Zet daarvoor de public key (~/.ssh/id_rsa.pub standaard) van de host (waarvan je connect) op de remote machine in ~/.ssh/aurhorized_keys.

[ Voor 34% gewijzigd door gertvdijk op 20-06-2009 23:23 ]

[Anoniem: 178962]

gertvdijk schreef op zaterdag 20 juni 2009 @ 23:20:
[...]
Tuurlijk kan je SSH op een andere poort gaan draaien, maar dat is imo security through obscurity. Niet echt iets waar je vanop aankan.

Nee dit is geen security through obscurity aangezien de tegenpartij nooit kan weten welke poort jij hebt gekozen en er aanzienlijk veel poorten zijn om uit te kiezen. Dit is dus net zo min security through obscurity als bijvoorbeeld een wachtwoord.

Daarnaast is het doel niet echt het verhogen van de veiligheid, het doel is het voorkomen van aanvallen door bots. Vergelijk het een beetje met een AXA slot op je fiets, natuurlijk knip je die met een betonschaar zo door net zoals ieder ander slot. Maar doordat het een AXA slot is is dat net ff iets lastiger en zal een dief eerder gaan voor de vele fietsen zonder zo'n slot.

Hoewel het dus qua beveiliging niets helpt in principe voorkomt het in de praktijk wel veel aanvallen. In een ideale wereld zou het niet uit moeten maken hoe vaak het aangevallen wordt want de beveiliging moet in orde zijn. Echter zie je in de praktijk zoals nu dat er haast altijd wel een lek te vinden is.

Overigens is er ook een poortwachter techniek te implementeren op de firewall. Je kan dan bijvoorbeeld aangeven dat er eerst een connectie op poort y en daarna een connectie op poort z gemaakt moet worden voordat het uberhaupt mogelijk is een connectie op poort x te maken. Dat soort beveiliging werkt ook erg goed, maar een beetje omslachtig doordat veel software er geen ingebouwde functies voor hebben.

[ Voor 14% gewijzigd door Anoniem: 178962 op 21-06-2009 00:35 ]

[gertvdijk]

Anoniem: 178962 schreef op zondag 21 juni 2009 @ 00:33:
Nee dit is geen security through obscurity aangezien de tegenpartij nooit kan weten welke poort jij hebt gekozen en er aanzienlijk veel poorten zijn om uit te kiezen. Dit is dus net zo min security through obscurity als bijvoorbeeld een wachtwoord.

Aangezien het aantal mogelijke poorten een stuk kleiner is dan het aantal wachtwoorden dat je kan kiezen is het wat mij betreft wel heel wat anders. Bovendien is een scan op alle mogelijke poorten moeilijker te blokkeren bij een X aantal pogingen dan bij wachtwoorden...
Het is immers eenvoudig met een simpele nmap query om erachter te komen op welke poort SSH dan wel draait.

Anoniem: 178962 schreef op zondag 21 juni 2009 @ 00:33:
Hoewel het dus qua beveiliging niets helpt in principe voorkomt het in de praktijk wel veel aanvallen. In een ideale wereld zou het niet uit moeten maken hoe vaak het aangevallen wordt want de beveiliging moet in orde zijn. Echter zie je in de praktijk zoals nu dat er haast altijd wel een lek te vinden is.

In de praktijk zullen bots het eerder opgeven, het voorkomt daarmee in principe niks, alleen dat er waarschijnlijk minder bots zullen bemerken dat SSH op een andere poort draait, simpelweg omdat het meer tijd vergt deze poort te ontdekken. Ik ben wel met je eens dat het onderdeel kan uitmaken van een schakel waarin de hacker zijn poging zal staken. Maar dit neemt natuurlijk niet weg dat je andere veiligheidsmaatregelen niet mag versoepelen/negeren als je SSH op een andere poort draait!

Anoniem: 178962 schreef op zondag 21 juni 2009 @ 00:33:
Overigens is er ook een poortwachter techniek te implementeren op de firewall. Je kan dan bijvoorbeeld aangeven dat er eerst een connectie op poort y en daarna een connectie op poort z gemaakt moet worden voordat het uberhaupt mogelijk is een connectie op poort x te maken. Dat soort beveiliging werkt ook erg goed, maar een beetje omslachtig doordat veel software er geen ingebouwde functies voor hebben.

Dat heet knocking en daarmee ben ik bekend. Het is inderdaad omslachtig en geeft veel overhead in firewall systemen.

[Wolfboy]

Stacheldraht schreef op zaterdag 20 juni 2009 @ 16:16:
[...]


Je hebt hebt superkleine USB sticks tegenwoordig, desnoods hang je hem aan je sleutelbos. Heb je nog een leuke sleutelhanger ook. Overigens als je meerdere servers binnen hetzelfde netwerk via ssh wilt benaderen is een ssh jumpbox echt een aanrader. Ik gebruik dus zoiets dagelijks

code:

thuis (key 1) - wan -> ssh jumpbox (key 2) - lan -> servers

Dat doe ik meestal op m'n FreeBSD bakken ook, 1 hele kale jail met maximale logging waar je heen kan ssh'en om daarna door te kunnen ssh'en naar de andere jails (en eventueel de host van de jails).

Werkt prima en een stuk veiliger (voor m'n gevoel iig )

Boudewijn schreef op zaterdag 20 juni 2009 @ 20:47:
[...]

Op mijn laptop doie ik altijd bij me heb .

Met ^^

En anders op m'n telefoon (Nokia E90 met PuTTy)

Anoniem: 178962 schreef op zondag 21 juni 2009 @ 00:33:
Nee dit is geen security through obscurity aangezien de tegenpartij nooit kan weten welke poort jij hebt gekozen en er aanzienlijk veel poorten zijn om uit te kiezen. Dit is dus net zo min security through obscurity als bijvoorbeeld een wachtwoord.

Euhm... lijkt me toch wel eigenlijk?
De moeilijk te gokken poort (maar niet onmogelijk, maar 65534 mogelijkheden te gokken, prima te doen voor een bot) geeft geen daadwerkelijk toegevoegde beveiliging. Dus is het per definitie "security by obscurity" (vertaling: beveiliging door onbekendheid).

Daarnaast is het doel niet echt het verhogen van de veiligheid, het doel is het voorkomen van aanvallen door bots. Vergelijk het een beetje met een AXA slot op je fiets, natuurlijk knip je die met een betonschaar zo door net zoals ieder ander slot. Maar doordat het een AXA slot is is dat net ff iets lastiger en zal een dief eerder gaan voor de vele fietsen zonder zo'n slot.

Een betere vergelijking zou zijn... het slot verstoppen op de fiets, het zit er wel maar je hebt geen idee waar en of het er wel zit. Na eventjes zoeken (65534 poorten) weet je of er wel/geen slot op zit.

[VisionMaster]

Wolfboy schreef op zondag 21 juni 2009 @ 01:27:
[...]
Dat doe ik meestal op m'n FreeBSD bakken ook, 1 hele kale jail met maximale logging waar je heen kan ssh'en om daarna door te kunnen ssh'en naar de andere jails (en eventueel de host van de jails).

Werkt prima en een stuk veiliger (voor m'n gevoel iig )
[...]
Met ^^

En anders op m'n telefoon (Nokia E90 met PuTTy)
[...]
Euhm... lijkt me toch wel eigenlijk?
De moeilijk te gokken poort (maar niet onmogelijk, maar 65534 mogelijkheden te gokken, prima te doen voor een bot) geeft geen daadwerkelijk toegevoegde beveiliging. Dus is het per definitie "security by obscurity" (vertaling: beveiliging door onbekendheid).
[...]
Een betere vergelijking zou zijn... het slot verstoppen op de fiets, het zit er wel maar je hebt geen idee waar en of het er wel zit. Na eventjes zoeken (65534 poorten) weet je of er wel/geen slot op zit.

Ik heb ook mijn SSHd op een vaag port nummer geconfigureerd. En dit is simpel security through obscurity. Het enige dat ik er mee bereik (met veel succes) is dat ik alle bots tegenhoudt die enkel port 22 proberen. Aangezien dat het de meeste zijn blijft mijn log een beetje schoon.

[Anoniem: 178962]

De aanvaller moet toch een extra stap in z'n proces toevoegen, namelijk het zoeken naar de juiste poort. Dit is het grote verschil met security through obscurity.

Bij vrijwel alle voorbeelden van security through obscurity werkt de aanval in ongewijzigde vorm nog steeds maar weet de hacker vaak niet meteen welke aanval hij moet toepassen. Bijvoorbeeld het verbergen van een software versie nummer, dit maakt het op geen enkele manier veiliger maar de hacker weet niet dat je versie x draait waar exploit y op van toepassing is. Probeert de hacker echter exploit y dan werkt het meteen.

Het aantal mogelijkheden zijn wel beperkt bij het kiezen van de poort maar ook weer niet zo beperkt dat de hacker het snel doorheeft.

De meeste firewall software heeft wel mogelijkheden om na 4 pogingen op poorten waar niets actief is een IP te blocken voor 30 min bijvoorbeeld. Doordat de aanvaller niet simpel kan zien of de poort simpelweg niet actief is of hij geblocked is kan hij de juiste poort zo voorbij gaan waardoor hij niet binnen kan komen.

Ik heb zelf ook altijd SSH op een of andere vaag poort zitten en mijn logs zijn altijd erg clean. Voor mijn IP honderdduizenden IP's die SSH wel op de default poort hebben zitten.

Wel is het natuurlijk zo dat de veiligheid voor de rest nog steeds top moet zijn. Maar het doel is om de kans op hacks zo klein mogelijk te maken en niet om een zo goed mogelijke beveiliging te hebben, dat is enkel het middel om het doel te bereiken.

[ Voor 20% gewijzigd door Anoniem: 178962 op 21-06-2009 19:07 ]

[VisionMaster]

Anoniem: 178962 schreef op zondag 21 juni 2009 @ 19:02:
De aanvaller moet toch een extra stap in z'n proces toevoegen, namelijk het zoeken naar de juiste poort. Dit is het grote verschil met security through obscurity.

Bij vrijwel alle voorbeelden van security through obscurity werkt de aanval in ongewijzigde vorm nog steeds maar weet de hacker vaak niet meteen welke aanval hij moet toepassen. Bijvoorbeeld het verbergen van een software versie nummer, dit maakt het op geen enkele manier veiliger maar de hacker weet niet dat je versie x draait waar exploit y op van toepassing is. Probeert de hacker echter exploit y dan werkt het meteen.

Het aantal mogelijkheden zijn wel beperkt bij het kiezen van de poort maar ook weer niet zo beperkt dat de hacker het snel doorheeft.

De meeste firewall software heeft wel mogelijkheden om na 4 pogingen op poorten waar niets actief is een IP te blocken voor 30 min bijvoorbeeld. Doordat de aanvaller niet simpel kan zien of de poort simpelweg niet actief is of hij geblocked is kan hij de juiste poort zo voorbij gaan waardoor hij niet binnen kan komen.

Ik heb zelf ook altijd SSH op een of andere vaag poort zitten en mijn logs zijn altijd erg clean. Voor mijn IP honderdduizenden IP's die SSH wel op de default poort hebben zitten.

Wel is het natuurlijk zo dat de veiligheid voor de rest nog steeds top moet zijn. Maar het doel is om de kans op hacks zo klein mogelijk te maken en niet om een zo goed mogelijke beveiliging te hebben, dat is enkel het middel om het doel te bereiken.

Helemaal mee eens. Alleen het feit dat de aanvaller meer moet doen en op ontdekkingstocht moet gaan, die extra stap, is simpel weg een security through obscurity methode. Daar is niks mis mee toch? Het werkt ook nog. De term 'Obscurity' is meestal wel lekker beladen als een super negatief iets, maar dat is het toch niet altijd? Iedere stap die gedaan moet worden door een aanvaller om binnen te komen is een extra stap die je kan helpen in de verdediging.
Ow en een ander ding waar ik het niet helemaal mee eens ben is de ontdekkingstocht mogelijkheden van je SSH versie. Zelfs als je de SSH banner uitzet kan nmap nog een aardige schatting doen in welke range van versies je moet zitten met je sshd als het iets dergelijks gevonden heeft op een betreffend portnummertje.

[igmar]

MartinMeijerink schreef op zaterdag 20 juni 2009 @ 11:52:
[...]
Waarom geen ssh dmv wachtwoorden dan? Leg eens uit...

euh, omdat mensen de gewoonte hebben goed onthoudbare (en dus vaak slechte) wachtwoorden te kiezen ? SSH keys hebben dat probleem simpelweg niet.

[John_Glenn]

Ik realiseer me dat dit een paar daagjes oud is intussen, maar was benieuwd wat je er uiteindelijk mee gedaan hebt?

gertvdijk schreef op vrijdag 19 juni 2009 @ 00:02:
• Wekelijks draai ik volledige backups van het / filesystem d.m.v. rdiff-backup dus ik backup ook binaries.

Bevat je rdiff-backup dan niet bijna alle info die je je maar kan wensen? Met de --list-changed-since optie moet je een heel eind kunnen komen denk ik. SysRescCd heeft rdiff-backup aan boord... Een ander idee is misschien gewoon een recursive diff met bestanden uit de backup en van de gehackte disk na gaan lopen.

Zuur veel werk, dat wel. Maar het geeft je een zekerder gevoel, dat is ook wat waard.

[Anoniem: 22473]

N.a.v. dit topic zit ik nu ook te kijken naar mijn beveiliging. Nu zie ik het volgende in /var/log/auth.log

Zijn dit dus zogenaamde bots die brute-force aanvallen uitvoeren?

Jun 28 09:28:03 Phoebe sshd[7267]: Failed password for invalid user sales from 196.6.x.x port 2142 ssh2
Jun 28 09:28:10 Phoebe sshd[7269]: Invalid user web from 196.6.x.x
Jun 28 09:28:10 Phoebe sshd[7269]: pam_unix(sshd:auth): check pass; user unknown
Jun 28 09:28:10 Phoebe sshd[7269]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=196.6.129.218
Jun 28 09:28:12 Phoebe sshd[7269]: Failed password for invalid user web from 196.6.x.x port 3282 ssh2
Jun 28 09:28:19 Phoebe sshd[7271]: Invalid user www from 196.6.x.x

[Manuel]

Ik kom hier nu ook dagelijks mee in aanraking, alleen door CSF krijg ik een bericht als iemand op SSH probeert in te loggen (zelfde met port-floods etc), zoals hieronder een voorbeeld van vandaag:

Jun 29 12:46:59 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:0c:29:a7:b1:0e:00:0c:29:a5:e8:f1:08:00 SRC=61.190.91.66 DST=xxxx LEN=48 TOS=0x00 PREC=0x00 TTL=105 ID=29403 DF PROTO=TCP SPT=51314 DPT=3128 WINDOW=65535 RES=0x00 SYN URGP=0
Jun 29 13:09:32 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:0c:29:a7:b1:0e:00:0c:29:a5:e8:f1:08:00 SRC=129.219.182.147 DST=xxxx LEN=48 TOS=0x00 PREC=0x00 TTL=108 ID=19332 PROTO=TCP SPT=44586 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
Jun 29 13:09:32 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:0c:29:a7:b1:0e:00:0c:29:a5:e8:f1:08:00 SRC=129.219.182.147 DST=xxxx LEN=48 TOS=0x00 PREC=0x00 TTL=108 ID=55274 PROTO=TCP SPT=44586 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
Jun 29 13:09:32 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:0c:29:a7:b1:0e:00:0c:29:a5:e8:f1:08:00 SRC=129.219.182.147 DST=xxxx LEN=48 TOS=0x00 PREC=0x00 TTL=108 ID=59299 PROTO=TCP SPT=44586 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
Jun 29 13:09:32 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:0c:29:a7:b1:0e:00:0c:29:a5:e8:f1:08:00 SRC=129.219.182.147 DST=xxxx LEN=48 TOS=0x00 PREC=0x00 TTL=108 ID=62671 PROTO=TCP SPT=44586 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
Jun 29 13:09:32 server kernel: Firewall: *Port Flood* IN=eth0 OUT= MAC=00:0c:29:a7:b1:0e:00:0c:29:a5:e8:f1:08:00 SRC=129.219.182.147 DST=xxxx LEN=48 TOS=0x00 PREC=0x00 TTL=108 ID=47214 PROTO=TCP SPT=44586 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
Jun 29 13:09:32 server kernel: Firewall: *Port Flood* IN=eth0 OUT= MAC=00:0c:29:a7:b1:0e:00:0c:29:a5:e8:f1:08:00 SRC=129.219.182.147 DST=xxxx LEN=48 TOS=0x00 PREC=0x00 TTL=108 ID=49308 PROTO=TCP SPT=44586 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
Jun 29 13:12:38 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:0c:29:a7:b1:0e:00:0c:29:a5:e8:f1:08:00 SRC=122.224.52.156 DST=xxxx LEN=40 TOS=0x00 PREC=0x00 TTL=95 ID=256 PROTO=TCP SPT=6000 DPT=1433 WINDOW=16384 RES=0x00 SYN URGP=0
Jun 29 13:12:38 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:0c:29:a7:b1:0e:00:0c:29:a5:e8:f1:08:00 SRC=122.224.52.156 DST=xxxx LEN=40 TOS=0x00 PREC=0x00 TTL=96 ID=256 PROTO=TCP SPT=6000 DPT=1433 WINDOW=16384 RES=0x00 SYN URGP=0
Jun 29 13:12:38 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:0c:29:a7:b1:0e:00:0c:29:a5:e8:f1:08:00 SRC=122.224.52.156 DST=xxxx LEN=40 TOS=0x00 PREC=0x00 TTL=95 ID=256 PROTO=TCP SPT=6000 DPT=1433 WINDOW=16384 RES=0x00 SYN URGP=0
Jun 29 13:12:38 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:0c:29:a7:b1:0e:00:0c:29:a5:e8:f1:08:00 SRC=122.224.52.156 DST=xxxx LEN=40 TOS=0x00 PREC=0x00 TTL=96 ID=256 PROTO=TCP SPT=6000 DPT=1433 WINDOW=16384 RES=0x00 SYN URGP=0

Een goede firewall is het halve werk zoals sommigen zeggen

Hieronder trouwens een voorbeeld van een e-mail die je dan ontvangt:

Subject: lfd on server.**************: SSH login alert for user manuel from 213.17.**.** (NL/Netherlands/.adsl.wanadoo.nl)
Time:    Mon Jun 29 13:35:43 2009 +0200
IP:      213.17.**.** (NL/Netherlands/.adsl.wanadoo.nl)
Account: manuel
Method:  password authentication

Trouwens, voordat ik het vergeet: CSF.

[gertvdijk]

Anoniem: 22473 schreef op maandag 29 juni 2009 @ 13:25:
N.a.v. dit topic zit ik nu ook te kijken naar mijn beveiliging. Nu zie ik het volgende in /var/log/auth.log

Zijn dit dus zogenaamde bots die brute-force aanvallen uitvoeren?

Ja. Meest eenvoudige 'oplossing' vind ik fail2ban, die schakelt standaard een IP voor 10 minuten uit na 6 mislukte inlogpogingen.

John_Glenn schreef op maandag 29 juni 2009 @ 03:36:
Ik realiseer me dat dit een paar daagjes oud is intussen, maar was benieuwd wat je er uiteindelijk mee gedaan hebt?

Ik heb handmatig een aantal binaries, zoals ls gemd5'd en gecontroleerd met de repo's en die kwamen allemaal keurig overeen. Ik heb daarop besloten de reinstall uit te stellen tot volgende week.

John_Glenn schreef op maandag 29 juni 2009 @ 03:36:
Bevat je rdiff-backup dan niet bijna alle info die je je maar kan wensen? Met de --list-changed-since optie moet je een heel eind kunnen komen denk ik. SysRescCd heeft rdiff-backup aan boord... Een ander idee is misschien gewoon een recursive diff met bestanden uit de backup en van de gehackte disk na gaan lopen.

Die rdiff-backup bevat inderdaad veel informatie, maar het zure is, blijkt nu, dat ik niets direct kan restoren. Het geval wil namelijk dat er een probleem is met het verschil in versies tussen Ubuntu 8.04 (mijn remote backup machine) en 9.04. En in rdiff-backup doen ze dergelijke protocolveranderingen ook wel eens zonder waarschuwing doorvoeren... Nu moet ik via een omweg restoren op de remote machine en dan weer over scp'en... heel irritant en tijdrovend, waardoor ik het wel moest uitstellen allemaal. Volgende week heb ik vakantie en dus zat tijd.

[John_Glenn]

gertvdijk schreef op maandag 29 juni 2009 @ 14:24:
Die rdiff-backup bevat inderdaad veel informatie, maar het zure is, blijkt nu, dat ik niets direct kan restoren. Het geval wil namelijk dat er een probleem is met het verschil in versies tussen Ubuntu 8.04 (mijn remote backup machine) en 9.04. En in rdiff-backup doen ze dergelijke protocolveranderingen ook wel eens zonder waarschuwing doorvoeren... Nu moet ik via een omweg restoren op de remote machine en dan weer over scp'en... heel irritant en tijdrovend, waardoor ik het wel moest uitstellen allemaal. Volgende week heb ik vakantie en dus zat tijd.

Sjit, dat is inderdaad _heel_ irritant. Zit het net te lezen, neem aan dat je dit bedoelt:
https://bugs.launchpad.ne.../rdiff-backup/+bug/128242

Als die inbreker niks ernstigs heeft uitgehaald hoef je natuurlijk niet perse te restoren. In principe kan de backup machine in zijn eentje de huidige met de oude staat van de data vergelijken (daarvoor moet je wel een backup van de huidige staat maken - tis nog best een gedoe om dat op een manier te doen die niet de oude staat in de backup kan wijzigen...), dus misschien zit je wel goed.

Toch irritant, van rdiff-backup...

[Wolfboy]

gertvdijk schreef op maandag 29 juni 2009 @ 14:24:
Ik heb handmatig een aantal binaries, zoals ls gemd5'd en gecontroleerd met de repo's en die kwamen allemaal keurig overeen. Ik heb daarop besloten de reinstall uit te stellen tot volgende week.

Ik neem aan dat je ook rkhunter gedraait hebt?

[Stacheldraht]

gertvdijk schreef op maandag 29 juni 2009 @ 14:24:
Die rdiff-backup bevat inderdaad veel informatie, maar het zure is, blijkt nu, dat ik niets direct kan restoren. Het geval wil namelijk dat er een probleem is met het verschil in versies tussen Ubuntu 8.04 (mijn remote backup machine) en 9.04. En in rdiff-backup doen ze dergelijke protocolveranderingen ook wel eens zonder waarschuwing doorvoeren... Nu moet ik via een omweg restoren op de remote machine en dan weer over scp'en... heel irritant en tijdrovend, waardoor ik het wel moest uitstellen allemaal. Volgende week heb ik vakantie en dus zat tijd.

Dit is voor mij ook de voornaamste reden om nooit rdiff-backup te gebruiken ik heb over dit rdiff-backup probleem al zoveel ellende gehoord.

rsnap-shot ftw

[Anoniem: 177412]

En wat als je ssh tunneling gebruikt met een unprivileged extra user zonder shell access, en alleen die user mag inloggen met een ww? Kan er dan zonder shell access nog iets uitgevoerd worden?

[ Voor 9% gewijzigd door Anoniem: 177412 op 01-08-2009 16:01 ]

[Anoniem: 311571]

Ik zou toch een nieuwe installatie en verversing van je keys aanraden.

Het kan zijn de de "hacker / script" alleen de cruciale logjes verwijderd heeft waarin vermeld word wat hij eventueel als root of met meer rechten uitgevreten kan hebben.

Of je wekelijkse backup terugzetten en de huidige binaries overschrijven met die uit de backup.
(maar je keys verversen is wel een must!)