Hozzászólások
-
Bejegyzés
-
A probléma egy primitív CPU terhelés logban mutatkozott meg. Egy adott időpontban extrém méretűre nőtt a terhelés.
Ezt kellene kideríteni.
Tehát az biztos, hogy a CPU terhelés megnőtt. De ehhez kapcsolódóan ha megjelenítené valami az összes többi terhelést, ki lehetne találni, hogy a web, a mail vagy egyéb programok vitték-e el a túl sok erőforrást.
Tehát nem egy konkrét terület elemzéséhez keresek programot, hanem összefoglaló, összehasonlító elemzésekhez.
(Ezért lenne hasznos az is, ha tudná a logokat olvasni visszamenőlegesen is.)uzsolt wrote:Válogass!Köszönöm. Én is itt keresgélek, amyg válasz nem érkezik tőletek, de végigpróbálgatni mindet … Mire kiderül, tudják-e azt, amit szeretnék… Persze egy csomó csak web-log, ez dobható. Egy csomó meg nem azt csinálja, amit szeretnék. (Már ameddig eddig eljutottam.) Tehát kb annyi idő, mintha magam kezdenék kódolni. Ezért lenne jó valami konkrétabb ismeret. Ki hazsnál ilyent? Melyiket? Melyiknek mik a korlátai? Melyiket érdemes? … Meg effélék …
Azért köszi! 🙂És RPM alatt mi ez a parancs? Mert az általam ismert RPM-ek sem tudják ezt. (Vagyis pontosabban én nem tudom, hogy tudják-e.)
Köszi!
Bár ubuntun ülök, ilyent nem találtam. (Igaz, ez xubuntu). De találtam egy autoclean-t. Ez lenne az?A frissítés veszélyes út!
Az up2date a múltkor úgy frissítette a php-mat, hogy néhány program azóta nem fut (vagyis át kellett írni). Pedig ott még verzió váltás sincs!
És sajnos sok ügyfél van már a környezeten. 🙁
Tehát a frissítés a végső megoldás lehet csak. 🙁Én is megpróbáltam suphp-t, mivel ahhoz RH9-es rpm-et is találtam. De az rpm telepítéskor lefagyott. (Ilyen se sok van linux alatt.) De legalább kipakolta a fájlokat, és csak utána. Azonban az apache nem indul el, mivel azt mondja:
Code:Cannot load /etc/httpd/modules/mod_suphp.so into server: /etc/httpd/modules/mod_suphp.so: undefined symbol: apr_procattr_error_check_setMegpróbáltam kézzel is fordítani forrásból. Sajnos csak a 0.6.1-es fordul, mert a 0.6.2-eshez már túl régi az autoconf-om.
Tehát lefordult hiba nélkül, majd ugyanezt a hibát adta az apache, mikor megpróbáltam a használatára késztetni …
Vagyis itt bebuktam. Ha erre van valakinek valami ötlete, az is jó lenne. Én suphp-t is szívesen használnék.Ezzel csak az a baj, ha jól értem, hogy minden user PHP-ja apacha alatt fut. Én meg pont azt szeretném elérni, hogy saját felhasználóként mehessenek. PHP safe módban csak akkor tud mappát is létrehozni, ha a mappa, amiben létre akarja hozni, tulajdonosa az apache. De akkor mi van a felhasználói quotával. És mi van az FTP hozzáféréssel?
Mi ezt scripteléssel oldottuk meg, bár a graylistnek szerintem ez csak egy, nagyon leszűkített funkciója.
Leszűkített, de 100%-os. Az így kidobott leveleket biztos, hogy nem kell tovább szűrni. Nincs benne hiba. Ennyi az előnye.
Úgy tűnik, nekem is scripteket kell írnom hozzá, ami mindig azt az érzetet kelti bennem, hogy feleslegesen dolgozom, hisz ezt már valahol biztos megcsinálták, és várhatóan jobban is mint én fogom. 🙁Ha jól olvasom, ez nem azt csinálja, amit én szeretnék, hanem először visszautasítja, és csak másodszorra fogadja el, mondván a spammerek nem próbálkoznak újra.
Ez azért alapvetően más, mint amit én szeretnék.
Vagy be lehet konfigurálni olyanra, mint amit én szeretnék?Lezárásként mindenki okulására a jelenlegi állapot. A levélküldés módszere a következő volt. Volt egy PHP program a szerveren, ami a paraméterül kapott változót, mint fájlnév-perfixet használta egy inkclude parancsban. A spammerek ennek a változónak egy olyan URL-t adtak át, ami otputként egy php meta típusú php forráskódot adott vissza, ami így lefutott a szerveren.
A php.ini-ben tiltottam az allowurlopen-t (vagy valami efféle, most nem tuodm pontosda), ami alapból engedélyezve van, és engedi a php-nak külső url-ek megnyitását, include-olását.
Találtam továbbá egy ugyanilyen módszerrel felmásolt trójait is a gépen. Ezt kiirtottam.
Két érdekessége van az esetnek.
1 – A gyanús php kódoknál (ahol include-ban használ a kód GET paramétert), a támadók nem próbálták végig az összes GET paramétert, csak az esélyest tesztelték. Ott is, ahol a változó nem prefix volt, tehát külső URL behelyettesítése nem működöt. Nem próbálták végig az összeset.
2 – Mióta mindez kiderült, nem jött új kísérlet sem.
Remélem, a letörölt trójai volt a forrásuk, és az nézte át a PHP kódokat, keresve include utáni változókat, majd bepróbálkozott GEt-ként, hogy törhető-e így.
A törések nem fix IP-ről jöttek. Valószínűleg feltört gépekről.
Hát ennyit tudok jelenleg.
Azért szerintem érdemes mindenkinek az allowUrlOpen-t mindenkinek tiltani, ha nem feltétlen szükséges az engedélyezése.
További jó hack mentes netezgetést mindenkinek.
legutóbbi hsz