Možete naučiti kako konfigurirati MikroTik na online tečaju o opremi ovog proizvođača. Autor tečaja je certificirani MikroTik trener. Više možete pročitati na kraju članka.
Članak daje odgovor na pitanje koliko je opasno blokirati ICMP promet.
ICMP je jabuka razdora
Mnogi mrežni administratori vjeruju da Internet Control Message Protocol (ICMP) predstavlja sigurnosni rizik i stoga ga treba uvijek blokirati. Istina je da protokol ima neke povezane sigurnosne probleme i da bi se neki zahtjevi trebali blokirati blokirati sav ICMP promet!
ICMP promet ima mnoge važne funkcije; Neki od njih su korisni za rješavanje problema, dok su drugi potrebni za ispravno funkcioniranje mreže. Ispod su neki važni dijelovi ICMP protokola koje biste trebali znati. Trebali biste razmotriti kako ih najbolje usmjeriti kroz svoju mrežu.
Echo zahtjev i Echo odgovor
IPv4 – Echo zahtjev (Type8, Code0) i Echo odgovor (Type0, Code0)
IPv6 – Echo zahtjev (Type128, Code0) i Echo odgovor (Type129, Code0)
Svi dobro znamo da je ping jedan od prvih alata za rješavanje problema. Da, ako omogućite obradu ICMP paketa na svom hardveru, to znači da je vaš host sada vidljiv, ali ne sluša li vaš već port 80 i šalje odgovore na zahtjeve klijenta? Naravno, blokirajte i ove zahtjeve ako stvarno želite da vaš DMZ bude na rubu mreže. Ali blokiranjem ICMP prometa unutar vaše mreže nećete ojačati svoju sigurnost, naprotiv, dobit ćete sustav s nepotrebno složenim postupkom rješavanja problema ("Molimo provjerite odgovara li pristupnik na mrežne zahtjeve?", "Ne, ali to me uopće ne uzrujava, jer me nije briga.”
Zapamtite, također možete dopustiti zahtjevima da idu u određenom smjeru; na primjer, konfigurirajte opremu tako da Echo zahtjevi s vaše mreže idu na Internet, a Echo odgovori s Interneta na vašu mrežu, ali ne obrnuto.
Potrebna je fragmentacija paketa (IPv4) / Paket je prevelik (IPv6)
IPv4 – (Tip3, Kod4)
IPv6 – (Tip2, Kod0)
Ove komponente ICMP protokola su vrlo važne jer su važna komponenta u Path MTU Discovery (PMTUD), koji je sastavni dio TCP protokola. Omogućuje dvama glavnim računalima da prilagode vrijednost TCP maksimalne veličine segmenta (MSS) na vrijednost koja odgovara najmanjem MTU duž komunikacijskog puta između dva odredišta. Ako na putu paketa postoji čvor s manjom maksimalnom jedinicom prijenosa od pošiljatelja ili primatelja, a oni nemaju sredstva za otkrivanje ovog sudara, tada će promet biti tiho odbačen. I nećete razumjeti što se događa s komunikacijskim kanalom; drugim riječima, "za vas će doći veseli dani".
Nemojte fragmentirati – ICMP neće proći!
Prijenos IPv4 paketa s postavljenim bitovima Nemoj fragmentirati (većina njih!) ili IPv6 paketa (zapamtite da u IPv6 nema fragmentacije usmjerivačima) koji su preveliki za prijenos kroz sučelje uzrokovat će da usmjerivač odbaci paket i generirajte odgovor izvoru prijenosa sa sljedećim ICMP pogreškama: Potrebna fragmentacija ( Potrebna fragmentacija), ili pakiranje je preveliko ( Paket također Velik). Ako se odgovori s ovim pogreškama ne mogu vratiti pošiljatelju, on će protumačiti izostanak potvrdnih odgovora o isporuci ACK paketa ( Priznanje) od primatelja kao zagušenje/gubitak i izvor za ponovni prijenos paketa koji će također biti odbačeni.
Teško je identificirati uzrok takvog problema i brzo ga riješiti; postupak TCP rukovanja radi dobro jer uključuje male pakete, ali čim dođe do masovnog prijenosa podataka, sesija prijenosa se zamrzava jer izvor prijenosa ne radi. primati poruke o greškama.
Istraživanje putanje isporuke paketa
RFC 4821 osmišljen je kako bi pomogao sudionicima u mrežnom prometu da zaobiđu ovaj problem korištenjem ispitivanja putanje paketa (Otkrivanje puta MTU (PLPMTUD). Standard vam omogućuje otkrivanje maksimalne količine podataka (Maksimalna prijenosna jedinica (MTU), koji se protokolom može prenijeti u jednoj iteraciji, postupnim povećanjem maksimalne veličine korisnog bloka podataka (Maksimalna veličina segmenta (MSS), kako bi se pronašla najveća moguća veličina paketa bez njegovog fragmentiranja na putu od odašiljača do prijamnika. Ova funkcionalnost smanjuje ovisnost o pravodobnom primanju odgovora o pogrešci putem Internet Control Message Protocol (ICMP) i dostupna je u većini skupova mrežnih uređaja i operativnih sustava klijenata, nažalost, nije tako učinkovita kao izravno dobivanje podataka o maksimalnoj mogućoj veličini poslanih paketa, dopustite ovim ICMP porukama da se vrate izvoru prijenosa, u redu?
Vrijeme prijenosa paketa je prekoračeno
IPv4 – (Tip11, Kod0)
IPv6 – (Tip3, Kod0)
Traceroute je vrlo koristan alat za rješavanje problema s mrežnim vezama između dva računala, s pojedinostima o svakom koraku putovanja.
Šalje paket s vijekom trajanja podatkovnog paketa za IP protokol (Vrijeme za život (TTL) jednak 1 da prvi usmjerivač pošalje poruku o pogrešci (uključujući vlastitu IP adresu) da je paketu isteklo vrijeme života. Zatim šalje paket s TTL 2 i tako dalje. Ovaj postupak je neophodan kako bi se otkrio svaki čvor duž putanje paketa.
NDP i SLAAC (IPv6)
Traženje usmjerivača (RS) (Type133, Code0)
Oglašavanje usmjerivača (RA) (Type134, Code0)
Privlačenje susjeda (NS) (Type135, Code0)
Oglašavanje susjeda (NA) (Type136, Code0)
Preusmjeravanje (Tip137, Kod0)
Dok je IPv4 koristio Address Resolution Protocol (ARP) za mapiranje slojeva 2 i 3 OSI mrežnog modela, IPv6 koristi drugačiji pristup u obliku Neighbor Discovery Protocol (NDP). NDP pruža mnoge značajke uključujući otkrivanje usmjerivača, otkrivanje prefiksa, razlučivanje adrese i više. Uz NDP, StateLess Address AutoConfiguration (SLAAC) omogućuje dinamičku konfiguraciju glavnog računala na mreži, slično konceptu Dynamic Host Configuration Protocol (DHCP) (iako je DHCPv6 namijenjen za detaljniju kontrolu).
Ovih pet tipova ICMP poruka ne smiju biti blokirani unutar vaše mreže (zanemarujući vanjski perimetar) kako bi IP protokol za prijenos podataka ispravno funkcionirao.
ICMP numeriranje tipa
Internet Control Message Protocol (ICMP) sadrži mnogo poruka koje su identificirane poljem "type".
| Tip | Ime | Specifikacija |
|---|---|---|
| 0 | Odgovor jekom | |
| 1 | Nedodijeljeno | |
| 2 | Nedodijeljeno | |
| 3 | Odredište nedostupno | |
| 4 | Gušenje izvora (zastarjelo) | |
| 5 | Preusmjeri | |
| 6 | Alternativna adresa glavnog računala (zastarjelo) | |
| 7 | Nedodijeljeno | |
| 8 | Jeka | |
| 9 | Oglas za ruter | |
| 10 | Traženje usmjerivača | |
| 11 | Vrijeme je prekoračeno | |
| 12 | Problem s parametrima | |
| 13 | Vremenska oznaka | |
| 14 | Vremenska oznaka Odgovor | |
| 15 | Zahtjev za informacijama (zastarjelo) | |
| 16 | Informacijski odgovor (zastarjelo) | |
| 17 | Zahtjev za masku adrese (zastarjelo) | |
| 18 | Odgovor maske adrese (zastarjelo) | |
| 19 | Rezervirano (za sigurnost) | Solo |
| 20-29 | Rezervirano (za eksperiment robusnosti) | ZSu |
| 30 | Traceroute (zastarjelo) | |
| 31 | Pogreška konverzije datagrama (zastarjelo) | |
| 32 | Preusmjeravanje mobilnog hosta (zastarjelo) | David_Johnson |
| 33 | IPv6 Gdje ste (zastarjelo) | |
| 34 | IPv6 Ja sam ovdje (zastarjelo) | |
| 35 | Zahtjev za mobilnu registraciju (zastarjelo) | |
| 36 | Odgovor o mobilnoj registraciji (zastarjelo) | |
| 37 | Zahtjev za naziv domene (zastarjelo) | |
| 38 | Odgovor na naziv domene (zastarjelo) | |
| 39 | PRESKOČI (zastarjelo) | |
| 40 | Photuris | |
| 41 | ICMP poruke koje koriste eksperimentalni protokoli mobilnosti kao što je Seamoby | |
| 42 | Prošireni eho zahtjev | |
| 43 | Prošireni eho odgovor | |
| 44-252 | Nedodijeljeno | |
| 253 | Eksperiment 1 u stilu RFC3692 | |
| 254 | Eksperiment 2 u stilu RFC3692 | |
| 255 | Rezervirano |
Nekoliko riječi o ograničenjima brzine
Dok ICMP poruke poput onih opisanih u ovom članku mogu biti vrlo korisne, zapamtite da generiranje svih ovih poruka oduzima CPU vrijeme na vašim usmjerivačima i generira promet. Očekujete li doista da ćete dobiti 1000 pingova u sekundi kroz vaš firewall u normalnoj situaciji? Hoće li se to smatrati normalnim prometom? Vjerojatno ne. Ograničite propusnost mreže za ove vrste ICMP prometa kako vam odgovara; ovaj vam korak može pomoći da zaštitite svoju mrežu.
Čitajte, istražujte i razumite
S obzirom na to da rasprava o temi “blokirati ili ne blokirati” ICMP pakete uvijek dovodi do zabune, sporova i neslaganja, predlažem da nastavite sami proučavati ovu temu. Dao sam mnogo poveznica na ovoj stranici; vjerujem da biste za potpunije razumijevanje problema trebali potrošiti vrijeme na njihovo čitanje. I donesite informirane odluke o tome što najbolje funkcionira za vašu mrežu.
MikroTik: gdje kliknuti da bi radio?
Uz sve svoje prednosti, MikroTik proizvodi imaju jedan nedostatak - postoji mnogo raštrkanih i ne uvijek pouzdanih informacija o njegovoj konfiguraciji. Preporučujemo pouzdani izvor na ruskom, gdje je sve prikupljeno, logično i strukturirano - video tečaj “ Postavljanje MikroTik opreme" Tečaj uključuje 162 video lekcije, 45 laboratorijskih radova, pitanja za samotestiranje i bilješke. Svi materijali ostaju kod vas na neodređeno vrijeme. Početak tečaja možete pogledati besplatno ostavljanjem zahtjeva na stranici tečaja. Autor tečaja je certificirani MikroTik trener.
Tajni kanali jedna su od metoda informacijske sigurnosti koja se može koristiti i s predznakom plus (za osiguranje anonimnosti i povjerljivosti) i s predznakom minus (za organiziranje curenja podataka). Razmotrimo drugu komponentu - detekciju skrivenog prijenosa podataka, odnosno prijenos podataka skrivenim kanalima, što je jedan od najtežih problema informacijske sigurnosti za rješavanje u praksi. Kako ne bih povećavao veličinu članka, namjerno ću zanemariti mehanizme skrivanja podataka kao što su enkripcija i steganografija.
Aleksej Lukacki
Ciscov savjetnik za sigurnost
Što je skriveni prijenos podataka?
Skriveni prijenos podataka preko mreže nije jedina primjena ove metode. Pojam "prikriveni kanal" prvi put se pojavio 1973. godine i koristio se za računalne sustave koji nemaju tradicionalnu mrežnu vezu. Na primjer, parna vrijednost za trajanje procesa može značiti jedan, a neparna vrijednost može značiti nulu. Dakle, manipulirajući trajanjem procesa, možemo formirati niz od 0 i 1, kojim možemo opisati bilo što (to je tzv. vremenski kanal). Drugi primjer skrivenog procesa u računalnim sustavima je kada proces započne određeni zadatak i dovrši ga u određeno vrijeme, što se može tumačiti kao cjelina; i nula ako zadatak nije dovršen unutar navedenog vremena.
Kako se tajni prijenos može provesti?
Ako govorimo o skrivenom mrežnom prijenosu podataka, onda je jedna od najpopularnijih i relativno jednostavnih za implementaciju metoda enkapsulacija, koja se sastoji od uključivanja zaštićenih informacija koje se moraju prenijeti izvana, ili naredbe koja se mora primiti izvana, u autorizirani protokol.
U ovom slučaju mogu se koristiti potpuno različite mogućnosti enkapsulacije:
Godine 1987. predložena je ideja o tajnom mrežnom prijenosu i od tog trenutka počela su ozbiljna istraživanja ove metode osiguranja povjerljivosti ili curenja podataka (ovisno s koje strane ograde gledate). Konkretno, 1989. godine prvi put je predloženo manipuliranje neiskorištenim bitovima Ethernet okvira i brojnim drugim kanalskim protokolima. Očito, tajni kanali u lokalnoj mreži nisu toliko zanimljivi za proučavanje, za razliku od skrivanja podataka u globalnim mrežama. Probojem (barem javnim) može se smatrati 1996. godina, kada je objavljena studija koja je pokazala stvarni prijenos i prijem podataka preko skrivenog TCP/IP kanala; odnosno u pojedinim poljima njegovog zaglavlja.
- Na razini HTTP-a, koji je odavno postao de facto standard za izgradnju drugih aplikacijskih protokola na njegovoj osnovi. Na primjer, anonimna JAP mreža koristi HTTP za prijenos podataka, također koristeći Tor mrežu koju je teško kontrolirati. U HTTP-u je moguće koristiti GET i POST naredbe za prijenos podataka, a ako se HTTP koristi za prijenos video i audio streaminga, tada mogućnost napadača za prijenos velike količine podataka postaje gotovo neograničena.
- Na DNS razini, kada su informacije skrivene unutar DNS upita i odgovora na njih. O ovoj metodi se počelo govoriti ranih 2000-ih, kada se pojavio DeNiSe alat za tuneliranje TCP protokola u DNS. Kasnije se pojavila studija Dana Kaminskog koja je pokazala mogućnost enkapsulacije SSH kroz DNS i predstavljena na Defcon konferenciji 2005. A onda je ova tema počela dobivati na popularnosti - pojavili su se dns2tcp, DNScapy, DNScat, Heyoka, iodine, squeeza itd.
- Na ICMP razini, kada su podaci enkapsulirani unutar normalno sigurnog ICMP protokola. Program Loki, prvi put spomenut 1996. u časopisu Phrack, funkcionirao je na tom principu. Slijedio ga je napredniji Loki2. Postoji i alat pod nazivom icm-pchat koji vam omogućuje komunikaciju šifriranim porukama putem ICMP-a.
- Na TCP/UDP/IP razini, kada se pojedinačna polja zaglavlja paketa koriste za skrivanje curenja ili primanje naredbi izvana. Ovisno o korištenom protokolu, veličina prenesenih podataka varirat će od 2 do 12 odnosno 38 bajtova u IP, UDP i TCP protokolima. Vrlo zanimljiv alat koji koristi modifikaciju TCP zaglavlja zove se Nushu. Njegova posebnost je u tome što on sam ne stvara nikakav promet, već samo modificira onaj koji je već poslan iz čvora od strane neke aplikacije ili procesa. Drugim riječima, modificirani promet šalje se tamo gdje bi trebao biti, a napadač ga jednostavno presreće preko mreže, prikupljajući podatke koji su na taj način procurili.
- U bežičnim mrežama, kada su podaci maskirani u odaslanom prometu distribuiranom emitiranjem. Usput, u ovom slučaju nije lako otkriti prijemnu stranu, koja može raditi u pasivnom načinu - samo za primanje podataka. Alat HICCUPS izgrađen je na ovom principu.
Kako se može otkriti skriveni prijenos?
Vidjevši tako različite metode koje tajni kanali koriste i protokole u kojima se nalaze, možete razumjeti zašto postoji toliko različitih metoda za otkrivanje tajnih prijenosa. Glavna je kontrola anomalija, koja se sastoji od provjere sljedećih parametara (nepotpun popis):
- Veličina zahtjeva i odgovora. Na primjer, poznato je da prosječna duljina DNS zahtjeva nije veća od 40-60 bajtova. Stoga povećanje broja DNS upita s povećanom duljinom paketa može značiti da tajni kanal radi. Slična praksa može se predložiti i za druge protokole - ICMP, SIP, itd.
- Količina zahtjeva. Obično je obujam prometa za određene vrste protokola, ako ne fiksna vrijednost, onda se rijetko mijenja unutar nekoliko djelića postotka. Stoga iznenadno povećanje prometa servisnog protokola ili broja DNS zahtjeva ili njihove veličine može ukazivati na anomaliju i potrebu za istraživanjem. Štoviše, profil prometa u ovom slučaju može se procijeniti i za čvor pošiljatelja i za čvor primatelja.
- Broj ili geografija pogodaka također može poslužiti kao karakteristika skrivenih kanala. Na primjer, ako imate unutarnji DNS poslužitelj, trajni pozivi vanjskom DNS čvoru također mogu ukazivati na anomaliju.
- Ostale vrste statističke analize također su korisne za otkrivanje skrivenih kanala. Na primjer, možete analizirati razinu entropije u nazivima hostova za DNS. Ako se skrivene informacije prenose u DNS upitima, distribucija korištenih znakova razlikovat će se od tradicionalne.
Alat koji vam omogućuje praćenje takvih anomalija u mrežnom prometu su sustavi klase NBAD (Network-based Anomaly Detection), koji ili već sadrže veliki broj ugrađenih pravila ili se mogu konfigurirati neovisno nakon moda obuke.
Osim analizom anomalija, skriveni kanali mogu se otkriti i proučavanjem sadržaja u određenim protokolima. To se može učiniti korištenjem tradicionalnih rješenja klase sljedeće generacije, koja mogu pratiti odstupanja prometa aplikacijskog protokola od RFC-ova, i korištenjem sustava za otkrivanje upada. Na primjer, ovako izgleda potpis za otkrivanje skrivenog NSTX kanala u DNS protokolu za rješenje otvorenog koda Snort:
upozorenje udp $EXTERNAL_NET bilo koji - > $HOME_NET 53 (msg:"Potencijalno NSTX DNS tuneliranje"; sadržaj:"|01 00|"; pomak:2; unutar:4; sadržaj:"cT"; pomak:12; dubina:3 ; content:"|00 10 00 01|"; classtype:bad-unknown;
Sažetak
Nedostatak univerzalnosti možda je glavna prepreka i aktivnoj uporabi tajnih kanala i borbi protiv njih.
Prikriveni kanali u mrežnom prometu vrlo su specifična metoda koja nije univerzalna i ima svoja ograničenja i opseg. Svaki prikriveni kanal ima svoje karakteristike, kao što su širina pojasa, šum, način prijenosa (dvosmjerni ili jednosmjerni), o kojima se mora voditi računa – kako pri korištenju tako i pri borbi protiv njih. Ipak, “Rat i mir” L.N. Tolstoy se ne može brzo prenijeti takvim kanalima, a neke metode tajnog prijenosa imaju vrlo visoku razinu šuma, što onemogućuje njihovo učinkovito korištenje u globalnim mrežama, u kojima vanjski čimbenici mogu uvelike utjecati na uspjeh tajnog prijenosa.
Nedostatak univerzalnosti možda je glavna prepreka i aktivnoj uporabi tajnih kanala i borbi protiv njih. Velik broj ograničenja tajnog prijenosa podataka čini ga domenom samo ciljanih prijetnji razvijenih za određeni zadatak i određenog korisnika. Isti nedostatak univerzalnosti dovodi do ideje da ni sada nema srebrnog metka u obliku jednog proizvoda, te je potrebno koristiti cijeli niz alata i tehnologija za otkrivanje i neutraliziranje skrivenog prijenosa podataka.
Ovaj kratki članak pokazat će vam kako koristiti nekoliko računala, nekoliko zabavnih alata i operativni sustav za bežični pristup internetu gdje god je to moguće. Prilično sam jasno opisao tehničku stranu i dao komentare.
1. Uvod.
Upravo sam dobio svoje prvo prijenosno računalo i želio sam probati raditi nešto nestašno s njim (čak sam pokušao raditi nešto, ali bilo je previše zamorno
:)). Warriving je u početku bila prilično zabavna aktivnost, ali mi je postalo malo dosadno kada sam shvatio da mreže štite
WEP mi je pretežak (budući da nije bilo intranetskog prometa - mreže bi se mogle smatrati mrtvima), a nezaštićene mreže me uopće ne zanimaju. Srećom, bežična mreža na mom sveučilišnom kampusu bila je malo zanimljivija.
Mreža pruža besplatan bežični internet, ali zahtijeva da svoju MAC adresu registrirate na svoje ime prije dopuštanja pristupa - neregistrirani korisnici se preusmjeravaju na stranicu pružatelja usluga (stranica za registraciju). Registracija bi uključivala dvominutni razgovor s administratorom, ali pomislio sam, “Možda
način za dobivanje pristupa bez takve komunikacije? Naravno da je bio.
2. Prva metoda prodora je MAC spoofing.
Kako se sve vrtjelo oko MAC adrese, prvo što mi je palo na pamet je
bio je pronaći već registriranu MAC adresu i riješiti je
lažiranje. Naravno, lako je pričati, ali to nije zahtijevalo gotovo nikakav napor čak i s obzirom na to da to nikad prije nisam radio.
Prvo što sam napravio bilo je pokrenuti kismet ("kismet -c orinoco,eth1,wifi") i ponjušiti mesh. Kismet sprema sve što ste preuzeli
informacije u datoteku ("/var/log/kismet/*.dump" u mom slučaju), rezultati njuškanja mogu se vidjeti kakvi jesu
primanja. Kao rezultat toga, mogao sam vidjeti sve informacije i
zapišite odgovarajuću MAC adresu.
Naredbe koje se koriste za promjenu MAC adrese mrežne kartice:
ifconfig eth1 dolje
killall dhclient
ifconfig hw ether 00:11:22:33:44:55
ifconfig eth1 gore
dhclient eth1
Nisu sve naredbe potrebne, ali su vrlo korisne kada pokušavate promijeniti nekoliko MAC adresa jednu za drugom, što
Bilo mi je samo korisno, jer... MAC adresa koju sam pokušao promijeniti nije odmah radila. Dobio sam zabranu, mreža je pala i više se nije htjela uključiti, zbog čega sam imao problema s nekim pomalo iritantnim problemima
u vašem sustavu. Možda ovi problemi
pojavio zbog pogrešnih firmvera ili možda zato što je na mreži već postojala mrežna kartica s istom MAC adresom.
Nisu sve radne stanice bile aktivne, a korištenje kismeta za pregled rezultata kako su pristizali bilo je neučinkovito, pa sam pokušao drugu metodu.
Na mreži je filtriranje MAC adresa provedeno na prilično visokoj razini. Mogao sam pristupiti mreži bilo kada, jer... Kad sam se pokušao pridružiti, odveden sam na stranicu na kojoj se od mene tražilo da se registriram.
Naravno, dok smo razmišljali o aktivnim hostovima, na pamet mi je pao nmap. Pa sam počeo provjeravati IP raspon za aktivne stanice.
marktwain:~# nmap -sP 10.0.0.1/22
Počevši od nmapa 3.81 (http://www.insecure.org/nmap/) 2005-05-23 12:54 EEST
Čini se da host 10.1.0.14 radi.
MAC adresa: 00:0E:35:97:8C:A7 (Intel)
Čini se da host 10.1.0.95 radi.
Čini se da host 10.1.0.109 radi.
MAC adresa: 00:0D:54:A0:81:39 (3Com Europe)
...odrezati...
Čini se da host 10.1.2.92 radi.
MAC adresa: 00:02:2D:4D:1C:CE (Agere Systems)
Čini se da host 10.1.2.187 radi.
MAC adresa: 00:02:2D:4D:1C:43 (Agere Systems)
Nmap završen: 1024 IP adrese (20 hostova gore) skenirane u 53.980 sekundi
Hrpa MAC adresa. Većina
Rezultirajuća tablica adresa (kao što pretpostavljam) su MAC adrese strojeva koji su posjetili mrežu u proteklih nekoliko dana. U tablici je bilo 245 različitih MAS-ova
adrese. Ne znam je li to normalno ponašanje za
pristupne točke, ali mislim da dečkima nešto treba
promjena u distribuciji Interneta. U svakom slučaju, sada imam dovoljno MAC adresa strojeva koji su posjetili mrežu, ali su najvjerojatnije davno otišli. Par pokušaja lažiranja i već sam krenuo na neworder.box.sk...
3. Pokušaj broj 2 - ICMP tuneliranje.
Ostvario sam sve što sam želio, ali bilo je još prostora za kopanje u ovoj mreži. Ali što
Mogao bih to učiniti da ova mreža nema
ne bih imao niti jedan jedini moj auto? Ako
Zar se nmap ne bi otvorio i pokazao sve ove MAC adrese? U svakom slučaju, odlučio sam pokušati pristupiti na drugačiji način.
Ovo nije spomenuto prije, ali zaobiđite sustav
Internetska distribucija daje dopuštenje, a DHCP, mreža je omogućila nesmetan prolaz ICMP porukama. Provjera aktivnosti bilo kojeg internetskog mjesta radila je savršeno (stvarno mi nije jasno zašto ga nisu blokirali - osim ako nisu zaboravili), ping
otkriven je čak i na njuškalu koji je bio pokrenut na mom poslužitelju.
Moj plan je bio pokušati stvoriti tunel između mog laptopa na sveučilištu i poslužitelja kod kuće. I provucite sve veze kroz njega.
Tražio sam aplikacije za ICMP tuneliranje na internetu, ali nijedna nije radila onako kako sam želio (naime, želio sam da bude jednostavno - tako da ako pokrenem svoj omiljeni preglednik ili bilo koji drugi program, radi samo s tunelom) ili barem
izgledalo probavljivo.
4. Malo kodiranja.
Isprva nisam planirao ništa kodirati. Upravo sam isprobao neke aplikacije ICMP tunela
s packetstormom, ali iznenada sam se zatekao kako čitam izvorni kod jednog od njih i shvatio koliko je nevjerojatno jednostavan i kako bi lako bilo napraviti ovako nešto. Naziv programa – itunnel -
Uobičajeni pomoćni program za ICMP tuneliranje. Itunnel je sjajan. Ali to je samo tunel. Pokrenete ga na jednom stroju, a na kraju izgleda kao da ste spojili dva
mrežne kartice zajedno. Nije bilo dovoljno za ono što sam želio učiniti.
Već sam čuo za kernel modul TUN/TAP, koji omogućuje korisničkim procesima da primaju i šalju pakete informacija izravno u/od kernela.
Program stvara virtualno mrežno sučelje.
Stvara mrežno sučelje koje
radi potpuno isto
standard Najzanimljivije je to
korisnički programi moraju
djeluju kao fizički sloj za sučelje
tunel. Moraju čitati pakete informacija iz
datoteku uređaja (na primjer, "/dev/net/tun0") i proslijedite ih na bilo koji način i napišite pakete odgovora
natrag na datoteku.
Nisam mogao pronaći nijedan dobar izvor
putem TUN/TAP-a, ali postoji program - vtun - koji je koristio TUN/TAP za svoje tunele, pa sam
Koristio sam vtun izvore. Nakon malog istraživanja ispostavilo se da postoji mala biblioteka funkcija koje se koriste za kreiranje, čitanje i pisanje u tun*
uređaja. Zašto bih sam trebao napisati program ako to mogu učiniti popravljanjem nekoliko bitova?
Kod koji sam zapravo napisao:
#include "driver.h" /* proglasite vtun knjižnicu */
#uključi
#uključi
/* malo modificirani main() iz itunnela
*/
int run_icmp_tunnel (int id, int veličina paketa, char *desthost, int tun_fd);
/* maksimalna jedinica – maksimum
veličina inkapsuliranog pakiranja
*/
const int mtu = 1400;
int main(int argc, char **argv) (
char *dev;
int tun_fd = 0;
/* stvaranje tunelskog uređaja */
dev = (char *) malloc(16);
if (dev == NULL) (
printf("ako nikada niste imali problema sa
dodjeljivanje 16 bajtova\"
"sjećanje je tvoj prvi put. Fatal.n");
povratak 1;
}
dev = 0;
/*
lijepa knjižnična funkcija
iz vtun prihvaća prazan niz kao*
*
argument, stvara tunX uređaj i
prosljeđuje ga *dev */
tun_fd = tun_open(dev);
ako (tun_fd< 1) {
printf("Nije moguće stvoriti uređaj. Fatal.n");
povratak 1;
}
drugo(
printf("Stvoren uređaj za tuneliranje: %sn", dev);
}
/* 7530 je ICMP ID polje,
koristi se za pakete u tunelu
*/
run_icmp_tunnel(7530, mtu, argv, tun_fd);
tun_close(tun_fd, dev);
}
Evo ga. A većina toga su komentari i provjera pogrešaka
Kao što sam već spomenuo, itunnel je idealan za izgradnju tunela. Ima glavnu funkciju koja je
otvorene datoteke za ulaz, izlaz i utičnicu; Također
Primio sam neke parametre za naredbeni redak (koji bi mogli biti korisni za moje potrebe). Zatim je pozvao pomalo apstraktnu funkciju koja je u biti samo prenosila pakete informacija. ICMP zaglavlje bez
opisano je u kodu i može se lako promijeniti u bilo koje drugo zaglavlje,
ulaz/izlaz/utičnica može se konfigurirati prema nekom drugom logičkom sklopu - funkcija će raditi uz minimalne prilagodbe.
Najveća promjena koju sam napravio bilo je uklanjanje svih manipulacija s naredbenim retkom - u biti uklanjanje nekoliko blokova koda. Što je najvažnije za logiku tunela, uklonio sam razliku između ulaza i izlaza jer su oboje
visi na istom deskriptoru (tunX uređaj) –
to mi je dalo umjesto da se ponašam kao
netcat i proslijedite stdin na ICMP utičnicu i ICMP utičnicu na stdout,
šalje izlazni signal tunX uređaju (poput http zahtjeva iz preglednika) na ICMP
utičnica i izlaz ICMP utičnice (kao da je HTTP
zahtjevi s poslužitelja poslani su natrag
kroz tunel) do tunX uređaja (do
vratit će se natrag u preglednik). Budući da je zadnja rečenica vrlo dugačka i zamršena, dajem mali dijagram za ilustraciju:
Paketi odgovora s informacijama slijede isti put, ali
na drugi način.
U jednom trenutku sam dovoljno poludio i zapravo sam napisao novu liniju koda. Ovako izgleda:
memcpy(&(target->sin_addr.s_addr), &(from.sin_addr.s_addr), 4);
Njegova funkcija je započeti slanje svih paketa informacija na mjesto gdje je zadnji paket stigao. mogu
pokrenite ga na mom poslužitelju i povežite se
s bilo kojeg mjesta pošaljite paket kroz tunel
i odmah mijenja IP primatelja u IP
moj laptop.
Rezultat možete preuzeti odavde:
5. Postavljanje tunela.
Testirao sam tunel kod kuće i dobro je radio, ali kod kuće nije bilo vatrozida. Sljedeći dan na sveučilištu bio sam spreman isprobati ga u stvarnom životu. Igrom slučaja, dok sam sjedio za stolom u kafiću, lažiranjem sam pronašao MAC adresu i uspostavio tunel.
Teško je sjetiti se svih gluposti koje sam pokušao i malih eksperimenata koje sam radio, pa sam ovaj dio pokušao učiniti što organiziranijim. Zapravo nisam sve tako jasno napravio.
Da mi sve uspije
Trebalo mi je 3 sata i pokušao sam sve što sam mogao dok sam njuškao gdje god sam mogao i modificirao kod tako da bi pjevao "Paket!" kada bi primio paket informacija, i nešto neugodno kada bi poslao vlastiti paket. I tako dalje.
Pokrenuo sam ove naredbe na poslužitelju:
tsee-diees:~# ./create_tun wifi.ttu.ee
Kreiran tunelski uređaj: tun0
Zaustavljen ./create_tun wifi.ttu.ee
tsee-diees:~# ifconfig tun0 mtu 1400 192.168.3.1 gore
tsee-diees:~# ruta dodaj 192.168.3.2 tun0
tsee-diees:~# tethereal -i eth0 -f "icmp"
Mislio sam da će ovo odmah proraditi i upravo sam ovo pokrenuo na svom laptopu:
marktwain:~# ./create_tun 194.204.48.52
Kreiran tunelski uređaj: tun0
Zaustavljeno ./create_tun 194.204.48.52
marktwain:~# ifconfig tun0 mtu 1400 192.168.3.2 gore
marktwain:~# route add 192.168.3.1 tun0
marktwain:~# tethereal -i eth0 -f "icmp"
Ono što sam trebao učiniti je stvarati
mrežu s dva hosta na njoj - poslužitelj kao 192.168.3.1 i laptop kao 192.168.3.2. Jednostavan normalan LAN, samo će njegov fizički sloj biti ICMP tunel. Vjerojatno kao i ti
razumljivo iz ostatka teksta u članku
metoda zapravo nije djelovala. Pokrenuo sam ping ("ping 192.168.3.1"), ali paketi i dalje nisu prolazili.
Srećom, njuškalo na prijenosnom računalu dalo mi je mali trag - ICMP paketi bili su povratni odgovori. Naravno da nemaju
odlazili. Dakle, ubijamo tunel, omogućujemo itunnel na laptopu i koristimo icmp povratne odgovore (promijenite “icmp->type = 0;” u “icmp->type = 8;”), vraćamo tunel.
Sustav i dalje nije radio, ali ovaj put paketi
pojavio na njuškalu na poslužitelju.
Što bi moglo biti pogrešno? Probao sam jednu modifikaciju koja je trebala viknuti "Paket!" kada stigne sljedeći paket, ali uzvici nisu
nastao. "Zašto bi, zapravo", pitao sam se, "ako je vatrozid instaliran, trebao blokirati sve ICMP pakete s Interneta?" Nakon nekog vremena shvatio sam da je to zapravo tako (svi ICMP paketi s interneta su blokirani).
Već bolje. Tunel uzvikuje "Paket!" , a odgovori se mogu vidjeti na snifferu na poslužitelju. Zapravo, postoje dva odgovora na svaki zahtjev, od kojih se samo jedan može vidjeti na snifferu na prijenosnom računalu. A ping i dalje ne radi.
Budući da je jedan od dva paketa suvišan, rekao sam kernelu da ne odgovara na icmp povratne poruke:
tsee-diees:~# echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
I pingovi su počeli prolaziti! U ovom trenutku još uvijek sam se oslanjao na lažnu MAC adresu za pristup poslužitelju. Budući da je ideja bila da paketi putuju u oba smjera od neregistriranog korisnika, prestao sam lažirati MAC adrese. Istodobno, tunel je nastavio s radom, što je bilo prilično ugodno iznenađenje.
Uspostavljen je protok paketa i došlo je vrijeme da "Internet" proradi.
Potrebno napraviti neke promjene na IP-u
usmjeravanje na laptopu. Put kroz
sveučilišni bežični usmjerivač morao je biti zamijenjen adresom tunela poslužitelja (192.168.3.1 u ovom slučaju). I dalje treba postojati put do poslužitelja tako da sam tunel može raditi (ICMP paketi tunela također trebaju put koji treba pratiti).
Dobio sam dobre rezultate:
marktwain:~# route add 194.204.48.52 gw 10.0.0.111 # kroz bežični ruter
marktwain:~# zadana ruta
marktwain:~# route add default gw 192.168.3.1 # sve ostalo kroz tunel.
A budući da sam nekako pametan, mislio sam da bi moglo postojati neslaganje između
broj paketa poslanih na i sa poslužitelja. Počeo sam pingati
u pozadini za praćenje situacije:.
marktwain:~# ping 194.204.48.52 -i 0.2
PING 194.204.48.52 (194.204.48.52) 56(84) bajtova podataka.
Naravno, nije bilo odgovora, jer to nisu bili "pingovi tunela", a odgovori kernela su bili
ugašen.
Budući da je moj poslužitelj već bio obučen
dijeliti internetsku vezu između nekoliko računala, sve što sam trebao učiniti na poslužitelju bilo je dodati dva pravila za
FORWARD lanac u iptables za prihvaćanje paketa od i do tun0. Kad sam rutinski provjeravao trenutna pravila ("iptables -vL FORWARD"), veza je iznenada umrla. Ponovno sam se povezao i istražio ovaj problem,
ali ubrzo je veza ponovno umrla. Bio sam jako iznenađen - zašto je veza tako nestabilna?
Nakon razmišljanja, shvatio sam da svaki put poslužitelj šalje veliki ICMP odgovor
(uostalom, samo je ping zaglavlje bilo 1400+), odbijeno je
sama oprema. Budući da je tunel bio fizički
na IP razini, TCP je prirodno ponovno pokušao poslati pakete, ali veličina je i dalje bila ista, a oni su i dalje odbačeni. Pa sam promijenio MTU za tunel na 300 (in
općenito govoreći slučajno)
marktwain:~# ifconfig tun0 mtu 300
tsee-diees:~# ifconfig tun0 mtu 300
I cijeli je sustav funkcionirao.
6. Zaključak.
Sada to učinite sami.
Skriveni kanali je jedan od načina prikrivanja radnji ili izvođenja napada, koji se koristi za tajni, neovlašteni ili nezakoniti prijenos informacija. Uz pomoć skrivenih kanala, informacije mogu curiti ili, obrnuto, informacije se mogu unijeti u organizaciju. Skriveni kanal na internetu može se usporediti s tajnim pretincem u aktovci u koji napadač može pokušati sakriti tajne dokumente kako bi ih prokrijumčario kroz ulaz u sigurnosnu ustanovu. Na internetu napadači mogu koristiti skrivene kanale za prijenos tajnih materijala, a da pritom ostanu neotkriveni - u ovom slučaju mrežni sigurnosni mehanizmi djeluju kao sigurnosni pristupnik. Baš kao što špijun može sakriti oružje u isti tajni odjeljak da ga sakrije od sigurnosti i prodrijeti zajedno s njim u objekt, na internetu, napadači mogu koristiti skrivene kanale za tajni prijenos cyber oružja, na primjer, za preuzimanje zlonamjernog softvera s vanjskog poslužitelja na čvor u privatnoj mreži organizacije.
Razumijevanje skrivenih kanala na internetu
Tajni kanali na Internetu mogu se temeljiti na nekonvencionalnoj upotrebi poznatih internetskih protokola. Krajnje točke zasebnog kanala - zaraženo računalo i zapovjedni centar napadača - moraju koristiti poseban softver sposoban prepoznati i obraditi takve nekonvencionalne tehnike za napad ili skrivanje akcija. Takav softver može instalirati sam korisnik ili zlonamjerni softver ili napadači koji koriste alate za udaljenu administraciju (RAT). Internetski skriveni kanali razlikuju se od šifriranih tunela. Informacije preko njih mogu se prenositi nešifrirane (to se često događa), ali ti su kanali sami skriveni od stranaca. U ovom slučaju nema potrebe za korištenjem enkripcijskih ili kriptografskih ključeva, ali ponekad tajni kanali ipak koriste različite metode šifriranja ili maskiranja podataka.
Pogledajmo dva primjera. Prva tehnika je tajni prijenos informacija jedan po jedan znak u polje identifikatora (ID) zaglavlja paketa internetskog protokola (IP). U uobičajenim implementacijama ove tehnike, ASCII kodovi znakova množe se s 256 kako bi se stvorile 16-bitne vrijednosti koje su zamijenjene u polju identifikatora. Za prijenos ICANN akronima bilo bi potrebno prenijeti 5 IP paketa sa sljedećim vrijednostima polja identifikatora:
| Plastična vrećica | Decimalna ASCII vrijednost | ID IP paketa (x256) |
| 1 | 71 ("ja") | 18176 |
| 2 | 67 ("C") | 17152 |
| 3 | 65 ("A") | 16640 |
| 4 | 78 ("N") | 19968 |
| 5 | 78 ("N") | 19968 |
Prijemno računalo dekriptira vrijednost ID polja IP paketa dijeljenjem dobivene vrijednosti s 256. Prijenos takvih vrijednosti ne izaziva nikakvu sumnju, a budući da IP protokol dopušta prijenos dvostrukih paketa, vjerojatnost takvog promet koji se otkriva je nizak. Spora brzina kompenzira se skrivenošću prijenosa.
Druga tehnika za kreiranje skrivenog kanala uključuje korištenje protokola payload, odnosno tehničkih informacija koje se prenose unutar okvira odabranog protokola. U ovom slučaju, podaci se dodaju ECHO zahtjevima i odgovorima - to su servisne poruke koje se koriste u Internet Control Message Protocol ili ICMP. ECHO poruke se koriste u zajedničkoj usluzi ping. Mrežni administratori često koriste ping kako bi provjerili je li udaljeni host dostupan, tako da je ICMP ECHO paketni promet obično dopušten putem mrežnih sigurnosnih alata kao što su vatrozidi.
Ako želite saznati više o ovim tehnikama, pogledajte sljedeće članke: Pitanja i odgovori o prikrivenim kanalima i prikriveni kanali preko ICMP-a (PDF, 740 KB).
Unaprijediti. DNS skriveni kanali
Protokol Domain Name System (DNS) ima niz karakteristika koje ga čine praktičnim za korištenje skrivenih kanala. DNS promet dopušten je kroz vatrozid u oba smjera. Opasnosti korištenja DNS-a za stvaranje skrivenih kanala često se zanemaruju ili podcjenjuju, zbog čega organizacije ili davatelji internetskih usluga ne provjeravaju uvijek DNS promet radi znakova napada. Ponekad DNS promet procuri na širi internet kako bi se razriješila imena prije nego što se izvrše funkcije autorizacije ili provjere autentičnosti korisnika, što omogućuje korištenje tajnih DNS kanala za zaobilaženje takvih kontrola pristupa.
U našem sljedećem postu, pokrit ćemo kako se skriveni DNS kanali mogu koristiti za izdvajanje podataka, zaobilaženje kontrola pristupa ili preuzimanje zlonamjernog softvera.