Kliens IP címe
Nem tudom, szerver- vagy kliensoldali probléma: logolni akarom a kliensek IP címét, hogy az illető később vissza tudja nézni, milyen IP-kről jelentkezett be a szolgáltatásba.
Hányféle módszer van a kliens IP címének begyűjtésére?
A kérdés eredete: több webes e-mail szolgáltatónál van ilyen lehetőség, hogy listázzam, milyen címekről léptem be. A legtöbb helyen a valós WAN címem szerepel. Kivéve, ahol nem mindig... mert ha a lokális proxy-mat (squid - ahogy felmegy ubuntun, nincs plusz konfig rajta amennyire emlékszem) használom, akkor nem a WAN címet látom ebben a listában, hanem a LAN-os címeket.
És itt egy kicsit vakarom a fejem, hogy ezt akkor most mégis hogyan...
Megfelelő, neten lévő szerver hiányában nem tudok tcpdump-ot készíteni a forgalomról, nem látom, miért találja meg az egyik a LAN-os címet és miért látja a másik a valódit...
■ Hányféle módszer van a kliens IP címének begyűjtésére?
A kérdés eredete: több webes e-mail szolgáltatónál van ilyen lehetőség, hogy listázzam, milyen címekről léptem be. A legtöbb helyen a valós WAN címem szerepel. Kivéve, ahol nem mindig... mert ha a lokális proxy-mat (squid - ahogy felmegy ubuntun, nincs plusz konfig rajta amennyire emlékszem) használom, akkor nem a WAN címet látom ebben a listában, hanem a LAN-os címeket.
És itt egy kicsit vakarom a fejem, hogy ezt akkor most mégis hogyan...
Megfelelő, neten lévő szerver hiányában nem tudok tcpdump-ot készíteni a forgalomról, nem látom, miért találja meg az egyik a LAN-os címet és miért látja a másik a valódit...
Lövésem sincs, de ha proxy-t
Köszi, hogy hozzászóltál,
Szóval az van, hogy alapjáraton a squid forwarded_for paramétere on-ra van állítva, amitől az X-Forwarded-For headerbe bekerül a LAN-os cím. Ha off-ra teszem, akkor unknown lesz az értéke, ha transparent-re, akkor nincs ilyen bejegyzés a headerben, ettől kezdve az a nyomorult site is a valós IP címem rögzíti.
B.Ú.É.K.! :)
Nekem kellene valami olyan
DDOS ellen az nginx (nem csak
Spam elleni védelmet nem tudok, ez szerintem nem is a proxy feladata, mivel alkalmazás függő.
A squidnak is van pár érdekes dolga, meg talán a squid-guard is bevethető (illetve valamelyik forkja, mert úgy rémlik, a squid-guard fejlesztése megállt)
Szerintem simán lehet a proxy
Mondom: az írás szerint az
Sose használtam ilyesmit, pedig üzemeltettem clustert, de ott másképp ment az erőforrás megosztás,olyan ma már nem létezik, amivel én dolgoztam.
Az, hogy a ddos védelem nem igazán lehet hatékony, az csak az én privát véleményem. Ilyen támadást többnyire fertőzött gépek tömegéről indítanak, amit kb. egy digitalocean/google/amazon méretű, felhős szolgáltatónak van esélye kivédeni. Kicsi szolgáltatónak, egy-két-öt-tíz szerverrel nem annyira. Eldugítják az az 1-10Gbps sávszélt, mit csinálsz?
A spamvédelem más téma: az szerintem az alkalmazás dolga, a reverse proxy nem nagyon tudhatja, hogy az adott tartalom spam-e vagy kifejezetten az alkalmazáshoz illeszkedő infó (nem mindegy, hogy egy olyan oldal működik mögötte, ami pornó oldalak linkcseréjét biztosítja, vagy valami politikai fórum, ahol a tömeges pornó linkelés már spam ;) )
Spam szűrés
Pl kapsz egy error-t parsoláskor, azt logolni is a proxinak kell, pedig alkalmazás / kliens hiba.
Ugyanakkor az alkalmazásod sokkal könnyebben kiválogatja / figyeli csak azokat a végpontokat, ahol lehet is spamelni (feltéve, hogy nem minden POST request-tel lehet). Nyilván a felhasználó- és jogosultságkezelést se akarod a proxy-ra bízni, azt pedig sokkal egyszerűbb ellenőrizni, hogy pillanatnyilag küldhet-e oda tartalmat az XY, mint magát a tartalmat.
Szóval szerintem túlságosan elmosódnának a határok, hogy kinek mi a feladata, spam maradjon az alkalmazás dolga.
Ja, igazad van.