Pokusy o přihlášení na Mikrotiky

Návody a problémy s konfigurací.
iTomB
Příspěvky: 755
Registrován: 12 years ago

Re: Pokusy o přihlášení na Mikrotiky

Příspěvekod iTomB » 6 months ago

Jedna se o verzi 6.36.4 a je tam i FW, vypada ze sel utok z vnitrni site, kde je mikrotik s tim samym FW, ale omezeni je u ip services.

Torch je ticho, ale on tam neni zadny prutok ted. Dal jsem pravidla na LOGovani uvidim. Vecer nahravame novejsi verzi.
0 x

mrazek609
Příspěvky: 167
Registrován: 7 years ago

Příspěvekod mrazek609 » 6 months ago

Když bylo nastaveno IP services i FW správně, tak by mě zajímalo, zda nemohl jít útok přes L2 jak zde psal tuším pan Klíma? Třeba přes mac-telnet nebo mac-winbox.
0 x

menicks
Příspěvky: 215
Registrován: 10 years ago

Příspěvekod menicks » 6 months ago

iTomB píše:Jedna se o verzi 6.36.4 a je tam i FW, vypada ze sel utok z vnitrni site, kde je mikrotik s tim samym FW, ale omezeni je u ip services.Torch je ticho, ale on tam neni zadny prutok ted. Dal jsem pravidla na LOGovani uvidim. Vecer nahravame novejsi verzi.


Omezení u IP services je na nic pokud je tam chyba. Protože port je pořád otevřený a až po pokusu o přihlášení na základě ip odmítá.
0 x

mpcz
Příspěvky: 2290
Registrován: 13 years ago

Příspěvekod mpcz » 6 months ago

No čekal jsem každou chvíli, až se vynoří tento katastrofický scénář. Protože doteď napadený stroj scanoval pouze 2 oct. do WANU, ale až se to začne šířit i v LANkách, popř. po MAC, pokud to samozřejmě jde, to bude teprve legrace. A půjde to asi i rychleji. mpcz, 22.5.2018
0 x

ludvik
Příspěvky: 3983
Registrován: 7 years ago

Příspěvekod ludvik » 6 months ago

@menicks: Jaký k tomu máš důkaz?

ip/services je služba typu superserver, inetd nebo něco podobného. Tedy spuštění programu na základě prvního požadavku z venku. Čili s vlastní chybnou službou to ještě nemá nic společného. Ta je spuštěna až po ověření IP. Mikrotik by byl i sám proti sobě, kdyby nevyužil možnost konfigurovat jen jednu službu místo osmi. Zároveň tento způsob trochu šetří prostředky, protože služba prostě neběží, pokud není potřeba.
Mimochodem proto tam jsou služby, co tam jsou a ne třeba DNS který takový způsob práce neumožňuje.

Kdyby byla chyba už v této fázi, tak je jedno na co se útočí - ftp, ssh, nebo klidně API. Což si myslím, že už by se provalilo.

Jediný rozdíl od seknutí firewallem (DROPem) je, že je to odmítnuté aktivně, čili útočník ví, že tam ta služba nejspíš je.

Musel by se dokázat šířit přes MAC-server, což jsem ovšem ještě neslyšel. Kromě toho to je broadcast, čili by takový virus musel hopkat z routeru na router.

https://forum.mikrotik.com/viewtopic.php?f=21&t=133533
0 x
Ohledně GDPR již nediskutuji. Když nic nevím, musím si to nastudovat jinde - a pak už to vím a nemám potřebu diskutovat zde.

Dalibor Toman
Příspěvky: 1201
Registrován: 6 years ago

Příspěvekod Dalibor Toman » 6 months ago

menicks píše:
iTomB píše:Jedna se o verzi 6.36.4 a je tam i FW, vypada ze sel utok z vnitrni site, kde je mikrotik s tim samym FW, ale omezeni je u ip services.Torch je ticho, ale on tam neni zadny prutok ted. Dal jsem pravidla na LOGovani uvidim. Vecer nahravame novejsi verzi.


Omezení u IP services je na nic pokud je tam chyba. Protože port je pořád otevřený a až po pokusu o přihlášení na základě ip odmítá.


to by bylo dost hloupe implementovane. Normalne se to dela tak, ze:
1) operacni system da vedet aplikaci, ze ma na socketu prichozi spojeni
2) aplikace si spojeni 'vyzvedne' z fronty cekajicich novych spojeni (Accept funkce), tim ziska informace o IP adrese zdroje (necte jeste zadna data poslana druhou stranou)
3) pokud se aplikace IP adresa puvodce spojeni nelibi tak spojeni ukonci

behem toho aplikace necte zadna data cili i kdyby v ni byla nejaka chyba pri zpracovani dat tak se nemuze aktivovat. Casto je dokonce ten kdo prijima od OS spojeni jedna aplikace (ta kontroluje nastaveni omezni IP apod) a pokud je vse v poradku preda rizeni dalsi aplikaci. dela se to tak bezne pokud aplikace neni volana prilis casto (nejedna se o vytizeny WWW server apod). Takze je mozne, ze pri odmitnuti na zaklade nepovoleneho IP se WWW server v mikrotiku vubec nespusti.
0 x

Noxus28
Příspěvky: 334
Registrován: 7 years ago

Příspěvekod Noxus28 » 6 months ago

Tak som dnes od rána nasadil doma na FTTH od Orange log na pokusy na 8291. Nazbieralo sa pokusov zo zhruba 10 IP v rovnakom AS. A.B.0.0
Pozoroval niekto že si vie napadnutý RB zistiť IP za ktorú je NATnutý a následne testovať daný rozsah alebo testuje len rozsahy IP na interfacoch? Pýtam sa preto, lebo Orange u nás nedáva automaticky verejky klientom, tie končia na ONT a klientské zariadenie za ním je NATované.
0 x
MTCNA, MTCRE, MTCTCE a furt toho viem málo 🤓

menicks
Příspěvky: 215
Registrován: 10 years ago

Příspěvekod menicks » 6 months ago

Dalibor Toman píše:
menicks píše:
iTomB píše:Jedna se o verzi 6.36.4 a je tam i FW, vypada ze sel utok z vnitrni site, kde je mikrotik s tim samym FW, ale omezeni je u ip services.Torch je ticho, ale on tam neni zadny prutok ted. Dal jsem pravidla na LOGovani uvidim. Vecer nahravame novejsi verzi.


Omezení u IP services je na nic pokud je tam chyba. Protože port je pořád otevřený a až po pokusu o přihlášení na základě ip odmítá.


to by bylo dost hloupe implementovane. Normalne se to dela tak, ze:
1) operacni system da vedet aplikaci, ze ma na socketu prichozi spojeni
2) aplikace si spojeni 'vyzvedne' z fronty cekajicich novych spojeni (Accept funkce), tim ziska informace o IP adrese zdroje (necte jeste zadna data poslana druhou stranou)
3) pokud se aplikace IP adresa puvodce spojeni nelibi tak spojeni ukonci

behem toho aplikace necte zadna data cili i kdyby v ni byla nejaka chyba pri zpracovani dat tak se nemuze aktivovat. Casto je dokonce ten kdo prijima od OS spojeni jedna aplikace (ta kontroluje nastaveni omezni IP apod) a pokud je vse v poradku preda rizeni dalsi aplikaci. dela se to tak bezne pokud aplikace neni volana prilis casto (nejedna se o vytizeny WWW server apod). Takze je mozne, ze pri odmitnuti na zaklade nepovoleneho IP se WWW server v mikrotiku vubec nespusti.


Ano je to hloupě naprogramované :) Opravdu to prošlo i skrz omezení v ip services. Edit: Jinak tento problém asi není ve všech verzích...
0 x

Dalibor Toman
Příspěvky: 1201
Registrován: 6 years ago

Příspěvekod Dalibor Toman » 6 months ago

menicks píše:
Ano je to hloupě naprogramované :) Opravdu to prošlo i skrz omezení v ip services. Edit: Jinak tento problém asi není ve všech verzích...


moc se mi to mu nechce verit. Spis prolezla nakaza z IP ktere to mely dovolene. Nekdo od MT tusim na forum tvrdil, ze aplikace z ip services se spousteji az po kontrole IPcek (cili standardnim logickym zpusobem z nejakeho centralniho demona, ktery jen nasloucha na portech a pak spousti ty aplikace).

Pokud mas nejake podezreni/dukaz tak doufam, ze support byl informovan, aby se to pro priste opravilo - protoze by to byl docela prusvih
0 x

menicks
Příspěvky: 215
Registrován: 10 years ago

Příspěvekod menicks » 6 months ago

Dalibor Toman píše:
menicks píše:
Ano je to hloupě naprogramované :) Opravdu to prošlo i skrz omezení v ip services. Edit: Jinak tento problém asi není ve všech verzích...


moc se mi to mu nechce verit. Spis prolezla nakaza z IP ktere to mely dovolene. Nekdo od MT tusim na forum tvrdil, ze aplikace z ip services se spousteji az po kontrole IPcek (cili standardnim logickym zpusobem z nejakeho centralniho demona, ktery jen nasloucha na portech a pak spousti ty aplikace).

Pokud mas nejake podezreni/dukaz tak doufam, ze support byl informovan, aby se to pro priste opravilo - protoze by to byl docela prusvih


Ano dle monitoringu sítě to šlo z venku a ne z vnitřní adresy a nebyl jsem jediný kdo to reportoval.

Kód: Vybrat vše

apr/20 08:34:28 system,error,critical login failure for user admin from 103.1.221.
39 via winbox
apr/20 08:34:29 system,error,critical login failure for user admin from 103.1.221.
39 via winbox
apr/20 08:34:30 system,info,account user admin logged in from 103.1.221.39 via win
box
apr/20 08:34:37 system,info ip service changed by admin
apr/20 08:34:38 system,info ip service changed by admin
apr/20 08:34:54 system,info,account user admin logged in from 103.1.221.39 via ssh
 
apr/20 08:35:01 system,info,account user admin logged in from 103.1.221.39 via tel
net
apr/20 08:35:01 system,info,account user admin logged out from 103.1.221.39 via te
lnet
apr/20 08:35:04 system,info ip service changed by admin
apr/20 08:35:04 system,info ip service changed by admin
apr/20 08:35:05 system,info,account user admin logged out from 103.1.221.39 via wi
nbox
apr/20 08:35:05 system,info,account user admin logged out from 103.1.221.39 via ss


set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes port=8080
set ssh disabled=yes
set api disabled=yes
set winbox address=naseverejky,10.0.0.0/8,192.168.0.0/16
set api-ssl disabled=yes

edit: nelze mi přiložit soubor z vypisu monitoringu sítě, píšte to že je soubor moc velky ale má jen 150kB tak nevím. ale tam je jasně vidět odkud to šlo.
0 x

pgb
Příspěvky: 466
Registrován: 2 years ago

Příspěvekod pgb » 6 months ago

s takovouhle restrikcí se můžeš jít zahrabat :) ...
naseverejky,10.0.0.0/8,192.168.0.0/16
... stačí jeden neaktualizovanej, nezafirewallovany mk třeba u klienta na veřejce nebo i ve vnitřní síti s nat 1:1 a průnik je na světě .. .dyť ten vir první co zkoumá je jeho nejbližší okolí
0 x

Dalibor Toman
Příspěvky: 1201
Registrován: 6 years ago

Příspěvekod Dalibor Toman » 6 months ago

menicks píše:Ano dle monitoringu sítě to šlo z venku a ne z vnitřní adresy a nebyl jsem jediný kdo to reportoval.
....


no tak to je opravdu sila. Mas k tomu nejaky komentar od supportu?
0 x

menicks
Příspěvky: 215
Registrován: 10 years ago

Příspěvekod menicks » 6 months ago

pgb píše:s takovouhle restrikcí se můžeš jít zahrabat :) ...
naseverejky,10.0.0.0/8,192.168.0.0/16
... stačí jeden neaktualizovanej, nezafirewallovany mk třeba u klienta na veřejce nebo i ve vnitřní síti s nat 1:1 a průnik je na světě .. .dyť ten vir první co zkoumá je jeho nejbližší okolí


Z klientského routeru se nelze dostat na pateř to už si řeší hlavní FW. Ty rozsahy jsou tam pro sichr kdyby jsme změnili, zvětšili rozsahy pateřních/klientských routeru. Jinak toto byl klientský router.
0 x

Dalibor Toman
Příspěvky: 1201
Registrován: 6 years ago

Příspěvekod Dalibor Toman » 6 months ago

pgb píše:s takovouhle restrikcí se můžeš jít zahrabat :) ...
naseverejky,10.0.0.0/8,192.168.0.0/16
... stačí jeden neaktualizovanej, nezafirewallovany mk třeba u klienta na veřejce nebo i ve vnitřní síti s nat 1:1 a průnik je na světě .. .dyť ten vir první co zkoumá je jeho nejbližší okolí


no a ted si na chvilku predstavme, ze se objevi nejaka dira v mac-telnetu/mac-winboxu a muzes si vymejslet firewally treba s 'drop any any' na prvnim radku
0 x

pgb
Příspěvky: 466
Registrován: 2 years ago

Příspěvekod pgb » 6 months ago

a někteří mi říkají, že jsem jsem paranoidní, když zakazuji mac-telnet na bridgi kde se potkávají klientská data z portu do vpls :)

PS: ano v případě hypotetického napadení core infrastruktury bych měl i tak smůlu ... vím :)
0 x


Zpět na „Konfigurace“

Kdo je online

Uživatelé prohlížející si toto fórum: Žádní registrovaní uživatelé a 8 hostů