Scopul paravanului de protecție este să permită administratorului-utilizator să restricționeze anumite trafic de rețea, astfel încât fiecare regulă firewall specifică un anumit tip de pachet de rețea care nu va fi trimis prin rețea. A fost posibil să se precizeze o serie de motive, dar acest lucru depășește deja domeniul de aplicare al acestui articol. Cu toate acestea, voi descrie în detaliu situația dificilă în care am făcut-o și sper că alți utilizatori vor găsi ceva util în această descriere. Sper că acest scenariu și diferitele moduri în care se utilizează funcționalitatea firewall-ului vor servi ca exemplu prin care cititorul va putea deduce soluții pentru propriile nevoi.
avertisment:
La configurarea firewall-ului există un anumit nivel de pericol. Puteți defini din greșeală o regulă de firewall care va face transmițătorul indisponibil, iar paravanul de protecție vă va cere să mergeți la acest emițător și este posibil să fie nevoie să resetați setările doar pentru a vă redobândi accesul. Verificați întotdeauna că, indiferent de firewall-ul pe care vi l-ați oferit, înainte de a le aplica în practică. Luați măsuri de precauție: nu uitați să faceți o copie de siguranță a configurației înainte de a schimba paravanul de protecție și să fiți pregătit pentru cel mai rău caz.
Pentru utilizarea simplă, documentele firewall standard sunt destul de simple și oferă o înțelegere clară a funcționării lor. Interfața web în configurarea firewall-ului este destul de simplă. Iar câteva dificultăți sunt descrise mai jos.
Firmware v5.6.2 AirMax (.bin)
Detalii importante despre paravanul de protecție au scăzut în Documentele AirOS
AirOS firewall pentru documente nu arată că ar trebui să fie specificate părți «MASCA» CIDR, de exemplu, 192.168.1.0/24 (în contrast cu punctata-quad 192.168.1.0/255.255.255.0. Folosit versiunile anterioare AirOS.) Atunci când sursa sau destinația se referă la (și nu la rețea), trebuie să selectați masca CIDR corectă, care este egală cu cea a gazdei / 32. Dacă faceți o greșeală, interfața va lua valoarea, dar va avea nici un efect, traficul nu va fi blocat.
Există exemple când s-au aplicat cele mai simple setări? Dacă rețelele au fost create, schimbate, întreținute, răspunsul este "mic", există întotdeauna un amestec de subrețele, fiecare cu conexiuni diferite și cerințe de securitate. Dau un exemplu de rețea (de fapt existentă):
Exemplu de descriere a rețelei
DOCSIS 2.0 modem de cablu (8 MB / s primi de ieșire 2 Mb / s) Belkin router se conectează la Internet. Unul dintre portul de Internet (cablu) conectează Bullet2HP (AP WDS / modul router) la o rețea LAN / intranet (și, prin urmare, la Internet prin NAT.) O altă (stație WDS / punte) Bullet2HP 3 mile distanță, este conectat prin o rețea wireless la primul - o conexiune cu două sensuri „de lungă rază de acțiune“ conexiune prin intermediul rețelei de transport. port de emițător la Internet în modul de pod se conectează celălalt Bullet2 (modul AP / router) și se conectează wireless la al treilea Bullet2. există și alți emițători CPE, cu moduri diferite. (A se vedea figura.)
Înainte de a descrie cum și unde să aplice cerințele de mai sus, este important de remarcat faptul că există următorul fenomen: poate că v-ați întâlnit documente sau rapoarte că funcționarea firewall-ul este imposibil de transmițătoare care funcționează în modul de pod. Deși a fost prezentă în versiunile anterioare ale AirOS. Nu sunt sigur ce este acum. reguli de firewall pot fi utilizate în modul de pod pentru a preveni trimiterea de trafic prin ea, acesta va fi folosit numai traficul care trece prin pod (aceasta înseamnă că traficul va trece doar ceea ce este destinat pentru aceeași subrețea).
Cerința nr. 2
Această cerință se aplică stației / podului WDS prin regula firewall:
Acest trafic blochează regulă de la orice gazdă, alta decât 192.168.4.1 de rețea 192.168.4.0/24 AP router, prevenind astfel orice penetrare a rețelei 192.168.5.0/24 (care determină 192.168.4.10 ca o poarta de acces).
Cerința nr. 3
Această cerință se aplică ruterului punctului de acces prin regula firewall:
Această regulă împiedică transmiterea traficului ICMP de către un anumit router (care trebuie să aibă o statică IP) către gazde în rețea. Router-ul a trimis ICMP gazdei pentru redirecționări către alte gazde, deoarece au crezut greșit că sunt mai aproape de Internet decât de poarta sa. Aceste cadre false erau enervante și distrugătoare pentru alți gazde; această regulă obligă aceste cadre să fie șterse. Această regulă poate să fi fost executată pe CPE a abonatului, însă a lăsat gazdele în rețea în imposibilitatea de a verifica conexiunea la punctul de acces / router (acest lucru poate fi necesar în mod neașteptat în orice moment pentru depanare).
Cerința nr. 4
Această cerință poate fi setată numai pentru fiecare CPE conectat. Blochează traficul ARP între host-urile conectate ale router-ului punctului de acces. Transmisiile ARP care apar în rețeaua de abonați sunt aproape inutile în cel mai bun caz și sunt teoretic distructive în cel mai rău caz:
Această regulă împiedică transmiterea ARP de la ruterul punctului de acces de la intersecția cu podul CPE. Acest lucru nu afectează traficul AR P între gazde în rețeaua abonatului, afectează numai traficul care traversează podul.
Rețineți că această cerință poate fi aplicată forțând CPE să utilizeze modul router. Suprapunerea stratului NAT pare excesivă, deci sunt permise punțile CPE, atâta timp cât transmisiile ARP care apar în spatele lor sunt stocate acolo.
În plus, nimic nu va proteja împotriva desemnării unei reguli care va face transmițătorul inaccesibil. O dată am găsit accidental o regulă în AP / WDS router cu 192.168.4.0/24 identificat ca sursă și destinație! Acest lucru a condus la imposibilitatea comunicării cu transmițătorul prin 192.168.4.1 IP (și dezactiva conexiunea între acesta și stația / WDS pod.) Eroarea m-ar fi costat o excursie la transmițător, dar din fericire am fost în stare să ajungă la el printr-un alt 192.168.1.10 IP.
Trimiteți-le prietenilor: