Jag ville bara veta exakt vad FIN-attacken är. Jag känner till FIN-flaggan som används för att indikera att anslutningen stängs via TCP. Men vad är FIN-attack exakt?
Kommentarer
- Har du gjort någon egen undersökning? Hur hörde du om ” FIN-attacken ”?
- I grund och botten gavs det i en uppgift. Jag har läst lite men har bara stött på FIN som en flagga i TCP-rubriken. Men ingenting om en FIN-attack.
- Då kan du få lite mer information från din instruktör om termen ” FIN Attack ”? Det finns skanningar och översvämningar, men jag ’ är inte säker på att jag skulle beskriva någon av dem som ” attacker ”
- Om du läser de två frågorna till detta svar kommer du att se att de antar att du menar en FIN-genomsökning. Skanningar är inte attacker. Menar du FIN-skanning, eller får du fortfarande inte de svar du behöver …?
- Ja, jag tänkte så mycket. Fortfarande har jag inte ’ t kommer att få mycket information om det men jag tror att det i grund och botten använder FIN-paketen för att hitta ett hål någonstans eftersom det ibland kan kunna kringgå brandväggar.
Svar
Det är en äldre attack som ursprungligen var tänkt att vara en ”smygande, brandväggsbypass” som var beroende av några faktorer som är nu ovanliga idag: gamla Unix-operativsystem, brist på statliga brandväggar, brist på NIDS / NIPS etc. Det kan fortfarande vara användbart när man testar (dvs. som fingeravtrycksteknik inte en attack i sig) helt nya eller nya TCP / IP-stackar (eller bara nytt för dig eller din miljö), vilket är sällsynt men kan hända.
Här är en modern ersättning, TCP-protokollsökning:
nmap --reason -n -Pn --packet-trace -g 80 -sO -p 6 <target ip> Vilket är nästan exakt detsamma som TCP ACK-skanningen (som kan användas för att kartlägga värdar, öppna portar, brandväggsregler, etc med den förbehåll som vissa NIPS, IDS och moderna brandväggar kommer att upptäcka – med en annan situationsspecifik händelse där jag kanske t kommer inte att meddela incidentresponderar eller säkerhetsoperationscentra eftersom de har viktigare saker att titta på idag):
nmap --reason -n -Pn --packet-trace -g 80 -sA -p 80 <target ip> Men utgångarna är lite annorlunda och du kan också se de andra skillnaderna på paketnivå.
Vad du letar efter för att utveckla en mer avancerad teknik är att identifiera finesser i RST-paketen och deras fönsterstorlekar. Om du får fönsterstorlekar som inte är noll, kanske du vill byta till att använda TCP Window-skanning istället för TCP ACK-skanning. Mer information finns i http://nmap.org/book/man-port-scanning-techniques.html
Några andra tekniker finns i NSE-guide , till exempel brandwalk och brandvägg-bypass-skript. Det finns dock många andra tekniker inklusive BNAT, fragroute, osstmm-afd, 0trace, lft och potentiellt andra som upptäcker andra inbyggda, icke-brandväggsenheter som WAFs, IDS, IPS, reverse proxies, gateways och bedrägerisystem som honeypots eller aktiva försvar. Du vill vara medveten om allt detta och mer om du utför ett nätverkspenetrationstest, men de är praktiska för felsökning av alla typer av nätverks- och säkerhetsfrågor.
Kommentarer
- Jag uppskattar ditt svar men jag får ändå inte ’ vad en FIN-attack är. Åh, älskar Nmaps dock: D
- Jag tror att den korta versionen är, du skickar en FIN som inte ’ inte tillhör en session och lär dig av svaret du skaffa sig. Resten av @atdre ’ s svar är tillräckligt bra Jag ’ vill bara se honom lägga till denna detalj.
- Ja, låter ungefär rätt .. Försöker bara räkna ut hur man använder FIN-skanningen på ett angreppssätt.
Svar
FIN Attack (jag antar att du menar FIN Scan) är en typ av TCP-portskanning.
Enligt RFC 793: ”Trafik till en stängd port ska alltid returnera RST”. RFC 793 anger också om en port är öppen och segmentet inte har flaggan SYN, RST eller ACK. Paketet ska tappas. Det kan vara ett gammalt datagram från en redan avslutad session.
Så vad FIN Attack gör är att missbruka detta. Om vi skickar ett FIN-paket till en stängd port får vi tillbaka en RST. Om vi inte får något svar vet vi att antingen tappas av brandväggen eller så är porten öppen. FIN Attack är också mer osynlig än SYN Scan (skickar SYN för att se svaret).
Många system returnerar dock alltid RST. Och då är det inte möjligt att veta om porten är öppen eller stängd, till exempel gör Windows detta men inte UNIX.
Kommentarer
- Hmmmmm, så det skickas i grunden för att få svar så att ” angriparen ” och vet vad du ska göra?
- Ja, du undersöker målmaskinen för öppna portar. Detta kan utföras av en admin eller en angripare för att hitta sårbarheter.
- Åh, ja .. Jag tänkte samma sak. Men behövde en bekräftelse.
Svara
FIN-skanningar, som NULL-, XMAS- eller specialflaggssökningar – var och– används för att kringgå brandväggen och ibland undvika IDS, jag citerar:
FIN Scan: Den viktigaste fördelen till dessa skanningstyper är att de kan smyga igenom vissa icke-stateful brandväggar och paketfiltreringsroutrar. Sådana brandväggar försöker förhindra inkommande TCP-anslutningar (samtidigt som de tillåter utgående) Att demonstrera den fullständiga, brandväggsstyrda kraften för dessa genomsökningar kräver en ganska halt målväggkonfiguration. Med en modern stateful brandvägg bör en FIN-skanning inte ge någon extra information.
SYN / FIN En intressant anpassad skanningstyp är SYN / FIN. Ibland kommer en brandväggadministratör eller enhetstillverkare att försöka blockera inkommande anslutningar med en regel som ”släpp alla inkommande paket med endast SYN Hag-uppsättningen”. De begränsar det till endast SYN-flaggan eftersom de inte vill blockera SYN / ACK-paketen som returneras som det andra steget i en utgående anslutning. Problemet med detta tillvägagångssätt är att de flesta slutsystem accepterar initiala SYN-paket som innehåller andra (icke-ACK) flaggor också. Till exempel skickar Nmap OS-fingeravtryckssystemet ett SYN / FIN / URG / PSH-paket till en öppen port. Mer än hälften av fingeravtrycken i databasen svarar med ett SYN / ACK. de tillåter portavsökning med detta paket och tillåter i allmänhet också att göra en fullständig TCP-anslutning. Vissa system har till och med varit kända för att svara med SYN / ACK på ett SYN / RST-paket! TCP RFC är tvetydigt om vilka flaggor som är acceptabla i en initial SYN-paket, även om SYN / RST verkligen verkar falskt. Exempel 5.13 visar att Ereet genomför en framgångsrik SYNIFIN-genomsökning av Google. Han blir tydligen uttråkad av scanme.nmap.org.
NMAP Network Discovery av Gordon ”Fyodor” Lyon