Puteți afla cum să configurați MikroTik într-un curs online despre echipamente de la acest producător. Autorul cursului este un trainer certificat MikroTik. Puteți citi mai multe la sfârșitul articolului.
Articolul răspunde la întrebarea cât de periculos este blocarea traficului ICMP.
ICMP este un element al disputei
Mulți administratori de rețea consideră că protocolul pentru mesaje de control Internet (ICMP) este un risc de securitate și, prin urmare, ar trebui să fie întotdeauna blocat pe . Este adevărat că protocolul are unele probleme de securitate asociate și că unele solicitări ar trebui blocate. Dar asta nu este motiv pentru a bloca tot traficul ICMP!
Traficul ICMP are multe funcții importante; unele dintre ele sunt utile pentru depanare, în timp ce altele sunt necesare pentru buna funcționare a rețelei. Următoarele sunt câteva dintre părțile importante ale protocolului ICMP de care ar trebui să le cunoașteți. Ar trebui să vă gândiți cum să le transmiteți cel mai bine prin rețeaua dvs.
Solicitare eco și răspuns eco
IPv4 - Solicitare ecou (Tip 8, Cod 0) și Răspuns ecou (Tip 0, Cod 0)
IPv6 - Solicitare Echo (Tip128, Cod 0) și Răspuns Ecou (Tip 129, Cod 0)
Știm cu toții bine că ping-ul este unul dintre primele instrumente de depanare. Da, dacă activați procesarea pachetelor ICMP pe hardware-ul dvs., atunci aceasta înseamnă că gazda dvs. este acum descoperită, dar gazda dvs. nu ascultă deja pe portul 80 și nu trimite răspunsuri la solicitările clientului? Desigur, blocați și aceste solicitări dacă doriți cu adevărat ca DMZ-ul dvs. să fie la marginea rețelei. Dar blocarea traficului ICMP în rețeaua dvs. nu crește securitatea, dimpotrivă, obțineți un sistem cu un proces de depanare inutil de complicat („Vă rugăm să verificați dacă gateway-ul răspunde la solicitările rețelei?”, „Nu, dar acest lucru nu mă deranjează deloc, pentru că nu va spune nimic!"
Amintiți-vă, puteți permite, de asemenea, solicitărilor să meargă într-o anumită direcție; de exemplu, configurați hardware-ul astfel încât cererile Echo din rețeaua dvs. să ajungă la Internet și răspunsurile Echo de la Internet către rețeaua dvs., dar nu invers.
Fragmentarea pachetului este necesară (IPv4) / Pachetul prea mare (IPv6)
IPv4 - (Tip3, Cod4)
IPv6 - (Tip2, Cod0)
Aceste componente ale protocolului ICMP sunt foarte importante deoarece sunt o componentă importantă în Path MTU Discovery (PMTUD), care este o parte integrantă a protocolului TCP. Permite două gazde să ajusteze valoarea TCP Maximum Segment Size (MSS) la o valoare care se potrivește cu cea mai mică MTU de-a lungul căii de legătură între două destinații. Dacă există un nod de-a lungul căii pachetelor cu o unitate de transmisie maximă mai mică decât expeditorul sau receptorul și nu au mijloacele pentru a detecta această coliziune, atunci traficul va fi scăpat imperceptibil. Și nu veți înțelege ce se întâmplă cu canalul de comunicare; cu alte cuvinte, „vor veni zile fericite pentru tine”.
Nu fragmentați - ICMP nu va trece!
Transmiterea pachetelor IPv4 cu bitul Don't Fragment set (majoritatea dintre ele!) sau pachete IPv6 (rețineți că nu există fragmentare de către routere în IPv6) care sunt prea mari pentru a trece prin interfață va determina routerul să renunțe la pachet. și formularul de răspuns la expeditor cu următoarele erori ICMP: Fragmentare necesară ( Fragmentarea necesară), sau Pachet prea mare ( Pachetele de asemenea mare). Dacă răspunsurile cu aceste erori nu se întorc la expeditor, atunci acesta va interpreta absența răspunsurilor de confirmare cu privire la livrarea pachetelor ACK ( Recunoașteți) de la receptor ca congestie/pierdere și sursa pentru a retransmite pachetele care vor fi, de asemenea, abandonate.
Este dificil să identifici cauza unei astfel de probleme și să o remediezi rapid, procesul de strângere de mână TCP funcționează bine, deoarece implică pachete mici, dar de îndată ce are loc un transfer de date în bloc, sesiunea de transfer se blochează deoarece sursa de transfer nu primește eroare. mesaje.
Studiu calea de livrare a pachetelor
RFC 4821 a fost conceput pentru a ajuta participanții la rețea să rezolve această problemă utilizând descoperirea căilor de propagare a pachetelor. (Descoperire MTU cale (PLPMTUD). Standardul vă permite să detectați cantitatea maximă de date (Unitate de transmisie maximă (MTU), care poate fi transferat de protocol într-o singură iterație, prin creșterea treptată a dimensiunii maxime a blocului de date util (Dimensiunea maximă a segmentului (MSS), pentru a găsi dimensiunea maximă posibilă a pachetului fără fragmentare pe drumul de la emițător la receptor. Această funcționalitate reduce dependența de primirea în timp util a răspunsurilor de eroare Internet Control Message Protocol (ICMP) și este disponibilă pe majoritatea stivelor de dispozitive de rețea și sistemelor de operare client. Din păcate, nu este la fel de eficientă ca obținerea directă a datelor cu privire la dimensiunea maximă posibilă a pachete transmise Vă rugăm să lăsați aceste mesaje de protocol ICMP să se întoarcă la sursa transmisiei, bine?
Timp de expirare a pachetului
IPv4 - (Tip11, Cod0)
IPv6 - (Tip3, Cod0)
Traceroute este un instrument foarte util pentru depanarea conexiunilor de rețea între două gazde, detaliind fiecare pas al căii.
Trimite un pachet cu durata de viață a pachetului de date pentru protocolul IP (Timp de trăit (TTL) egal 1 pentru ca primul router să trimită un mesaj de eroare (inclusiv propria sa adresă IP) că pachetul a expirat. Apoi trimite un pachet cu TTL 2 și așa mai departe. Această procedură este necesară pentru a descoperi fiecare nod de-a lungul căii pachetelor.
NDP și SLAAC (IPv6)
Solicitare router (RS) (Tip133, Cod0)
Publicitate pentru router (RA) (Tip134, Cod0)
Solicitare vecină (NS) (Tip135, Cod0)
Anunț pentru vecini (NA) (Tip136, Cod0)
Redirecționare (Tip137, Cod0)
În timp ce IPv4 a folosit Address Resolution Protocol (ARP) pentru a mapa straturile 2 și 3 ale modelului de rețea OSI, IPv6 utilizează o abordare diferită sub forma Neighbor Discovery Protocol (NDP). NDP oferă multe funcții, inclusiv descoperirea routerului, descoperirea prefixelor, rezoluția adreselor și multe altele. Pe lângă NDP, StateLess Address AutoConfiguration (SLAAC) vă permite să configurați dinamic o gazdă într-o rețea, similar conceptului Dynamic Host Configuration Protocol (DHCP) (deși DHCPv6 este destinat să fie mai granular).
Aceste cinci tipuri de mesaje ICMP nu trebuie blocate în interiorul rețelei dvs. (ignorând perimetrul exterior) pentru ca protocolul de date IP să funcționeze corect.
Numerotare tip ICMP
Internet Control Message Protocol (ICMP) conține multe mesaje care sunt identificate printr-un câmp „tip”.
| Tip | Nume | Specificație |
|---|---|---|
| 0 | ecou răspuns | |
| 1 | Nealocat | |
| 2 | Nealocat | |
| 3 | Destinație inaccesabilă | |
| 4 | Stingere sursă (învechit) | |
| 5 | Redirecţiona | |
| 6 | Adresă de gazdă alternativă (învechit) | |
| 7 | Nealocat | |
| 8 | ecou | |
| 9 | Publicitate la router | |
| 10 | Solicitare router | |
| 11 | Timp depășit | |
| 12 | Problema parametrilor | |
| 13 | Timestamp-ul | |
| 14 | Răspuns marcaj temporal | |
| 15 | Solicitare de informații (învechit) | |
| 16 | Răspuns la informații (învechit) | |
| 17 | Solicitare de mască de adresă (învechit) | |
| 18 | Răspuns pentru masca de adresă (învechit) | |
| 19 | Rezervat (pentru securitate) | Solo |
| 20-29 | Rezervat (pentru experimentul de robustețe) | ZSu |
| 30 | Traceroute (învechit) | |
| 31 | Eroare de conversie a datagramei (învechit) | |
| 32 | Redirecționare gazdă mobilă (învechit) | David_Johnson |
| 33 | IPv6 Unde ești (învechit) | |
| 34 | IPv6 Sunt aici (învechit) | |
| 35 | Solicitare de înregistrare mobilă (învechit) | |
| 36 | Răspuns de înregistrare mobil (învechit) | |
| 37 | Solicitare nume de domeniu (învechit) | |
| 38 | Răspuns nume de domeniu (învechit) | |
| 39 | SKIP (învechit) | |
| 40 | Photoris | |
| 41 | Mesaje ICMP utilizate de protocoale experimentale de mobilitate, cum ar fi Seamoby | |
| 42 | cerere extinsă de ecou | |
| 43 | Răspuns Echo extins | |
| 44-252 | Nealocat | |
| 253 | Experimentul 1 în stil RFC3692 | |
| 254 | Experimentul 2 în stil RFC3692 | |
| 255 | Rezervat |
Câteva cuvinte despre limita de viteză
În timp ce mesajele ICMP precum cele din acest articol pot fi foarte utile, rețineți că generarea tuturor acestor mesaje necesită timp CPU pe routerele dvs. și generează trafic. Chiar vă așteptați să obțineți 1000 de ping-uri pe secundă prin firewall într-o situație normală? Va fi considerat trafic normal? Probabil ca nu. Limitați lățimea de bandă a rețelei pentru aceste tipuri de trafic ICMP după cum credeți de cuviință; acest pas vă poate ajuta să vă securizați rețeaua.
Citiți, explorați și înțelegeți
Având în vedere că discuția subiectului „blocați sau nu blocați” pachetele ICMP duce întotdeauna la confuzii, dispute și dezacorduri, vă sugerez să continuați să studiați acest subiect pe cont propriu. Am citat o mulțime de link-uri pe această pagină, cred că pentru o înțelegere mai completă a problemei, ar trebui să petreceți timp citindu-le. Și faceți o alegere informată cu privire la ceea ce funcționează cel mai bine pentru rețeaua dvs.
MikroTik: unde să dai clic pentru a-l face să funcționeze?
Cu toate meritele sale, produsele MikroTik au un dezavantaj - o mulțime de informații deconectate și departe de a fi întotdeauna de încredere despre setările sale. Vă recomandăm o sursă de încredere în limba rusă, unde totul este adunat, logic și structurat - curs video " Configurarea hardware-ului MikroTik". Cursul include 162 de lecții video, 45 de laboratoare, întrebări de autotest și note. Toate materialele rămân la tine pe termen nelimitat. Puteți urmări gratuit începutul cursului lăsând o solicitare pe pagina cursului. Autorul cursului este un trainer certificat MikroTik.
Canalele secrete (canale secrete) este una dintre metodele în securitatea informației, care poate fi folosită atât cu semnul plus (pentru a asigura anonimatul și confidențialitatea), cât și cu semnul minus (pentru a organiza scurgerile de date). Să luăm în considerare a doua componentă - detectarea transmisiei secrete de date sau transmisia datelor prin canale secrete, care este una dintre cele mai dificile sarcini de securitate a informațiilor din practică. Pentru a nu mări dimensiunea articolului, voi ignora în mod deliberat mecanismele de ascundere a datelor, cum ar fi criptarea și steganografia.
Alexei Lukatsky
Consultant de securitate Cisco
Ce este transmisia de date ascunse?
Transmiterea sub acoperire a datelor printr-o rețea nu este singura aplicare a acestei metode. Termenul „canal secret” a apărut pentru prima dată în 1973 și a fost folosit pentru sistemele de calcul care nu au o conexiune tradițională la rețea. De exemplu, o valoare pară pentru durata unui proces poate însemna unul, iar o valoare impară poate însemna zero. Astfel, prin manipularea duratei procesului, putem forma o secvență de 0 și 1, cu care putem descrie orice (acesta este așa-numitul canal de timp). Un alt exemplu de proces ascuns în sistemele de calcul este lansarea de către un proces a unei anumite sarcini și finalizarea acesteia la un anumit moment, care poate fi tratată ca o unitate; și zero dacă sarcina nu s-a finalizat la momentul specificat.
Cum poate fi implementată transmisia sub acoperire?
Dacă vorbim de transferul ascuns de date în rețea, atunci una dintre cele mai populare și relativ ușor de implementat metode este încapsularea, care constă în includerea informațiilor protejate care trebuie transmise în exterior, sau o comandă care trebuie acceptată din exterior, într-un protocol permis. .
În acest caz, pot fi utilizate opțiuni de încapsulare complet diferite:
În 1987 s-a propus ideea transmiterii sub acoperire prin rețea, iar din acel moment au început cercetări serioase asupra acestei metode de asigurare a confidențialității sau scurgeri de date (în funcție de ce parte a baricadelor se privește). În special, în 1989, pentru prima dată, s-a propus să se manipuleze biți neutilizați de cadre Ethernet și o serie de alte protocoale de canal. Evident, canalele ascunse dintr-o rețea locală nu sunt la fel de interesante de studiat, spre deosebire de ascunderea datelor în rețelele extinse. O descoperire (cel puțin una publică) poate fi considerată anul 1996, când a fost publicat un studiu care a demonstrat transmiterea și recepția reală a datelor pe un canal TCP/IP ascuns; sau mai degrabă, în câmpuri separate ale antetului său.
- La nivel HTTP, care a devenit mult timp standardul de facto pentru construirea altor protocoale de aplicație pe baza acestuia. De exemplu, rețeaua anonimă JAP folosește HTTP pentru a transfera date, utilizând în același timp și rețeaua Tor puternic controlată. În HTTP, este posibil să folosiți comenzile GET și POST pentru a transfera date, iar dacă HTTP este folosit pentru a transfera streaming video și audio, atunci posibilitățile atacatorilor de a transfera cantități mari de date devin aproape nelimitate.
- La nivel DNS, când informațiile sunt ascunse în interogările și răspunsurile DNS. Despre această metodă s-a vorbit pentru prima dată la începutul anilor 2000, când a apărut instrumentul DeNiSe pentru tunelarea TCP la DNS. Mai târziu a existat un studiu al lui Dan Kaminsky care arăta posibilitatea încapsulării SSH peste DNS și a fost prezentat la conferința Defcon din 2005. Și atunci acest subiect a început să câștige popularitate - au apărut dns2tcp, DNScapy, DNScat, Heyoka, iod, squeeza etc.
- La nivel ICMP, atunci când datele sunt încapsulate în protocolul ICMP permis în mod normal de caracteristicile de securitate. Programul Loki, care a fost menționat pentru prima dată în 1996 în revista Phrack, a funcționat cândva pe acest principiu. A fost urmat de Loki2, mai avansat. Există, de asemenea, un instrument precum icm-pchat care vă permite să comunicați prin mesaje criptate prin ICMP.
- La nivel TCP / UDP / IP, când sunt folosite câmpuri separate ale antetului pachetului pentru a ascunde scurgerea sau pentru a primi comenzi din exterior. În funcție de protocolul utilizat, dimensiunea datelor transmise va varia de la 2 la 12 și, respectiv, 38 de octeți în protocoalele IP, UDP și TCP. Un instrument foarte interesant care utilizează modificarea antetului TCP se numește Nushu. Particularitatea sa este că nu creează nici un trafic în sine, ci îl modifică doar pe cel care este deja trimis de la nod de către o aplicație sau un proces. Cu alte cuvinte, traficul modificat este trimis acolo unde ar trebui să fie, iar atacatorul pur și simplu îl interceptează prin rețea, colectând datele scurse în acest fel.
- În rețelele fără fir, când datele sunt mascate în traficul de difuzare. Apropo, în acest caz nu este ușor să găsiți partea de recepție, care poate funcționa în modul pasiv - doar pentru a primi date. Instrumentul HICCUPS este construit pe acest principiu.
Cum poate fi detectată transmiterea sub acoperire?
Văzând o asemenea varietate de metode care sunt utilizate de canalele ascunse și protocoalele în care sunt localizate, înțelegeți de ce sunt oferite atât de multe metode diferite pentru detectarea transmisiilor ascunse. Principalul este controlul anomaliilor, care constă în verificarea următorilor parametri (listă neexhaustivă):
- Dimensiunea cererii și a răspunsului. De exemplu, se știe că lungimea medie a unei interogări DNS nu depășește 40–60 de octeți. Prin urmare, o creștere a numărului de interogări DNS cu lungimi de pachete crescute poate indica funcționarea unui canal secret. O practică similară poate fi propusă pentru alte protocoale - ICMP, SIP etc.
- Volumul cererilor. De obicei, volumul de trafic pe anumite tipuri de protocoale este, dacă nu este o valoare fixă, atunci rareori se modifică în câteva fracțiuni de procent. Prin urmare, o creștere bruscă a traficului protocolului de serviciu sau a numărului de solicitări DNS sau a mărimii acestora poate indica o anomalie și necesitatea de a investiga. În acest caz, profilul de trafic în acest caz poate fi evaluat atât pentru nodul expeditor, cât și pentru nodul destinatar.
- Numărul sau geografia apelurilor poate servi și ca o caracteristică a canalelor ascunse. De exemplu, dacă aveți un server DNS intern, referirea constantă la o gazdă DNS externă poate fi, de asemenea, un semn al unei anomalii.
- Alte tipuri de analiză statistică sunt, de asemenea, utile pentru descoperirea canalelor secrete. De exemplu, puteți analiza nivelul de entropie în numele de gazdă pentru DNS. Dacă informațiile ascunse sunt transmise în interogările DNS, atunci distribuția caracterelor folosite va diferi de cea tradițională.
Un instrument care vă permite să urmăriți astfel de anomalii în traficul de rețea este sistemele de clasă NBAD (Network-based Anomaly Detection), care fie conțin deja un număr mare de reguli încorporate, fie pot fi configurate independent după modul de antrenament.
Pe lângă analiza anomaliilor, canalele ascunse pot fi detectate și prin examinarea conținutului din anumite protocoale. Acest lucru se poate face atât cu soluțiile tradiționale Next Generation, care pot urmări abaterile traficului protocolului de aplicație de la RFC-uri, cât și cu ajutorul sistemelor de detectare a intruziunilor. De exemplu, iată semnătura pentru detectarea canalului secret NSTX în protocolul DNS pentru soluția open source Snort:
alertă udp $EXTERNAL_NET orice - > $HOME_NET 53 (msg:„Potențial NSTX DNS Tunneling”; conținut:”|01 00|”; offset:2; în:4; conținut:”cT”; offset:12; adâncime:3 ; continut:"|00 10 00 01|"; in:255; classtype:bad-necunoscut; sid:1000 2;)
rezumat
Neuniversalitatea este, poate, principalul obstacol atât pentru utilizarea activă a canalelor secrete, cât și pentru combaterea acestora.
Canalele ascunse în traficul de rețea este o metodă foarte specifică, care nu este universală și are limitările și domeniul de aplicare. Fiecare canal secret are propriile caracteristici, cum ar fi debitul, zgomotul, modul de transmisie (bidirecțional sau unidirecțional), care trebuie luate în considerare - atât în utilizarea lor, cât și în lupta împotriva lor. Totuși, „Război și pace” L.N. Tolstoi nu poate fi transmis rapid prin astfel de canale, iar unele metode de transmisie sub acoperire au un nivel de zgomot foarte ridicat, ceea ce le împiedică să fie aplicate eficient în rețelele globale, în care factorii externi pot afecta foarte mult succesul transmisiei sub acoperire.
Neuniversalitatea este, poate, principalul obstacol atât pentru utilizarea activă a canalelor secrete, cât și pentru combaterea acestora. Un număr mare de restricții pentru transmiterea sub acoperire a datelor fac din aceasta o mulțime de amenințări țintite dezvoltate pentru o anumită sarcină și un anumit client. Aceeași non-universalitate duce la ideea că nu există nici un glonț de argint sub forma unui singur produs și este necesar să se folosească o întreagă gamă de instrumente și tehnologii pentru detectarea și neutralizarea transmisiei secrete de date.
Acest scurt articol vă arată cum să utilizați câteva computere, câteva instrumente distractive și un sistem de operare pentru a obține acces la internet wireless ori de câte ori este posibil. Am descris partea tehnică destul de clar și am oferit comentarii.
1. Introducere.
Tocmai mi-am luat primul laptop și am vrut să încerc să fac niște lucruri murdare cu el (am încercat chiar să lucrez, dar a fost prea obositor
:)). Wardriving a fost destul de distractiv la început, dar m-am plictisit când mi-am dat seama că rețelele sunt protejate
WEP este prea dur pentru mine (din moment ce nu a existat trafic intranet - rețelele puteau fi considerate moarte), iar rețelele nesecurizate nu prezintă niciun interes. Din fericire, rețeaua wireless din campusul meu s-a dovedit a fi puțin mai interesantă.
Rețeaua oferă internet wireless gratuit, dar vă solicită să vă înregistrați adresa MAC pe numele dvs. înainte de a permite accesul - utilizatorii neînregistrați sunt redirecționați către pagina furnizorului (pagina de înregistrare). Înscrierea ar fi implicat o conversație de două minute cu administratorul, dar m-am gândit: „Poate că acolo
o modalitate de a obține acces fără a fi nevoie să comunici așa?” Bineînțeles că era.
2. Prima metodă de penetrare este falsificarea MAC.
Deoarece totul se învârtea în jurul adresei MAC, primul lucru care mi-a venit în minte a fost
a fost să aflu adresa MAC deja înregistrată și să o rezolv
falsificarea. Desigur, a vorbi este ușor, dar nu a fost nevoie de aproape niciun efort, deși nu am mai făcut-o niciodată.
Primul lucru pe care l-am făcut a fost să alerg kismet ("kismet -c orinoco,eth1,wifi") și să adulmec plasa. Kismet salvează totul adulmecat
informații într-un fișier ("/var/log/kismet/*.dump" în cazul meu), rezultatele sniffing-ului pot fi vizualizate așa cum sunt
chitanțe. Drept urmare, am putut vedea toate informațiile și
notează adresa MAC corectă.
Comenzi folosite pentru a schimba adresa MAC a plăcii de rețea:
ifconfig eth1 jos
ucide dhclient
ifconfig hw ether 00:11:22:33:44:55
ifconfig eth1 sus
dhclient eth1
Nu sunt necesare toate comenzile, dar sunt foarte utile atunci când încercați să schimbați mai multe adrese MAC una câte una, care
mi-a fost de folos, nu. Adresa MAC pe care am încercat să o schimb nu a funcționat imediat. Am fost interzis, rețeaua s-a offline și nu s-a pornit din nou, așa că a trebuit să mă joc cu câteva erori enervante
în sistemul dumneavoastră. Poate aceste probleme
a aparut din cauza firmware-ului, si posibil pentru ca reteaua avea deja o placa de retea cu aceeasi adresa MAC.
Nu toate stațiile de lucru erau active și utilizarea kismet pentru a vedea rezultatele pe măsură ce au venit a fost ineficientă, așa că am încercat o altă metodă.
În rețea, filtrarea după adresa MAC a fost efectuată la un nivel destul de ridicat. Oricand puteam accesa reteaua, pentru ca. când am încercat să mă înscriu, am ajuns la o pagină cu o ofertă de înregistrare.
Desigur, în timpul gândirii la gazde active, nmap mi-a venit în minte. Așa că am efectuat o verificare a intervalului IP pentru stațiile active.
marktwain:~# nmap -sP 10.0.0.1/22
Începând cu nmap 3.81 (http://www.insecure.org/nmap/) la 2005-05-23 12:54 EEST
Gazda 10.1.0.14 pare să fie activată.
Adresă MAC: 00:0E:35:97:8C:A7 (Intel)
Gazda 10.1.0.95 pare să fie activată.
Gazda 10.1.0.109 pare să fie activată.
Adresa MAC: 00:0D:54:A0:81:39 (3Com Europe)
... trage...
Gazda 10.1.2.92 pare să fie activată.
Adresa MAC: 00:02:2D:4D:1C:CE (Agere Systems)
Gazda 10.1.2.187 pare să fie activată.
Adresă MAC: 00:02:2D:4D:1C:43 (Agere Systems)
Nmap terminat: 1024 de adrese IP (20 de gazde în sus) scanate în 53.980 de secunde
O grămadă de adrese MAC. Majoritatea
tabelul de adrese rezultat este (presupun că) adresele MAC ale mașinilor care au vizitat rețeaua în ultimele zile. Au fost 245 de MAC-uri diferite în tabel
adrese. Nu știu dacă acesta este un comportament normal
puncte de acces, dar cred că băieții merită ceva
schimbarea distribuției internetului. Oricare ar fi cazul, acum am destule adrese MAC ale mașinilor care au vizitat grila, dar cel mai probabil au părăsit cu mult timp în urmă. Câteva încercări de falsificare și deja înot la neworder.box.sk...
3. Încercarea numărul 2 - Tunnel ICMP.
Am făcut tot ce mi-am dorit, dar mai era loc de săpat în această rețea. Dar ce
Aș putea face dacă această rețea nu ar avea
nici o singură mașină deținută de mine? Dacă
nmap nu s-ar deschide și nu ar arăta toate aceste adrese MAC? Deci, oricum, am decis să încerc o altă modalitate de a obține acces.
Acest lucru nu a fost menționat anterior, dar ocolind sistemul
Distribuția pe Internet dând permisiunea și DHCP, rețeaua a permis mesajelor ICMP să treacă liber. Verificarea activității oricărui site de internet a funcționat bine (chiar nu pot să-mi dau seama de ce nu l-au blocat - cu excepția cazului în care au uitat), ping
chiar a apărut pe sniffer-ul care rula pe serverul meu.
Planul meu a fost să încerc să creez un tunel între laptopul meu de la universitate și un server de acasă. Și treceți toate conexiunile prin el.
Am căutat aplicații de tunel ICMP pe Internet, dar niciuna nu a funcționat așa cum mi-am dorit (și anume, am vrut să fie simplu - astfel încât dacă rulez browserul meu preferat sau orice alt program, va funcționa doar cu tunnel) sau cel puțin
părea plăcut la gust.
4. Un pic de codare.
La început nu am plănuit să codific nimic. Tocmai am încercat câteva aplicații de tunel ICMP
cu packetstorm, dar apoi m-am trezit brusc citind sursa unuia dintre ele și îmi dau seama cât de uimitor de simplu este și cât de ușor ar fi să faci așa ceva. Numele programului este itunnel -
un utilitar comun pentru tunelul ICMP. iTunes este uimitor. Dar este doar un tunel. Îl rulezi pe o singură mașină și, în cele din urmă, se pare că ai conectat două
plăcile de rețea împreună. Nu a fost suficient pentru ceea ce am vrut să fac.
Am auzit deja despre modulul kernel TUN/TAP, care permite proceselor utilizatorului să primească și să trimită pachete de informații direct către/de la kernel.
Programul creează o interfață de rețea virtuală.
Acesta creează o interfață de rețea care
functioneaza exact la fel
standard. Cel mai interesant lucru este că
programele utilizator trebuie
acționează ca un strat fizic pentru o interfață
tunel. Ei trebuie să citească pachete de informații din
dispozitiv (de exemplu, „/dev/net/tun0”) și trimiteți-le prin orice mijloc și scrieți pachete de răspuns
înapoi la dosar.
Nu am găsit nicio resursă bună
peste TUN/TAP, dar există un program - vtun - care a folosit TUN/TAP pentru tunelurile sale, așa că am
surse poyuzal vtun. După câteva cercetări, s-a dovedit că există o bibliotecă mică de funcții folosite pentru a crea, a citi și a scrie în tun*
dispozitive. De ce ar trebui să scriu eu însumi programul, dacă se poate remedia câțiva biți?
Codul pe care l-am scris de fapt:
#include „driver.h” /* declara biblioteca vtun */
#include
#include
/* main() ușor modificat din itunnel
*/
int run_icmp_tunnel(int id, int packetsize, char *desthost, int tun_fd);
/* unitate maximă - maxim
dimensiunea pungii încapsulate
*/
const int mtu = 1400;
int main(int argc, char **argv) (
char*dev;
int tun_fd = 0;
/* crearea unui dispozitiv tunel */
dev = (char *) malloc(16);
dacă (dev == NULL) (
printf("Dacă nu ați avut niciodată probleme cu
16 octeți\"
"memoria este prima dată. Fatal.n");
întoarcere 1;
}
dev=0;
/*
funcție de bibliotecă frumoasă
de la vtun acceptă șirul gol ca*
*
argument, creează un dispozitiv tunX și
îl transmite la *dev */
tun_fd = tun_open(dev);
dacă (tun_fd< 1) {
printf("Nu se poate crea dispozitivul. Fatal.n");
întoarcere 1;
}
altfel(
printf("Dispozitiv de tunel creat: %sn", dev);
}
/* 7530 este câmpul ID ICMP,
folosit pentru pachetele din tunel
*/
run_icmp_tunnel(7530, mtu, argv, tun_fd);
tun_close(tun_fd, dev);
}
Aici era. Și cea mai mare parte sunt comentarii și verificarea erorilor
După cum am menționat, itunnel este ideal pentru construirea unui tunel. Are o funcție principală care
deschideți fișiere pentru intrare, ieșire și socket; De asemenea
am primit niște parametri pentru linia de comandă (care ar putea fi utile pentru scopurile mele). Apoi a numit o funcție ușor abstractă care, în esență, doar transporta pachete de informații. Antet ICMP gratuit
descris în cod și poate fi schimbat cu ușurință în orice alt antet,
intrarea/ieșirea/socket-ul poate fi configurat în conformitate cu o altă schemă logică - funcția va funcționa cu ajustări minime.
Cea mai mare schimbare pe care am făcut-o este eliminarea tuturor manipulărilor din linia de comandă - în esență eliminarea câtorva blocuri de cod. Cel mai important pentru logica tunelului, am eliminat distincția dintre intrare și ieșire, deoarece sunt ambele
agățați de același descriptor (dispozitiv tunX) -
mi-a dat ceea ce în loc să mă comport
netcat și trimite stdin la soclul ICMP și soclul ICMP la stdout,
trimite semnalul de ieșire către dispozitivul tunX (sub formă de solicitări http din browser) către ICMP
socket și ieșire socket ICMP (ca și cum HTTP
cererile de la server au fost trimise înapoi
prin tunel) la dispozitivul tunX (la
va reveni la browser). Deoarece ultima propoziție este foarte lungă și complicată, vă ofer o diagramă mică pentru a ilustra:
Pachetele de răspuns de informații urmează aceeași cale, dar
în sens invers.
La un moment dat, am înnebunit suficient de mult încât să scriu de fapt o nouă linie de cod. Ea arata asa:
memcpy(&(target->sin_addr.s_addr), &(from.sin_addr.s_addr), 4);
Funcția sa este de a începe să trimită toate pachetele de informații de unde a venit ultimul pachet. Eu pot
rulează-l pe serverul meu și conectează-te
de oriunde trimite un pachet prin tunel
și schimbă instantaneu IP-ul destinatarului în IP
laptopul meu.
Ce s-a întâmplat ca urmare, puteți lua de aici:
5. Instalarea tunelurilor.
Am testat tunelul acasă și a funcționat bine, dar nu exista firewall acasă. A doua zi, la universitate, eram gata să-l testez în viața reală. Din întâmplare, stând la o masă într-o cafenea, am găsit adresa MAC folosind spoofing și am creat un tunel.
Este greu să-mi amintesc toate modurile stupide pe care le-am încercat și micile experimente pe care le-am făcut, așa că am încercat să fac această parte cât mai organizată. De fapt, nu am făcut totul atât de clar.
Pentru a face totul să funcționeze pentru mine
Mi-a luat 3 ore și am încercat tot ce am putut în timp ce adulmecam oriunde am putut și am modificat codul astfel încât să scaneze „Pachet!” Și așa mai departe.
Am rulat aceste comenzi pe server:
tsee-diees:~# ./create_tun wifi.ttu.ee
Dispozitiv tunel creat: tun0
S-a oprit ./create_tun wifi.ttu.ee
tsee-diees:~# ifconfig tun0 mtu 1400 192.168.3.1 up
tsee-diees:~# route add 192.168.3.2 tun0
tsee-diees:~# tethereal -i eth0 -f "icmp"
M-am gândit că va funcționa imediat și am rulat asta pe laptopul meu:
marktwain:~# ./create_tun 194.204.48.52
Dispozitiv tunel creat: tun0
Oprit ./create_tun 194.204.48.52
marktwain:~# ifconfig tun0 mtu 1400 192.168.3.2 up
marktwain:~# route add 192.168.3.1 tun0
marktwain:~# tethereal -i eth0 -f "icmp"
Ceea ce trebuia să fac era să creez
rețea cu două gazde pe ea - server ca 192.168.3.1 și laptop ca 192.168.3.2. Un simplu LAN normal, doar stratul său fizic va fi un tunel ICMP. Cum faci probabil
înțeles din restul textului din articol
metoda nu a funcționat prea bine. Am rulat un ping ("ping 192.168.3.1"), dar pachetele încă nu au ajuns.
Din fericire, sniffer-ul de pe laptop mi-a dat un mic indiciu - pachetele ICMP erau răspunsuri returnate. Bineînțeles că nu
au fost trimise. Deci omorâm tunelul, activăm itunnel pe laptop și folosim răspunsurile inverse icmp (schimbăm „icmp->type = 0;” în „icmp->type = 8;”), returnăm tunelul.
Sistemul tot nu a funcționat, dar de data aceasta pachetele
a apărut pe sniffer-ul de pe server.
Ce ar putea fi în neregulă? Am încercat o modificare care ar fi trebuit să strige „Pachet!” când a sosit următorul pachet, dar exclamațiile nu au făcut-o.
apărea. "Și de ce, de fapt, ar trebui - am fost surprins - dacă firewall-ul este setat să blocheze toate pachetele ICMP de pe Internet?" După un timp, mi-am dat seama că acesta a fost de fapt cazul (toate pachetele ICMP de pe Internet au fost blocate).
Deja mai bine. Tunelul exclamă „Pachet!” , iar răspunsurile pot fi văzute pe sniffer-ul de pe server. De fapt, există două răspunsuri pentru fiecare cerere, dintre care doar unul poate fi văzut pe snifferul de pe laptop. Și ping-ul încă nu funcționează.
Deoarece unul dintre cele două pachete este redundant, i-am spus nucleului (kernel-ului) să nu răspundă la solicitările inverse icmp:
tsee-diees:~# echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
Și au început să treacă ping-uri! În acest moment, încă mă bazam pe adresa MAC falsificată pentru a avea acces la server. Deoarece ideea a fost de a primi pachete care călătoresc înainte și înapoi de la un utilizator neînregistrat, am încetat să falsific adresele MAC. În același timp, tunelul a continuat să funcționeze, ceea ce a fost o surpriză destul de plăcută.
Fluxul de pachete a fost stabilit și era timpul să facă „Internetul” să funcționeze.
A trebuit să fac câteva modificări la IP
rutare pe un laptop. drum prin
routerul wireless al universității ar fi trebuit înlocuit cu adresa de tunel a serverului (192.168.3.1 în acest caz). Mai trebuie să existe o cale către server, astfel încât tunelul în sine să poată funcționa (pachetele de tunel ICMP au nevoie și de o cale de urmat).
Am obtinut niste rezultate destul de bune:
marktwain:~# route add 194.204.48.52 gw 10.0.0.111 # prin routerul wireless
marktwain:~# route del default
marktwain:~# route add default gw 192.168.3.1 # totul altceva prin tunel.
Și, din moment ce sunt cam deștept, m-am gândit că ar putea exista o nepotrivire între
numărul de pachete trimise către și de la server. Am început să pun ping
în fundal pentru a urmări situația:.
marktwain:~# ping 194.204.48.52 -i 0.2
PING 194.204.48.52 (194.204.48.52) 56(84) octeți de date.
Desigur, nu au existat răspunsuri, deoarece acestea nu erau „ping-uri de tunel”, iar răspunsurile din nucleu erau
oprit.
Din moment ce serverul meu a fost deja predat
pentru a partaja o conexiune la Internet între mai multe computere, tot ce trebuia să fac pe server era să adaug două reguli pt
Lanț FORWARD în iptables pentru a accepta pachete de la și către tun0. Când am verificat în mod obișnuit regulile actuale ("iptables -vL FORWARD"), conexiunea a încetat brusc. M-am reconectat și am cercetat această întrebare,
dar în curând legătura a murit din nou. Am fost cu adevărat surprins - de ce este conexiunea atât de instabilă?
Reflectând, mi-am dat seama că de fiecare dată serverul a trimis un răspuns ICMP mare
(la urma urmei, doar antetul ping a fost 1400+), a fost aruncat
echipamentul în sine. Din moment ce tunelul era fizic
Stratul IP, TCP a încercat în mod natural să trimită pachete din nou, dar dimensiunea a fost încă aceeași și au fost încă aruncate. Așa că am schimbat MTU pentru tunel la 300 (in
în general vorbind întâmplător)
marktwain:~# ifconfig tun0 mtu 300
tsee-diees:~# ifconfig tun0 mtu 300
Și întregul sistem a funcționat.
6. Concluzie.
Acum fă-o singur.
canale ascunse este una dintre metodele de disimulare a acțiunilor sau de implementare a atacurilor, care este folosită pentru transmiterea secretă, neautorizată sau ilegală de informații. Cu ajutorul canalelor secrete, informațiile pot fi scurse sau, dimpotrivă, introducerea de informații în organizație. Un canal ascuns pe Internet poate fi comparat cu un compartiment secret dintr-o servietă, în care un atacator poate încerca să ascundă documente secrete pentru a le introduce ilegal prin poarta unei unități securizate. Pe Internet, canalele ascunse pot fi folosite de intruși pentru a transmite materiale secrete fără a fi observate - în acest caz, mecanismele de securitate a rețelei acționează ca un obiect de securitate de trecere. Așa cum un spion poate ascunde armele în același compartiment secret pentru a le ascunde de securitate și pătrunde odată cu el către un obiect, pe Internet, atacatorii pot folosi canale ascunse pentru a transfera în secret arme cibernetice, de exemplu, pentru a descărca malware de pe un server extern pe o gazdă din rețeaua privată a unei organizații.
Bazele canalelor secrete de pe Internet
Canalele ascunse de pe Internet se pot baza pe utilizarea netradițională a protocoalelor de Internet familiare. Punctele finale ale unui singur canal - computerul infectat și centrul de comandă al atacatorului - trebuie să utilizeze software special pentru a ataca sau a ascunde acțiuni care pot recunoaște și procesa astfel de trucuri neconvenționale. Un astfel de software poate fi instalat de către utilizator însuși sau de malware, sau de către atacatori folosind instrumente de administrare la distanță (RAT). Canalele de internet secrete sunt diferite de tunelurile criptate. Informațiile despre ele pot fi transmise într-o formă necriptată (deseori acest lucru se întâmplă), dar aceste canale în sine sunt ascunse de cei din afară. În acest caz, nu este nevoie să folosiți chei de criptare sau criptografice, totuși, uneori, canalele ascunse folosesc în continuare diverse metode de criptare sau ofuscare a datelor.
Să ne uităm la două exemple. Prima tehnică este de a transmite în secret informații, câte un caracter, în câmpul de identificare (ID) al unui antet de pachet de protocol Internet (IP). În implementările comune ale acestei tehnici, codurile de caractere ASCII sunt înmulțite cu 256 pentru a crea valori de 16 biți care sunt înlocuite în câmpul de identificare. Pentru a trimite abrevierea, ICANN ar trebui să trimită 5 pachete IP cu următoarele valori ale câmpului de identificare:
| Punga de plastic | Valoare zecimală ASCII | ID pachet IP (x256) |
| 1 | 71 ("I") | 18176 |
| 2 | 67 ("C") | 17152 |
| 3 | 65 ("A") | 16640 |
| 4 | 78 ("N") | 19968 |
| 5 | 78 ("N") | 19968 |
Calculatorul receptor decodifică valoarea câmpului ID al pachetului IP împărțind valoarea primită la 256. Transmiterea unor astfel de valori nu ridică nicio suspiciune și, deoarece protocolul IP permite transmiterea de pachete duplicate, este puțin probabil că un astfel de trafic va fi detectat. Viteza mică este compensată de secretul transmisiei.
A doua tehnică pentru crearea unui canal secret implică utilizarea unei încărcături utile de protocol, adică informații tehnice transmise în cadrul protocolului selectat. În acest caz, datele sunt adăugate la solicitările și răspunsurile ECHO - acestea sunt mesaje de serviciu care sunt utilizate în Protocolul de mesaje de control al Internetului sau ICMP. Mesajele ECHO sunt utilizate într-un serviciu comun ping. Administratorii de rețea folosesc adesea serviciul ping pentru a verifica dacă o anumită gazdă la distanță este accesibilă, astfel încât traficul de pachete ICMP ECHO este de obicei permis prin instrumente de securitate a rețelei, cum ar fi firewall-urile.
Dacă sunteți interesat să aflați mai multe despre aceste tehnici, consultați următoarele articole: (Întrebări și răspunsuri despre canalele secrete) și Canalele secrete prin ICMP (PDF, 740 KB).
Mai departe. Canale ascunse DNS
Protocolul Domain Name System (DNS) are o serie de caracteristici care fac convenabil utilizarea canalelor ascunse. Traficul DNS este trecut prin firewall-uri în ambele direcții. Pericolul utilizării DNS pentru a crea canale ascunse este adesea trecut cu vederea sau subestimat, astfel încât organizațiile sau ISP-urile nu verifică întotdeauna traficul DNS pentru semne de atac. Uneori, traficul DNS este transmis către internetul mai larg pentru a rezolva numele înainte ca funcțiile de autorizare sau autentificare ale utilizatorilor să fie efectuate, permițând canalelor ascunse DNS să ocolească astfel de controale de acces.
În următoarea noastră postare, vom explora modul în care canalele secrete DNS pot fi folosite pentru a extrage date, a ocoli controalele de acces sau a descărca programe malware.