Jeg ville bare vite hva som egentlig er FIN-angrepet. Jeg vet om FIN-flagget som brukes til å indikere at en forbindelse stenges via TCP. Men hva er egentlig FIN-angrep?
Kommentarer
- Har du forsket på egen hånd? Hvordan hørte du om » FIN-angrepet «?
- I utgangspunktet ble det gitt i en oppgave. Jeg har lest litt, men har bare kommet over FIN som et flagg i TCP-overskriften. Men ingenting om et FIN-angrep.
- Så kan du få litt mer informasjon fra instruktøren din om begrepet » FIN Attack «? Det er skanninger og flom, men jeg ‘ er ikke sikker på at jeg vil beskrive noen av dem som » angrep »
- Hvis du leser de to spørsmålene til dette svaret, vil du se at de antar at du mener en FIN-skanning. Skanning er ikke angrep. Mener du FIN-skanning, eller får du fremdeles ikke svarene du trenger …?
- Ja, jeg skjønte så mye. Fortsatt har ikke ‘ mye informasjon om det, men jeg regner med at det i utgangspunktet bruker FIN-pakkene til å finne et hull et sted siden det noen ganger kan være i stand til å omgå brannmurer. ul>
Svar
Det er et eldre angrep som opprinnelig var ment å være en «luskende, brannmuromgå» som var avhengig av noen få faktorer som er nå uvanlig i dag: gamle Unix-operativsystemer, mangel på stateful brannmurer, mangel på NIDS / NIPS, etc. Det kan fortsatt være nyttig når man tester (dvs. som fingeravtrykksteknikk ikke et angrep i seg selv) helt nye eller nye TCP / IP-stabler (eller bare nytt for deg eller ditt miljø), noe som er sjelden, men som kan skje.
Her er en moderne erstatning, TCP-protokollskanning:
nmap --reason -n -Pn --packet-trace -g 80 -sO -p 6 <target ip> Som er nesten nøyaktig det samme som TCP ACK-skanningen (som kan brukes til å kartlegge verter, åpne porter, brannmurregelsett osv. med advarselen som noen NIPS, IDS og moderne brannmurer vil oppdage – med en annen situasjonsspesifikk hendelse der kanskje jeg t vil ikke varsle hendelsessvarere eller sikkerhetsoperasjonssentre fordi de har viktigere ting å se på i disse dager):
nmap --reason -n -Pn --packet-trace -g 80 -sA -p 80 <target ip> Men utgangene er litt forskjellige, og du kan også se de andre forskjellene på pakkenivå.
Det du leter etter for å utvikle en mer avansert teknikk er å identifisere finesser i RST-pakkene og deres vindusstørrelser. Hvis du får vindusstørrelser som ikke er null, kan det være lurt å bytte til å bruke TCP Window-skanning i stedet for TCP ACK-skanning. For mer informasjon, se http://nmap.org/book/man-port-scanning-techniques.html
Noen andre teknikker finnes i NSE-guide , for eksempel brannkjøring og brannmur-bypass-skript. Imidlertid er det mange andre teknikker, inkludert BNAT, fragroute, osstmm-afd, 0trace, lft og potensielt andre som oppdager andre innebygde, ikke-brannmur enheter som WAFs, IDS, IPS, reverse proxies, gateways og bedragssystemer som honningkrukker eller aktivt forsvar. Du vil være oppmerksom på alt dette og mer hvis du utfører en nettverkspenetrasjonstest, men de er nyttige for feilsøking av alle slags nettverks- og sikkerhetsproblemer.
Kommentarer
- Jeg setter pris på svaret ditt, men jeg får fortsatt ikke ‘ det FIN-angrep er. Å, elsker Nmaps skjønt: D
- Jeg tror kortversjonen er, du sender en FIN som ikke ‘ ikke tilhører en økt og lærer av svaret du få. Resten av @atdre ‘ s svar er godt nok. Jeg ‘ vil bare se ham legge til denne detalj.
- Ja, høres omtrent riktig ut. Bare prøver å finne ut hvordan du kan bruke FIN-skanningen på en angrepsmåte.
Svar
FIN Attack (jeg antar at du mener FIN Scan) er en type TCP-portskanning.
I følge RFC 793: «Trafikk til en lukket port skal alltid returnere RST». RFC 793 sier også om en port er åpen og segmentet ikke har flagg SYN, RST eller ACK. Pakken skal slippes. Det kan være et gammelt datagram fra en allerede lukket økt.
Så hva FIN Attack gjør er å misbruke dette. Hvis vi sender en FIN-pakke til en lukket port, får vi en RST tilbake. Hvis vi ikke får noe svar, vet vi at enten slippes av brannmuren eller at porten er åpen. FIN Attack er også mer usynlig enn SYN Scan (sender SYN for å se responsen).
Imidlertid returnerer mange systemer alltid RST. Og da er det ikke mulig å vite om porten er åpen eller lukket, for eksempel gjør Windows dette, men ikke UNIX.
Kommentarer
- Hmmmmm, så det blir i utgangspunktet sendt for å få et svar så » angriper » og vet hva du skal gjøre?
- Ja, du undersøker målmaskinen for åpne porter. Dette kan utføres av en administrator eller en angriper for å finne sårbarheter.
- Å, ja .. Jeg tenkte det samme. Men trengte noen bekreftelse.
Svar
FIN-skanninger, som NULL, XMAS eller custom-flags skanninger – were and– brukes til å omgå brannmur og noen ganger unngå IDS, jeg siterer:
FIN Scan: Den viktigste fordelen til disse skanningstypene er at de kan snike seg gjennom visse ikke-stateful brannmurer og rutere for pakkefiltrering. Slike brannmurer prøver å forhindre innkommende TCP-tilkoblinger (samtidig som de tillater utgående) Å demonstrere den fulle, brannmuromkoblingsstyrken til disse skanningene krever en ganske halt målbrannmurkonfigurasjon. Med en moderne stateful brannmur, bør ikke FIN-skanning produsere ekstra informasjon.
SYN / FIN En interessant tilpasset skanningstype er SYN / FIN. Noen ganger vil en brannmuradministrator eller enhetsprodusent forsøke å blokkere innkommende tilkoblinger med en regel som «slipp innkommende pakker med bare SYN Hag-settet». De begrenser det til bare SYN-flagget fordi de ikke vil blokkere SYN / ACK-pakkene som returneres som det andre trinnet i en utgående forbindelse. Problemet med denne tilnærmingen er at de fleste sluttsystemer aksepterer innledende SYN-pakker som inneholder andre (ikke-ACK) flagg også. For eksempel sender Nmap OS fingeravtrykkingssystem en SYN / FIN / URG / PSH-pakke til en åpen port. Mer enn halvparten av fingeravtrykkene i databasen svarer med en SYN / ACK. Dermed de tillater portskanning med denne pakken og tillater generelt også å lage en full TCP-forbindelse. Noen systemer har til og med vært kjent for å svare med SYN / ACK til en SYN / RST-pakke! TCP RFC er tvetydig med hvilke flagg som er akseptable i en innledende SYN-pakke, selv om SYN / RST absolutt virker falsk. Eksempel 5.13 viser at Ereet gjennomfører en vellykket SYNIFIN-skanning av Google. Han kjeder seg tilsynelatende med scanme.nmap.org.
NMAP Network Discovery av Gordon «Fyodor» Lyon