Új hozzászólás Aktív témák

• #24675 mrots junior tag ekkold #24669

  Új Válasz 2025-07-31 13:35:54 #24675

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  mrots

  junior tag

  válasz ekkold #24669 üzenetére

  Ez valoszinuleg nem a jo megkozelites. Az enyem sem biztos, hogy jo. De en inkabb akkor kapcsolnam be, amikor a wireshark szerint olyan szegmensek erkeznek a negyedik retegben (TCP - ISO/OSI transzport reteg) amely szegmensek kivul esnek a csuszoablakon. Ezeket normalis esetben eldobna az eszkoz. Normal esetben ilyen forglamat az ember nem varna, hiszen a TCP handshake soran a csuszoablak merete is egyeztetesre kerul, tehat a kuldo pontosan tudja, hogy a fogadonak mekkora buffer all rendelkezesre es csak annyi adatot kuld, nem tobbet. Tehat normal mukodes soran erre nincs szukseg. Viszont a linux kernelben regota benne van, tehat gondolom annyi tortenik, hogy a mikrotik kivezet a felhasznaloi feluletre egy beallitast ami eddig nem volt lehetseges azon, de maga az OS eddig is tamogatta volna.

  Az egyetlen eset ami eszembe jut amikor erre talan szukseg lehet, a TCP challenge ACK. Ekkor a haromutas kezfogas nem az iskolaban tanult modon zajlik le, hanem a TCP SYN-re a cimzett egy SYN nelkuli ACK-t valaszol vissza, raadasul egy olyan sorszammal ami nem passzol a szekvenciaba. Ez normalis, igy mukodik a challenge ACK. Erre harmadik csomagkent egy RST kell, hogy menjen az eredeti kapcsolatot kezdemenyezotol. Ez az RST elkepzelheto, hogy eldobasra kerul, ha a beallitas ki van kapcsolva. Nem ellenoriztem, nem olvastam el az RFC-t, szoval lehet tevedek, de most nekem semmilyen mas legitim ok nem jut eszembe, amiert egy RST-t el kellene fogadjak, nem pedig eldobnom.

  Ha tehat a mikrotikom tuzfalkent funkcional egy forras es egy cel kozott, akkor amennyiben a cel challenge ACK-t hasznal, e nelkul a funkcio nelkul sosem fog tudni egy TCP kapcsolat felepulni, szerintem.

Új hozzászólás Aktív témák