layer3 korlátozás kliensek közt, routerrel

Security-all

adott egy mezei router [egyik portja a wan, eth1], rajta kliensek [eth2-3-4-eth5], ok [routeros, de az mindegy, a kérdést általánosságban tenném fel]

cél: a kliensek NE lássák egymást -> mármint "belső hálózaton" [tehát ha még cam attack-el letámadja egy belső gép a routerboard 450G-t, akkor se tudja az promiscous módban lelesni a másik gép, pl.: ftp forgalmát, az által az ahhoz tartozó jelszót]

router ip = 192.168.1.1
chain = forward
srcip = 192.168.1.2-192.168.1.255
dstip = 192.168.1.2-192.168.1.255
action = drop

-> de ez nem jó, mert a támadó simán felveszi a 192.168.1.1-es ip címet, és kész...

milyen lehetőségek vannak a korlátozásra még? vlan? layer2-őn érdemes korlátozni?

előre is köszi!

  • 2342 megtekintés

( Mcsiv v | 2010. 11. 05., p – 12:26 )

semmilyen, mert emlékezetem szerint a routerboard 450G lan oldali portjai nem külön lan portok, hanem fizikailag egy port + switch


gbor@debian:~$ wget -q -O - "http://pastebin.com/download.php?i=X8FuRYb7" | grep -i -B 2 "name=ether[0-9]"
/interface ethernet
set 0 arp=enabled auto-negotiation=yes bandwidth=unlimited/unlimited comment="" disabled=no full-duplex=yes l2mtu=1524 mac-address=XX:XX:XX:XX:XX:XX master-port=none mtu=1500 \
    name=ether1-gateway speed=100Mbps
set 1 arp=enabled auto-negotiation=yes bandwidth=unlimited/unlimited comment="" disabled=no full-duplex=yes l2mtu=1524 mac-address=YY:YY:YY:YY:YY:YY master-port=none mtu=1500 \
    name=ether2-local speed=100Mbps
set 2 arp=enabled auto-negotiation=yes bandwidth=unlimited/unlimited comment="" disabled=no full-duplex=yes l2mtu=1524 mac-address=ZZ:ZZ:ZZ:ZZ:ZZ:ZZ master-port=none mtu=1500 \
    name=ether3-local speed=100Mbps
set 3 arp=enabled auto-negotiation=yes bandwidth=unlimited/unlimited comment="" disabled=no full-duplex=yes l2mtu=1524 mac-address=QQ:QQ:QQ:QQ:QQ:QQ master-port=none mtu=1500 \
    name=ether4-local speed=100Mbps
set 4 arp=enabled auto-negotiation=yes bandwidth=unlimited/unlimited comment="" disabled=no full-duplex=yes l2mtu=1524 mac-address=TT:TT:TT:TT:TT:TT master-port=none mtu=1500 \
    name=ether5-local speed=100Mbps
gbor@debian:~$

egy reset/default config megtartás után ezt írja. szóval külön lehet configolni az egyes portokat. alapból pedig egy bridge-ben van az eth2-3-4-5

a kérdés "általánosságban" szólna, mármint mit szoktak ilyenkor kitalálni/alkalmazni, h. a kliensek el legyenek szeparálva egymástól? :O

( KomiZ | 2010. 11. 05., p – 15:44 )

Ha külön alhálóba teszed a klienseket, az nem jó?
Ezután ip alapon lehet tűzfalazni.
És persze a LAN oldal ne legyen összebridgelve, vagy ha igen, elvileg van valami
firewall a bridge résznél is, de azt nem néztem sosem.
Ha külön ip tartomány a LAN 1-2-3-4, (eth2-eth5) akkor lehet figyelni, hogy ha pl
lan1 192.168.1.0/24, akkor ha src ip nem ebből van, de in interfész lan1, akkor drop.
stb.

( dash | 2011. 04. 10., v – 00:06 )

subscribe

---
színes
Hogyha egy üvegfenekű űrhajóval fénysebességgel közlekedünk és hátranézünk a kilövés pillanatát látjuk állóképen.

( nehai v | 2011. 04. 09., szo – 15:29 )

Ha az eth2-5 bridge-be van akkor írd be ezt a sort az
"/interface bridge filter" táblába:

chain=forward out-interface=!eth1 out-bridge=bridge1 action=drop in-interface=!eth1 in-bridge=bridge1

( eCaffee | 2011. 04. 10., v – 07:39 )

adott egy mezei router [egyik portja a wan, eth1], rajta kliensek [eth2-3-4-eth5]...
cél: a kliensek NE lássák egymást -> mármint "belső hálózaton"... akkor se tudja az promiscous módban lelesni a másik gép, pl.: ftp forgalmát...

Vegyél n darab legolcsóbb kis switchet, és tedd a kliensek és a router közé...
máris kész a hardveres védelem a lehallgató mód ellen...

Szoftver oldal: a kliensekre pl. Little Susie vagy openSUSE (még sok más disztró alapból megfelelő, a Windows és az Ubuntu NEM...mielőtt még mindenki nekem esne, nem szapultam az Ubuntut, mindössze a biztonsági modellek közt tettem különbséget. A Windows is konfigolható kegyetlen megszorításokra, de mivel nem ez a jellemző eset, gyári biztonsága adott esetben csak pár percre elegendő. A módosítatlan Ubuntu számára a gazda és a user egy személy, akinek érdekeit védi és elő is segíti, a kérdésben vázolt tevékenységekben pedig messzemenően támogatja. Ez céges környezetben egy kliens gépen nem megengedhető.)

Ha ezután még mindig üldöz az egészséges szakmai paranoia,
akkor a klienseket tedd ifup-ra NetworkManager helyett,
és az összesről töröld a libpcap-et is, ehhez le kell szedni
a DSL és a modemes tárcsázót, smpppd, pptp, stb.
Függenek tőle, de belső hálón nincs is rájuk szükség.
A grub-ból init-en keresztüli rootolás ellen lehet védekezni,
már csak egy jó BIOS password kell és kis lakat a gépházakra. :)

-
"Attempting to crack SpeedLock can damage your sanity"

( gbor | 2011. 04. 10., v – 10:51 )

na, hozzászóltak, zsír! :)

azóta viszont megnéztem a dolgot, és rájöttem: nem mindig lehet tűzfalszabályként lekorlátozni azt, h. pl.: az alhálózaton a pl.: 192.168.1.5 a 192.168.1.10-el beszélget, mert egyszerűen tcpdump-ban sem jelenikg meg a forgalom. pedig a két ip mögött levő gép kommunikál egymással

A LÉNYEG: azóta már az OpenVPN mellett tettem le a voksomat. hisz hitelesítve van a server oldal+a teljes forgalom titkosítva van=nem lehet átb*szni [elvileg] - csak h. ha vkit érdekel a megoldás, ez lett

hm, most megfogtál, de szerintem véd, lévén, hogy ha rendesen be van állítva akkor csak a routterrel* tudsz kommunikálni, más gépet pedig ha akarsz sem látsz (Layer 2 szintű szeparáció)

Olcsó switch-ben még nem láttam Private VLAN-t.

*: behelyettesítendő tetszőleges más eszközzel

ott is lehet játszani, de ez már massive attack.
A private vlan kinyitasi modszere, hogy "eldugitod" az adott switch arp tablajat, bar erre meg switch valogatja, hogyan reagal. Az esetek 90%-ban minden laba nyitott lesz es minden forgalom mindenhova eljut (atvalt hub modba). Rosszabb esetben osszefossa magat.
Ez persze az olcsobb switchekre igaz, de a legtobbel eljatszhato