Full IP-spoofing är svårt för allmänheten.
Allt i IP är tillverkat av paket. Varje paket har en källadress och en destinationsadress . IP-förfalskning handlar om att skicka paket med fel källadress. Att skicka ett sådant paket är tillräckligt enkelt med några rader kod (det tenderar att kräva lokala administratörs- / root-rättigheter; på Linux är det en fråga om ett -uttag () -systemsamtal med SOCK_RAW -parameter).
Att få paketet att nå sin destination kan vara lite problematiskt. Normalt hoppar paket från router till router och routrar tittar bara på destinationsadressen (de är intresserade av vart paketet ska gå, inte varifrån det kommer). En del routrar tillämpar dock anti-spoofing-mekanismer: routrarna "vet" vilka IP-adresser som ligger bakom det och kommer att se att det falska paketet inte är "möjligt" (dess källadress är inte en av de källadresser som normalt ligger bakom router). Sådana routrar reagerar genom att släppa det kränkande paketet. Vissa Internet-leverantörer använder sådana routrar, eftersom de inte vill ses som slapp Internet-leverantör som låter sina kunder bedriva nätverksmetoder av tvivelaktig moral och laglighet.
Förutsatt att din Internet-leverantör är slapp och låter de falska paketen passera , når du det andra problemet som kallas " TCP-sekvensnummer ". En webbserver förväntar sig inte ensamma paket utan en TCP-anslutning. TCP-anslutningen börjar med "trevägs handskakning":
- Klienten skickar ett första paket som innehåller SYN-flaggan.
- Servern svarar på det paketet med ett paket som innehåller SYN- och ACK-flagga.
- Klienten svarar på det paketet med ett paket som innehåller ACK-flaggan.
Varje paket med SYN innehåller initialt sekvensnummer (ett 32-bitarsvärde) för dataströmmen som kommer från samma maskin. I själva verket kommer varje databit att "numreras" och räknaren börjar vid ett värde som avsändaren väljer. Dessa värden används i TCP-kontrollflödet; klient och server använder dem för att berätta för den andra maskinen vilka byte har tagits emot ("bekräfta"). I synnerhet MÅSTE det tredje paketet för trevägshandskakningen (ACK från klienten) MÅSTE innehålla sekvensnumret som servern skickade i sitt SYN + ACK-paket.
Men en falsk klient aldrig får det SYN + ACK-paketet. Servern skickar faktiskt sitt SYN + ACK till den påstådda klientadressen, som är källadressen i SYN-paketet. Per definition använde spoofing-klienten en falsk källadress. Så SYN + ACK gick till den där falska adressen, inte till klienten. Eftersom klienten inte har fått SYN + ACK har han inget sätt att gissa det sekvensnummer som servern lade in i SYN + ACK. Därför kan klienten inte skicka ett giltigt ACK. Servern kommer således aldrig att betrakta trevägshandskakningen som slutförd. Inget handslag, inga data. Inga data, ingen HTTP-begäran eller svar. Försöket att ansluta till en falsk källadress fungerar helt enkelt inte.
Det är svårt att gissa servernas sekvensnummer om servern använder en anständig slumptalsgenerator. TCP-sekvensförutsägelseattacket handlar om att först öppna några anslutningar till målservern för att få några nya "slumpmässiga" sekvensnummer. Därefter försöker angriparen räkna ut det interna tillståndet för Slumpgenerator som används av serverns operativsystem för att producera sekvensnumren. Om RNG är av kryptografisk kvalitet (som det borde vara i något anständigt operativsystem) är sådan förutsägelse inte möjlig, och angriparen måste förlita sig på tur. Eftersom sekvensnummer är över 32 bitar har angriparen en chans på cirka fyra miljarder för att få rätt. Det är inte bra odds för angriparen ...
För att kunna avsluta trevägs-handskakningen måste angriparen praktiskt taget "se" SYN + ACK-paketet, även om det skickas till den falska adressen. Detta kräver att angriparen är "nära" målservern, på samma LAN eller kanske en eller två routrar högst. Detta förklarar varför jag sa att full IP-spoofing är svårt för allmänheten : som en grundläggande ISP-kund har du inte den fysiska åtkomsten till kablarna som krävs för att göra en fullständig TCP-falska på en generisk webbserver . Naturligtvis kan anställda vid anläggningarna där servern är värd göra mycket fler saker ...
Och svaret? Även om du lyckas göra trevägs- handskakning och skickar HTTP-begäran, kommer servern att skicka HTTP -svaret till den falska adressen, inte till dig. Där igen behöver du omfattande trådnivååtkomst för att få svaret. Annars kan du i bästa fall skicka "blind" begäran men inte bevittna resultatet. Detta kan vara tillräckligt för en attack, eller inte, beroende på vad servern gör och varför du försöker kontakta den under en falsk adress.