XMX

Ingyenes biztonsági ellenőrzés 19 forrásból

Mit lát a támadó a weboldaladból?

Amit te nem nézel meg, azt más nézi meg helyetted. Írd be a domained, az IP-címed vagy egy gyanús linket: tíz másodperc múlva tudod, szerepel-e feketelistán, mi fut a szerveren és mi látszik belőle kifelé, milyen ismert hibák fenyegetik, és mit tegyél először.

Mit vizsgáljunk?

Ingyenes. Regisztráció nélkül. Passzív vizsgálat: nem támadunk, nem szkennelünk.

nyilvános adatforrás
19
beállítás-ellenőrzés
14
kérdés, sorban megválaszolva
6
regisztráció nélkül
0 Ft

Így működik

Három lépés, és tudod, hol állsz.

  1. Beírod, mit vizsgáljunk

    Domain, IP-cím vagy egy link, amit valaki küldött. A típust magunktól felismerjük, nem kell beállítani semmit.

  2. Lekérdezzük a forrásokat

    19 nyilvános adatbázis és a saját ellenőrzéseink: DNS, tanúsítvány, fejlécek, levélvédelem. A céltól csak annyit kérünk le, amennyit egy böngésző is látna.

  3. Megkapod a jelentést

    Egy képernyőn a lényeg: a szint, a három legfontosabb teendő és a hat lépés eredménye. Alatta minden bizonyíték, forrással és dátummal.

A jelentés

Nem riogatunk. Megmondjuk, mit tegyél, és miért.

Minden jelzésnél három dolgot kapsz: mi a baj, mennyire biztos, és hogyan javítsd. A legfontosabb teendő az első helyen, a bizonyíték egy kattintásra. A jelentést továbbküldheted a fejlesztődnek vagy a tárhelyszolgáltatódnak: ők is pontosan látják, mit kell tenni.

  • Szint, egy bekezdéses magyarázattal, kitalált pontszám nélkül
  • A három legfontosabb teendő, sorrendben, a javítás módjával
  • Hat lépés, egy-egy mondatban, zöld-sárga-piros jelzéssel
  • Minden megállapításnál: forrás, dátum, mennyire biztos
Minta

Biztonsági jelentés

weboldalad.hu

Figyelmet érdemlő jelzések

Ubuntu 22.04 LTS, Apache és OpenSSH fut rajta. Az OpenSSL ága lejárt, két ismert hiba vonatkozik rá. A HTTPS rendben, a DMARC csak figyel.

Mit tegyek először?

  1. 1Frissítsd az OpenSSL-t támogatott ágra
  2. 2Állítsd a DMARC-ot p=quarantine-ra
  3. 3Rejtsd el a szerver verziószámát

A vizsgálat hat lépése

  1. Kit vizsgáltunk? Rendben
  2. Mi fut a szerveren? Rendben
  3. Milyen ismert hibák vonatkoznak rájuk? Javítandó
  4. Mi látszik kifelé? Rendben
  5. Hogyan van beállítva a weboldal? Javítandó
  6. Szerepel-e feketelistán? Rendben
Minta: így néz ki egy jelentés első képernyője

Mit tudsz meg

Hat kérdés, amire valódi választ kapsz

Abban a sorrendben, ahogy egy biztonsági szakember is végigmenne rajta: a céltól a szoftvereken és az ismert hibákon át a feketelistákig.

  1. 1. lépés

    Kit vizsgáltunk?

    A domain, a mögötte álló IP-cím és hálózat, a DNS és a nyilvános tanúsítvány-napló. Ez a kiindulópont: minden további adat ehhez kötődik.

  2. 2. lépés

    Mi fut a szerveren?

    Operációs rendszer, webszerver, szolgáltatások és verzióik: a kezdőlap jeleiből és a Shodan megfigyeléséből, minden tételnél azzal, honnan tudjuk és mennyire biztos.

  3. 3. lépés

    Milyen ismert hibák vonatkoznak rájuk?

    A felismert verziókhoz tartozó CVE-k szoftverenként, pontszámmal és a kihasználtság jelzésével. Ez verzióegyezés, nem igazolt érintettség: a disztribúció a verziószám változtatása nélkül is javíthat.

  4. 4. lépés

    Mi látszik kifelé?

    A Shodan által korábban látott nyitott portok és szolgáltatások, értelmezve: mi az, és kell-e nyilvánosnak lennie.

  5. 5. lépés

    Hogyan van beállítva a weboldal?

    HTTPS, biztonsági fejlécek, a levelezés védelme és a DNS: 14 ellenőrzés egy pillantásra.

  6. 6. lépés

    Szerepel-e feketelistán?

    A Google veszélylistája, az abuse.ch malware-adatbázisa, az AbuseIPDB bejelentései és a korábbi nyilvános vizsgálatok.

Kinek való

Nem kell szakembernek lenned. Elég, ha van egy domained.

Webshop, cég, egyesület

Fizetsz a tárhelyért, de senki nem mondja meg, mi látszik belőle kifelé. Most tíz másodperc alatt megtudod, és a jelentést továbbküldheted annak, aki az oldalt kezeli.

Rendszergazda, fejlesztő

Költözés, új szerver, új szolgáltatás után egy kattintás a külső kép: verziók, CVE-k, portok, fejlécek, SPF és DMARC, forrással és dátummal.

Aki gyanús linket kapott

Ne nyisd meg. Másold be ide: megnézzük a Google, az abuse.ch és az urlscan.io adatbázisában, anélkül hogy a link megnyílna.

Mit csinálunk és mit nem?

Csak nyilvános forrásokat kérdezünk, és a célból annyit nézünk meg, amennyit egy böngésző is látna: DNS, tanúsítvány, a kezdőlap és a fejlécei. Nem szkennelünk portot, nem próbálgatunk jelszót, nem küldünk támadó kérést, nem keresünk rejtett könyvtárakat, és a beírt URL-t nem nyitjuk meg.

Nem riogatunk. Nem találgatunk. Bizonyítékot mutatunk.

19 forrás, egyetlen jelentésben

  • DNS
  • DNSSEC
  • RIPEstat
  • Shodan InternetDB
  • TLS-tanúsítvány
  • HTTP-fejlécek
  • Certificate Transparency
  • Certificate Transparency (Cert Spotter)
  • URLhaus
  • Google Web Risk
  • urlscan.io
  • AbuseIPDB
  • WPVulnerability
  • Wordfence Intelligence
  • OSV.dev
  • Packagist Security Advisories
  • Drupal Security
  • NVD (NIST)
  • endoflife.date

Biztonsági elemző: gyakori kérdések

Tényleg ingyenes? Kell regisztrálni?

Igen, ingyenes, és nem kérünk se regisztrációt, se e-mail-címet. A forrásoknak napi kerete van, ezért egy helyről korlátozott számú vizsgálat indítható, és egy friss jelentést nem futtatunk le újra feleslegesen.

Mennyi ideig tart, és meddig érhető el a jelentés?

Általában tíz másodperc; ha egy forrás lassú, legfeljebb fél perc, és közben látod, melyik forrás hol tart. A jelentés 30 napig elérhető a saját linkjén, a keresők nem indexelik, és csak az látja, akinek elküldöd.

Miben más, mint egy sérülékenység-szkenner?

A szkenner aktívan próbálgatja a szervert, ehhez a tulajdonos engedélye kell. Mi csak azt gyűjtjük össze, ami már most nyilvános: amit a Shodan, a tanúsítvány-naplók, a feketelisták és a kezdőlap elárul. Ez az a kép, amit bárki, egy támadó is lát. Ezért nem helyettesíti a belső auditot, viszont bármikor, bármelyik domainre lefuttatható.

Észreveszi a tulajdonos, hogy ellenőriztem az oldalát?

Egyetlen kérést küldünk a kezdőlapra, ahogy egy böngésző is tenné, XMX néven azonosítva magunkat; ez a szerver naplójában látszik. Minden más adat nyilvános adatbázisokból jön, a célt nem érinti.

Mi az IP-reputáció?

Egy IP-cím "előélete": szerepelt-e spam-, támadás- vagy malware-listákon, és jelentettek-e róla visszaélést. A levelezők, tűzfalak és szűrők ebből döntik el, mennyire bíznak a címről érkező forgalomban. A rossz reputáció nem mindig a jelenlegi tulajdonos hibája: a címek gazdát cserélnek, és egy közös tárhely IP-jén sok ügyfél osztozik.

Honnan tudható, hogy egy IP gyanús?

Független adatbázisokból: közösségi bejelentésekből (AbuseIPDB), malware-listákból (URLhaus), és az internetet folyamatosan pásztázó szolgáltatások megfigyeléseiből (Shodan). Egyetlen forrás ritkán elég: mi megmutatjuk, melyik forrás mit mond, mikor látta, és mennyire biztos.

Mit jelentenek az abuse-bejelentések?

Más rendszergazdák jelentik, ha egy IP-ről támadást láttak (jelszópróbálgatás, portszkennelés, spam). A bizalmi pontszám azt mutatja, hány független bejelentő és milyen frissen jelezte. Egy régi, egyetlen bejelentés keveset mond; sok friss bejelentés komoly jel.

Mire jó a domainreputáció ellenőrzése?

Kiderül, szerepel-e a domain a böngészők veszélylistáján (Google Web Risk), tiltólistán vagy malware-adatbázisban. Ha igen, a látogatóid figyelmeztető oldalt kaphatnak, a leveleid pedig a spam mappába kerülhetnek.

Miért nem bizonyítja egy feketelistás találat, hogy egy weboldalt feltörtek?

Mert a lista gyakran az IP-címről szól, nem a weboldalról: egy CDN vagy közös tárhely címén több ezer oldal osztozik, és a cím korábbi gazdája is okozhatta. A jelentésben ezért mindig jelöljük, mihez kötődik a találat, és mennyire biztos.

Mit jelent egy ismert CVE?

A CVE egy nyilvánosan ismert szoftverhiba azonosítója. Ha egy szerveren a hibás verzió fut, a hiba kihasználható lehet. A külső megfigyelés csak a verziószámot látja, ezért ezt "lehetséges sérülékenységnek" nevezzük: a Linux-disztribúciók sokszor a verzió változtatása nélkül javítanak.

Hogyan ismeritek fel, milyen technológiával készült egy weboldal?

A kezdőlap egyetlen lekéréséből: a válasz fejléceiből, a sütik nevéből, a "generator" metából és a saját erőforrások útvonalaiból (pl. /wp-content/). Ez ugyanaz, amit egy böngésző is lát; nem keresünk rejtett könyvtárakat, nem futtatunk szkriptet. Ezt egészíti ki a Shodan passzív megfigyelése: a szerver IP-címén látott szoftverek és verziók (webszerver, OpenSSH, OpenSSL), amelyek a kezdőlapon nem látszanak. Az OpenSSH csomagverziójából az operációs rendszer kiadása is kiderül. A jelek hamisíthatók és az IP-adat megosztott tárhelyen másik oldalé lehet, ezért felismerésről beszélünk, nem igazolásról, és minden technológiához megadjuk, mennyire biztos.

Honnan tudjátok, milyen ismert hibák vonatkoznak a szerver szoftvereire?

A felismert pontos verziót az amerikai NVD adatbázisban kérdezzük le (ugyanazzal a módszerrel, amivel a Shodan is dolgozik), és csak azokat a CVE-ket mutatjuk, ahol a verzió a sérülékeny konfigurációk között szerepel. Melléírjuk a CVSS-pontszámot, és jelöljük, ha a CISA aktívan kihasználtnak tartja. Linux-disztribúció alatt a javítás gyakran a verziószám változtatása nélkül érkezik, ezért ott a lista "lehetséges", nem igazolt érintettség; ha a verzió bizonyíthatóan nem a disztribúció csomagja, ezt is kiírjuk.

Miért nem látjátok a Laravel vagy a bővítmények verzióját?

Mert nem publikus: a Laravel kívülről legfeljebb utaló jelekből ismerhető fel, a WordPress-bővítmények pedig többnyire a core verzióját írják a fájljaikra. Verzió nélkül csak azt mondjuk meg, milyen advisoryk ismertek a termékhez, és nem állítjuk, hogy a telepítés érintett.

Milyen gyakran érdemes ellenőrizni egy szervert?

Változás után mindig (új szerver, költözés, új szolgáltatás), egyébként havonta. A tanúsítvány lejárata és egy véletlenül megnyitott adatbázis-port a leggyakoribb hiba, és mindkettő gyorsan javítható.

Egy perc, és tudod, hol állsz.

Ingyen, regisztráció nélkül. A jelentés 30 napig elérhető a saját linkjén, a keresők nem indexelik, és csak az látja, akinek elküldöd.