Ugrás a tartalomra
web-coder weboldal logo Kapcsolat
POST_1489

Mi veszélyezteti a weboldaladat? Vírusok, malware-ek, botok és webes támadások

Weboldal biztonsági probléma sokféleképpen jelentkezhet. Idegen hirdetések jelennek meg, a látogatókat másik oldalra irányítják, ismeretlen tartalmak kerülnek a keresőbe, vagy a honlap egyszerűen elérhetetlenné válik. Más esetekben a probléma a háttérben zajlik: a támadó hozzáférést tart fenn, adatokat gyűjt, vagy automatizált eszközökkel próbál visszaélni az oldal funkcióival.

Ezeket a helyzeteket könnyű egyetlen szóval elintézni: „vírusos lett a weboldal”. A pontosabb fogalmak azonban segítenek megérteni, mi történt, mit kell megvizsgálni, és miért nem ugyanaz a megoldás minden biztonsági problémára.

Ebben a cikksorozatban a weboldalakat veszélyeztető kártékony kódokat, automatizált visszaéléseket és támadási módszereket vesszük sorra. Az első rész a fogalmakat és a csoportosítás szempontjait rendezi rendszerbe. A folytatások az egyes témákat bontják ki részletesen.

1. Vírus, malware vagy támadás: miről beszélünk?

A malware, magyarul kártékony szoftver, gyűjtőfogalom. Olyan programokra és kódokra használjuk, amelyek rosszindulatú célokat szolgálnak: például adatokat szereznek meg, módosítják egy rendszer működését vagy jogosulatlan hozzáférést tesznek lehetővé. A vírus a malware egyik típusa; a két szó nem ugyanazt jelenti. [1]

A weboldal biztonságát ugyanakkor olyan támadások is veszélyeztethetik, amelyekhez nem kell kártékony programot telepíteni a tárhelyre. Egy automatizált belépési próbálkozás, az űrlapok tömeges elárasztása vagy egy túlterheléses támadás önmagában még nem jelenti azt, hogy az oldal fájljai megfertőződtek. [5][10]

Ezért az elemzéshez négy külön kérdést érdemes feltenni:

  • Milyen gyengeséget használhat ki a támadó? Ez a sérülékenység vagy más kihasználható hiányosság.
  • Mit tesz a támadó? Ez a támadás módszere.
  • Milyen eszközt vagy kódot használ? Ez lehet például bot vagy webshell.
  • Mit ér el vele? Ez a következmény: például adatlopás, tartalommódosítás vagy kiesés.

Technikai magyarázat: A sérülékenység megléte, a támadási kísérlet és a sikeres kompromittálás külön állapotok. Egy SQL-injectiont próbáló kérés a naplóban a próbálkozást mutatja. A sikeres adatkiolvasás vagy módosítás megállapításához további bizonyíték kell. A naplózás az ilyen események vizsgálatának fontos alapja. [16]

2. A legfontosabb fogalmak röviden

Vírus és féreg: hogyan terjed a kód?

A klasszikus vírus más programhoz vagy fájlhoz kapcsolódva képes saját kódját továbbterjeszteni. A féreg önálló, önmagát másoló program, amely hálózaton keresztül is terjedhet. Ezek a megnevezések elsősorban a terjedés jellemzőit írják le. [1][2]

Ha egy weboldalban idegen kódot találunk, abból még nem következik, hogy klasszikus vírusról van szó. A kód célját és működését is meg kell vizsgálni. Egy átirányító JavaScript-részlet vagy egy távoli hozzáférést adó PHP-fájl pontosabb megnevezést igényel.

Trójai: hasznosnak látszó program, rejtett működéssel

A trójai olyan program, amely ártalmatlannak vagy hasznosnak mutatkozik, közben azonban rejtett, rosszindulatú feladatot is ellát. A fogalom a megtévesztő jellegre utal; nem feltételez önálló terjedést. [3]

Szemléltető, kitalált példa: egy ingyenesen megszerezhetőnek hirdetett prémium sablon valóban megjeleníti a weboldalt, de a módosított csomag egy jogosulatlan hozzáférést létrehozó összetevőt is tartalmaz. Ebben a példában a látható funkció és a rejtett funkció egyszerre működik.

Hátsó kapu és webshell: hogyan marad meg a hozzáférés?

A hátsó kapu, angolul backdoor, a rendes hozzáférési szabályokat megkerülő bejutási lehetőség. A webshell a webkiszolgálón elhelyezett olyan kód, amely webes kéréseken keresztül adhat hozzáférést és műveletvégzési lehetőséget a támadónak. A webshell a tartós hozzáférés egyik eszköze lehet. [4]

A két kifejezés nem teljesen azonos. Egy hátsó kapu működhet más módon is, a webshell pedig konkrét webes megvalósítást jelöl. A hozzáférés mértékét a kód és az azt futtató környezet jogosultságai is meghatározzák.

Bot és botnet: ki végzi az automatizált műveleteket?

A bot automatizált feladatokat végző szoftver. Az automatizálás önmagában nem rosszindulatú: keresőrobotok és rendelkezésreállást ellenőrző eszközök is működhetnek rendeltetésszerűen. A visszaélés célja és módja alapján beszélünk rosszindulatú bottevékenységről. [5]

A botok például belépési adatokat próbálhatnak ki, űrlapokat tölthetnek ki tömegesen, vagy az alkalmazás erőforrásait terhelhetik. A botnet több, közösen vezérelt eszközből álló hálózat; szerepet kaphat elosztott támadásokban. A bot és a botnet tehát nem felcserélhető fogalom. [5][10]

3. Csoportosítás a támadó célja szerint

A tulajdonos számára az egyik legfontosabb kérdés: mire akarják felhasználni a weboldalát? Az alábbi csoportok a célokat rendezik áttekinthető formába. Egy incidens egyszerre több csoportba is tartozhat.

Keresőtalálatok manipulálása és SEO-spam

SEO-spamnél a támadó idegen tartalmakat, hivatkozásokat vagy oldalakat helyezhet el a honlapon, hogy azok a keresőben megjelenjenek. A Google a feltört tartalmak között külön említi a kód- és tartalombefecskendezést, új oldalak létrehozását, valamint az átirányításokat. [6]

A feltört honlap így más termékeket vagy szolgáltatásokat népszerűsíthet a tulajdonos engedélye nélkül. A keresőben megjelenő idegen cím vagy leírás vizsgálatot indokol, de a pontos ok megállapításához az oldal és az indexelt tartalom ellenőrzése is szükséges.

Látogatók átirányítása és megtévesztése

A támadó másik weboldalra terelheti a látogatókat. A Google dokumentációja olyan feltételes átirányítást is bemutat, amely keresőből érkezve működik, közvetlen megnyitáskor viszont nem. Ez megnehezítheti a probléma észlelését. [6]

Az átirányítás a működés módja; a célja lehet például idegen tartalom látogatottságának növelése vagy a látogató megtévesztése. A vizsgálat során az eredeti oldalt és az átirányítás célpontját is el kell különíteni.

Adatok megszerzése

A kártékony kód bizalmas információk megszerzését is szolgálhatja. Webes környezetben külön figyelmet igényel, hogy az oldalba beillesztett JavaScript milyen adatokhoz fér hozzá. Egy külső szkript kompromittálódása a böngészőben megjelenő információkat is veszélyeztetheti. [1][13]

Az adatlopás és az adathalászat tárgyalásakor különválasztjuk a háttérben végzett adatgyűjtést és azt a megtévesztést, amelynél a felhasználót kérik adatok megadására. Ezek részletes elemzése a sorozat külön részeinek feladata lesz.

Automatizált visszaélés a weboldal funkcióival

Az OWASP külön automatizált fenyegetésként tárgyalja a spam elhelyezését, a tömeges fióklétrehozást, a tartalomgyűjtést, a mérőszámok manipulálását és a készletek mesterséges lefoglalását is. Ezeknél az oldal meglévő funkciói válhatnak a visszaélés eszközévé. [5]

Itt a helyreállítás feladata eltérhet a kártékony fájlok eltávolításától. A visszaéléshez használt funkció működését, korlátozásait és megfigyelhetőségét kell értékelni.

Működés megzavarása

A szolgáltatásmegtagadásos támadás, vagyis DoS célja a szolgáltatás elérhetőségének rontása. A DDoS ennek elosztott formája. A támadás a hálózatot és az alkalmazás működését is érintheti: egy költséges művelet ismételt elindítása is erőforrás-kimerüléshez vezethet. [10]

A kiesés azonban önmagában nem bizonyít támadást. Az elérhetőségi problémák vizsgálatában a terhelési adatok, a naplók és a kiszolgáló állapota együtt adnak használható képet.

Erőforrások jogosulatlan felhasználása

A megszerzett környezet számítási kapacitása önmagában is értéket jelenthet a támadónak. A MITRE a számítási erőforrások eltérítésén belül tárgyalja a kriptovaluta-bányászatot. Ennek célpontjai kiszolgálók és felhős rendszerek is lehetnek. A jogosulatlan folyamatok a rendelkezésre álló kapacitást fogyaszthatják. [19]

A cryptojacking kifejezéssel a jogosulatlan kriptovaluta-bányászatra utalunk. Itt a cél a számítási teljesítmény felhasználása. A magas processzorterhelés önmagában még nem azonosít bányászprogramot: az értékeléshez a futó folyamatok és a kapcsolatok megfigyelése is szükséges. [19]

A weboldal elcsúfítása és üzenetek elhelyezése

A defacement a megjelenő tartalom jogosulatlan megváltoztatását jelöli. A támadó módosíthatja az oldal szövegét, képeit vagy más látható elemeit. A beavatkozás üzenetközvetítésre és megfélemlítésre is szolgálhat. [20]

Ez különbözik attól a céltól, amikor a támadó észrevétlenül akar adatot gyűjteni. A feltűnő változás azonban a beavatkozás látható része: a vizsgálat kérdése marad, milyen hozzáféréssel történt a módosítás, és milyen további műveleteket lehetett ezzel a hozzáféréssel elvégezni.

Zsarolás és az adatok hozzáférhetetlenné tétele

A ransomware, magyarul zsarolóprogram, az adatok titkosításával akadályozhatja meg a rendes hozzáférést. A zsarolás adatok eltulajdonításával és nyilvánosságra hozataluk fenyegetésével is összekapcsolódhat. A CISA ezért együtt tárgyalja a zsarolóprogramok és az adatlopásra épülő zsarolás kockázatait. [21]

Weboldal esetén az érintett adatokat és a mögöttes környezetet is azonosítani kell. A titkosítás, a törlés és az elérhetetlenség külön állapot: egy működésképtelen oldal alapján nem lehet automatikusan zsarolóprogramra következtetni.

4. Csoportosítás a bejutás módja szerint

A káros következmény nem árulja el automatikusan, hogyan kezdődött az incidens. Ugyanaz a jogosulatlan tartalom többféle hozzáférésből is létrejöhet. Ezért a bejutás útját külön kell vizsgálni.

Sérülékenységek kihasználása

A sérülékenységet kihasználó eljárást vagy kódot exploitnak nevezzük. A webes alkalmazások biztonsági hibáinak rendszerezéséhez az OWASP anyagai adnak szakmai kiindulópontot. [7]

Technikai magyarázat – SQL-injection: A hiba akkor keletkezhet, ha az alkalmazás a kívülről kapott adatot veszélyes módon építi SQL-parancsba. A támadó így az adatbázis-művelet értelmét módosíthatja. A paraméterezett lekérdezés az adat és az SQL-kód elválasztásának alapvető eszköze. A hozzáférhető adatok és műveletek körét az adatbázis-jogosultságok is befolyásolják. [8]

Technikai magyarázat – XSS: A cross-site scripting olyan hiba, amelynél nem megbízható tartalom a böngésző által végrehajtható kódként jelenhet meg. Az XSS-nek több formája van; a kód nem feltétlenül kerül tartósan a szerverre. A megfelelő védelem függ attól is, hogy az adat HTML-ben, JavaScriptben vagy más környezetben jelenik meg. [9]

Veszélyes fájlfeltöltés

Egy feltöltési funkciónál a fájl neve, típusa, tartalma, mérete és tárolási helye egyaránt számít. Az OWASP ezért több, egymást kiegészítő ellenőrzést javasol. A fájlkiterjesztés vagy a böngésző által megadott tartalomtípus önmagában nem elégséges ellenőrzés. [11]

Szemléltető, kitalált példa: egy képfeltöltő olyan fájlt fogad el és olyan helyre ment, ahol azt a szerver programként futtatja. Ebben az esetben a feltöltési hiba a kódfuttatás belépési pontja lehet.

Megszerzett belépési adatok

A támadónak nincs mindig szüksége programhibára. A credential stuffing során korábbi adatszivárgásokból megszerzett felhasználónév–jelszó párokat próbálnak ki más szolgáltatásokon. A password spraying kevés, gyakori jelszó sok fiókon történő kipróbálását jelenti. Ezeket érdemes elkülöníteni az egyetlen fiókra összpontosító jelszópróbálgatástól. [12]

A sikeres belépés után végrehajtható műveleteket a fiók jogosultságai határozzák meg. A bejelentkezés és a jogosultság-ellenőrzés külön biztonsági feladat: az alkalmazásnak minden érzékeny műveletnél ellenőriznie kell, hogy a felhasználó elvégezheti-e azt. [14]

Bővítmények, függőségek és külső szolgáltatások

A weboldal több szereplő által készített összetevőkre támaszkodhat. A szoftverellátási lánc biztonsága ezért a fejlesztési és terjesztési folyamatokat, az összetevők eredetét, valamint a függőségeket is érinti. [15]

Külön eset, amikor az oldal közvetlenül külső kiszolgálóról tölt be JavaScriptet. A külső szolgáltatónál végzett módosítás ilyenkor a látogatók böngészőjében futó kódot is megváltoztathatja. Ennek vizsgálata túlmutat a saját tárhelyen tárolt fájlokon. [13]

5. Csoportosítás az érintett környezet szerint

A „hol van a fertőzés?” kérdésre pontosabb választ ad, ha különválasztjuk a tárolás helyét, a végrehajtás helyét és az elért erőforrást. Egy adatbázisban tárolt szkriptrészlet például a látogató böngészőjében futhat le.

Vizsgált területMit vizsgálunk rajta?
WeboldalfájlokJogosulatlan módosításokat, új programfájlokat, megváltozott összetevőket
AdatbázisTartalmakat, beállításokat és hozzáféréseket
BöngészőA ténylegesen betöltött és végrehajtott kódot
Külső integrációkA más szolgáltatóktól érkező kódot és adatkapcsolatokat
Tárhely és kiszolgálóA weboldal mögötti futtatási környezetet és jogosultságokat
Üzemeltetői hozzáférésekA webhely kezelésére használt fiókokat és eszközöket

A táblázat vizsgálati nézőpontokat ad, nem önálló fertőzéstípusokat. A WordPress hivatalos biztonsági útmutatója is több réteget kezel: az üzemeltető számítógépét, a webkiszolgálót, a hálózatot, a fájljogosultságokat és az adatbázist. [17]

Technikai magyarázat: A weboldal felületének módosítása nem azonos a teljes kiszolgáló feletti irányítás megszerzésével. A megállapított hozzáférés hatókörét külön kell dokumentálni. Egy webshell esetén is számít, milyen felhasználó nevében és milyen jogosultságokkal fut a webes folyamat. [4]

6. Csoportosítás a működés és a rejtőzködés szerint

Egy kártékony összetevőt a feladata alapján is megnevezhetünk: hozzáférést tart fenn, adatot gyűjt, módosítja a megjelenő tartalmat vagy további kód működését készíti elő. Ez más szempont, mint az, hogy milyen úton került az oldalra. [1][4]

A webshell például lehet a későbbi műveletek kiindulópontja. Eltávolítása a hozzáférés egy ismert eszközét szünteti meg; abból azonban külön vizsgálat nélkül nem következik, hogy más hozzáférés vagy más módosítás nem maradt. A MITRE leírása ezért a webshellt a hozzáférés fenntartásához kapcsolódó technikák között is tárgyalja. [4]

A rejtőzködés tárgyalásakor külön szót érdemel a cloaking, vagyis az eltérő tartalom kiszolgálása. A Google szerint a feltört oldalak támadói is alkalmazhatnak ilyet, hogy a beavatkozás nehezebben legyen észrevehető. [6]

Egy vizsgálati eredményt ezért a megfigyelés körülményeivel együtt érdemes értelmezni: melyik URL-t, mikor, milyen belépési állapotban és milyen útvonalon megnyitva ellenőrizték? A naplózás az időpontok és események összekapcsolásában is segítséget ad. [16]

Tartósan tárolt és csak az adott kérésnél megjelenő kód

További hasznos különbség, hogy a káros tartalom megmarad-e az alkalmazásban. A tárolt XSS-nél a veszélyes adat például egy hozzászólásban vagy más tárolt tartalomban kerülhet vissza a felhasználókhoz. A visszatükrözött XSS-nél egy kérésben kapott adat kerül veszélyes módon a válaszba. [9]

Ez a különbség a vizsgálat helyét is befolyásolja. Ha a jelenség egy adott hivatkozás megnyitásához kötődik, érdemes azt a teljes címet és körülményt rögzíteni. Ha tárolt tartalomhoz kapcsolódik, a tartalom eredetét és módosításának lehetőségét kell feltárni.

Automatizált és ember által irányított műveletek

Az automatizálás külön csoportosítási tengely: azt írja le, hogyan hajtják végre a műveleteket. Az OWASP automatizált fenyegetései között felderítés, belépési adatok ellenőrzése és alkalmazásfunkciókkal való visszaélés egyaránt szerepel. [5]

A naplókban megjelenő hasonló kéréssorozat tehát más kérdésre ad választ, mint egy felfedezett kártékony fájl. Az előbbi az interakciókról, az utóbbi egy megtalált összetevőről mond valamit. A kettőt az időpontok és a megfigyelt változások alapján lehet összekapcsolni.

7. Hogyan kapcsolódnak össze a kategóriák?

Az alábbi kitalált, szemléltető eset több fogalmat köt össze; nem egy konkrét incidens leírása.

Egy automatizált eszköz weboldalakat vizsgál, és talál egy hibás fájlfeltöltési funkciót. A támadó ezen keresztül futtatható állományt helyez el. Az állomány webshellként hozzáférést ad további műveletekhez. A támadó ezután idegen aloldalakat készít, amelyeket a keresőben szeretne megjeleníteni.

SzempontA példában szereplő elem
Automatizált eszközA weboldalakat vizsgáló bot
Bejutási módA fájlfeltöltési hiba kihasználása
Hozzáférési eszközA feltöltött webshell
Támadói célSEO-spam elhelyezése
Érintett területA feltöltés helye, majd az idegen tartalom tárolása

Ebből a példából látszik, miért érdemes több kérdést feltenni ahelyett, hogy egyetlen nevet keresnénk az egész eseményre. A bot, a feltöltési hiba, a webshell és a SEO-spam ugyanannak a történetnek különböző részeit írja le.

8. Mire figyelj WordPress és Joomla esetén?

WordPress-kitekintés

A WordPressnél az alaprendszer mellett a bővítmények, sablonok, hozzáférések és a futtatási környezet biztonsága is számít. A hivatalos útmutató külön tárgyalja a megbízható beszerzési forrásokat, a jelszavakat, a jogosultságokat, a mentéseket és a megfigyelést. [17]

Az oldal biztonságáról ezért a telepített összetevők és a hozzáférések ismeretében lehet érdemben beszélni. Egy vizsgálatnál érdemes rögzíteni, mely összetevők és fiókok tartoznak az elvárt állapothoz. Ez ad összehasonlítási alapot a későbbi változások értékeléséhez.

Joomla-kitekintés

A Joomla biztonsági dokumentációja a fejlesztők számára többek között az adatbázis-kezelés, az XSS, a CSRF és a fájlfeltöltés kérdéseihez ad útmutatást. Ezek az alkalmazás működésének különböző pontjain jelentkező kockázatok. [18]

A sorozat Joomla-blokkjaiban az adott fenyegetéshez kapcsolódó komponenseket, modulokat, plugineket, sablonokat és jogosultsági helyzeteket külön tárgyaljuk. A konkrét ellenőrzési lépésekhez mindig szükség lesz az érintett verzió és összetevő azonosítására.

Mindkét rendszernél ugyanazokat az alapvető kérdéseket tesszük fel: mi a belépési pont, milyen művelet történt, mi változott, és milyen hozzáférés maradhatott? Az adott CMS ezután segít meghatározni a vizsgálat konkrét helyeit.

9. Mit bizonyítanak a tünetek és a naplóbejegyzések?

Az idegen tartalom vagy egy ismeretlen fájl fontos nyom lehet. Egy sikertelen belépési kísérlet viszont nem ugyanazt bizonyítja, mint egy jogosulatlanul létrehozott adminisztrátori fiók. A vizsgálatban meg kell különböztetni a kísérletet, az észlelt változást és a már igazolt következményt. [16]

Az OWASP naplózási útmutatója többek között a hitelesítési és jogosultsági események, az alkalmazáshibák, valamint a gyanús műveletek rögzítését is tárgyalja. Az ilyen adatok segíthetnek az eseménysor felépítésében. A naplók hozzáférését és megőrzését ugyanakkor védeni kell, mert érzékeny adatokat is tartalmazhatnak. [16]

Tulajdonosként hasznos kiindulópont a tapasztalt jelenség pontos feljegyzése: melyik címen, mikor és milyen művelet után jelent meg? Ha más és más körülmények között eltérő eredményt tapasztalsz, ezt is érdemes dokumentálni. A megfigyelés pontos leírása többet segít a kivizsgálásban, mint egy előre kiválasztott fertőzésnév.

Mitől térhet vissza egy látszólag megszüntetett probléma?

Szemléltető, kitalált helyzet: a tulajdonos törli az idegen aloldalt, de az azt létrehozó hozzáférés megmarad. A támadó később újra elvégzi ugyanazt a műveletet. Egy másik lehetséges példában a módosítás egy megmaradt webshellen keresztül történik. A két eset hasonló eredményt adhat, de eltérő nyomokat kell hozzá keresni.

Ezért hasznos az ismert változások mellett az azokhoz szükséges jogosultságokat is vizsgálni. Egy fiók letiltása, egy fájl eltávolítása és egy sérülékenység javítása más-más részét kezeli az eseménysornak. Az összefüggések tisztázása után határozható meg, melyik intézkedés mire adott választ.

Mi tartozik a megelőzéshez és mi a kivizsgáláshoz?

A megelőző intézkedések a támadási lehetőségeket és a várható hatásokat csökkentik. A kivizsgálás azt próbálja megállapítani, mi történt ténylegesen. Egy beállítás utólagos szigorítása ezért nem helyettesíti a korábbi események feltárását.

A WordPress útmutatója a biztonságot kockázatcsökkentésként írja le, és a hozzáférések korlátozása mellett a lehetséges károk behatárolását, valamint a felkészülést is kiemeli. A mentések, naplók és ismert kiinduló állapot ennek a felkészülésnek is részei. [17]

10. Hogyan folytatódik a sorozat?

A következő részekben az egyes fenyegetéseket külön vesszük végig. Bemutatjuk a működésüket, az észlelhető jeleket, a vizsgálat alapjait és a kockázatcsökkentés lehetőségeit. Külön cikket kapnak a hátsó kapuk és webshell-ek, a rosszindulatú botok, a SEO-spam, az átirányítások és az egyes sérülékenységi típusok.

A sorozat alapja végig ugyanaz marad: megkülönböztetjük a támadó eszközét, a bejutás módját, a működés helyét és az elérni kívánt célt. Ez segít abban, hogy egy biztonsági probléma leírása a kivizsgáláshoz is használható legyen.

Források

Az alábbi hivatkozások az adott számmal jelölt magyarázatok szakmai alapjai. A szemléltető példák kitaláltak. A csoportosítások szerkesztett áttekintést adnak; nem egyetlen hivatalos osztályozási rendszer átvételei.

  1. NIST: Malware, Virus.
  2. NIST: Worm.
  3. NIST: Trojan horse.
  4. MITRE ATT&CK: Web Shell – T1505.003.
  5. OWASP: Automated Threats to Web Applications.
  6. Google Search Central: Spam policies – hacked content and cloaking.
  7. OWASP: Top 10.
  8. OWASP: SQL Injection Prevention.
  9. OWASP: Cross Site Scripting Prevention.
  10. OWASP: Denial of Service.
  11. OWASP: File Upload.
  12. OWASP: Credential Stuffing Prevention.
  13. OWASP: Third Party JavaScript Management.
  14. OWASP: Authorization.
  15. OWASP: Software Supply Chain Security.
  16. OWASP: Logging.
  17. WordPress: Hardening WordPress.
  18. Joomla: Security.
  19. MITRE ATT&CK: Compute Hijacking – T1496.001.
  20. MITRE ATT&CK: Defacement – T1491.
  21. CISA: StopRansomware Guide.

Ha gyanús, hogy weboldalad vírusos vagy feltört, segítünk a helyreállításban