Csak azt akartam tudni, hogy mi is pontosan a FIN támadása. Tudok a FIN zászlóról, amelyet a TCP-n keresztüli kapcsolat lezárásának jelzésére használnak. De mi is az a FIN támadás?
Megjegyzések
- Végeztél már saját kutatást? Hogyan hallott a ” FIN támadásról “?
- Alapvetően egy feladatban adták meg. Néha olvasgattak, de csak FIN-vel találkoztak a TCP fejlécében. De semmi a FIN támadásról.
- Akkor kaphatna további részleteket az oktatójától a ” FIN Attack “? Vannak átvizsgálások és árvizek, de én ‘ nem vagyok biztos abban, hogy egyiküket sem leírnám ” támadásokként ”
- Ha elolvassa a válasz 2 kérdését, látni fogja, hogy azok feltételezik, hogy FIN vizsgálatra gondolsz. A vizsgálatok nem támadások. FIN szkennelésre gondol, vagy még mindig nem kapja meg a szükséges válaszokat …?
- Igen, ennyit gondoltam. Még mindig nem találok ‘ sok információt róla, de úgy gondolom, hogy alapvetően a FIN csomagok segítségével találunk lyukat valahol, mivel néha képesek megkerülni a tűzfalakat.
Válasz
Ez egy régebbi támadás, amelyet eredetileg egy “alattomos, tűzfal-bypass” -nak szántak, és amely néhány tényezőtől függ. ma már nem jellemzőek: a régi Unix operációs rendszerek, az állapotfájlok hiánya, a NIDS / NIPS hiánya stb. Ez még mindig hasznos lehet, amikor tesztelnek (azaz ujjlenyomat-technikaként nem támadás önmagában) teljesen új vagy újszerű TCP / IP csomagok (vagy csak új az Ön vagy a környezete számára), ami ritka, de előfordulhat.
Itt van egy modern helyettesítés, a TCP protokoll vizsgálata:
nmap --reason -n -Pn --packet-trace -g 80 -sO -p 6 <target ip> Ami majdnem pontosan megegyezik a TCP ACK vizsgálatával (amely gazdagépek, nyitott portok, tűzfalszabályok stb. feltérképezésére használható azzal a figyelmeztetéssel, amelyet egyes NIPS, IDS és modern tűzfalak észlelnek – egy másiksal helyzet-specifikus esemény, ahol talán i t nem értesítjük az eseményeket elhárítókat vagy a biztonsági műveleti központokat, mert manapság fontosabb dolgokat kell megvizsgálniuk:
nmap --reason -n -Pn --packet-trace -g 80 -sA -p 80 <target ip> De a kimenetek kissé eltérnek, és Ön láthatja a többi csomagszintbeli különbséget is.
Amit egy fejlettebb technika kifejlesztése érdekében keres, az az, hogy azonosítja az RST csomagokban rejlő finomságokat és azok ablakméretét. Ha nem nulla ablakméreteket kap, akkor érdemes áttérnie a TCP Window scan használatára a TCP ACK vizsgálat helyett. További információ: http://nmap.org/book/man-port-scanning-techniques.html
Néhány egyéb technika található a NSE útmutató , például a tűzfal és a tűzfal megkerülésének parancsfájljai. Számos más technika létezik, beleértve a BNAT-t, a fragroute-t, az osstmm-afd, a 0trace-t, az lft-t és potenciálisan másokat is, amelyek más inline, nem tűzfal eszközöket észlelnek, mint például WAF-k, IDS, IPS, fordított proxyk, átjárók és megtévesztő rendszerek, mint pl. mézes edények vagy aktív védekezés. Tudnia kell minderről és még sok másról, ha hálózati penetrációs tesztet hajt végre, de ezek hasznosak mindenféle hálózati és biztonsági probléma elhárításához.
Megjegyzések
- Nagyra értékelem a válaszodat, de még mindig nem értem ‘, hogy mégis mi a FIN támadás. Ó, szeresd az Nmaps-ot: D
- Szerintem a rövid verzió az, hogy küldesz egy FIN-t, amely nem ‘ nem tartozik egy munkamenethez, és tanulj az általad kapott válaszból. kap. A @atdre ‘ válaszok többi része elég jó, én ‘ szeretném, ha csak látnám, ahogy ezt a részletet hozzáadta.
- Igen, csaknem jól hangzik .. Csak megpróbálom kitalálni, hogyan kell a FIN vizsgálatot támadás módjára használni.
Válasz
A FIN Attack (feltételezem, hogy a FIN Scanre gondol) a TCP portok vizsgálatának egy típusa.
Az RFC 793 szerint: “A zárt port felé irányuló forgalomnak mindig vissza kell térnie az RST-re”. Az RFC 793 azt is jelzi, ha egy port nyitva van, és a szegmensben nincs beállítva a SYN, RST vagy ACK jelző. A csomagot el kell dobni. Lehet, hogy egy régi datagram egy már lezárt munkamenetből.
Tehát a FIN Attack ezzel visszaél. Ha FIN csomagot küldünk egy zárt portra, akkor egy RST-t kapunk. Ha nem kapunk választ, tudjuk, hogy vagy a tűzfal dobja el, vagy a port nyitva van. Ezenkívül a FIN Attack láthatatlanabb, mint a SYN Scan (a SYN küldése a válaszok megtekintéséhez).
Sok rendszer azonban mindig RST-t ad vissza. És akkor nem lehet tudni, hogy a port nyitva vagy zárva van-e, például a Windows csinálja, de nem a UNIX.
Megjegyzések
- Hmmmmm, ezért alapvetően válasz küldése, így a ” támadó ” és tudja, mit kell tennie?
- Igen, megvizsgálja a célgép nyitott portjait. Ezt adminisztrátor vagy támadó hajthatja végre a sebezhetőségek felkutatása érdekében.
- Ó, igen .. Ugyanerre gondoltam. De némi megerősítésre szorult.
Válasz
FIN ellenőrzések, NULL, XMAS vagy custom-flags ellenőrzések
FIN Scan: A legfontosabb előny ezekhez a szkennelési típusokhoz az az, hogy be tudnak lopakodni bizonyos, állapot nélküli tűzfalakon és csomagszűrő routereken. Az ilyen tűzfalak megpróbálják megakadályozni a bejövő TCP-kapcsolatokat (miközben lehetővé teszik a kimenő kapcsolatokat is). Ezen ellenőrzések teljes, tűzfal-megkerülő erejének bemutatásához meglehetősen béna tűzfal-konfigurációra van szükség. A modern állapotú tűzfalon a FIN vizsgálata nem hozhat létre további információkat.
SYN / FIN Az egyik érdekes egyéni vizsgálat típusa a SYN / FIN. Előfordul, hogy a tűzfal rendszergazdája vagy az eszköz gyártója megpróbálja blokkolni a bejövő kapcsolatokat egy olyan szabállyal, mint például “a bejövő csomagok eldobása csak a SYN Hag készlettel”. Csak a SYN zászlóra korlátozzák, mert nem akarják blokkolni a kimenő kapcsolat második lépéseként visszaküldött SYN / ACK csomagokat. Ezzel a megközelítéssel az a probléma, hogy a legtöbb végrendszer elfogadja azokat a kezdeti SYN csomagokat, amelyek tartalmazzák egyéb (nem ACK) jelzők is. Például az Nmap OS ujjlenyomat-rendszere egy SYN / FIN / URG / PSH csomagot küld egy nyitott portra. Az adatbázis ujjlenyomatainak több mint a fele SYN / ACK-val válaszol. lehetővé teszik a port szkennelését ezzel a csomaggal, és általában lehetővé teszik a teljes TCP kapcsolat létrehozását is. Egyes rendszerekről még az is ismert, hogy SYN / ACK-val reagálnak egy SYN / RST csomagra! SYN csomag, bár a SYN / RST minden bizonnyal hamisnak tűnik. Az 5.13. Példa azt mutatja, hogy Ereet sikeres SYNIFIN keresést végez a Google-on. Nyilvánvalóan unja a scanme.nmap.org fájlt. >
NMAP Network Discovery, Gordon “Fyodor” Lyon