Interziceți traficul icmp către VPN-ul dvs. Cisco ACL pentru avansat. Liste de acces extinse. Resetați sau permiteți traficul de la anumite adrese MAC
Deci, să continuăm să ne ocupăm de ACL-uri. De data aceasta, avem ACL-uri extinse. Vom lua topologia din articolul anterior, sper că ați studiat-o temeinic. Dacă nu este cazul, atunci vă recomand cu căldură să o citiți, astfel încât materialele din acest articol să fie mai înțelese.
În primul rând, voi începe cu ce sunt ACL-urile extinse. ACL-urile extinse vă permit să specificați protocolul, adresa de destinație și porturile în plus față de adresa sursă. Precum și parametri speciali ai unui anumit protocol. Cel mai bine este să înveți din exemple, așa că haideți să creăm o nouă sarcină, complicând-o pe cea anterioară. Apropo, cineva ar putea fi interesat să se ocupe de problemele distribuției traficului în funcție de prioritate după aceasta, recomand Clasificarea și Marcarea QoS bun articol, deși în engleză. Ei bine, deocamdată, să revenim la sarcina noastră:
Sarcină.
- Permiteți cereri de ecou de la gazdele din rețeaua 192.168.0.0/24 către server.
- De la server – interziceți cererile de eco către rețeaua internă.
- Permite accesul WEB la server de la nodul 192.168.0.11.
- Permite accesul FTP de la gazda 192.168.0.13 la server.
Sarcină complexă. De asemenea, o vom rezolva cuprinzător. În primul rând, mă voi uita la sintaxa pentru utilizarea unui ACL extins.
Opțiuni ACL extinse
<номер от 100 до 199> <действие permit, deny> <протокол> <источник> <порт> <назначение> <порт> <опции>
Numerele de port sunt indicate numai pentru protocoalele TCP/UDP, desigur. Pot exista și prefixe echivalentul(numărul portului egal cu cel specificat), gt/lt(numărul portului este mai mare/mai mic decât cel specificat), neq(numărul portului nu este egal cu cel specificat), gamă(gamă de porturi).
ACL-uri denumite
Apropo, listele de acces nu pot fi doar numerotate, ci și denumite! Poate că această metodă ți se va părea mai convenabilă. De data asta vom face exact asta. Aceste comenzi sunt executate în contextul configurației globale, iar sintaxa este:
Router(config)#ip lista de acces extinsă<имя>
Deci, să începem să formăm regulile.
- Permiterea ping-urilor din rețea 192.168.0.0/24
la server. Asa de, ecou-cererile sunt un protocol ICMP, vom selecta subrețeaua noastră ca adresă sursă, adresa serverului ca adresă de destinație, tipul mesajului – pe interfața de intrare ecou, la iesire - ecou-răspuns. Router(config)#ip access-list extins INT_IN Router(config-ext-nacl)#permit icmp 192.168.0.0 0.0.0.255 gazdă 10.0.0.100 echo Hopa, ce este în neregulă cu masca de subrețea? Da, acesta este un truc ACL. Așa-zisul WildCard-masca. Se calculează ca masca inversă față de cea obișnuită. Acestea. 255.255.255.255
- Mască de rețea. În cazul nostru, subrețeaua 255.255.255.0
, după scădere ceea ce rămâne este just 0.0.0.255
.Cred că această regulă nu are nevoie de explicații? Protocol icmp, adresa sursă – subrețea 192.168.0.0/24
, adresa de destinatie – gazdă 10.0.0.100, tipul mesajului – ecou(cerere). Apropo, este ușor de observat asta gazdă 10.0.0.100 echivalent 10.0.0.100 0.0.0.0
.Aplicam aceasta regula la interfata. Router(config)#int fa0/0
Router(config-if)#ip acces-grup INT_IN în Ei bine, ceva de genul acesta. Acum, dacă verificați ping-urile, este ușor să vedeți că totul funcționează bine. Aici, însă, ne așteaptă o surpriză, care va apărea puțin mai târziu. Nu o voi dezvălui încă. Cine a ghicit - bravo! - De pe server – interzicem toate cererile de eco către rețeaua internă (192.168.0.0/24). Definim o nouă listă denumită, INT_OUT, și o atașăm la interfața cea mai apropiată de server.
Router(config)#ip access-list extins INT_OUT
Router(config-ext-nacl)#deny icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo
Router(config-ext-nacl)#exit
Router(config)#int fa0/1
Router(config-if)#ip acces-grup INT_OUT în
Lasă-mă să explic ce am făcut. A creat o listă de acces extinsă cu numele INT_OUT, dezactivând protocolul din ea icmp cu tip ecou de la gazdă 10.0.0.100 pe subrețea 192.168.0.0/24 și aplicat la intrarea interfeței fa0/1, adică cel mai apropiat de server. Încercăm să trimitem ping de pe server.
SERVER>ping 192.168.0.11
Ping 192.168.0.11 cu 32 de octeți de date:
Răspuns de la 10.0.0.1: Gazda destinație inaccesibilă.
Răspuns de la 10.0.0.1: Gazda destinație inaccesibilă.
Răspuns de la 10.0.0.1: Gazda destinație inaccesibilă.
Statistici ping pentru 192.168.0.11:
Pachete: trimise = 4, primite = 0, pierdute = 4 (pierdere de 100%)
Ei bine, părea să funcționeze așa cum ar trebui. Pentru cei care nu știu să trimită ping-uri, faceți clic pe nodul care ne interesează, de exemplu, un server. Du-te la fila Desktop, acolo Command Prompt. Și acum, gluma promisă. Încercați să trimiteți un ping de la gazdă, ca în primul punct. PC>ping 10.0.0.100
Ping 10.0.0.100 cu 32 de octeți de date:
Cererea a expirat.
Cererea a expirat.
Cererea a expirat.
Cererea a expirat.Iată una pentru tine. Totul a funcționat! De ce s-a oprit? Aceasta este surpriza promisă. Vă explic care este problema. Da, prima regulă nu a dispărut. Permite trimiterea unei cereri de ecou către nodul serverului. Dar unde este permisiunea de a transmite răspunsuri eco? El a plecat! Trimitem o cerere, dar nu putem accepta un răspuns! De ce a funcționat totul înainte? Pe atunci nu aveam un ACL pe interfață. fa0/1. Și din moment ce nu există ACL, atunci totul este permis. Va trebui să creați o regulă pentru a permite primirea răspunsurilor icmp.
Adăugați la lista INT_OUT
Să adăugăm același lucru la lista INT_IN.
Router(config-ext-nacl)#permit icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo-reply
Acum nu te plânge. Totul merge grozav!
- Permitem accesul WEB la server din nodul *.11.Procedam la fel! Aici, totuși, trebuie să știți puțin despre cum apar apelurile prin protocoale de nivel 4 (TCP, UDP). Portul client este selectat în mod arbitrar > 1024, iar portul serverului este selectat corespunzător serviciului. Pentru WEB, acesta este portul 80 (protocol http).Ce zici de serverul WEB? În mod implicit, serviciul WEB este deja instalat pe server, îl puteți vedea în setările nodului. Asigurați-vă că există o bifă. Și vă puteți conecta la server selectând comanda rapidă „Web Browser” de pe „Desktop” al oricărui nod. Desigur, nu va exista acces acum. Pentru că avem ACL-uri pe interfețele routerului și nu au nicio regulă de permisiuni pentru acces. Ei bine, să creăm o listă de acces INT_IN (care se află pe interfață fa0/0) adăugați regula: Router(config-ext-nacl)#permit tcp host 192.168.0.11 gt 1024 host 10.0.0.100 eq 80 Adică, permitem protocolul TCP de la gazda noastră (port arbitrar, > 1024) la adresa serverului , port HTTP.
Și, desigur, regula opusă este în lista INT_OUT (care se află pe interfață fa0/1):
Router(config-ext-nacl)#permit tcp host 10.0.0.100 eq 80 host 192.168.0.11 stabilit
Adică permitem TCP din port 80 servere pe gazdă *.11 , iar conexiunea ar trebui să fie deja stabilită! Poate in schimb stabilit indica la fel GT 1024, va funcționa la fel de bine. Dar sensul este puțin diferit.
Raspunde in comentarii ce ar fi mai sigur?
- Permitem accesul FTP de la nodul *.13 la server. Nici absolut nimic complicat! Să ne uităm la modul în care interacțiunea are loc prin protocol FTP. În viitor, intenționez să dedic o serie întreagă de articole lucrării diferitelor protocoale, deoarece acest lucru este foarte util în crearea unor reguli ACL precise (lunetist). Ei bine, deocamdată: Acțiuni server și client:+ Clientul încearcă să stabilească o conexiune și trimite un pachet (care conține o indicație că va funcționa în modul pasiv) către portul 21 al serverului de la portul său X (X > 1024, portul liber) + Serverul trimite un răspuns și raportează numărul portului său pentru a forma un canal de date Y (Y > 1024) către portul client X, extras din antetul pachetului TCP.+ Clientul inițiază o comunicare pentru a transfera date pe portul X+1 către portul server Y (luat din antet). a tranzacției anterioare). Ceva de genul. Sună puțin complicat, dar trebuie doar să-ți dai seama! Adăugați regulile în lista INT_IN:
permis gazdă tcp 192.168.0.13 gt 1024 gazdă 10.0.0.100 eq 21
permis gazdă tcp 192.168.0.13 gt 1024 gazdă 10.0.0.100 gt 1024Și adăugați reguli la lista INT_OUT:
permite gazdă tcp 10.0.0.100 eq gazdă ftp 192.168.0.13 gt 1024
permis gazdă tcp 10.0.0.100 gt 1024 gazdă 192.168.0.13 gt 1024Verificare de la Linie de comanda, echipa ftp 10.0.0.100, unde ne conectăm folosind datele noastre de autentificare cisco:cisco(luat din setările serverului), introduceți comanda acolo dir si vom vedea ca datele, precum si comenzile, sunt transmise cu succes.
Cam atât se referă la listele de acces extinse.
Deci, să ne uităm la regulile noastre:
Acces la router#sh
Lista de acces IP extinsă INT_IN
permis icmp 192.168.0.0 0.0.0.255 gazdă 10.0.0.100 echo (17 meci(e))
permis gazdă icmp 10.0.0.100 192.168.0.0 0.0.0.255 echo-reply
permis gazdă tcp 192.168.0.11 gt 1024 gazdă 10.0.0.100 eq www (36 meci(e))
permis gazdă tcp 192.168.0.13 gt 1024 gazdă 10.0.0.100 eq ftp (40 potrivire(e))
permis gazdă tcp 192.168.0.13 gt 1024 gazdă 10.0.0.100 gt 1024 (4 meci(e))
Lista de acces IP extinsă INT_OUT
deny icmp host 10.0.0.100 192.168.0.0 0.0.0.255 echo (4 meci(e))
permis gazdă icmp 10.0.0.100 192.168.0.0 0.0.0.255 echo-reply (4 potrivire(e))
permis gazdă tcp 10.0.0.100 eq www gazdă 192.168.0.11 stabilită (3 potriviri)
permis gazdă tcp 10.0.0.100 eq gazdă ftp 192.168.0.13 gt 1024 (16 potriviri)
permis gazdă tcp 10.0.0.100 gt 1024 gazdă 192.168.0.13 gt 1024 (3 meci(e))
Utilizatorii sunt adesea enervați de încetineala internetului. Acest lucru se aplică în special armatei mari de amatori jocuri de rețea. Puteți reduce potențialele întârzieri dezactivând funcția ping.
Vei avea nevoie
- - PC cu sistem de operare Windows instalat;
- - Acces la internet.
Instrucțiuni
Instrucțiuni
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 ICMP (Internet Control Message Protocol) este un risc de securitate și, prin urmare, ar trebui să fie întotdeauna blocat. Este adevărat că protocolul are unele probleme de securitate asociate și că unele solicitări ar trebui blocate. Dar acesta nu este un 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 operatiune adecvata retelelor. Mai jos sunt câteva părți importante ale protocolului ICMP despre care ar trebui să le cunoașteți. Ar trebui să luați în considerare cum să le direcționați cel mai bine prin rețeaua dvs.
Solicitare eco și răspuns eco
IPv4 – Cerere ecou (Tip8, Code0) și răspuns ecou (Tip0, Code0)
IPv6 – Solicitare ecou (Tip128, Code0) și răspuns ecou (Tip129, Code0)
Ș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., aceasta înseamnă că gazda dvs. este acum descoperită, dar a dvs. nu ascultă deja pe portul 80 și trimite răspunsuri la solicitările clientului? Desigur, blocați și aceste solicitări dacă doriți cu adevărat DMZ-ul dvs. la marginea rețelei. Dar blocând traficul ICMP în rețeaua dvs., nu vă veți consolida securitatea; dimpotrivă, veți ajunge la un sistem cu un proces de depanare inutil de complex („Vă rugăm să verificați dacă gateway-ul răspunde la solicitările rețelei?”, „Nu, dar asta nu mă supără deloc, că nu-mi pasă.” nu va spune nimic!”).
Amintiți-vă, puteți, de asemenea, să permiteți cererilor să meargă într-o anumită direcție; de exemplu, configurați echipamentul astfel încât solicitările 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 Protocolul 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 comunicații dintre cele două destinații. Dacă de-a lungul traseului pachetelor există un nod cu o unitate de transmisie maximă mai mică decât expeditorul sau destinatarul și nu au mijloacele pentru a detecta această coliziune, atunci traficul va fi eliminat în liniște. Și nu veți înțelege ce se întâmplă cu canalul de comunicare; cu alte cuvinte, „vor veni zile vesele pentru tine”.
Nu fragmentați – ICMP nu va trece!
Transmiterea pachetelor IPv4 cu setul de biți Don't Fragment (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 fi transmise prin interfață va determina routerul să renunțe la pachet. și generați răspuns la sursa de transmisie cu următoarele erori ICMP: Fragmentare necesară ( Fragmentarea necesară), sau Pachet prea mare ( Pachetul de asemenea Mare). Dacă răspunsurile cu aceste erori nu pot fi returnate expeditorului, atunci acesta va interpreta absența răspunsurilor de confirmare cu privire la livrarea pachetelor ACK ( Confirmare) de la receptor ca congestie/pierdere și sursa de retransmitere a pachetelor care vor fi, de asemenea, aruncate.
Este dificil să identifici cauza unei astfel de probleme și să o rezolvi 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 transferului nu primi mesaje de eroare.
Explorarea căii de livrare a pachetelor
RFC 4821 a fost conceput pentru a ajuta participanții la traficul de rețea să rezolve această problemă utilizând sondarea căilor de pachete (Descoperire MTU cale (PLPMTUD). Standardul vă permite să detectați cantitatea maximă de date (Unitate de transmisie maximă (MTU), care poate fi transmis prin 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 unui pachet fără a-l fragmenta pe traseul de la emițător la receptor. Această funcționalitate reduce dependența de primirea în timp util a răspunsurilor de eroare prin Internet Control Message Protocol (ICMP) și este disponibilă în majoritatea stack-urilor de dispozitive de rețea și a sistemelor de operare client.Din păcate, nu este la fel de eficientă ca obținerea directă a datelor despre dimensiunea maximă posibilă. a pachetelor transmise. Vă rugăm să permiteți acestor mesaje ICMP să revină la sursa de transmisie, bine?
Timpul de transmisie a pachetului a fost depășit
IPv4 – (Tip11, Cod0)
IPv6 – (Tip3, Cod0)
Traceroute este un instrument foarte util pentru depanare conexiuni de reteaî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 și-a depășit timpul de viață. Apoi trimite un pachet cu TTL 2 și așa mai departe. Această procedură este necesară pentru a detecta fiecare nod de-a lungul căii pachetului.
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 Layer 2 și Layer 3 model de rețea OSI, IPv6 adoptă 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. În plus față de 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 unui control mai granular).
Aceste cinci tipuri de mesaje ICMP nu trebuie blocate în rețeaua dumneavoastră (ignorând perimetrul exterior) pentru ca protocolul de transfer de date IP să funcționeze corect.
Numerotarea tipului ICMP
Internet Control Message Protocol (ICMP) conține multe mesaje care sunt identificate prin câmpul „tip”.
Tip | Nume | Specificație |
---|---|---|
0 | Echo Răspuns | |
1 | Nealocat | |
2 | Nealocat | |
3 | Destinație indisponibilă | |
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 | Adresă Mască răspuns (î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 | Solicitare Echo extinsă | |
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 limitele de viteză
În timp ce mesajele ICMP precum cele descrise în acest articol pot fi foarte utile, rețineți că generarea tuturor acestor mesaje ocupă 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. Limită debitului rețele 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, cercetați și înțelegeți
Având în vedere că discutarea subiectului „a bloca sau a nu bloca” pachetele ICMP duce întotdeauna la confuzie, dispute și dezacorduri, vă sugerez să continuați să studiați acest subiect pe cont propriu. Am oferit multe link-uri pe această pagină; cred că pentru o înțelegere mai completă a problemelor, ar trebui să petreceți timp citindu-le. Și faceți alegeri informate cu privire la ceea ce funcționează cel mai bine pentru rețeaua dvs.
MikroTik: unde să faceți clic pentru a-l face să funcționeze?
Pentru toate avantajele sale, produsele MikroTik au un dezavantaj - există o mulțime de informații dispersate și nu întotdeauna de încredere despre configurația sa. Vă recomandăm o sursă de încredere în limba rusă, unde totul este adunat, logic și structurat - curs video „ Configurarea echipamentului MikroTik" Cursul include 162 de lecții video, 45 de lucrări de laborator, întrebări și note de autotest. 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.
Un firewall este prima linie de apărare pentru orice server și împotriva acestuia setări corecte depinde dacă atacatorul poate avansa mai mult în încercările sale de a pătrunde în sistem. Fireware-ul modern oferă multe mecanisme de securitate, cu ajutorul cărora puteți ține 99% dintre atacatori în afara buclei. Și toate acestea fără a fi nevoie să achiziționați echipamente scumpe și software comercial.
Scopul principal al tuturor hackerilor este să obțină acces la interpretul de comandă al serverului pentru a-și folosi capacitățile în avantajul lor. Cel mai adesea, pătrunderea în „sfântul sfintelor” se realizează folosind găuri în servicii sau prin ghicirea parolei (forță brută) la unul dintre ele (de exemplu, ssh).
Scanare porturi
Pentru a identifica prezența serviciilor vulnerabile pe o mașină, atacatorul efectuează recunoaștere folosind un scanner de porturi și diverse sisteme de detectare a vulnerabilităților. De obicei, nmap este folosit ca scanner de porturi, care este capabil să scaneze zeci de în diverse moduri iar în unele cazuri poate detecta versiuni și servicii ale sistemului de operare. Iată o listă cu steaguri nmap deosebit de populare care sunt utilizate în mod obișnuit de atacatori:
Steaguri Nmap utilizate în timpul scanării
- -sT - scanare TCP normală prin deschiderea unei conexiuni la portul specificat și terminarea acesteia;
- -sS - SYN/ACK scan, conexiunea este întreruptă imediat după răspuns la cererea de deschidere a conexiunii;
- -sU - scanare UDP;
- -sF - scanare în pachete cu flag-ul FIN setat;
- -sX - scanare cu pachete cu steagurile FIN, PSH și URG setate;
- -sN - scanează în pachete fără steaguri setate.
Metoda anti-scanare este simplă și cunoscută oricărui administrator de sistem. Constă în simpla închidere a tuturor serviciilor care nu ar trebui să fie vizibile din rețeaua externă. De exemplu, dacă mașina rulează servicii ssh, samba și apache și numai un server web cu o pagină web corporativă ar trebui să fie vizibil din lumea exterioară, atunci firewall-ul poate fi configurat astfel:
Configurarea inițială a iptables
outif="eth1"
iptables -F
iptables -i $outif -A INTRARE \
-m conttrack\
--ctstate ESTABLISHED,RELATED \
-j ACCEPT
iptables -i $outif -A INTRARE -p tcp \
--dport 80 -j ACCEPT
iptables -i $outif -P INPUT DROP
iptables -i $outif -P IEȘIRE ACCEPT
Configurare inițială ipfw
outif="rl0"
ipfw add allow ip from any to any \
prin lo0
ipfw adauga permite ip de la mine la orice \
prin $outif
ipfw add permit tcp de la oricare pentru mine \
stabilit prin $outif
ipfw add allow tcp din orice 80 \
la mine prin $outif
ipfw adăugați deny ip de la orice la orice \
prin $outif
Configurarea pf inițială
outif="rl0"
setați skip pe lo0
blocheaza tot
leși pe $outif de la $outif \
la orice stat de păstrare
transmiteți $outif proto de la orice \
la portul $outif 80
Toate cele trei seturi de reguli fac același lucru - permit oricărui trafic să treacă prin interfața de loopback, permit acceptarea pachetelor de la conexiuni deja stabilite (deci, de exemplu, browserul poate primi un răspuns la o solicitare către server la distanta), permiteți apeluri către portul 80, blocând toate celelalte și permiteți orice conexiuni către exterior. Vă rugăm să rețineți că, dacă în exemplele iptables și ipfw am stabilit în mod explicit reguli care să permită recepția de pachete de la conexiuni deja stabilite, atunci în cazul pf a fost suficient să specificați „starea de păstrare” în setul de reguli, permițând orice conexiuni de ieșire.
În general, această schemă de protecție a serviciilor de rețea de scanare și intruziune funcționează excelent, dar putem merge mai departe și putem configura firewall-ul astfel încât unele tipuri de scanare să nu poată fi efectuate deloc. Din punct de vedere tehnic, nu putem face acest lucru pentru scanările obișnuite (nmap flags „-sT”, „-sS” și „-sU”) pur și simplu pentru că nu este nimic criminal, ci tipuri de scanare non-standard precum „-sN” „-sF „ și „-sX” generează pachete care nu ar fi putut fi create de aplicații legitime.
Prin urmare, fără nicio umbră de îndoială, respingem astfel de conexiuni.
Metode de combatere a tipurilor exotice de scanare
# Dezactivează scanarea FIN
Linux> iptables -A INPUT –p tcp\
–m tcp\
--tcp-flags FIN,ACK FIN -j DROP
FreeBSD>
nu stabilit tcpflags fin
# Dezactivează scanarea X
Linux>
--tcp-flags FIN,SYN,RST,PSH,ACK,URG
FIN,SYN,RST,PSH,ACK,URG\
–j DROP
FreeBSD> ipfw adaugă respinge tcp de la orice la orice \
tcpflags fin, syn, rst, psh, ack, urg
# Dezactivează N-scan
Linux> iptables -A INPUT –p tcp –m tcp\
--tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE –j DROP
FreeBSD> ipfw adaugă respinge tcp de la orice la orice \
tcpflags !fin, !syn, !rst, !psh, !ack, !urg
În OpenBSD, toate aceste linii pot fi înlocuite cu o simplă intrare la început
/etc/pf.conf:
freacă în toate
Directiva scrub permite un mecanism de normalizare a pachetelor în care pachetele fragmentate sunt reunite și pachetele cu combinații de semnalizare invalide sunt aruncate. Pe lângă tipurile exotice de scanare, scrub vă permite, de asemenea, să vă protejați de sistemele de detectare a intruziunilor înșelătoare (trimiterea de pachete foarte fragmentate) și de unele tipuri de atacuri DoS.
Pentru a ne proteja împotriva scanărilor SYN/ACK inițiate folosind steag-ul nmap „-sS”, putem folosi metoda de amprentă a sistemului de operare pasiv disponibilă în firewall-urile pf și iptables/netfilter (începând cu versiunea 1.4.6). În timpul unei scanări obișnuite (steagul „-sT”), nmap folosește interfața standard de socket a sistemului de operare, astfel încât o astfel de scanare nu este aproape deloc diferită de un flux de pachete obișnuite (ne vom uita la unele dintre diferențele sale mai jos), totuși , în timpul scanării SYN/ACK, nmap generează pachetele ei înșiși, deci au unele caracteristici care le dezvăluie sursa. Metoda de detectare a sistemului de operare pasiv vă permite să identificați aceste pachete și să le eliminați folosind regulile standard de firewall:
OpenBSD> blocați rapid din orice sistem NMAP
Linux> iptables -I INPUT -p tcp -m osf --gen NMAP \
-j CĂDARE
Modulul osf iptables/netfilter firewall folosește o bază de date de amprente compilată și actualizată de dezvoltatorii OpenBSD (/etc/pf.os), așa că ambele reguli ar trebui să producă aceleași rezultate. De asemenea, este interesant că pot contracara eficient funcția de detectare a sistemului de operare a utilitarului nmap (steagul „-O”).
Acum suntem protejați de aproape toate tipurile de scanare, cu excepția standardului și stupidului „-sT”. Ce să faci cu el? Este de fapt simplu. Faptul de scanare porturi este ușor de observat prin simpla analiză a jurnalelor de firewall. Dacă într-o perioadă scurtă de timp au fost multe conexiuni la diferite porturi, înseamnă că am fost scanați. Tot ce rămâne este să transferăm această idee în regulile firewall-ului. Există o rețetă excelentă pentru iptables care îi blochează pe toți cei care sunt prea persistenti în a bate la porturile care nu funcționează:
Combaterea scanării cu iptables
# Verificați dacă nu bate în porturile nefuncționale (10 pe oră)
--seconds 3600 --hitcount 10 --rttl -j RETURN
# A doua verificare pentru bătăi la porturi nefuncționale (2 pe minut)
iptables -A INPUT -m recent --rcheck \
--seconds 60 --hitcount 2 --rttl -j RETURN
# Punem pe listă adresele celor care bat
iptables -A INPUT -m recent --set
# Aruncă pachetele de la toți cei care depășesc limita cu
numărul de conexiuni
iptables -P INPUT -j DROP
Prin instalarea pachetului xtables-addons, care conține dezvoltările proiectului patch-omatic, vom obține acces la modulul PSD (Port Scan Detect), implementat în imaginea și asemănarea demonului scanlogd. Toate liniile anterioare pot fi ușor înlocuite cu o regulă simplă:
# iptables -A INPUT -m psd -j DROP
Din păcate, nu există nimic de genul acesta în filtrele de pachete ipfw și pf, dar aceasta nu este o problemă, deoarece demonul PortSentry și scanlogd sunt bine contracarate prin scanarea portului.
Interzicerea mesajelor Icmp
De asemenea, este o practică bună să dezactivați mesajele ICMP care ar putea provoca Informații suplimentare despre gazdă sau să fie utilizat pentru a efectua diverse acțiuni rău intenționate (de exemplu, modificarea tabelului de rutare). Mai jos este un tabel care listează tipurile posibile de mesaje ICMP:
Tipuri de mesaje ICMP
- 0 - răspuns ecou (răspuns ecou, ping)
- 3 - destinație inaccesabilă (destinatarul este inaccesibil)
- 4 - stingerea sursei (suprimarea sursei, vă rugăm să trimiteți pachetele mai încet)
- 5 - redirecționare
- 8 - cerere ecou (cerere ecou, ping)
- 9 - reclamă la router
- 10 - solicitarea routerului
- 11 - durata de viață depășită (expirarea duratei de viață a pachetului)
- 12 - Antet IP greșit (antet pachet IP incorect)
- 13 - cerere de marcaj temporal (cerere pentru valoarea contorului de timp)
- 14 - răspuns marcaj temporal (răspuns la o solicitare pentru valoarea contorului de timp)
- 15 - cerere de informare
- 16 - răspuns la informații (răspuns la o solicitare de informații)
- 17 - cerere de mască de adresă (cerere de mască de rețea)
- 18 - răspuns la mască de adresă (răspuns la cererea de mască de rețea)
După cum puteți vedea, răspunsul la unele mesaje ICMP poate duce la dezvăluirea unor informații despre gazdă, în timp ce altele pot duce la modificarea tabelului de rutare, deci trebuie dezactivate.
De obicei, mesajele ICMP 0, 3, 4, 11 și 12 au voie să iasă în lumea exterioară, în timp ce doar 3, 8 și 12 sunt acceptate ca intrare. Iată cum este implementat acest lucru în diferite firewall-uri:
Interzicerea mesajelor ICMP periculoase
Linux> iptables -A INPUT -p icmp\
-icmp-tip 3,8,12 -j ACCEPT
Linux> iptables -A IEȘIRE -p icmp\
-icmp-tip 0,3,4,11,12 -j ACCEPT
FreeBSD> ipfw add allow icmp \
de la orice la $outif în \
prin $outif icmptype 3,8,12
FreeBSD> ipfw add allow icmp \
de la $outif la orice out \
prin $outif icmptype 0,3,4,11,12
OpenBSD> trece în inet proto icmp \
de la oricare la $outif \
icmp-type ( 3, 8, 12 ) păstrează starea
OpenBSD> distribui inet proto icmp \
de la $outif la orice \
tip-icmp (0, 3, 4, 11, 12)\
păstrează starea
Dacă doriți, puteți bloca tot traficul ICMP, inclusiv solicitările ping, dar acest lucru poate afecta funcționarea corectă a rețelei.
Forta bruta
După ce a căutat informații despre porturi deschiseși OS, atacatorul încearcă să pătrundă în sistem, care se poate baza pe exploatarea găurilor în servicii sau ghicirea parolelor. Un firewall nu ne va ajuta să prevenim posibilitatea de a pirata serviciile, dar este ușor să încetinim procesul de forțare brută a parolelor. Pentru a face acest lucru, se utilizează capabilități pentru a limita numărul de pachete care sosesc la o mașină de la o adresă IP. Iată cum să o faci folosind iptables:
Protecție cu forța brută cu iptables
# Lanț pentru verificarea conexiunilor
iptables -N brute_check
# Blocați adresa dacă aveți peste 60
secunde a inițiat mai mult de 2 conexiuni
--update --secunde 60\
--hitcount 3 -j DROP
# Dacă nu, permiteți conexiunea și
adăugați adresa în listă
iptables -A brute_check -m recent\
--set -j ACCEPT
# Ștergeți lanțul INPUT
iptables -F INPUT
# Trimite brute_check la lanț
toți cei care încearcă să se conecteze
al 22-lea port
--ctstate NOU -p tcp \
--dport 22 -j brute_check
iptables -P INPUT DROP
Același lucru se poate face folosind pf:
Protecția forței brute folosind pf
# Creați un tabel pentru forțatorii bruti
masa
# Blocați pe toți cei care intră în el
blocați rapid din
# Puneți în tabelul bruteforcers pe toți cei care inițiază mai mult de două conexiuni pe portul 22 pe minut
transmiteți $ext_if inet proto tcp la $outif \
portul 22 steaguri S/SA păstrează starea \
(max-src-conn-rate 60/2, \overload
Paravanul de protecție ipfw nu are suficientă funcționalitate pentru a contracara eficient forțatorii bruti, așa că utilizatorii săi trebuie să folosească instrumente mai avansate nivel inalt, cum ar fi module PAM speciale, sisteme de detectare a intruziunilor și programe precum sshguard.
Falsificarea
Spoofing (spoofing-ul adresei sursă a unui pachet) poate fi folosit pentru a efectua atacuri DoS sau pentru a ocoli un firewall. În primul caz, spoofing-ul oferă un avantaj uriaș atacatorului, deoarece complică semnificativ răspunsul la atac (pachetele care sosesc cu adrese complet diferite ale expeditorului nu sunt atât de ușor de clasificat și blocat) și întârzie procesul de închidere a noilor conexiuni (de obicei adresa falsă este inaccesibilă, astfel încât conexiunea este închisă numai după expirarea timpului de expirare). Falsificarea, efectuată pentru a ocoli sistemele de securitate, este mai puțin periculoasă și în majoritatea cazurilor poate fi controlată.
Destul de des, blocarea externă servicii de rețea hosta, administratorii de sistem lăsați-le deschise pentru o anumită gamă de adrese (de exemplu, pentru a vă conecta de la aparatul dvs. de acasă). După ce a descoperit una dintre aceste adrese, un atacator poate forma un pachet folosind această adresă ca adresă de retur și, astfel, „strecura” prin firewall. Apoi poate ghici numerele de secvență ale pachetelor TCP și se poate asigura că serviciul care are încredere în adresa de retur efectuează acțiunea dorită. Acesta este un atac foarte greu de implementat, care, cu toate acestea, poate fi efectuat de un specialist competent, iar dacă vorbim despre protocolul UDP, atunci chiar și un hacker îl poate face.
Din fericire, este ușor să te protejezi de aceste atacuri. Este suficient să nu deschideți porturile serviciilor neprotejate către lumea exterioară și, în caz de necesitate urgentă, să utilizați sistemele de securitate ale serviciilor în sine (de exemplu, certificate ssh) sau mecanismul „port knocking” (discutat la sfârșitul articolul).
Situația devine mai complicată când vine vorba de pod de rețea, separând rețelele interne și externe (sau două rețele locale). Relații de încredere în interior retea locala- Lucrul obişnuit. Serviciile sunt disponibile pentru toată lumea, fără autentificare, criptare etc. - doar o bucată delicioasă pentru un hoț. Fiind într-o rețea externă, el poate afla masca de rețea a rețelei interne și poate genera pachete cu o adresă de retur corespunzătoare, ceea ce va duce la obținerea accesului la toate resursele locale. Aceasta este o situație cu adevărat periculoasă, dar poate fi prevenită cu ușurință printr-o configurare adecvată a sistemului de protecție sau a sistemului de operare.
Pentru a face acest lucru, este suficient să interziceți trecerea pachetelor ale căror adrese de retur corespund celor utilizate în rețeaua internă de la interfața externă:
Linux> iptables -A INPUT -i $outif \
-s 192.168.1.0/24 -j DENY
FreeBSD> ipfw add deny ip from \
192.168.1.0/24 către orice prin $outif
OpenBSD> blocați pe $outif din \
192.168.1.0/24 la oricare
Ca măsură de securitate alternativă sau suplimentară, puteți (și chiar trebuie să) utilizați directive speciale ipfw și pf și setările kernel-ului Linux:
Linux> echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
FreeBSD> ipfw add deny ip from any to any not antispoof in
OpenBSD> antispoof rapid pentru $ext_if
Aceste trei comenzi produc aceleași rezultate. Toate pachetele ale căror adrese de retur se potrivesc cu masca de rețea a altei interfețe sunt aruncate.
Beneficiile IPTABLES
La sfârșitul articolului, ne vom uita la câteva caracteristici interesante ale iptables/netfilter care pot fi utile pentru a vă proteja serverul de intruziuni. Să începem cu mecanismul telecomandă firewall, numit „port knocking”. Esența sa este de a forța firewall-ul să efectueze anumite acțiuni după conectarea la un anumit port. Mai jos este un exemplu de reguli care deschid portul SSH timp de 10 secunde după ce ați bătut la portul 27520:
iptables și port knocking
# Lanț pentru verificarea conexiunilor la portul protejat
iptables -N bate
# Permiteți conexiunea dacă a fost o lovitură în ultimul
10 secunde
iptables -A bătaie -m recent --rcheck --seconds 10\
-j ACCEPT
# Ștergeți INTRAREA
iptables -F INPUT
# Permite tot ceea ce se aplică deja legături stabilite
iptables -A INPUT -m conttrack\
--ctstate STABILIT,AFERAT -j ACCEPT
# Toate încercările de a deschide o conexiune la portul 22 sunt trimise
pentru a verifica lanțul de detonare
-p tcp --dport 22 -j bate
# Adăugați în listă adresa persoanei care bate la portul 27520
iptables -A INPUT -m conntrack --ctstate NOU \
-p tcp --dport 27520 -m recent --set
# Când bateți în porturile învecinate, eliminați adresa din listă
iptables -A INPUT -m conntrack --ctstate NOU -p tcp \
-m multiport --dport 27519,27521 -m recent --remove
# Interziceți totul
iptables -P INPUT DROP
A treia regulă de la sfârșit adaugă pe listă adresa persoanei care bate. Dacă aceeași mașină accesează portul 22 în 10 secunde de la detonare, conexiunea va fi stabilită. Penultima regulă este protecția împotriva „ciocănirii cu forță brută”. Dacă un atacator încearcă să bată secvențial la toate porturile cu speranța că unul dintre ele va deschide portul 22, această regulă va funcționa și adresa sa va fi eliminată din listă imediat după ce o atinge.
Al doilea utilitar iptables este distribuit în pachetul xtables-addons (patch-o-matic) și se numește TARPIT. Aceasta este o acțiune (la fel ca ACCEPT sau DENY) care „blochează” conexiunea, împiedicând atacatorul să o închidă. O conexiune ale cărei pachete cad în TARPIT va fi stabilită cu succes, dar dimensiunea ferestrei va fi zero, astfel încât mașina de la distanță nu va putea trimite date, irosindu-și resursele, iar conexiunea va fi închisă numai după un timeout. TARPIT poate fi utilizat în cazuri de urgență pentru a proteja împotriva DoS:
# iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT
Sau pentru a induce în eroare atacatorul și a lupta împotriva scanerelor
porturi (doar scanarea TCP normală, „-sT”):
# iptables -A INTRARE -p tcp -m tcp --dport 80 -j ACCEPT
# iptables -A INTRARE -p tcp -m tcp --dport 25 -j ACCEPT
# iptables -A INPUT -p tcp -m tcp -j TARPIT
Aceste reguli creează aspectul unui sistem în care toate porturile sunt deschise, dar dacă încercați să vă conectați la oricare dintre ele (cu excepția celor 80 și 25), conexiunile se vor îngheța. Același rezultat, dar fără conexiuni slabe, poate fi obținut folosind acțiunea DELUDE, care răspunde corect la toate încercările de inițiere a conexiunii, dar trimite un pachet RST ca răspuns la toate celelalte pachete. Pentru a deruta și mai mult atacatorul, puteți folosi acțiunea CHAOS, care activează aleatoriu una dintre cele două acțiuni descrise mai sus.
concluzii
Cu suficiente cunoștințe și citirea atentă a documentației, puteți crea un bastion foarte puternic de care nu va fi atât de ușor să vă apropiați. Firewall-urile moderne, și în special pf și iptables, oferă multe protecție împotriva oaspeților neinvitați, pe care le puteți obține absolut gratuit.
Legături
- sf.net/projects/sentrytools - PortSentry
- www.openwall.com/scanlogd - scanlogd
Combaterea scurgerii de resurse
Atunci când utilizați acțiunea TARPIT, asigurați-vă că adăugați următoarea regulă la configurație, altfel conexiunile „scăderea” vor consuma resurse atunci când sunt procesate de subsistemul conntrack:
# iptables -t raw -I PREROUTING -p tcp --dport 25 -j NOTRACK