User kizárása hibás bejelentkezéseket követően
2013-04-01T17:24:52+02:00
2013-04-02T15:56:44+02:00
2022-08-07T15:35:28+02:00
balint85
Ez fontos? Jelenleg úgy működik az oldalam, hogy a hibás bejelentkezéseket egy táblában tárolom (USERID, NUM_OF_ATTEMPTS, DATE_OF_LAST_ATTEMPT) és 5 hibás bejelentkezést követően emailben értesül erről a user.
Van értelme kizárnom a felhasználót ezután? Kipróbáltam és pl. a drupal vagy a yahoo nem zár ki 15 próbálkozás után sem.
Persze a felhasználónak egy 15 perces kizárás egyfajta védelmet nyújt a szótártámadással szemben, viszont nekem, mint szolgáltató szempontjából nem jelent kisebb adatbázis terhelést, mivel a bejelentkezéskor vizsgálnom kell az adattáblában hogy hányadik bejelentkezésről van szó az adott user névvel.
Rosszul gondolom?
Mutasd a teljes hozzászólást!
egyrészt igen. Ne az adott névre figyelj, amire próbál bejelentkezni.
Én így oldom meg :
$sql = "delete from loginfail where `time`<".strtotime("-24 hour",time());
Ez lefut az adatbázishoz kapcsolódás után, így külön macera nélkül törli a megadott időn túli sikertelen próbálkozásokat (mint látod, nálam 24 óra a tiltás ideje)

$sql = "select id from loginfail use index(ip) where ip=\"{$_SERVER['REMOTE_ADDR']}\" order by `time` asc"; $result = mysql_query($sql);
Ezzel pedig megnézem, hogy mennyinél tart. 5 lehetősége van.
Ki is írom neki, hogy sikertelen, még # alkalommal próbálkozhat.
Ennek a két lekérdezésnek a terhelése majdnem 0 (a próbálkozásokhoz képest).
Aztán ha elérte a max. sikertelen belépések számát :
if (mysql_num_rows($result)>=5) { die("Az oldalhoz való hozzáférésed 24 órára felfüggesztésre került."); }
Mutasd a teljes hozzászólást!

  • Ha terhelőnek véled mysql-ben tárolni, tárold txt-ben. Bár ekkor lesz kismillió fileod. Az már másik kérdés, hogy a sok apró file mennyire befolyásolja a winchesterek sebességét.
    Mutasd a teljes hozzászólást!
  • A kérdés inkább arra vonatkozott hogy a kizárásnak mi értelme van.
    Mutasd a teljes hozzászólást!
  • Esetleg adott IP-t bannolhatod 15 percre, hogy még a form se jöjjön be neki. Bár ennek is van hátránya.
    Mutasd a teljes hozzászólást!
  • Hát mondjuk a bruteforce elleni védekezésnél van szerepe. Ha valaki ráenged egy ilyet akkor addig próbálkozhat amíg a szerver bírja, vagy le nem tiltod a próbálkozását.
    Mutasd a teljes hozzászólást!
  • Mit tiltsak le? Mert ahogy írtam, ha van adatbázis kapcsolat akkor már van terhelés.
    Mutasd a teljes hozzászólást!
  • Mekkora az oldal forgalma? Ha kifogsz egy ilyen esetet, akkor elenyésző lesz az a terhelés amit ez a lekérés okoz azzal szemben, ha valaki erőszakosan próbál bejutni. Az a baj, hogy még te sem tudod mit akarsz tudni.

    Leírtam, hogy mi van akkor ha... És leírtam hogyan óvhatod a terheléstől a mysql-t... de egyiket sem olvastad/értelmezted.
    Mutasd a teljes hozzászólást!
  • A plusz teendőket állítsd szembe az előnyökkel, ez alapján neked kell eldöntened, hogy megéri-e. Azt is gondold végig, hogy egy támadás esetén egy jól megírt kizárás mennyi erőforrást tud megspórolni, vagy egy illetéktelen belépés mekkora kárt tud okozni.
    Mutasd a teljes hozzászólást!
  • Ezta kárt vagy illetéktelen belépést hogy előzöd meg vagy véded ki? Gondolom nemcsak mysqlrealescapesting kell.
    Mutasd a teljes hozzászólást!
  • Kizárásról szól a téma; átmeneti kizárással csökkenthető az illetéktelen belépés lehetősége.
    Mutasd a teljes hozzászólást!
  • egyrészt igen. Ne az adott névre figyelj, amire próbál bejelentkezni.
    Én így oldom meg :
    $sql = "delete from loginfail where `time`<".strtotime("-24 hour",time());
    Ez lefut az adatbázishoz kapcsolódás után, így külön macera nélkül törli a megadott időn túli sikertelen próbálkozásokat (mint látod, nálam 24 óra a tiltás ideje)

    $sql = "select id from loginfail use index(ip) where ip=\"{$_SERVER['REMOTE_ADDR']}\" order by `time` asc"; $result = mysql_query($sql);
    Ezzel pedig megnézem, hogy mennyinél tart. 5 lehetősége van.
    Ki is írom neki, hogy sikertelen, még # alkalommal próbálkozhat.
    Ennek a két lekérdezésnek a terhelése majdnem 0 (a próbálkozásokhoz képest).
    Aztán ha elérte a max. sikertelen belépések számát :
    if (mysql_num_rows($result)>=5) { die("Az oldalhoz való hozzáférésed 24 órára felfüggesztésre került."); }
    Mutasd a teljes hozzászólást!
  • Értem, csak azt mondom (ha jól gondolom), hogy ha 1000x próbálok bejelentkezni egy accountba, akkor az sql selected lefut 1000x.
    Mert rendben, kizárom a usert mondjuk 1 órára, ami neki jó, hiszen csak 5 próbálkozás lehetséges óránként, de ettől még minden egyes alkalommal (akár másodpercenként 1000x) történik adatbázis query.
    Mutasd a teljes hozzászólást!
  • ok. akkor számolj kicsit.
    Tételezzük fel, hogy már letiltottad a júzert.
    Mi történik amikor megnyitná az oldalt? dobsz egy sima szöveges üzenetet, hogy nem megy.
    2 lekérdezés összesen (törlöd a régieket, és ellenőrzöd az állapotot) + egy sima szöveg kiírása (engem nem érdekel, hogy a letiltott júzer nem kap csilivili üzenetet).

    Mi van, ha nem tiltod le?
    Megkeresed az adott névhez tartozó rekordot, kódolod a jelszót, ellenőrzöd, ha sikertelen, kiírod (ehhez akár 1000x felépíted az oldalt + naplózod a sikertelen belépést), hogy hibás név/jelszó.
    Plusz, előbb vagy utóbb sikerül (mondjuk brute-force) megtörnie a jelszót.
    minimum 2 lekérdezés ebben az esetben is, plusz létrehozod a tartalmat (több fájlból áll, képeket tölt le, css-eket, etc).

    Végülis ... igazad lehet, alig jár kevesebb terheléssel.
    Csak az accountot fogják feltörni

    Komolyra fordítva.
    Nem azért kell korlátozni, mert kevesebb terhelést okoz, hanem biztonsági szempontból. Ne tudjanak más nevében rosszalkodni (hardveraprón történt pont ilyesmi mostanában, lett is belőle sündőrségi ügy)
    Mutasd a teljes hozzászólást!
  • Csináld meg azt, hogy ha valaki pl. 5-ször próbálkozott és így sem tudta a jelszót, akkor egy sima fájlba (vagy egyd táblába) feltöltöd az ip címét, meg azt, hogy mikor történt az eset (pl. időbélyeg formájában). Ezután minden oldalon (vagy legalábbis a bejelentkező felülethez, de inkább minden oldalra) rögtön a lap elején ellenőrizd le a felhasználókat, hogy benne vannak-e ebben a listában. Ha igen akkor nem is kell tovább futnia a kódsornak.
    Mutasd a teljes hozzászólást!
  • Ha vki IP címet akar blokkolni (amit én nem feltétlenül tennék), akkor már tűzfalon blokkolja és ne php szinten. Ha php-val blokkolsz, akkor a webkiszolgálót ugyanúgy terhelné már a kérés, ráadásul egy szöveges file-t is kezelni kéne, ami még kevésbé hatékony, mint egy db.
    Mutasd a teljes hozzászólást!
  • Azért alap esetben egy egyszerű tárhelyszolgáltatónál ez nem hiszem, hogy életképes lehetőség lenne, hogy egy ügyfél csak úgy a tűzfalba nyúljon.
    Mutasd a teljes hozzászólást!
  • Röviden és tömören: Köszönöm a kielégítő választ. A letiltás tehát a user szempontjából jó, ahogy sejtettem, de bizonyos mértékű adatbázis terhelés-feloldást is jelent.
    Mutasd a teljes hozzászólást!
  • rossz ötlet. Nehezebb törölni belőle, ha lejárt a tiltás ideje.
    Mutasd a teljes hozzászólást!
  • Eszembe jut itt egy történet: Számítás technika tanár nagy önelégültséggel mondja a diákoknak, hogy két hibás bejelentkezés után a rendszer letiltja a felhasználót és csak ő oldhatja majd fel. Erre megkérdezi az egyik gyerek: Szóval ez azt jelenti, hogy két enter lenyomásával azt zárok ki akit csak akarok? xD (a user nevek a rendes nevek rövidítései voltak, így mindenki tudta mindenkiét.)
    Mutasd a teljes hozzászólást!
  • php-ból LAMP -on nem férsz hozzá a tűzfalhoz. WAMP-on meg ... ehh ... hagyjuk is, van annak normális tűzfala?
    Mutasd a teljes hozzászólást!
  • php-ból LAMP -on nem férsz hozzá a tűzfalhoz.


    1. Ez az állítás így ebben a formájában téves.
    2. Ha még1x elolvasod a hozzászólásomat, azt írtam, hogy nem javaslom az IP cím alapján történő tiltást.

    @juhostt1:

    Ha már vkinek a terhelés miatt kell aggódnia, az ne egy ingyenes/olcsó tárhelyszolgáltatónál tartsa a weboldalát.
    Mutasd a teljes hozzászólást!
  • 1., akkor megkérnélek avass be, hogy egy 'sima' linux-apache-php-mysql rendszeren hogy tudod írni az iptables-t wwwuser -el. Melyik az a bátor rendszergazda, aki ehez hozzáférést ad? (mert egy laza csuklómozdulattal le lehet tiltani mindent, vagy ennek az ellenkezőjét)
    2., mivel a hitelesítés nem sikerült (hibás név/jelszó), így hogy másképp azonosítod az usert akit tiltani akarsz? Küldesz neki cookie-t? IP-t is tud cserélni (dsl-en a legegyszerűbb), de az mégis 1 hajszálnyival macerásabb, mint egy sütit kitörölni. Amúgy nem végleges a tiltás (legalábbis én nem azt javasoltam). Csak egy időre szól (5/10/20/x perc/óra/nap...fényév)
    Mutasd a teljes hozzászólást!
  • akkor megkérnélek avass be, hogy egy 'sima' linux-apache-php-mysql rendszeren hogy tudod írni az iptables-t wwwuser -el.


    Ki mondta, hogy az iptables látja el a tűzfal funkcióját? Ki beszélt arról, hogy a wwwuser-rel kell ezt megcsinálni?

    IP-t is tud cserélni (dsl-en a legegyszerűbb), de az mégis 1 hajszálnyival macerásabb, mint egy sütit kitörölni.


    Alapvetően félreérted a problémámat! Mi van a natolt hálózatokkal meg a dinamikus IP címekkel? Egy IP cím letiltásával az én munkahelyem esetén akár több tízezer vétlen felhasználót le lehet tiltani. Vagy a dinamikus IP címet a szolgáltató egy másik, vétlen felhasználóhoz allokálja az IP címet, aki aztán néz, mint a moziban!

    IP címet csak legvégső esetben, túlterheléses támadások esetén tilt bármilyen épeszű rendszergazda. Egy webes alkalmazás felhasználói fiókjának betörésvédelmét az adott fiók alkalmazás szinten történő ideiglenes zárolásával célszerű megoldani.
    Mutasd a teljes hozzászólást!
  • Ki mondta, hogy az iptables látja el a tűzfal funkcióját

    Tűzfalról volt szó, az pedig az iptables

    Ki beszélt arról, hogy a wwwuser-rel kell ezt megcsinálni

    Alapesetben a scriptek (php/perl/kutyagumi) a wwwuser alatt futnak. Hacsak nem chroot-olod az apacheot is (ezzel más problémákat a nyakadba véve), vagy nem állítod át, akkor wwwuser. Neki pedig nincs ehez (sem) joga.

    Mi van a natolt hálózatokkal meg a dinamikus IP címekkel

    Ez 2 kérdés 1 mondatban.
    A NAT-olt így járt. Ha onnan akar valaki betörni, majd gondolod engedem? Csak azért mert NAT? Lóf*szt
    Dinamikus IP-t pedig írtam én is. Nagyon nem tudsz vele mit kezdeni. Letiltod és csókolom. X idő elteltével pedig engedélyezed.

    ...alkalmazás szinten történő ideiglenes zárolásával célszerű megoldani.

    Ami lényegében ugyan az. Nem tud csinálni semmit. Miről is beszélünk tulajdonképpen? Én kiírom neki, hogy tiltva van, és ennyi. A te módszereddel pedig kattintgathat az oldalon, de (mondjuk) nem tud rendelni a webshopból, nem tud írni a fórumba, lényegét tekintve a te módszered "felhasználóbarátabb" (ha ezt írtam a te módszeredre, akkor az enyém "szerverbarátabb"?), de végül is fölösleges terhelést eredményez, mert a júzer próbálkozni fog, hátha valahol-valahogy mégis be tud jelentkezni. Így sem ill. úgy sem tud semmit sem csinálni, amíg a tiltása le nem jár.

    Amúgy a második kérdésemet nagyvonalúan figyelmen kívül hagytad.
    Hogy másképp azonosítod, ha név/jelszóval nem sikerült, és korlátozni akarod az oldalhoz való hozzáférését?

    Közben eszembejutott valami még ezzel kapcsolatban. Este le is írom (ezt veheted fenyegetésnek )
    Mutasd a teljes hozzászólást!
  • Tűzfalról volt szó, az pedig az iptables


    Az iptables az a linux kernelszintű csomagszűrőjének az IP és ARP csomagokra vonatkozó szabályait piszkáló progi, tehát egy tűzfal, de nem a tűzfal. Tűzfal ezen kívül van kismillió még linuxra is, a külön hardveres eszközökről nem is beszélve.

    Alapesetben a scriptek (php/perl/kutyagumi) a wwwuser alatt futnak. Hacsak nem chroot-olod az apacheot is (ezzel más problémákat a nyakadba véve), vagy nem állítod át, akkor wwwuser. Neki pedig nincs ehez (sem) joga.


    Egyrészt ez az alapeset, másrészt, ahogy már írtam: senki nem mondta, hogy iptables-ről van szó. Egyébként, még az apache-ot sem kell chroot-olni ahhoz, hogy php-ból más felhasználó nevében futass egy szkriptet. De ez megintcsak irreleváns, hiszen rajtad kívül senki sem beszélt iptables-ről.

    A NAT-olt így járt.

    Ez nem túl bizalomgerjesztő hozzáállás a részedről, pláne pár jelszó tévesztésért cserében. Valszeg gyorsan kezdenél felhasználókat veszíteni!

    a ezt írtam a te módszeredre, akkor az enyém "szerverbarátabb"?)


    Ha nem fogod már meg tűzfal szinten, akkor nem sokkal szerver barátabb azIP cím alapú tiltás, mint csak a felhasználói fiók tiltása!

    Így sem ill. úgy sem tud semmit sem csinálni, amíg a tiltása le nem jár.


    Ez így megintcsak nem feltétlenül igaz. Az oldal rendelkezhet olyan funkcióval, hogy a regisztrált email címre küld egy levelet egy aktiváló linkkel, amelyre kattintva a felhasználó újra aktiválhatja a felhasználói fiókját és akár új jelszót is kérhet. persze, ha IP cím alapján tiltod, akkor még IP címet is kellene cserélnie. Vagy netán mobil telefonra küld kódot, amit be kell írni (lásd gugli). És ez már válasz is a 2. kérdésedre. Gondoltam, ez elég nyilvánvaló megoldások, hiszen sok helyen alkalmazzák őket.
    Mutasd a teljes hozzászólást!
abcd