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

• #2980 Lortech addikt Pulsar #2979

  Új Válasz 2007-09-26 08:30:15 #2980

  Ú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

  

  Lortech

  addikt

  válasz Pulsar #2979 üzenetére

  Ez így leírva jól hangzana, csak a kérdés tekintve nincs semmi értelme, valamint félreérthető azoknak, akik nem tudják valójában, hogy a háttérben mi megy, csak a leírás alapján próbálják elképzelni.

  Adott:
  A : kliens PC - koli hálózaton, B: koli routere - interneten C : külső PC (pl. torrent tracker vagy peer) - interneten

  "A" gép nyilvánvalóan nem rendelkezik saját publikus internetes címmel, hanem NAT mögött van, és a B gépet használja átjárónak C felé. Ez tehát legyen A-.-.->B->C irány.
  Ha A küld adatokat C-nek, akkor C azt látja, hogy a B küldte neki, így a választ is B-nek fogja visszaküldeni, majd B összeveti a választ a NAT táblájával, és ha illeszkedik valamelyik bejegyzésre, akkor visszaküldi a NAT mögött lévő alhálózat gépeinek valamelyikének, itt az A gépnek. Ez bittorrentnél a passzív működésnek felel meg.
  Még tűzfalakról nem is volt szó. Egy kolis tűzfalnál alap (ami a B gép) alap, hogy _befelé_ minden forgalmat blokkol, kivéve a biztosítani kívánt szolgáltatások elérésére irányuló forgalmat (koli webszerver, ftp, ssh ), amennyiben van ilyen, illetve beengedi az A gép kapcsolat-kezdeményezésére C válaszként küldött forgalmát.
  De hiába is engedne be minden forgalmat B, nem volna hova továbbroute-olni, mivel az A gépet nem lehet megcímezni kívülről (ide port forwarding kéne).
  Másrészről A->B->C irányban is erősen korlátozva szokott lenni a forgalom, mivel A nem tud elérni tetszőleges, C portján figyelő szolgáltatást, mivel célportra is szűrve van, és általában minden blokkolva van, kivéve 80,21,22,3389 stb. Tfh. C gép 80-as portján figyel egy tracker. Ekkor A->B->C:80 és C:80->B -.-.->A - működik a forgalom, mivel A->C irányban kiengedi B a 80-as port felé irányuló forgalmat (és bekerül a NAT táblába ez a kapcsolat kezdeményezés), C->A irányban pedig a NAT miatt vissza tud menni a csomag A-hoz.
  Ha C-n a tracker valami 54654-ös porton van, akkor már A->B->C:54654 irányban sem engedi ki a tűzfal a kérést, így ez nem fog működni. Ez az egyik probléma, hogy ezzel nem tudsz mit kezdeni, mivel se a tűzfal policy-n nem tudsz változtatni, sem pedig azon, hogy milyen porton legyen a tracker és a peerek.

  És akkor nézzük a portscant. Portcannel meg tudod vizsgálni A-ról és C-ről, hogy milyen szolgáltatások érhetőek el B-n. Mivel a nyitott port nem azt jelenti, hogy B milyen portokat enged át ( nem úgy kell elképzelni, mint egy ajtót) hanem hogy adott port válaszol-e. Kicsit egyszerűsítve akkor válaszol egy port, ha szolgáltatás van rajta, és ez a port az adott irányból elérhető.
  Pl van egy FTP szerver a 21-es porton a B tűzfalon, ekkor 21-es port nyitott. De tfh csak a koli belső hálós interface felé van engedélyezve az elérése a tűzfalban, internet felőli interface-en pedig tiltott. Ekkor A gép portscanje jelezni fog, hogy ott figyel egy szolgáltatás, azaz "nyitott" a port, míg C gép ugyanezt a portot scannelve azt fogja látni, hogy zárva van. Szóval a kérdést tekintve értelmezhetetlen számomra, hogy nyújt majd megoldást a portscan.
  Még lehet tovább ragozni, de nincs több időm.
  Ha ezt mind megértetted, és még mindig látod értelmét itt a portscannek, akkor írd meg _konkrétan_, jelölésekkel, hogy mit, hogyan és miért portscannelnél. //Én látom értelmét egy bizonyos esetben a portscannek itt, de azzal sem megy semmire//

  ps: esetleges hibákért sorry, nincs időm visszaolvasni.

  Thank you to god for making me an atheist

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