Tűzfal
  • Dj Faustus #1487
    "1. Ha nincs olyan alkalmazás, ami fogadni tudja az adott portra érkező kérést, akkor az operációs rendszer vissza fog válaszolni egy RST flaggel ellátott TCP csomaggal."
    No erre mutatok egy gyakorlati példát - lásd a #1480-as hozzászólásomban felállított tesztkörnyezetet.

    Tehát a Windows XP-s gépen (192.168.1.3), bekapcsolom a Windows XP tűzfalát; a virtuális gépet (melyben fut a Windows XP) futtató gépről (192.168.1.102) pedig engedek egy teljes kapcsolódást (ezt a metodikát használja a t1shopper oldala is) a 19999-es TCP porthoz - a szkennelőprogram (nmap) a port állapotát szűrtnek mutatja, a közbe iktatott adatforgalom-figyelőben (tcpdump) meg úgy látszik, mint ha a tűzfal benyelte volna a kapcsolódási kérelmet:
    IP (tos 0x0, ttl 64, id 63132, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.102.37205 > 192.168.1.3.19999: Flags [S], cksum 0x70d5 (correct), seq 1715708963, win 5840, options [mss 1460,sackOK,TS val 479935 ecr 0,nop,wscale 6], length 0


    Ha viszont a Windows XP tűzfalában kinyitom a 19999-es TCP portot, a szkennelőprogram a port állapotát zártnak mutatja, az adatforgalom figyelőben meg láthetunk választ is:
    IP (tos 0x0, ttl 64, id 5156, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.102.59831 > 192.168.1.3.19999: Flags [S], cksum 0xec62 (correct), seq 529088195, win 5840, options [mss 1460,sackOK,TS val 666343 ecr 0,nop,wscale 6], length 0

    IP (tos 0x0, ttl 128, id 1127, offset 0, flags [none], proto TCP (6), length 40)
    192.168.1.3.19999 > 192.168.1.102.59831: Flags [R.], cksum 0x95f2 (correct), seq 0, ack 529088196, win 0, length 0