Még mielőtt elkezdenénk kombinálni...<br>Győzőt már ketesem vagy 3 napja az IRC-n, mivel tanácsot szeretnék kérni tőle, az én, valamint Gede Zoli (a szolgáltatónk) részére.<br>Ugyanis, a multkor volt egy szerver feltörés, amit sikerült rövid idő alatt helyretenni.<br>
Utána, rá egy hétre kezdődött egy DDOS támadás sorozat, mely sikeresen lassította a szerver működését, és egy adott oldal ellen irányult, melyet nem hozhatok nyilvánosságra, esetleg négyszemközt, magánbeszélgetés formájában.<br>
Nos azt szerettem(tük) volna megkérdezni tapasztaltabb kollégától, hogy DDOS támadás esetére, milyen tűzfalszabájokat érdemes hozni, mert amikor szigorítottunk, akkor engem mint partnert is backlistre tett, tehát nem tudtam elérni az oldalaimat.<br>
Az éjjszakai lassulásokat pedig az okozza, hogy akkor futnak le a különböző tesztek, logolások a mysql-on.<br>Azt tudni kell, hogy a szervergép, 50-60 %-os telitettséggel üzemel, tehát van bőven tartaléka, de egy DDOS támadásnak álltalában még a legerősebb hálózatok is meghasalnak, belassulnak.<br>
Sajnos az utóbbi időkben kijutott az Empirének minden jóból, de él és működik...<br>Jelen esetben ennek is nagyon örülök, hiszen a nagyobbik Lányom elég komoly egészségügyi problémával néz szembe, mely talán kihat majd a további életére is.... ezért sokkal nagyobb odafigyelést követel tőlem is ez a probléma.<br>
De ezzel nem akarlak terhelni titeket, csak azért írtam le, hogy értsétek a viszonylagos, ritkább jelenlét okát....<br>Ami nem jelenti azt, hogy feladom, még véletlen sem, csak a problémákat esetleg lassaban oldom meg, de megoldom.....<br>
Mindenkitöl bocs a kellemetlenségekért!<br><br>ui:Derivét megkérném, esetleg Janut, hogy segítsen ha tud, olyan tűzfalbeálítás létrehozásában, mely minimalizálja a DDOS támadások hatásait.<br>Köszönöm megértéseteket!<br><br>
<div class="gmail_quote">2010/6/9 G. J. Hazai <span dir="ltr">&lt;<a href="mailto:janu@janu.hu">janu@janu.hu</a>&gt;</span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2010-06-09 06:19 dátummal Harka Gyozo ezt írta:<br>
<div class="im">&gt; Nos. Nem ismerek olyan rendszert ami úgy authentikálna ( mivel a belépéskor<br>
&gt; jelent meg a probléma ), hogy javascriptből kapcsolódna egy SQL-hez, de<br>
&gt; persze elvben nem lehetetlen a dolog, javascriptből csatlakozik, ellenőrzi<br>
&gt; a usert, majd beír valamit egy táblába hogy beléptem amiből tudja a webes<br>
&gt; motor hogy bentvagyok... ugyanakkor nem csoda hogy nemigen látunk ilyet,<br>
&gt; ehhez az adatbázis jelszónak ( amivel írható is az adatbázis ) el kéne<br>
&gt; mennie a kliens gépre és vissza... nem túl biztonságos.<br>
<br>
</div>Az, hogy Te nem ismersz ilyen megoldást, még nem azt jelenti, hogy nincs.<br>
Viszont valóban nincs, mert a javascript alapeszméje az, hogy i/o-t *nem<br>
végez*. Ettől persze még lehet(ne) hálózati hiba, mert pl. az sem biztos, hogy<br>
az autentikálás javascript-en keresztül történik!<br>
<br>
(azt csak zárójelben jegyzem meg, hogy az adatbázis jelszó elmegy-e a<br>
kliensre, vagy nem, az független a problémától. Nem megy el - soha)<br>
<div class="im"><br>
&gt;<br>
&gt; Ebben az esetben lehetséges lenne hogy az én hálózatommal lenne a probléma.<br>
<br>
</div>Csak hogy tiszta legyen a dolog: nem csak ez az eset létezik. Elvben -<br>
hangsúlyozom: elvben - beleszaladhatott egy timeout-ba a kérés. Úgy képzeld<br>
el, hogy elment az autentikációs kérés, majd a user/pwd páros is elindult, de<br>
a szerver küldött egy szép, kövér NAK-ot. Megint elküldte a kliens, de a<br>
szerver még mindig nem érti. Közben meg lejárt a mysql connections ideje...<br>
Más kérdés, hogy ilyenkor illene &#39;connection timeout&#39;-tal visszatérni, de<br>
láttam én olyan hiba hamisításokat, hogy az ember csak dermedten bámul :-)<br>
<br>
&gt; [...]<br>
<div class="im">&gt; Egyébként pedig gyanús hogy egymilliószor láttam már ilyen hibát, és<br>
&gt; kitűnően látszik rajta hogy szerveroldali.<br>
<br>
</div>... ami azt jelenti, hogy a hibát a szerver észlelte, de ez csak egy vélhető<br>
hiba, attól még keletkezhetett a kliensen. Ezt én számtalanszor elmondom, most<br>
is erre hívnám fel a figyelmet: a jelzett hiba lehet egy következmény, nem a<br>
tényleges hibaok! Amikor a számítógép kiír egy hibát, az mindig csak egy<br>
vélhető hiba, lehet, hogy ténylegesen egész másról van szó!<br>
<div class="im"><br>
&gt;<br>
&gt; Másrészt ha jól megnézed a hibaoldal szövegét amit beidéztem az adatbázis<br>
&gt; szervert nem a localhost egy portján nem találta, hanem a<br>
&gt; /var/run/mysqld/mysqld.sock socketen keresztül.<br>
<br>
</div>Te mondd, ha történetesen azt írta volna ki, hogy &#39;CPU not found&#39;, akkor most<br>
azt írtad volna, hogy kilopták a szerverből a CPU-t? :-)<br>
(félreértés ne essék: láttam ilyen hibaüzenetet. Tréfás kedvű admin)<br>
<br>
&gt; [...]<br>
<div class="im">&gt; De nembánom, menjünk a részletekbe, ahol az ördög lakozik.<br>
&gt;<br>
&gt; A <a href="http://linuxempire.hu" target="_blank">linuxempire.hu</a> phpBB-t használ, ami ahogy a nevéből is jól látszik,<br>
&gt; php-zik. A PHP mint olyan szerver oldali programot jelent, amit általában<br>
&gt; egy apache modul szolgál ki. Ezért ha egy php-s hibaüzenetet lát az ember<br>
&gt; a böngészőjében tudhatja hogy az nem az Ő hibája, hanem bizony a<br>
&gt; webszerveren van a gond,<br>
<br>
</div>Kontra! Ettől még lehet más a gond, csak éppen azt hamisítja a szerver, hogy<br>
nála van a gond. Minél nehezebb kideríteni a hiba keletkezési helyét, annál<br>
&quot;biztonságosabb&quot; a szerver (és annál nagyobb a valószínűsége, hogy az admin<br>
előbb-utóbb beleőrül).<br>
<div class="im"><br>
&gt; mert ha nála lenne kapcsolati probléma nem kapna<br>
&gt; szép hibaüzenetet a távoli gép apache-ának a php moduljától. Ebben a<br>
&gt; specifikus esetben a phpBB azt üzente hogy nem tud kapcsolódni a helyi<br>
&gt; gépen ( tehát ugyanúgy a szerveren ) lévő adatbázis kiszolgálóhoz, ami egy<br>
&gt; MySQL.<br>
<br>
</div>Értem. Legközelebb meg azt fogja üzenni, hogy &#39;General failure on server&#39;.<br>
Akkor már nem a MySQL a hunyó, hanem az a rohadt generális???<br>
<br>
<br>
&gt; [...] Persze mielőtt a<br>
<div class="im">&gt; szolgáltatót hibáztatnánk mindenért, ne felejtsük el hogy a szolgáltató<br>
&gt; kiszolgálja a klienseit, akik sokszor elavult programokat használnak,<br>
&gt; amiket aránylag könnyű megtámadni/feltörni, stb.<br>
&gt; Pl. a linuxempire az összes modern bizbaszával együtt phpBB 3.0.6-ot<br>
&gt; használ ugye... pedig már a 3.0.7-ből is van magyar verzió.<br>
<br>
</div>Ez más egészen más tészta. Teljesen igazad van, bár megemlíteném a saját<br>
gyakorlatomat, hogy bizonyos web-lapokon csak akkor cserélem le az<br>
alkalmazást, ha a CHANGELOG alapján ez indokolt. Biztos vagyok benne, hogy a<br>
phpBB nem Microsoft, titkos hibajavítás nincs.<br>
<br>
&gt; [...]<br>
<div class="im">&gt; Az is furcsa nekem, hogy bár nem én vagyok az adminisztrátor, ha a<br>
&gt; kezdőlapra megyek jobb oldalt ottvan alul egy ACP link, ami újra elkéri a<br>
&gt; fórum userem és jelszavam, és eljutok az AVP-hez.<br>
<br>
</div>Na, ez komoly baj! És sajnos nem csak Neked engedi, hanem nekem is. Nyilván,<br>
ez nem a phpBB hibája, hanem valamilyen jogosultsági kérdés. ZSEBTYSON!!!<br>
<br>
<br>
&gt;[...]<br>
<div class="im">&gt; Gondolom ez is a helyi hálózatom hibája lehet :)<br>
<br>
</div>Kiszedtem a levélből ezt a részt, mert kissé hosszú. Nekem nem sikerült<br>
rekonstruálni, de biztos én vagyok a hülye :-D<br>
<br>
&gt;[...]<br>
<div class="im">&gt; Hehe, visszaadtam az olvasási jogokat. Jó játék ez.<br>
&gt; Ahogy nézem a különböző extra modulokat ( last active post show,<br>
&gt; rendezvények, galériák ) simán tudom adminisztrálni...<br>
<br>
</div>Azért most hadd kérjem, hogy olyan nagyon ne publikáljuk ezt a sajátosságot,<br>
tréfás kedvű fórumtársak esetleg elszórakoznának vele...<br>
<font color="#888888"><br>
--<br>
---[janu]---<br>
registered Linux user #46079<br>
homepage: <a href="http://www.janu.hu" target="_blank">http://www.janu.hu</a><br>
gpg --keyserver hkp://<a href="http://pgp.mit.edu" target="_blank">pgp.mit.edu</a> --recv-keys 7AE6D529<br>
fingerprint: 48AD 937E EBF7 46EE 06E6  81FC 3DC2 06A7 7AE6 D529<br>
</font><br>_______________________________________________<br>
Empire mailing list<br>
<a href="mailto:Empire@omega.ttk.pte.hu">Empire@omega.ttk.pte.hu</a><br>
<a href="https://omega.ttk.pte.hu/cgi-bin/mailman/listinfo/empire" target="_blank">https://omega.ttk.pte.hu/cgi-bin/mailman/listinfo/empire</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Szabadság, Tenger, Pálmafák, Szex, Linux..... :)<br>