csomag szures stb

[ka at mayten.sch.bme.hu]

Szia,

mint egykor kollegiumi netadmin, nem azt mondanam meg, hogy mit csinalj, 
hanem azt, hogy mi hogy csinaltuk.

On 2014-12-09 16:14, Zoltán Takács wrote:
> - loggoljam, hogy melyik végpont mikor-mit csinált, hogy ha
> szankcionálni kell, akkor legyen hol utána néznem...

ez minket kevesbe erdekelt, az erdekelt inkabb, hogy az IP amivel 
problema volt, az kie volt.  nem tudom nalad mekkora savszelesseg van, 
nalunk akkoriban 1 giga es kb 1200 forgalmazo gep.  Nincs az a hely 
ahova rogzithetnenk ki mit csinalt.  Az IP cimet mindenki felevente ujra 
kellett, hogy reigsztralja, azaz nevere vennie, a kovetkezo 
regisztracioig o felelt erte.

Akkoriban elegendo volt az IP - MAC cimparokat figyelni.  Ez olcso 
megoldaskent egy arpwatch is megoldja.  Nalunk amikor meg nem volt DHCP 
bevezetve (sot, tiltva volt) akkor minden esetben, amikor egy nem 
parositott ip - mac jelent meg a halozaton, azt kitiltottuk.  Modern 
kori megoldasok: VMPS, 802.1x, NAC, ezek mindegyike szofisztikaltabb 
megoldas ma mar, mint egy sima MAC figyeles (de a MAC figyeles a 
legolcsobb).

Amennyiben van DHCP nalatok (vagy lesz) es olyan a halozat is, force-old 
a DHCP hasznalatat dhcp snooping, ip source guard es DAI beallitasaval.

A MAC-re szures elonye, hogy nem kovetel a felhasznalotol extra 
autentikaciot, konnyebb es gyorsabb implementalni, hibakeresni, 
ugyanakkor kevesse biztonsagos, mint a felhasznalo azonositasa.

> - legyen lehetőségem sávszélesség állításra - lehetőleg
> felhasználónként vagy végpontonként... (a m0n0wall még mindig jó...)

IP cimenkent csinaltunk savkorlatot, egy masik VLAN-ba leptettuk az 
adott vegpontot (itt mar VMPS-t hasznaltunk, azaz mindegy hova volt 
bedugva a PC, az a port ahova kotottek mindenkepp a savkorlatozott 
VLANba kerult).  De volt olyan atmeneti idoszak is, amikor maradt az IP 
cime, maradt a VLANja is, ellenben a routeren egy policy map-et 
illesztettunk a kerdeses IP-kre es leszabalyoztuk onnan.  Ennek 
hatranya, hogy szoftveres megoldas, azaz mindenkepp CPU novelo a 
routeren.  itt megint csak az a lenyeges kerdes, hogy mekkora 
savszelessegre tervezel.  akkoriban nalunk hat-hetszaz mbit/s volt a 
plafon, azaz amit tenyleg forgalmaztak a kollegistak.

> - legyen lehetőségem pl. a torrentezés tiltására vagy legalábbis
> visszabb szorítására (itt valami csomagszűrésre vagy mit tudom én,

Hat, mi is akartuk tiltani, de akkor mi honnan szereztunk volna 
filmeket, ha senki nem tolti le? :)  Elso korben anno bevezettem az 
NBAR-t, amivel lehetett protokoll analizist csinalni egy egyszeru 
supervisor modulon is.  Hatranya, hogy idonkent annyi CPU-t hasznalt, 
hogy az egesz router belefagyott.  De amikor mukodott, egesz jo volt, a 
torrentet, legyen barmilyen porton, szepen lekorlatozta.

Mai megoldaskent en nem is gondolnek masra, mint alkalmazasi reteg-beli 
tuzfalra, peldaul egy megfelelo palo alto elbir barmilyen 
savszelesseggel.  ismet ugye a kerdes, mekkora sav, hany vegpont.

> beállítható, hogy a sávszélesség mondjuk 80%-át a 80-as porton
> forgalmazza és a maradék 20%-ot a többin.... Na, ilyet a m0n0wall-ban
> nem találtam...
> 

ezt sima iptables + tc megoldja neked, egy script az egesz.  de megint 
csak: ez full szoftveres megoldas, van az a savszelesseg amivel egy PC 
mar nem bir el es szuk keresztmetszet lesz.  a redundans megoldasrol nem 
is beszelve, ha van egy linuxos PC ami tuzfal, akkor az egyben single 
point of failure.  ha nincs sok felhasznalo, nem gond, de mondjuk nalunk 
ezer kollegista dorombolt az ajton egyszerre, ha nem volt net, plusz aki 
nem kollegista volt de kollegista eroforrast hasznalt volna kintrol, pl 
email, levlistak.

de amugy is, a torrentezes tok fuggetlen a portszamoktol, ugye az sehol 
nincs eloirva, hogy torrentezni ne lehetne a 80-as porton, raadasul ez a 
megkozelites megoli a standard ftp (20/21), scp (22), voip (5060 + rtp 
portok) es altalaban a stream hallgatast (gyakran jonnek a streamek pl 
8080, 8000 portokon).  Ha ezeknek mind 20%-on kell osztozni, mindenki 
hamar fog http tunnelezni.

nem tudom hany vegpontra tervezel, mekkora savszelesseged van, lehet, 
hogy valami linux-alapu megoldas is tokeletes lesz es nem kell 
tulgondolni.

udv
adam