-
Fototrend
Mikrotik routerekkel foglalkozó téma. Mikrotik router típusok, hardverek, router beállítások, programozás (scriptek írása), frissítés, és minden Mikrotik routerrel kapcsolatos beszélgetés helye.
Új hozzászólás Aktív témák
-
amol
addikt
Ennek a tápjával próbáltam, meg sem fordult a fejemben hogy esetleg nem egyenáramú ezért nem is néztem meg figyelmesebben.
Kitalálom tudom-e használni valahol illetve hogy van-e kedvem kisilabizálni a beállítását és jelentkezem.
Apropó, az ADSL modemek nem érdekelnek mennyiségi kedvezménnyel? -
gazrobur
csendes tag
Sziasztok.
Lehet olyat csinálni, hogy Mikrotik router-be bedugom a pendrive-ot, és távolról elérve, hozzá tudok férni a pendrive-on lévő adatokhoz. Megoldható ez? Persze van NAS, de Mikortik routerrel meg lehet ezt oldani?
Köszönöm segítségeteket.
-
#96292352
törölt tag
-
#96292352
törölt tag
válasz gazrobur #1608 üzenetére
Szerintem elég hogy legyen rajta USB.
Nekem ilyen van: Mikrotik 2011uias-2hnd -
-
nyilasmisi
tag
Szerintetek egy HAP eth5-ös portja amely POEout-os arra ráköthető távtáplálás gyanánt egy mAP Lite?
A pdf doksi szerint az mAP az 5-60V-ig fogad feszültséget, viszon magára a mAP Litre 5V power only felirat van gravírozva, és micro USB-s csatlakozós saját táp van gyárilag hozzá!
Nagyon jó lenne ha nem kellene a gyári telefontöltőt használni hozzá!
Egyelőre nem merem POE-san meghajtani a HAPból! Van valakinek valami 5lete? Nem szeretném a kis mAP-t kinyírni!
Köszönöm a segítséget -
brickm
őstag
válasz nyilasmisi #1616 üzenetére
Azért az van rágravirozva,mert az az USB-s tápra vonatkozik.. Ott ez a szabvány.
A leírása szerint:
The device accepts powering from the USB port or from the Ethernet port:
micro USB power jack accepts 5V DC, a USB 5V adapter is included with the product The Ethernet port accepts passive Power over Ethernet 11-57V DC.Szóval POEn nyomhatod neki az 57voltot is.
-
brickm
őstag
válasz nyilasmisi #1618 üzenetére
[link]
Az ötödik képen ottvan, hogy 5volt mellette meg POE IN 60Vmax -
brickm
őstag
Meg tudná valaki mondani mi történik ebben a videóban pontosan?
[link]
1 perces az egész, egy filter rile-t ad hozzá. Csak nem értem mi történik. -
Ablakos
őstag
Nem értem a lenti szabályok szerint, hogy a 22 portra az első próbálkozásra miért kerül a black listába a remote ip? Nem úgy működik a filter, hogy első szabály egyezés után végetér a (input) lánc feldolgozása?
8 ;;; drop ssh-22-port--blacklist ports
chain=input action=drop protocol=tcp src-address-list=ssh-22-port--blacklist dst-port=22 log=no log-prefix=""9 ;;; add to ssh-22-port-blacklist on 22 port connecting
chain=input action=add-src-to-address-list protocol=tcp address-list=ssh-22-port--blacklist address-list-timeout=0s dst-port=22 log=no log-prefix=""[ Szerkesztve ]
-
brickm
őstag
válasz Ablakos #1621 üzenetére
Néztem mikrotik wiki-s brute force filter rule-t.
Ami:
add chain=input protocol=tcp dst-port=22 src-address-list=ssh_blacklist action=drop \
comment="drop ssh brute forcers" disabled=noadd chain=input protocol=tcp dst-port=22 connection-state=new \
src-address-list=ssh_stage3 action=add-src-to-address-list address-list=ssh_blacklist \
address-list-timeout=10d comment="" disabled=noadd chain=input protocol=tcp dst-port=22 connection-state=new \
src-address-list=ssh_stage2 action=add-src-to-address-list address-list=ssh_stage3 \
address-list-timeout=1m comment="" disabled=noadd chain=input protocol=tcp dst-port=22 connection-state=new src-address-list=ssh_stage1 \
action=add-src-to-address-list address-list=ssh_stage2 address-list-timeout=1m comment="" disabled=noadd chain=input protocol=tcp dst-port=22 connection-state=new action=add-src-to-address-list \
address-list=ssh_stage1 address-list-timeout=1m comment="" disabled=noHa megnézed előbb van a drop rule, mint az, hogy adja a címet a listához. MIért vajon.
Én megfordítottam a dolgot, ez befolyásolj a működést?De a stage-ek is fordítva épülnek fel.
Szerk.:
Áhám.
Szóval előbb van a drop, mint a vizsgálat, hiszen ha előlről nézzük a láncot, jön egy kérés, megnézi el kell e dobni, ha nem megvizsgálja szerepel e a stage3-ban, nem, ha megnézi szerepel e a kettesben, nem megnézi szerepel e az 1esben, ha illik rá az egyes és nem szerepel benne beleteszi.
HA ezeket előbb végigzongorázn és csak utána drop-olna, akkor gyakorlatilag a stage 1-2-3 midnig lemenne akkor is ha droppolni kell már a címet.[ Szerkesztve ]
-
kammler
senior tag
Heló!
Nyüstölök egy RB3011-es mikrotikot. VPN-t akarok. PPTP az megy, L2TP ipsec az nem, kívülről, internetről. Egy androidos telóról probálom. Egy belső gépről, belső hálóról rögtön csatlakozik a mikrotikra l2tp vpn-el, megosztott kulccsal egy pc, úgyhogy gyanítom, hogy tűzfal, NAT gond. Teló felől jó a dolog, van egy mikroserverem, arra simán felmászik l2tp vpn-en a teló. A mikrotik a retkes t-s optikai modem mögött van( régen itthon ment a HP microserver, arra másztam rá l2tp vpn-el, egy laptoppal. Na itt aztán gondok voltak a NAT-al, windows registrybe kellett állítanom ezt azt, csak úgy volt jó). Ötlet? 4500,500, 1701-es portok engedélyezve vannak.
[ Szerkesztve ]
-
#96292352
törölt tag
Én is hasonlóan oldottam meg eleinte a brute force-t, mint ahogy itt írjátok, de úgy gondolom van ettől sokkal jobb is:
Chain: input -> Action: drop. szerk.: a külső IP felől
ez megfog minden inputot, vagyis ami a routert éri, ha ez megvan akkor lehet szépen egyesével engedni azt amit engedni szeretnénk.
Én úgy csináltam, hogy ezt a szabályt ki lehessen bármikor kerülni, ha megnyitom pl egy böngészőben a router ipjének egy portját, ami ugye nem fog csinálni semmi látszólagost, de a háttérben hozzáadja a forrás ip-t egy "white list"-hez, aminek az action nem drop, hanem accept lesz.[ Szerkesztve ]
-
brickm
őstag
Az előbb én is kilőttem magamat belőle. ment a reset.
Mi az eltérés, ha egy filter rule eleje input, vagy forward.
Mondjuk ha van 2 rule, az egyik input in interface digi ISP action drop
a másik forward in interface digi ISP action drop -
-
brickm
őstag
válasz bambano #1631 üzenetére
Értem, köszönöm!
Most nekiláttam mindenféle okosságot elkövetni a tűzfallal, ezáltal már vagy 3 reseten túl vagyok, mert mindig sikerült kitenni magamat is itthonról.. .
Azt vettem észre, hogy:
Eddig volt egy ilyen rule-om a legvégén:
add chain=forward action=drop connection-state=invalid comment="default configuration"Kicseréltem erre:
add action=drop chain=input comment="Drop everything else"Azt látom mi a fizikális eltérés a kettő között, de ennek van valami jelentősége egyébként a gyakorlatban?
Azt vettem észre, hogy míg előbbivel nem kellett konfigurálni pl a winbox engedélyezést, ssh-t stb, addig ezzel kell. De mit kell még? Mi az amit eddig nem vettem észre és nem fog működni, csak mert erre cseréltem a rule-t?szerk.: első észrevétel, nem jön be a google.hu
[ Szerkesztve ]
-
brickm
őstag
No.
Egyelőre ez a firewall-om.
A sorrend jó lehet így?
[link]
Igazán nem tudom az a forward established közel 50MB adatforgalommal jó helyen van-e ott, nem kellene- előrébb lennie?(16)Illetve a 15-ösnek nem értem a szerepét.
Ha jól értem a PPPOE-vonalon érkező cuccokat dobja el, amennyiben nem volt addig accept(gazdája) rule rá.
De ez nem felesleges amennyiben ott a drop anything?
Illetve ez a drop invalid...mitől invalid a csomag?
Sokáig nullás volt a számlálója, azóta került bele valami már.A kopogtató rule jó helyen van így?
Amennyiben kizárnám magamat egy filterrel, megnyitom a 19227 portot, ezáltal az IP-m whitelistre kerül és SSH-n elérem. Leteszteltem az input new rule-t kivettem, nem volt elérhető semmi, se net, se router, majd whitelisteltem magamat és elértem SSH-n. Elvileg így jólehet a dolog. -
bacus
őstag
Ez egy jó nagy szar.
Minden uj, majd minden related input accept, utána minden más drop?
Leirták mit jelent az input és forward közötti különbség, olvasd át mégegyszer.Ne nyúlj a gyári tűzfalhoz, se a sorrendjéhez, mert az egyszerű, de legalább jó. Az pont azt tudja mint a tplink vagy többi soho mikor kipipálod, hogy tüzfal igen, spi igen.
Kössünk egyezséget, megegyezős egyezséget... https://www.paypal.me/engiman/30
-
brickm
őstag
Köszönöm, hogy ránéztél, igazából ebbe a sorrendi dologban csak az a poén, hogy ahány oldalt találok firewall ügyben, pont annyi ellentétet is.
És pontosan itt a fórumon kaptam azt az információt is, hogy a legvégére tegyek egy mindent eldobó rule-t.
Azt értem már mi az input és mi a forward, de ez nekem nem mond sokat sorrend szempontjábl. legfeljebb annyit, hogy tegyem a forwardot előrébb..Ha TP-linkes tűzfalat akarnék, visszatenném a tp linket a hálózatomba.
-
brickm
őstag
Közben előástam az eredeti tűzfalat, amit a mikrotik tesz fel nálam:
add chain=input action=accept protocol=icmp comment="default configuration"
add chain=input action=accept connection-state=established comment="default configuration"
add chain=input action=accept connection-state=related comment="default configuration"
add chain=input action=drop in-interface=ether1 comment="default configuration"
add chain=forward action=accept connection-state=established comment="default configuration"
add chain=forward action=accept connection-state=related comment="default configuration"
add chain=forward action=drop connection-state=invalid comment="default configuration"Ha megnézed itt is előbb az inputra érkező icmp cosmagról rendelkezik, majd az established-re majd a relatedre, majd eldob mindent ami a net felől jön és nem illett ezekre.
Itt következik a forward ugyan azzal a sorrenddel, majd eldobja a hibás csomagokat a végén.
Itt csak azért nincs ugye a state:new, mert ő nem hibás és bár nem illik rá egyik szabály sem, átengedi.(gondolom én)
mivel nálam a végén mindent eldob, nekem kell elé egy state:new.[ Szerkesztve ]
-
-
Ablakos
őstag
Ha hozzám hasonló műkedvelő szeretne egy alapszintű korrekt tűzfalat megalkotni, akkor ajánlom a linuxakademia honlapján egy korábbi képzésüket. Vagy marad a hamis biztonság, megfűszerezve egy kis szarozással.
-
bacus
őstag
3 alap chain van, input, forward, output
Az utolsót hagyjuk, az input a routeredbe megy, azt védi, ha bármit szürsz, a forward átmegy, mind a ki, mind a be csomagok, ezzel védheted a hálozatod.
Kezeld is külön!
Az elsö illeszkedö szabály után nincs tovább. Ha a végén van egy drop, az jó, de ha elötte minden uj, vagy erre kapcsolatos dolgot acceptálsz, akkor az egyenlö a mindent elfogaddal, vagy azzal ha nincs is szabály!
Kössünk egyezséget, megegyezős egyezséget... https://www.paypal.me/engiman/30
-
brickm
őstag
Oké, ez eddig világos, de még mindig nem értem, ha az új kapcsolatoknak felveszek egy acceptet, hiba, mert minden ide tud tartozni, de ha nem veszek fel ide egy acceptet, akkor nincs is új kapcsolat...
add chain=input action=drop connection-state=invalid comment="Disallow weird packets"
add chain=input action=accept connection-state=new in-interface=LAN comment="Allow LAN access to router and Internet"
add chain=input action=accept connection-state=established comment="Allow connections that originated from LAN"
add chain=input action=accept connection-state=related comment="Allow connections that originated from LAN"
add chain=input action=accept protocol=icmp comment="Allow ping ICMP from anywhere"
add chain=input action=drop comment="Disallow anything from anywhere on any interface"
add chain=forward action=drop connection-state=invalid comment="Disallow weird packets"
add chain=forward action=accept connection-state=new in-interface=LAN comment="Allow LAN access to router and Internet"
add chain=forward action=accept connection-state=established comment="Allow connections that originated from LAN"
add chain=forward action=accept connection-state=related comment="Allow connections that originated from LAN"
add chain=forward action=dropEz ismét egy mikrotikes firewall rule list, itt is azt látom:
Invalid csomagokat az inputról eldobja, majd established majd related elfogad, ami ebbe nem tartozott bele eldob.
(bár nem értem akkor ezzel hogy lehet új kapcsolatot létesíteni, hisz ha én kiveszem a new accept rule-jaimat elmegy a net...eztán forwardról is eldobja az invalid csomagokat és megismétli forward chain-en amit az előbb, majd mindent eldob.
Meglátásom szerint ugyan ez történik nálam is csak nincs köztes drop rule.
De ha elmagyarázod ez miért nem igaz az én esetemben, megköszönöm! -
irány, kolléga, irány.
ez a megoldás csak a belülről kifelé menő kapcsolatoknál fogadja el az új kapcsolatot, tehát kintről nem lehet bemenni. hogy egyébként hova menne kintről befelé, az egy kérdés.erősen nézd az in-interface paramétert.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
brickm
őstag
válasz bambano #1642 üzenetére
JA bocs, nem ezt akartam, mert ebben van in interface jelölve, csak nem vettem észre.
add chain=input action=accept protocol=icmp
add chain=input action=accept connection-state=established
add chain=input action=accept connection-state=related
add chain=input action=drop in-interface=ether1
add chain=forward action=accept connection-state=established
add chain=forward action=accept connection-state=related
add chain=forward action=drop connection-state=invalidszóval akkor ha jól értelmezem ezt, meg amit előbb kolléga írt, itt azért van internetkapcsolat, mert a forward chain-ben a drop nem mindent dob el, csak az invalid csomagot. Ha azt cserélném, akkor nem lenne netkapcsolat, csak ha betennék egy chain:forward state:new rule-t?
ÉS ahogy elemzem akkor a negyedik rule eldob minden kapcsolódási kísérletet ami az ether1-en jön(isp felől) amennyiben nem én kezdeményeztem, hanem ő szeretne magától?
[ Szerkesztve ]
-
-
brickm
őstag
válasz bambano #1644 üzenetére
az ether1 kifelé néz(elvileg..ez a gyári az rb750-en). talapból sz-r firewall-t tettek rá. nagyszerű.
LEhet egy radikális kérdésem?
Mivan ha én megfogok az összes RULE-t és törlöm.
Tegyük fel, csinálok egy teljesen új tűzfalat, ami annyit tesz, hogy belső háló függvényének teszi ki a winbox és ssh elérést, esetleg MAC azonosítással.Illetve teszek bele egy kopogtató portot magamnak gond esetére.
elfogadja az icmp csomagokat, illetve egy részét. (ping, traceroute, bandwith test)
Szűri az SSH és telnet brute force-t.
majd szűri a 80-as portot szkennelőket. Illetve gyüjti az IP-jüket és következő kapcsolódási kísérletnél már az inputon eldobja.
Ezen felül eldobom az invalid csomagokat.Minden más átmegy.
Ez így egy sebezhető tűzfal?Vagy ehhez még tegyem hozzá az input-ról való mindennemű kapcsolat eldobását?
[ Szerkesztve ]
-
te milyen belső hálón vagy, ahol ssh bruteforce-ra kell számítani?
kicsit zagyva, amit írsz.
a linuxban, következésképp a mikrotikben is, meg lehet mondani, hogy melyik interfészre kapcsolódjon a szerver program. ha azt mondod, hogy az ssh-t a belső hálózati interfészre rakod fel, akkor mi a francnak külső oldalról ssh brute force védelem, mikor annál jobb brute force védelem, hogy semmi nem figyel az adott porton, nincs???szerintem szépen csomagold el a mikrotikedet és kezdj el alapszintű hálózati ismereteket tanulni, mert nagyon durván nem látod, hogy mi hogyan és miért van.
a kérdésedre a konkrét válasz: fogsz egy mikrotiket, ráböksz a gyári beállítás visszaállítására. utána kigyalulod az *ÖSSZES* tűzfal szabályt. felraksz egy natolást. átrakod az ssh-t és a winboxot a belső interfészre, letiltod a telnetet és jónapot.
ha a belső gépedet ki akarod tenni web szervernek, akkor ehhez kell még egy dsnat szabály. a web szervert törögető okosokat pedig a web szerveren kell megfogni, http protokoll szintű elemzésre a mikrotiket nem használnám.
remélem, félreértettem, hogy az ssh védelem mac azonosítással című történetet a külső hálózati interfészen akartad megcsinálni.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
brickm
őstag
Azért köszönöm nektek az eddigi segítséget!
-
vjozsef
senior tag
válasz bambano #1646 üzenetére
Ez a hsz talan kicsit foldbe dongeto volt de nagyjabol en is ezt gondolom.
Sokan tulmisztifikaljak ezt a tuzfal dolgot otthonra, holott teljesen felesleges nyitott portokat letrehozni feleslegesen vagy hibasan beallitott szolgaltatasokkal, hogy utana legyen meg melo vele pl letiltani kivulrol.