URL probing támadások - mit lehet tenni?

Hálózatok általános

Sziasztok!

Az elmúlt hetekben megszaporodtak azok az URL hacking jellegű támadások a szervereinken, amelyek mindenféle ismert webalkalmazások (fórumok, CMS-ek) különböző bejelentkezéses/regisztrálós URL-jeit próbálják hívogatni. Ezeknek a request-eknek rendszerint sima 404-es hiba a vége, de attól még zavaróak:


216.99.148.x oldal.domainneve.hu - [06/Aug/2013:09:46:55 +0200] "GET /wp-signup.php HTTP/1.1" 404 345 "-" "Java/1.6.0_24"
216.99.148.x oldal.domainneve.hu - [06/Aug/2013:09:46:55 +0200] "GET /wp-login.php?action=register HTTP/1.1" 404 345 "-" "Java/1.6.0_24"
216.99.148.x oldal.domainneve.hu - [06/Aug/2013:09:46:53 +0200] "GET /CreateUser.asp HTTP/1.1" 404 345 "-" "Java/1.6.0_24"
216.99.148.x oldal.domainneve.hu - [06/Aug/2013:09:46:52 +0200] "GET /tiki-register.php HTTP/1.1" 404 345 "-" "Java/1.6.0_24"
216.99.148.x oldal.domainneve.hu - [06/Aug/2013:09:46:51 +0200] "GET /index.asp HTTP/1.1" 404 345 "-" "Java/1.6.0_24"
216.99.148.x oldal.domainneve.hu - [06/Aug/2013:09:46:47 +0200] "GET /profile.php?mode=register HTTP/1.1" 404 345 "-" "Java/1.6.0_24"
216.99.148.x oldal.domainneve.hu - [06/Aug/2013:09:46:52 +0200] "GET /member.php?action=reg HTTP/1.1" 404 345 "-" "Java/1.6.0_24"
216.99.148.x oldal.domainneve.hu - [06/Aug/2013:09:46:47 +0200] "GET /registration_rules.asp HTTP/1.1" 404 345 "-" "Java/1.6.0_24"
216.99.148.x oldal.domainneve.hu - [06/Aug/2013:09:46:45 +0200] "GET /panel.php?act=register HTTP/1.1" 404 345 "-" "Java/1.6.0_24"
216.99.148.x oldal.domainneve.hu - [06/Aug/2013:09:46:44 +0200] "GET /login.php HTTP/1.1" 404 345 "-" "Java/1.6.0_24"
216.99.148.x oldal.domainneve.hu - [06/Aug/2013:09:46:44 +0200] "GET /login HTTP/1.1" 404 345 "-" "Java/1.6.0_24"
216.99.148.x oldal.domainneve.hu - [06/Aug/2013:09:46:42 +0200] "GET /account/register.php HTTP/1.1" 404 345 "-" "Java/1.6.0_24"

A user agentből jól látszik, hogy automatizált lekérdezésekről lehet szó (valami Java alapú HTTP kliens küldözgeti ezeket).

Ami még közös ismertetőjegye a támadásoknak, hogy:

* véletlenszerű időpontokban kezdeményezik
* általában minden szerverünket érintik, de eltérő időpontokban
* csak néhány request jön, vagyis nem DOS-olnak, csak felderítenek
* mivel több (szinte az összes) szerverünk érintett, gyanús, hogy célzott támadásról lehet szó

A támadások forrás IP-tartományai, amiket eddig sikerült felismernünk a logok alapján:

* 216.99.144.0/20, 208.110.64.0/19, 199.36.72.0/21

Írtam a szolgáltató abuse címére, ahol válaszoltak is, és azt mondták, kiiktatták a problémás IP-címeket. Alig telt el egy óra, ismét láttam újabb próbálkozásokat ugyanannak a subnetnek egy másik IP-címéről...

Kérdéseim:

* Tapasztaltok-e ti is bármi hasonlót mostanában?
* Van értelme ilyenkor az IP-szolgáltató abuse címére jelenteni az eseményt (tudnak-e bármi érdemlegeset tenni)?
* Van értelme tűzfalon tiltani ezeket a címeket? Ha kitiltok egy IP-címet, akkor egy másikról folytatják a próbálgatást. Komplett subneteket kitiltani pedig nem biztos, hogy okos megoldás...
* Ti mit tennétek ilyen helyzetben?

Előre is köszi a válaszokat!

( Swifty v | 2013. 08. 09., p – 14:04 )

1. Igen
2. Nem, nem
3. Nem. Jól látod.
4. Semmit.

:D

--
Debian Linux rulez... :D

( sz332 v | 2013. 08. 09., p – 14:07 )

Azt nézd meg, hogy az adott oldalt van-e értelme, hogy az adott ip tartományból nézegessék/elérjék, ahonnan a hackelési próbálkozás jön. Ha nincs, akkor tiltani a francba az adott tartományt.

( Lightning | 2013. 08. 09., p – 15:23 )

Nekem még az otthoni gépre is érkeznek a világ minden tájáról ilyenek. Méghozzá úgy, hogy csak https felett érhető el és az egész virtualhost base auth alatt van. De még a Google Bot is bekopog x időnként... Fail2ban mellett azért jobban alszok.

( lajos22 | 2013. 08. 09., p – 15:50 )

Nálam "Fucking scanner" UserAgenttel jönnek hasonlók. Idegesítő, hogy fél log ezzel van teli, de már megszoktam. Ha valami fontos kell a logból, akkor azt úgyis kikeresem...

Másik meg, hogy szoktak olyanok is jönni, amik azt sugallják, hogy proxynak akarják használni a rendszerem.

--
openSUSE 12.2 x86_64

( KoGa v | 2013. 08. 09., p – 16:36 )

iptables, mod_limit, mod_security (kb. ebben a sorrendben)

( uid_7086 | 2013. 08. 09., p – 16:43 )

Megint olyanról kérdezek, aminek utánanézhetnék, de ha már itt vagyok... :)
Reverse proxy + benne rendszeresen update-elt szűrők nem segíthetnek?
(ha nagy ökörséget kérdeztem, az most nem a szemem, hanem a tudatlanságom miatt van ;) - vegyétek úgy, hogy ez a "subs" hosszú, kódolt formája volt! :D )

Amikről tudod, hogy nálatok biztosan nincsenek.
Pl. ha tudod, hogy nincs wordpress oldalad, akkor a proxy-n kihajigálod a wordpress-es requesteket még azelőtt, hogy a szerverig eljutnának.

Az az igazság, hogy ez egy nagyon hirtelen jött ötlet volt, az eredete, hogy egy időben squid segítségével akartam megszabadulni a facebooktól, bizonyos reklámszerverektől.
Azok mintájára gondoltam valami ilyesmit megvalósítani.
De mint az előzőben említettem: lehet, hogy kapitális marhaság az ötlet.

Az örök kérdés, hogy mi értelme lenne? Scriptek nézik az IP-ket, azzal nem foglalkoznak amit nem találnak, csak azzal amit megtalálnak. Tehát:

- nincs nálad a cucc -> nincs probléma se
- van nálad a cucc, de biztonságos -> nincs probléma
- van nálad a cucc, de nem biztonságos -> az ellen nem véd.

Tehát kb. semmi értelme.

Vannak olyan próbálgatások (legalábbis nálam) ami proxyzásra hajaz. Ha elébaszok egy proxyt, és azon véletlen valami hibát találnak, máris az én szerverem IP-jével basszák tele spammel a netet, aztán lehet pitizni új IP-ért, mer nem éri meg pitizni a sok tiltás leszedéséért...

Igen tudom, be lehet lőni, hogy csak belsőhálóra menjen az a proxy, de azért inkább...

--
openSUSE 12.2 x86_64

( maszili | 2013. 08. 09., p – 17:24 )

Az ilyen felderítések ellen lehet használni azt, hogy T idő alatt okozott 404 hiba esetén az IP ideiglenes tiltásra kerül.

--
maszili

Az OSSEC egész jó dolog, én arra próbáltam beidomítani, hogy ha szokatlan IP tartományból érkezik kérés, akkor nyivákoljon. Sajnos a tanulási fázist nem volt türelmem végigcsinálni, illetve valami adaptív dolog jó lenne, azaz ha valaki nem jelentkezett már be hónapok óta egy tartományból akkor azt elfelejtené, illetve ha kb. egy kattintással lehetne felvenni bele tartományokat. Ja és igen, per user kéne, és asszem ez nincs meg benne.

( aladar68 | 2013. 08. 09., p – 21:11 )

Nálunk ez úgy működik hogy minden szerveren 5 percenként indul egy python script ami a logok (apache,auth) növekményét soronként átnézi és ha egy ip-ről x próbálkozásnál több jött be az utóbbi 5 perc alatt akkor felküldi a tűzfalra az ip-t, ami kitilt minden forgalmat erről az ipről. A cron hetente üríti a kitiltott chains-t. Így az ssh próbálkozások és az URL probing letudva. Kulcsos ssh-t használunk, elvileg esélytelen a próbálkozásuk, de mégiscsak viszi a drótot, cpu-t, vinyót.

( Mcsiv v | 2013. 08. 09., p – 22:06 )

Szia!
Az indító hsz alapján nekem is felmerült /legalább/ egy kérdésem.
Miért zavar ez téged?

A kérdéseidre a válaszok:
- Mindenki tapasztal ilyet akinek legalább egy hálózati eszköze van, egyetlen nyitott porttal.
- Míg nem konkrét támadás, teljesen felesleges az abuse címre írni (azzal hogy visszaírtak, legalább látod hogy figyelnek rá, legtöbb helyen az ilyet helyből küldik már a /dev/null -ba).
- Nincs értelme. Hidd el, több bot van a világban mint szabad memóriád a rule-oknak
- Semmit. Van rálátásom nagy rendszerre, az ilyenek már fel sem tűnnek:). Kis rendszernél meg csak tele spammeli a logot, de hely van rá, olcsóbb mint a false pozitív, túrkálásnál meg az univerzális tool a grep:)

Szóval visszatérve az elejére, egy 404 kiszolgálása mondjuk úgy, nem igazán performance kérdés. Egy normálisabb script több erőforrást pazarol az ilyenek kiszűrésére, mint amennyit ér az egész hercehurca

// Happy debugging, suckers
#define true (rand() > 10)

Szia!

Köszönöm a részletes válaszokat.

Igazából nem zavar annyira, csak feltűnt, hogy mostanában megszaporodtak az ilyen próbálkozások, egyre több szerveren és egyre gyakrabban látok ilyet, ez azért elgondolkodtató.

Amiért zavarhatna az az, hogy sejtésem szerint különféle, ismert sebezhetőségeket tartalmazó CMS-ekre és fórummotorokra vadásznak ezekkel a látszólag ártalmatlan requestekkel, hogy aztán a sebezhetőségeket végigpróbálgatva feltörhessék őket. Ez engem, mind sysadmint azért kicsit aggaszt... Ha nem lenne se fórum, se dobozos CMS-re épülő weboldal a szervereinken, akkor nem érdekelne, de sajnos fejből tudok mondani egy olyan site-ot az osztott szerverünkön, ami Wordpress-re épül, és erős a gyanúm, hogy az oldal adminjai nem frissítik a CMS-t kellő rendszerességgel - ha egyáltalán eszükbe jut ilyesmi.

Ez utóbbit megértem, viszont:
- Ha rövid a mintavételi időszak: nem tudod felderíteni az összes botot, vagyis csak redukálod az esélyeket
- ha hosszú a mintavételi időszek: felderítheted a botokat (bár így is lesz olyan ami átjut) viszont növeled a false pozitív eredményét (elég csak egy rossz helyre mutató kép az oldalon a 404 errorhoz).

Ráadásként egyre több bot proxy-zik (kb 3 hete volt egy konkrét pw probe támadásom, akkor 5 másodpercenként jött egy request, viszont a végelszámolásban kb 3000 ip szerepelt).

Felesleges ilyennel terhelni magad, mert csak megcsömörlik az ember:) Legyen backup, legyen mit visszarakni gyorsan ami friss, a többiért meg szívja az ügyfél a fogát hogy baszott frissíteni. Még nem találkoztam olyan esettel, akinek ilyen helyzetbe nem lehetett elmagyarázni hogy a hiba a szar, tákolt oldalában van.

// Happy debugging, suckers
#define true (rand() > 10)

Sajnos nem lehet figyelmen kívül hagyni az ilyen eseteket. Mert a felderítés után majd jön a 3000 tagú botnet hálózat, erőből wp-login.php-t hivogatni és akkor elviszi az erőforrásaidat. És nem mondhatod az ügyfélnek, hogy az ő hibája mert nem frissítette a wordpress keretrendszert.

A 404 hiba akkor is hiba ha az ügyfél hibájából adódik. Ha az oldalon több száz olyan hivatkozás van ami mögött nincs tartalom akkor az az oldal rossz.

--
maszili

Előfordul, hogy hülyék...
Sajnos én már többször is közelről láttam olyat, hogy nem finomkodtak. Megszámlálhatatlan IP címről egyidejűleg ~80-100 domainra záporoztak folyamatosan a POST wp-login.php kérések.

Persze az is egy szemlélet, hogy azért költ valaki milliókat hardverre, hogy az ügyfelek helyett kiszolgálja hakkert és a botnet hálózatot.

--
maszili

Ez inkább valószínű hogy több, egymástól független script nyálazta ugyanazt a tartományt. Legfeljebb azt lehet felróni nekik, hogy a botnetek üzemeltetői nem egyeztettek hogy mikor kit próbálnak törni :D

Ha meg DDOS-ról van szó, akkor úgyse működnek a házi barkácsok, legalább a szolgáltató segítsége kell, vagy inkább egy cloudflare vagy hasonló.

Továbbra is azt mondom, hogy ha megoldható, akkor egyszerűbb teljes IP tartományokat
kibannolni, weboldal szinten. Tehát, ha XY Kft. weboldala teljesen magyar nyelvű, akkor
ők valószínűleg engedélyezik, hogy kínából, indiából, meg tököm tudja honnan ne lehessen
megnézni az oldalukat, cserébe ennyivel kevesebb helyről tudnak betámadni. Jó eséllyel
elég, ha a magyar, meg a környező pár, magyar nyelvű lakossággal rendelkező országot engedélyezed,
esetleg ha nagyon jó fej vagy, akkor EU + környező pár ország.

Miért lett itt ekkora divat kapásból lehülyézni mindenkit?

Gondolj bele: mondjuk egy hazai építőipari, klímás, ablakos, egyéb hasonló területen működő kis cégnek mi szüksége lehet arra, hogy kínai, argentín, indiai (hozzám főként ilyen címekről jönnek érthetetlennek látszó csomagok) címekről nézegessék a weblapját? Elhanyagolhatóan kicsi az esélye, hogy valaki épp Kínában tartózkodik, mikor eszébe jut, hogy ablakot kéne cseréltetni a budapesti lakásában és sürgősen körül akar nézni egy ilyen cég weblapján. Szerintem.

A security through obscurity kifejezés használata erre az esetre teljesen hibás. Ezt a kifejezést akkor használjuk, amikor egy rendszer biztonságát azzal próbáljuk egyedül biztosítani, hogy nem mondjuk meg, hogyan működik.

Amit én javasoltam, az egy gyors megoldás egy problémára, ami a támadások jó részét blokkolja. Ez még nem jelenti azt, hogy más módon ne védekezzünk a probléma ellen - erre is volt egy csomó tipp a topicban - de ez egy gyors és viszonylag elég hatékony megoldást jelent.

Mondjuk azért, mert ritka nagy tahóság azért kitíltani a fél világot, mert ugyanez a rendszergazda összepisili magát két darab 404-től. Tanuld meg beállítani a szervered/neveld meg az ügyfeleidet, aztán mindjárt nem leszel feleslegesen paranoid, illetve nem hozol hülye szabályokat.

// Happy debugging, suckers
#define true (rand() > 10)

Tahóság? Má' bocs, de ha a cég érdekei úgy kívánják/nem hátráltatja semmiben a cég működését, már miért lenne ez tahóság? Szegény kis ferdeszemű hekkerpalántákkal szembeni kicseszés miatt? Vagy hogy? :)
Olyan felháborodással írod, mintha tudnád, hogy hol dolgozik a srác és épp áldozatul esnél egy ilyen kitiltásnak (jakérem, aki tor-t használ, az magára vessen!)

ui: felesleges paranoia manapság nem létezik, a internetes biztonságról van szó. :)

Pedig ezt a modszert sokan alkalmazzak. USA-ban el egy baratom es magyar VPN-re volt szuksege tobb magyar oldalhoz is. Most nem irom le melyik nagy tarhelyszolgaltato is meguszta volna, hogy torok bunozok ferget tegyenek minden ugyfeluk index oldalara.

Az lenne a jo, ha a szolgaltatok komolyan vennek ezt. Peldaul ha tobben jelentik, akkor net kikapcs, amig abba nem hagyja a tevekenyseget vagy le nem szedeti a ferget a geperol. Ezt lehetne osztonozni azzal, hogy ha x ISP sz*rik ra, akkor tiltani az egesz tartomanyat. Tehat egy ido utan szigette valna :)

Mail eseten ez anno megesett az Ax*leroval is. Nem foglalkoztak semmivel aztan egy ideig nem fogadtak az onnan kuldott levelelet a szerverek (akik spam adatbazist hasznaltak). Aztan gondolom forrottak a telefonok es gyorsan leszedettek magukat..

"meguszta volna, hogy torok bunozok ferget tegyenek minden ugyfeluk index oldalara."

Ezt azért nem fogadnám le egy pohár forró teába se. Ha nem valamelyik, netről letölthető "hacker kit"-tel törték őket akkor valszeg nem a saját gépükről végezték az érdemi támadást. Innen kezdve csak az a kérdés hogy mikor találnak megfelelő tartományban lévő ugródeszkát. Mert fognak találni, az nem kérdés :D

Ha egy oldal nem jott be, megnezted mindig kulfoldi VPN-el? Mert kulonben nem tudhatod. Egyebkent tobbszor is elofordul - Magyarorszagon belul is - hogy egy szolgaltatotol megy egy oldal, mastol meg nem. Persze ilyenkor rosszul beallitott routing a felelos altalaban. HUP-on is nem egy ilyen temat talalsz. Tehat az ideiglenes sziget uzem nem is olyan ritka dolog..

Bevallom neked őszintén, nem sűrűn találkozom olyan oldallal ami ne jönne be, ha meg mégis, akkor általában tesztelem más tartományból is (volt már hogy más tartományból bejött, de az az előbb említett elcseszett routing), nem konkrét országok tűzfalra rakásából eredt.

A véleményem továbbra is az, hogy megfelelően beállított szerver mellett nem szükséges az ilyen szintü paranoid védelem, a hülye ügyfelet pedig semmilyen védelem nem védi meg

// Happy debugging, suckers
#define true (rand() > 10)

Valószínűleg ez azért lehet, mert nem jellemző világszinten, hogy Mo-ról indítana valaki
támadást. Egyszerűen egy kicsi ország vagyunk, a szolgáltatók pedig valószínűleg elég
hamar morcosak lesznek attól, ha megkeresést kapnak, hogy kovács pistike éppen buta módon
proxy nélkül próbál hackelgetni egy oldalt. Esélyes, hogy ilyenkor egy bűntetőfeljelentés
is megy a rendőrségnek, azok meg szeretik a jó statisztikát, és nincs egyszerűbb, mint
egy adott fix címre kimenni, lefoglalni egy gépet, és begyűjteni a jópontokat.

Tor-t használtál már?
Én nem mertem bekapcsolni a routeremen, bár egy rövid ideig foglalkoztatott a gondolat, épp az említett youtube-os mocsokságok miatt, de végül győzött a paranoia: én kimehetek a netre bárhol a világon, ez igaz, de ki tudja, ki és mire használja úgy az én címem. És ezt már nem mertem bevállalni.

Ilyen alapon mondjuk a youtube is tahó dilettánsok gyülekezete, mert sok anyaguk van/volt amit csak bizonyos országokból lehet(ett) elérni. :) Ahogy az iptables-be is csak poénképp került a geoip modul. Nem néztem utána, de ennek milyen funkciója van még a földrajzi alapon történő tiltáson túl?
Mondjuk a youtube módszerét én is tahóságnak tartom. :)

Nem keverem, azt valódi tahóságnak tartom.
B+! Egy Led Zeppelin, egy Dire Straits, egy Pink Floyd... soroljam? Ilyen felvételeknél botlom sorra abba, hogy Magyarországról nem nézhető. (sajnos már töröltem mindenemet kémország médiaszerveréről, különben fel tudnám sorolni egyesével azokat, amiket egyszer megnéztem, eltettem a kedvencek közé, majd pár héttel később már elérhetetlenek voltak :( )

És ez egy nemzetközi cég, amiről meg eredetileg szó volt, az kis, hazai vállalkozások weboldala, ahol eleve nem jöhet távol keletről, dél-amerikai címekről legális forgalom, vagy ha jön, akkor is csak a sávszélt viszi, üzletet biztosan nem hoz.

http://hup.hu/node/126144?comments_per_page=9999#comment-1631645
http://hup.hu/node/126144?comments_per_page=9999#comment-1631582
http://hup.hu/node/126144?comments_per_page=9999#comment-1631102

Általában még előtte kiemelik, hogy legyen up-to-date a rendszer. Továbbra is fenntartom hogy az ilyen mókás barkácsolás csak árt.

Ha _muszáj_ a régi, elavult appot alkalmazni, futtatni, hostolni, bármi, akkor érdemi védelem kell elé (app/protokoll szintű proxy, fw), nem pedig a címekkel, tartományokkal zsonglőrködni.

Csak elegánsan átsiklasz azon apróság felett, hogy kifejezetten hazai célközönségű, kis cégekről beszéltünk eredetileg.
Senki sem mondta, hogy egy multi magyarországi telephelyén üzemelő szerverek esetében ez megoldás.

Viszont elnézve, hogy ami szemét dől az itthoni routeremre, az esetek 90%-ában kínai, dél-amerikai címekről jön... Valami alapja talán mégis lehet a fenti esetben.
És nem győzöm hangsúlyozni: kis cég, kifejezetten és határozottan magyarországi célközönséggel volt az eredeti téma.

Én nem a célközönségről beszélek hanem magáról az elvről.
Arról az elvről, hogy egy internetes szerver azért lóg a neten és nem egy belső hálón, hogy bárhol, bármikor, bárhonnan hozzáférjen a publikus tartalomhoz. Az hogy kitíltod a fél világot (mert ez a kettő terület ráadásként valóban lefedi a föld népességének a felét) nem véded meg a szervered semmitől (de, 50k logtól napi szinten), a föld maradék fele meg ugyanúgy megtöri mert szarul van beállítva.

// Happy debugging, suckers
#define true (rand() > 10)

Elv: kis cég, szűk célközönség, csak a célközönséget engedem be.
Ezzel a potenciális próbálkozók nagy részét kiszűrtem.
Tökéletes, törhetetlen rendszer nincs, ezt gondolom te is tudod. Akkor miért ne szabaduljak meg azoktól a kísérletezni vágyóktól, akik eleve nem is lehetnek számomra célközönség.
Épp elég az a megmaradó fél százalék is...
De ez csak a saját véleményem.

erősen offtopic ugyan, de: ha lenne munkahelyem és időnként az itthoni eszközökön akarnék matatni, az ssh-t/vpn-t biztosan csak a cég publikus címéről engedélyezném, holott tisztában vagyok vele, hogy hamisítható az IP cím, így semmi biztosíték rá, hogy valóban én próbálkozom onnan. De mégis kitiltom a világ többi részét, mert kevésbé tartok tőle, hogy olyan valaki esik be, aki sikeresen hamisítja a céges IP-t és a privát kulcsomat.

Mesélj, milyen alapismeretről beszélsz? :D
Ráadásul, de, elsősorban publikus szolgáltatásról beszélek, csak másodsorban említettem meg, hogy akkor is kizárom a világot, ha történetesen magamat be akarom engedni...

Kísértetiesen emlékeztet a stílusod bizonyos Stingére... Amikor kiderül, hogy nincs igaza, sürgősen elkezdi úgy terelgetni a társalgást, hogy megmagyarázza, de mégis és következetesen lehülyéz mindenkit, aki ellentmond neki. :))

Már nem azért, de szerintem rosszul látod. Ha van egy wordpress blogja a felhasználónak,
semmi nem garantálja, hogyha még a legújabb-legfrissebb is, nem tudják megtörni. Ezt úgy
hívják, hogy programozási hiba, és lehetsz te a világ legügyesebb rendszergazdája, attól
még meg fogják törni. Erre mit fog mondani az ügyfél? Hogy nem megy az oldala, csináld
meg. Ekkor te előszeded a mentést, és visszaállítod. Ez neked mind idő, mind pénz.

Ahelyett, hogy egyszerűen a lehetőséget se adnád meg a kici ócó hakkergyereknek azzal, hogy egész kínai/india/oroszország/stb. az adott site tekintetében bannolva lenne.

Ez nem azt jelenti, hogy a többi védelmi vonalat nem érdemes felhúzni, de ez szerintem *bizonyos esetekben* egy elég egyszerű megoldása a problémának.

( Dacr (nem ellenőrzött) | 2013. 08. 10., szo – 22:53 )

Azokra, ami nincs nalad es tuti 404re megy, irj fail2ban szabalyt. Par nap alatt leszoknak a szerveredrol. Csak vigyazz, ne hogy ugyfelet is tilts vele.
Nem haszontalan. Altalaban visszatero "vendegek", bovitik a keresett belepesi pontok listajat, amit szkennelnek.
Nalam ez a modszer kb egy eve teljesen megszuntette az ilyen probalkozasokat.
--
zsebHUP-ot használok!

A visszatérő "vendégre" meg oda kell tenni egy jó kis mézesbödönt (honeypot), hadd rágódjon rajta. Ha belemászik, amíg dolgozik rajta, addig lehet őt logolni, tanulmányozni, és egyéb kreatív módon gondoskodni arról is, hogy érezze a törődést. :)
-
"Attempting to crack SpeedLock can damage your sanity"

Ez egy script által generált forgalom, nem foglalkozik semmivel, nem kell neki mézes bödön. Csak szkennel és megy tovább. Ha talál valamit, azt elteszi a másik szkript részére, ami majd próbálkozik a töréssel. Ha sikerül neki, akkor szól a gazdinak. Ezért az első feltérképező szkriptnek nem kell adni semmit, hanem el kell hajtani a csába, különben rajtad fog csámcsogni.