Jeg ville bare vide, hvad der præcist er FIN-angrebet. Jeg kender til FIN-flag, der bruges til at indikere afslutningen af en forbindelse via TCP. Men hvad er FIN angreb nøjagtigt?
Kommentarer
- Har du lavet nogen undersøgelse alene? Hvordan hørte du om ” FIN-angreb “?
- Dybest set blev det givet i en opgave. Jeg har læst noget, men er kun stødt på FIN som et flag i TCP-headeren. Men intet om et FIN-angreb.
- Så kan du få flere detaljer fra din instruktør om udtrykket ” FIN Attack “? Der er scanninger og oversvømmelser, men jeg ‘ er ikke sikker på, at jeg vil beskrive nogen af dem som ” angreb ”
- Hvis du læser de 2 spørgsmål til dette svar, vil du se, at de antager, at du mener en FIN-scanning. Scanninger er ikke angreb. Mener du FIN-scanning, eller får du stadig ikke de svar, du har brug for …?
- Ja, jeg regnede så meget. Stadig tilflugtssted ‘ t får meget information om det, men jeg regner med, at det grundlæggende bruger FIN-pakkerne til at finde et hul et eller andet sted, da det nogle gange kan være i stand til at omgå firewalls. ul>
Svar
Det er et ældre angreb, der oprindeligt var beregnet til at være en “luskende, firewall-bypass”, der var afhængig af nogle få faktorer, der er nu ualmindelige i dag: gamle Unix-operativsystemer, mangel på statefulde firewalls, mangel på NIDS / NIPS osv. Det kan stadig være nyttigt, når man tester (dvs. som en fingeraftryksteknik ikke et angreb i sig selv) helt nye eller nye TCP / IP-stakke (eller bare nyt for dig eller dit miljø), hvilket er sjældent, men som kan ske.
Her er en moderne erstatning, TCP-protokolscanningen:
nmap --reason -n -Pn --packet-trace -g 80 -sO -p 6 <target ip> Hvilket er næsten nøjagtigt det samme som TCP ACK-scanningen (som kan bruges til at kortlægge værter, åbne porte, firewall-regelsæt osv. med den advarsel, som nogle NIPS, IDS og moderne firewalls vil opdage – med en anden situation-specifik begivenhed hvor måske jeg t underretter ikke hændelsesresponder eller sikkerhedsoperationscentre, fordi de har vigtigere ting at se på i disse dage):
nmap --reason -n -Pn --packet-trace -g 80 -sA -p 80 <target ip> Men output er lidt forskellige, og du kan også se de andre forskelle på pakkeniveau.
Det du leder efter for at udvikle en mere avanceret teknik er at identificere finesser i RST-pakkerne og deres vinduesstørrelser. Hvis du får vinduesstørrelser, der ikke er nul, kan du skifte til at bruge TCP Window-scanning i stedet for TCP ACK-scanning. For mere information, se http://nmap.org/book/man-port-scanning-techniques.html
Nogle andre teknikker findes i NSE-guide , f.eks. Firewalk og firewall-bypass-scripts. Der er dog mange andre teknikker, herunder BNAT, fragroute, osstmm-afd, 0trace, lft og potentielt andre, der registrerer andre inline, ikke-firewall-enheder såsom WAFer, IDS, IPS, reverse proxies, gateways og bedragssystemer såsom honningkasser eller aktivt forsvar. Du vil være opmærksom på alt dette og mere, hvis du udfører en netværksindtrængningstest, men de er nyttige til fejlfinding af alle mulige netværks- og sikkerhedsproblemer.
Kommentarer
- Jeg sætter pris på dit svar, men jeg får stadig ikke ‘, hvad et FIN-angreb er. Åh, elsk Nmaps dog: D
- Jeg tror, den korte version er, du sender en FIN, der ikke ‘ ikke hører til en session og lærer af det svar, du få. Resten af @atdre ‘ s svar er godt nok Jeg ‘ vil bare se ham tilføje denne detalje.
- Ja, lyder næsten lige rigtigt .. Bare forsøger at finde ud af, hvordan man bruger FIN-scanningen på en angrebs måde.
Svar
FIN Attack (jeg antager, at du mener FIN Scan) er en type TCP-portscanning.
Ifølge RFC 793: “Trafik til en lukket port skal altid returnere RST”. RFC 793 angiver også, om en port er åben, og segmentet ikke har flag SYN, RST eller ACK. Pakken skal tabes. Det kan være et gammelt datagram fra en allerede lukket session.
Så hvad FIN Attack gør er at misbruge dette. Hvis vi sender en FIN-pakke til en lukket havn, får vi en RST tilbage. Hvis vi ikke får noget svar, ved vi, at det enten falder ned af firewallen, eller at porten er åben. FIN Attack er også mere usynlig end SYN Scan (sender SYN for at se svaret).
Imidlertid returnerer mange systemer altid RST. Og så er det ikke muligt at vide, om porten er åben eller lukket, for eksempel gør Windows dette, men ikke UNIX.
Kommentarer
- Hmmmmm, så det sendes dybest set for at få et svar, så ” angriberen ” og ved hvad du skal gøre?
- Ja, du undersøger målmaskinen for åbne porte. Dette kunne udføres af en administrator eller en angriber for at finde sårbarheder.
- Åh, ja .. Jeg tænkte det samme. Men havde brug for en vis bekræftelse.
Svar
FIN-scanninger, som NULL-, XMAS- eller specialflagsscanninger – were og– bruges til at omgå firewall og undertiden undgå IDS, jeg citerer:
FIN Scan: Den største fordel til disse scanningstyper er, at de kan snige sig igennem visse ikke-statefulde firewalls og pakkefiltreringsroutere. Sådanne firewalls forsøger at forhindre indkommende TCP-forbindelser (mens de tillader udgående) Demonstration af den fulde, firewall-omgående effekt af disse scanninger kræver en temmelig halt mål-firewallkonfiguration. Med en moderne stateful firewall bør en FIN-scanning ikke give ekstra information.
SYN / FIN En interessant brugerdefineret scanningstype er SYN / FIN. Nogle gange vil en firewalladministrator eller enhedsfabrikant forsøge at blokere indgående forbindelser med en regel som “slip eventuelle indgående pakker med kun SYN Hag-indstillingen”. De begrænser det til kun SYN-flag, fordi de ikke ønsker at blokere SYN / ACK-pakker, der returneres som det andet trin i en udgående forbindelse. Problemet med denne tilgang er, at de fleste slutsystemer accepterer indledende SYN-pakker, der indeholder andre (ikke-ACK) flag også. For eksempel sender Nmap OS-fingeraftrykssystemet en SYN / FIN / URG / PSH-pakke til en åben port. Mere end halvdelen af fingeraftryk i databasen reagerer med en SYN / ACK. de tillader port scanning med denne pakke og tillader generelt også at oprette en fuld TCP-forbindelse. Nogle systemer har endda været kendt for at svare med SYN / ACK til en SYN / RST-pakke! TCP RFC er tvetydig med, hvilke flag der er acceptabelt i en indledende SYN-pakke, selvom SYN / RST helt sikkert synes falsk. Eksempel 5.13 viser Ereet, der gennemfører en vellykket SYNIFIN-scanning af Google. Han keder sig tilsyneladende med scanme.nmap.org.
NMAP Network Discovery af Gordon “Fyodor” Lyon