Csak Magyarországon használt internet-szolgáltatók IP subnet listája?

Közösségi kerekasztal

ha korlátozni szeretné az ember h. kizárólag csak Magyarországi IP tartományról érkező kapcsolatok jöhessenek be egy portra, kell hozzá egy up-to-date IP subnet lista.

Régen mint h. ha a bix.hu-n lett volna ilyesmi, manapság honnan szerzi be az ember és különböző eszközökön SSH-ra hogyan állítja be?

 

pl.: Kínából, Oroszországból soha nem lépek be.. akkor minek engedni? Tudom.. vannak ezen logika ellen pl.: Mo.-i VPN-ek, amivel egy "támadó" ezt kikerüli, de még mindig jobb ötlet a whitelisting, mint h. blacklistezzünk.

related: Állást foglalt a Mikrotik az örök flame-ben: engedjünk-e mindenhonnan kapcsolódást SSH portra

https://hup.hu/cikkek/20220321/allast_foglalt_a_mikrotik_az_orok_flame-…

 

Köszi :)

  • 1138 megtekintés

( zrubi v | 2022. 03. 23., sze – 08:38 )

ezzel sokkal több a macera, mint amennyit hozzáad a hamis biztonságérzetedhez ;)

 

szerintem.

zrubi.hu

( wladek1 | 2022. 03. 23., sze – 08:56 )

geoip iptables/nftables szures nem opcio?

Error: nmcli terminated by signal Félbeszakítás (2)

Például a 154.54-es kezdetű címeket egyáltalán nem is tartalmazza.

Melyikre gondolsz, mert az a lista amit írtál ezekből 1-1 IP-t ír, legalábbis a start és az end ip ugyanaz. Viszont 1 szolgáltató min 1 C osztályt kap/routeolhat RIPE szerint ...

Fedora 41, Thinkpad x280

Ezekre:
 

154.54.16.16 154.54.16.19 4
154.54.16.208 154.54.16.208 1
154.54.16.211 154.54.16.211 1
154.54.16.213 154.54.16.214 2
154.54.21.160 154.54.21.160 1
154.54.21.19 154.54.21.19 1
154.54.21.218 154.54.21.218 1
154.54.21.34 154.54.21.34 1
154.54.32.197 154.54.32.197 1
154.54.33.177 154.54.33.177 1
154.54.37.133 154.54.37.134 2
154.54.37.137 154.54.37.138 2
154.54.38.245 154.54.38.245 1
154.54.38.45 154.54.38.46 2
154.54.56.60 154.54.56.60 1
154.54.56.63 154.54.56.63 1
154.54.59.178 154.54.59.178 1
154.54.59.197 154.54.59.198 2
154.54.59.201 154.54.59.202 2
154.54.59.204 154.54.59.204 1
154.54.59.207 154.54.59.207 1
154.54.59.212 154.54.59.212 1
154.54.59.215 154.54.59.215 1
154.54.61.245 154.54.61.245 1
154.54.63.197 154.54.63.197 1
154.54.63.201 154.54.63.201 1
154.54.63.210 154.54.63.210 1
154.54.63.244 154.54.63.244 1
154.54.63.247 154.54.63.247 1
154.54.73.81 154.54.73.81 1
154.54.74.116 154.54.74.116 1
154.54.74.119 154.54.74.119 1
154.54.76.161 154.54.76.162 2

 

A lényeg hogy a másik ezeket egyáltalán nem tartalmazza. És ezt csak véletlen szúrtam ki. Gondolom vannak még különbségek.
Nem tudom melyik lista a jó/jobb. Csak feltűnt az eltérés.

Még 1x leírom 1-1 IP-t nem kap egy szolgáltató min C osztályt. így fogalmam sincsen mi az, hogy 1 tartományból 1 IP "magyar"

pl. 1 IP-t RIPE tól lekérdezve:

https://apps.db.ripe.net/db-web-ui/query?searchtext=154.54.16.211

Baromira nem magyar. Így ettől a listától én eltekintenék. Szerintem ahogy írták maradjál nyugodtan valamelyik geoip adatbázisnál. Azok is általában a RIPE és társai ból veszik az adatokat.

Persze árnyalja a képet, hogy ha van egy /22 től attól tunnelen keresztül használhatom én azt Kínában is ...

Fedora 41, Thinkpad x280

Én értem hogy mit mondasz, és engem nem is kell meggyőznöd. Azonban a dolognak annyi értelme csak lehet hogy első körben már kizárod azokat a fix helyi (orosz/iráni/észak-koreai, stb) szolgáltatókhoz (egyértelműen) tartozó tartományokat, ahonnan 99%-os valószínűséggel csak a sz@r jön/jönne értelmes megkeresés nem. Persze nyilván akkor ha nem a facebook.com-ot hanem pl egy magyar kis/középvállalkozás hálózatát üzemelteted akinek egyébként semmi kötődése a kizárt tartományokhoz köthető országokhoz.

De én fejlesztő vagyok nem sysadmin, szal fenntartom a lehetőséget hogy én gondolom rosszul.

Teljesen laikus kérdés, előre szólok h. nem értek hozzá, sosem dolgoztam sem networkingben sem ISP-nél, ergo a hülye kérdést ennek megfelelően reagáljátok le:

ha 1 rúterbe be szeretném tenni az összes ipv4 destination címet (helyesebben destination networköt, mivel nem kell mind a 4 milliárd /32-es címet egyenként letárolni), hogy mit merre kelljen küldenem (feltételezve h. >1 irányban látom a teljes internetet), akkor mekkora a "teljes rúting tábla" mérete manapság? Azaz egy nagy ISP-nek mekkore rúting táblát kell kezelnie az edge rútereinek, amik a külvilág felé látnak ki a saját belső rendszeréből? Annyi minimális tudomásom a BGP vs interior rúting protokollok (pl. ospf) különbségéről, hogy egy "benti" rúternek nem kell ismernie az egész világot ahhoz, hogy el tudjon küldeni 1 csomagot "bárhová".

Soknak, főleg régebbi core eszközökön. Amik mondjuk csak 256k tudtak. Persze értelemszerűen sok szolgáltatónak nem kell ennyi. 

Teszem azt valaki bevisz a BIX-be egy routert. Ott most talán 100-200e a prefixek száma. Ez ugye belfőld. Külföldhöz pedig általában kap BGP-n egy 0.0.0.0/0 prefixet, ha több partnere van, akkor nyilván kaphat több 0.0.0.0/0 -t is.  Ott nem jellemző a teljes táblá átküldése mert ugye minek, ami nincsen a BIX-en megy a 0.0.0.0 felé :>

Fedora 41, Thinkpad x280

Nagyon regi eszkozrol lehet szo ami "core router" es csak 256k fer bele. Jo par eve (10+) nem gond a 1M+ route egy asr9k/mx es e feletti routereknek, de teljesen igazad van, nagyon sok esetben teljesen felesleges a full feed es a 0/0 pontosan eleg, mert csak redundancia miatt van pl multihoming.

Erdekes lehet az az uzlet, ahol a full feed-re van igeny, de maga a biznisz nem birja el az ehhez megfelelo eszkozok beszerzeset, persze ertem en hogy jo dolog volt regi 6500-akat eletben tartani, de egyreszt egy sup2t-t nem kaptal nagyon gombokert soha, masreszt irgalmatlanul sokat fogyaszt, plusz egy ido utan a Nx10G sem volt eleg. Egyebkent az L3 switch szerintem teljesen rendben van, bcm jericho-ra epulo platformoknak nagyon jo a port/ar ertek es a full feed-el is elvannak es ahol nem kell full feed ott meg olcsobban is ki lehet jonni. Mikrotiket szeretjuk, de OOB-nel tobbet nem kell rabizni:)

Mi a RAM igénye 1M route entry-nek? Van rá valami képlet?

Ha én egy ISP vagyok nemzetközi kijáratokkal, és kellene nekem az az 1M entry, milyen az a legócskább vaterás/ebay-es cisco vas, amin már technikailag elfutna ez a mennyiség? Teljesen játszós szituációra gondolj, semennyire nem valódi prod rendszer 100K+ előfizetővel, csak magának a rútingnak a működőképessége okán! Nem kell a 100Tbit-es forgalomhoz passzoló supervisor modul!

Pl. porosodik nálam egy cisco 2811, az 768MB-ból mit bírna el? Mondom, játszós eszköz, semmi valódi milliárd dolláros infrastruktúrára nem kell gondolni. (akár Advipservices szoftverrel, ha az kell hozzá)

1M nem keves, de a mai eszkozoknek nem gond. A tobbi kerdesedre pedig,
- a RAM meretetol fugg a RIB merete, ugye ha 2 db full bgp feed-et kapsz akkor az 2M route, ha egy feed 1M. Sokszor van ra lehetoseg hogy tobb ramot tehetsz az adott platformba igy kitolva a RIB meretet is.
- CPU, ha flappel egy link es eltunik majd visszajon +1M route akkor azt a CPU porgeti vegig, hogy mi legyen a best path.
- FIB ide kerulnek az active/best path-ok, ez altalaban egy fix meretu dolog (TCAM), nem bovitheted.

chassis based eszkozoknel ezek a supervisor lego kockai es egyben tudod cserelni, igy egy chassis tobb generaciot es igenyt is ki tud szolgalni (a marketing szerint:) )

( wpeople v | 2022. 03. 23., sze – 09:17 )

Szerkesztve: 2022. 03. 23., sze – 09:47

a bix.hu-n továbbra is van szabadon letölthető lista DE ezen prefixek nem a magyar prefixek listája, hanem azon prefixeké, amelyek Bixen-n át elérhetők.
Ide érte HurricaneElectric által tranzitált IPcímeket is pl...

Van több GeoIP szolgáltató akitől elég naprakész listát tudsz letölteni lokáció alapján - free ill. fizetősben is.

( persicsb | 2022. 03. 23., sze – 09:50 )

Definiáld pontosan, hogy mit tekintesz magyar meg kínai címnek. Egy magyarországi VPS szolgáltatónál is lehet elhelyezve olyan szerver, ami oroszoké. Magyar telkom szolgáltató által magyar földrajzi helyen nyújtott IP címen is futhat kínai botnet.

Totál értelmetlen, amit csinálni akarsz. Ez ellen nem így kell küzdeni.

( vl v | 2022. 03. 23., sze – 10:48 )

Szerkesztve: 2022. 03. 23., sze – 10:49

A BIX oldalán van szolgáltató és AS-szám lista. Az AS-szám alapján a RIPE whoisból lehet inverse queryvel route listát szedni (pl. whois -h whois.ripe.net -i origin as15545). A lista nem lesz teljes, mivel ami cím nem a RIPE-tól származik, az ide nem is kerül be, a többi régióban pedig szerintem nincs ilyen szolgáltatás. Emiatt jó eséllyel az access szolgáltatások benne lesznek, de mondjuk a globális cloud szolgáltatók címei meg vagy igen, vagy nem.

Egyetértek amúgy: hacsak nem pár magyarországi szolgáltató címeit akarod így felvenni, akkor ez bőven sok macera. Ha tudod, melyik az a pár szolgáltató, ami szóba jöhet, akkor arra ezt meg lehet csinálni. Viszont az is igaz, hogy ha a nagy access szolgáltatókat felveszed (UPC/Voda, T, Telenor/Yettel), akkor szinte biztos, hogy egy csomó botnak is nyitod a kaput, azaz tényleg hamis lesz az a biztonságérzet.

Értelmesebb megoldások:
- szolgáltatói VPN
- kopogtatós engedélyezés, rövid fehérlista otthoni fix címre, másik VPS címére, stb.
- fehérllistához valamelyik szolgáltatónál fix IP címet allokálni, azt felvenni a fehérlistára, és amikor kell, akkor fellőni egy pici VM-et a fix címmel jumphostnak

( wladek1 | 2022. 03. 23., sze – 11:07 )

Annak mi az akadalya, hogy pl. egy OpenVPN -t kozbeiktass? 

Error: nmcli terminated by signal Félbeszakítás (2)

Ahogy az SSH-ba is be kell lépni. Az, hogy az egyes megoldások milyen biztonsági rétegeket biztosítanak erre, az más kérdés.

SSH esetén is lehet neked MFA-d, leveles értesítésed, címszűrésed, kulcsos authod, sok minden.
Az egyes VPN megoldások belépési lehetőségei is lehetnek sokfélék.

Nagyon nem mindegy, hogy egy rétegen, vagy kettőn kell áthámoznia magát - az sshd természetesen nem a publikus IP-n hallgat, hanem egy olyan IP-n, ami csak a felépített VPN-tunnelből érhető el. AHogy mondani szoktam "csőbe húzott ssh"-t csinálsz.
Az általam használt vps-en nincs "csőbe húzva" az ssh, van viszont 2FA az ssh-kulcsos auth mellé (jelszavas login tiltva), plusz fail2ban - bár ez utóbbi nem nagyon gyűjtögeti a találatokat, de "enni szinte nem kér", de amint látszik, azért nem rá van bízva a biztonság.
Néztem a geoip-alapon történő szűrést, de annyi időm/energiám (még) nem volt, amennyi ahhoz kéne, hogy jól (és önjáró módon) működőre összerakjam.

Nem biztonságosabb csőbe húzni az ssh-t.

Nem az kell, hogy eldöntse, hogy egy kliensnek engeded-e a csatlakozást, hogy honnan jön, hanem attól, hogy ő kicsoda. Az autentikáció a lényeg, nem az egyéb védelminek gondolt, de valódi védelmet nem nyújtó rétegek.

Van egy pszichológiai vetülete is az egymásra rétegzett védelminek gondolt megoldásoknak: minél több rétegen kell magát áthámoznia egy felhasználónak, annál hanyagabb lesz: ugyanazt a jelszót fogja használni, felírja a jelszót, ha a kettő eltér, próbál valamilyen shadow IT-t megvalósítani, hogy megkerülje az überbiztonságosnak gondolt megoldást.

A VPN továbbra is infrastruktúra kiépítésére való, és nem védelmi megoldás.

Amúgy ennyi erővel sima telnetet is használhatnál a VPN kapcsolaton belül, felesleges az ssh, ha azt mondod, hogy abban a kliensben, aki VPN-ről jött, megbízol, hiszen VPN-en belül van, másban meg nem.

Na mégygeszer... Van egy cső, amihez kell egy bizonyos azonosítás, mondjuk smartcard/token/egyéb nyalánkság (nem, a jelszó már régóta nem felel meg önmagában). Ez egy szint ahhoz, hogy egyáltalán az sshd-vel szóba tudjon állni. Ez után egy másik kulcsot/2FA-t ingyombingyomot (jelszó itt sem játszik!) kell használnia, hogy az sshd "túloldalával" szemben azonosítsa magát.

És igen, ha a vpn két vége "trusted", akkor abban a vpn-ben bőven mehet plaintext protokoll is - ahogy a http-is "csak" be van csomagolva TLS-be.

Szóval mi a biztonágosabb? Két réteg, megfelelően erős, egymástól független authentikációval, vagy egy réteg ugyanazzal az authentikációval, mint az előbbi? Ha egy rétegnél megbízol a kliensben, akkor kettőnél miért nem?

 

Ezesetben a biztonságot csak a több lépcsős azonosítás ad, nem a VPN. Pőre SSH-val is meg tudod valósítani a soklépcsős azonosítást, felesleges a VPN. Nálad is akkor lesz valaki trusted, ha több lépcsőben azonosította magát, a VPN-t itt csak arra használod, hogy az ő azonosítási szolgáltatásán is át kelljen menni. 

Ezt mezei SSH-val, VPN nélkül is meg tudod csinálni. MFA-t az OpenSSH is támogat gond nélkül. 
A két egymástól független autentikáció ugyanolyan álbiztonság, mint amikor a titkosított anyagot titkosítod.

A két egymástól független autentikáció ugyanolyan álbiztonság

Egy kivétellel nem: ha az egyik technológia eltörik (nem véd, nem azonosít), akkor annak az esélye csekély, hogy a másik is vele együtt eltörik, már persze ha nem ugyanaz van mindkét technológia alatt. Persze ha openssl-re épül mindkettő, és az openssl-ben találnak valamit, akkor Így Járás van.

A VPN egy előszűrés: csak az és csak onnan fér hozzá az ssh-hoz, aki fel tud építeni egy vpn-csatornát - attól függetlenül, hogy hol, merre van épp a világban. A pőre ssh-n a 2FA alap, viszont ha magában az implementációban van luk, akkor toszhatom, ellenben ha vpn-be van csomagolva, akkor az ssh közvetlenül nem támadható.

( hunti v | 2022. 03. 23., sze – 14:13 )

Én fordítva ültem a lóra, a nem RIPE /8-as subneteket tiltottam ki első sorban, bejelentkezési próbálkozások jelentős része ezzel blokkolva lett. A többire meg ott van a fail2ban (legalább is debianon). Hálózati eszközök kizárólag fixen definiált IP cím listáról fogadnak kapcsolatot, ezek saját VPN végpontok, illetve saját és bérelt VPS szerverek.

( x-daemon | 2022. 03. 24., cs – 12:56 )

Szerkesztve: 2022. 03. 24., cs – 12:57

mar nem emlexem hogy itt segitett valaki vagy a google segitett, igy csinalom maxmind regisztracio utan ahol kaptam egy license_key-t amit a MYKEY helyere kell beirni:

curl 'https://download.maxmind.com/app/geoip_download?edition_id=GeoLite2-Cou…' -o GeoLite2-Country-CSV.zip
curl 'https://download.maxmind.com/app/geoip_download?edition_id=GeoLite2-Cou…' -o GeoLite2-Country-CSV.zip.sha256

ha kell legacy GeoIP.dat akkor a geolite2legacy.py-al atkonvertalom (https://github.com/sherpya/geolite2legacy)

./geolite2legacy.py -i GeoLite2-Country-CSV.zip -f geoname2fips.csv -o GeoIP.dat

./geolite2legacy.py -i GeoLite2-Country-CSV.zip -f geoname2fips.csv -o GeoIPv6.dat -6      
 

de a csv-bol is ki lehet grepelni, a 719819 ami kell neked:

grep 719819 GeoLite2-Country-Blocks-IPv4.csv

neked aztan fura humorod van...