Gépek azonosítása

Debian GNU/Linux

Gépek azonosítása

  • 929 megtekintés

( hackac | 2005. 05. 05., cs – 15:52 )

Hali!

Ipsec: a klienseket nem tudom turkálni, olyan megoldás kell, amit egy egyszerű leirat alapján bárki be tud állítani
Authpf: ue. nem tudnák mi az az ssh, minek kell ez, stb.
Ez a nocat igéretesnek tűnik. Kicsit beleásom magam...

És emberek: kösz mindenkinek az eddigi segítséget is, egyre jöbb és jobb tippeket adtok :lol:

Hackac

( nug | 2005. 05. 03., k – 20:46 )

[quote:8024c917e4="hackac"]Azt hiszem ez a hét ötlete. Most rávetem magad a Google-ra, mert VPN-t még soha nem gyártottam.
A win OK, de nem tudod véletlenül, hogy mennyire macerás belőni a VPN klienst MacOS és Linux alatt?

Hackac

:)
Reszletes howtok minden disztribhez:
http://pptpclient.sourceforge.net/

pptp vpn-t ketfele modon tudsz csinalni.
En ezt a modszert hasznalom.
http://www.czeh.hu/linuxdoc/vpn-pptp.html

( hackac | 2005. 05. 02., h – 17:07 )

Hi!

Köszi a tippeket.
msandor, willothewisp, polya: Épp ezt a megoldást szeretném elkerülni, hogy a tűzfalscriptem elején legyen 100-150 "felesleges" sor.

broven: Ez már egy fokkal jobb, de mivel a MAC maszkolható, nem igazán megoldás.

Mivel arra lehetőség nincs hogy a felhasználók gépeihez hozzáférjek, jobban átgondolva a témát, két megoldást látok most:
1. a DHCP által aktuálisan kiosztott címeket nem a tűzfal scriptbe "építem" be, hanem a DNS config állományába, és csak innen engedek DNS lekérdezést. Így csak a csomagok töredékét kell "megszűrni", nem úgy mintha a tűzfal scriptben lenne. Így ugyan az IP beírásával még kimehet a netre, de ebbe valszeg bárki gyorsan beleunna.
2. valamilyen user autentikáció után mehet a netre. DE hogy lehet ezt platformfüggetlenül, a kliensekbe való turkálás nélkül megvalósítani???

Üdv,

Hackac

( csko | 2005. 05. 02., h – 17:24 )

msandor, willothewisp, polya: Épp ezt a megoldást szeretném elkerülni, hogy a tűzfalscriptem elején legyen 100-150 "felesleges" sor.

Ciklus, külön fileba az IP/MAC lista. :D

( hackac | 2005. 05. 04., sze – 11:51 )

Mi a másik verzió? Én csak ezt a fajtát fedeztem fel tegnap a Googlen... A kivitelezés viszont meglehetősen egyszerűnek tűnik.

Már csak egy valami nem teljesen világos nekem. Ok, hogy felépül a VPN kapcsolat, de azt hogy oldom meg, hogy csak az mehet ki, aki VPN-en jött be?

( macroharddoors v | 2005. 05. 04., sze – 12:01 )

PPPoE-server , nem jó ????

( nug | 2005. 05. 04., sze – 12:02 )

[quote:a06b93c8fd="hackac"]Mi a másik verzió? Én csak ezt a fajtát fedeztem fel tegnap a Googlen... A kivitelezés viszont meglehetősen egyszerűnek tűnik.

Már csak egy valami nem teljesen világos nekem. Ok, hogy felépül a VPN kapcsolat, de azt hogy oldom meg, hogy csak az mehet ki, aki VPN-en jött
be?

Ugy ertem, hogy a kernelhez ketfajta mppe modul is van. Kicsit maskepp kell hasznalni oket.
Masik modszer:
http://poptop.sourceforge.net/dox/replacing-windows-pptp-with-linux-howto.phtml
Debian alatt csomag is van hozza a kernel modulhoz:
http://pptpclient.sourceforge.net/howto-debian-build.phtml

A tuzfalon csak a ppp+ (akarmenyik ppp) interfaceket engeded ki a kulso halora, a belso ethernet interfacet nem.

( Elbandi v | 2005. 05. 04., sze – 13:28 )

nalam a pptpd megy, csak 1 a baj: 1szerre csak 1 kliens tud csatlakozni :o
nem tudom hogy koze van-e ahhoz, hogy a pppd ossza ki az ipt, mert minden felhasznalohoz kulon ipcim van (nem a pptpd ad ki egy szabad ipt)

( hackac | 2005. 05. 03., k – 08:51 )

Ciklus...
Ok, így nem lesznek sok plusz sorok a scriptben, de az "élő" tűzfalszabályok elején igen. Ergo, ugyanúgy átbumliznak sorban rajta az egyes csomagok. Ez az igazi célom, hogy ne így történjen, nem pedig "scriptesztétikai" gondjaim vannak :D

( nc | 2005. 05. 03., k – 09:37 )

Én azt csinálnám - szigorúan esztétikai megfontolások miatt -, hogy egy külön fájlba beírnám a mac címeket és egy rövid scripttel hozzáfűzném a scriptemhez minden indításkor (persze egy új, temporaly fájlba, hogy ne írja felül az eredeti iptables scriptet) és azt indítanám el.

Így világosan elkülönül a mac címek "táblázata" és maga az iptables script.

( hackac | 2005. 05. 04., sze – 15:54 )

PPPoE sem rossz, de első körben a PPTP egyszerűbbnek tűnik.

Kérdésem továbbra is a régi:
Már csak egy valami nem teljesen világos nekem. Ok, hogy felépül a VPN kapcsolat, de azt hogy oldom meg, hogy csak az mehet ki, aki VPN-en jött be?

( zoli1973 | 2005. 05. 04., sze – 16:00 )

Szia

Szerintem old meg PPPOE-vel akkor lesz egy ppp+ interfaced azt engedélyezed kifelé, ppp-auth filebe felveszed a felhasználókat és csak az tud belépni aki tudja.

( hackac | 2005. 05. 04., sze – 16:07 )

Igaz, ez eszembe sem jutott, hogy más iface lesz a téma. Hát igen, már a fától nem látom az erdőt...
Da ha már itt tartunk, ue van PPTP-nél is, nem?

( hackac | 2005. 05. 03., k – 11:08 )

Ez világos volt az előzőek alapján is, és ha ez a megoldás lesz, magamtól is így használtam volna.
Az igazi kérdés az, hogy hogyan kerülhető el az, hogy legyen a tűzfalam elején 100-200 szabály MAC/IP/akármi címekkel, amin minden csomagnak át kell bumliznia. Ha marad a bumlizás az erőforrás pocsékolás, ami bántja a lelkem. Tudom, hogy egy mai szerver teljesítménye mellett észre sem lehet venni plusz 200 szabálysort, de ez "nem jó a lelkemnek" akkor sem.
Mondok egy primitív példát.
Usernek el kell mennie adott belső hálózati weboldalra, ott beírni a logint és passwordot, és megy minden. Enélkül nem. Az én nagy bajom az, hogy fogalmam sincs milyen "tokent" lehet egy ilyen megoldással neki adni amit újraindításig meg is tart, nem kell hozzá a gépen kliensprogram, és platformfüggetlen. Erős a gyanúm, hogy ilyen megoldás nem létezik... :(

( polya v | 2005. 05. 04., sze – 16:34 )

szvsz a tunnelezes csak megbonyolitja a helyzetet/adminisztralhatosagot 200usernel kismilio tun interface. sima ipsec a lan-on linuxon/bsdn/win2k+-on is siman megy. kicsit jobban megeszi a procit mint a pptp viszont szebb megoldas es telen a kazant se kell bekapcsolni.

( dragi v | 2005. 05. 03., k – 11:20 )

Legyen web alapu, az platform fuggetlen. AMugy azt nem egeszen ertem, hogy ha a dhcp.leases alapjan generalod a tuzfal scriptet akkor az miert nem jo? Abban a mar kiosztott ipcimek szerepelnek csak.

( nug | 2005. 05. 03., k – 11:31 )

/etc/ethers

Amugy en a nagy es bonyolult rendszer helyett inkabb valami egyszerubbet csinalnek:
- mac cim beallitasa a swics portra
vagy
- az engedlyezett (vagy az osszes) mac cimeket kiengednem, es futtatnek valami mac cim - ip cim figyelo progit, ami ha loggol valami gyanusat azt megkeresnem.

A tuzfal szabalyok nagysagan meg ne problemazz mar! Majd ha tobbezer sornal jarsz es erezhetoen fogja a cpu-t akkor!

( nug | 2005. 05. 04., sze – 16:50 )

[quote:a761f2a315="hackac"]Igaz, ez eszembe sem jutott, hogy más iface lesz a téma. Hát igen, már a fától nem látom az erdőt...
Da ha már itt tartunk, ue van PPTP-nél is, nem?

Ja.

Amugy az ipsec vs pptp kerdeshez.
A pptp-t harom kattintas windowsban beallitani, az ipsec kicsit(joval) bonyolultabb. Es klienseid 99%-a ugyis windows lesz.
Ipsec:
http://people.arxnet.hu/airween/ipsec/index.html

( MGy v | 2005. 05. 03., k – 11:51 )

Az ethernet-IP hozzárendelésnek a változásait monitorozza az arpwatch program.
Ha megváltozik ír egy e-mailt és mehetsz a userhez a fa testápolóval.

Amúgy a /etc/ethers és a statikus ARP a leghatékonyabb.

( nug | 2005. 05. 03., k – 12:06 )

csinalhatsz egy weboldalt is, ahol autentikalod a felhasznalot, ha sikeres, akkor a mac cim ip cim parost felveszed adott idotartamra az engelyezett gepek koze. Ekkor en mar hasznalnek vmi egyszeru adatbazist segitsegnek.

A nem engedelyezett felhasznalokat pedig az azonosito weboldalra iranyitod.
iptables-sel lehet hogy ilyet nem lehet, de mas modszerrel biztosan.

( polya v | 2005. 05. 03., k – 12:16 )

+/1 100 sor-t nem fog megerezni a tuzfalad sokkal inkabb az szamit hogy ezelott a 100 sor elott es mogott mik vannak es milyen sorrendben.
+ a dhcp - ddns es update megoldas nem tuzfalhoz kotott - pl csinalhatsz statikus arp-t es a script a tuzfal arp tablajat updateli. viszont van 1 nagy kulombseg az arp-os es az ip-s megoldas kozott az egyik layer2-n fog szurni a masik 3-on - ami elso nekifutasra nem tunnik problemanak viszont ha beallitas arp-al az 1.2.3.4 hez 01:23:45:67:89:ab:cd mac-et attol meg johet csomag az 5.6.7.8 -rol a 01:23:45:67:89:ab:cd felol - es mivel tuzfalszabalyaid nincsenek(feltetelezhetoen managelheto switchek sem) max tippelni tudsz hogy melyik hostrol jon.
a dns-es megoldas kb olyan mintha random valasztalan ip-t es csak azoknak mondanad meg akiknek szeretned... barmelyik gepre feltesznek 1 dns-t amelyik be van regisztralva es neteznek.
de a szomoru hogy jolkepzett userek ellen ugysem tudsz mit tenni max az informatikai kivitelezest jogi megoldasokkal tamogatva.

( hackac | 2005. 04. 29., p – 15:49 )

Sziasztok!

Egy olyan problémám van, hogy tervezek egy belső hálózat, amelyen egy szerveren keresztül érhető el a Net. A címeket DHCP-vel osztom ki, de MAC alapján statikusan.
Hogy tudom azt elérni, hogy csak azok a címek kommunikálhassanak kifelé, akik a szervertől vették fel az IP címet-t, és aki kézzel állítja be magának az IP címet és átjárót az ne? Ötletek?
Lehetőleg olyan megoldás kellene, hogy a kliensekre ne kelljen semmit telepíteni.
Gondolkodtam olyan megoldásban, hogy valami scripttel beíratom a tűzfalkód elejére a kiosztott címeket, és csak ezeket engedem át, de ez nem az igazi...

Előre is kösz a segítséget!

Hackac

( msandor v | 2005. 04. 29., p – 15:55 )

hasonló problémába ütköztem 1-2 hónapja, úgy oldottam meg, hogy csak azokat a gépeket engedem ki a netre, akik szerepelnek a dhcpd.confban
mivel ezeket én tartom karban, így bárki mahinál a klienseken nem kap netet, mert nem szerepel az engedélyezettek körében

elég gügyén fogalmaztam, de talán meg lehet érteni

( golgota | 2005. 05. 03., k – 13:15 )

Most lehet, hogy nem értem tisztán, de nem lenne egyszerűbb egyszerűen letiltani azt, hogy a felhasználó állíthassa az ipcímet stb?
Ugye win-en ez nem nagy gond, de linuxon sem.
Akkor ugye ha nem tudja beálljtani kézzel, akkor biztos hogy a dhcp-től kapta és húzhat kifele.

( willothewisp | 2005. 04. 29., p – 16:27 )

ha iptables-ben mac address (-m mac --mac-source) és ip párosokhoz engedélyezed a forwardot az nem jó?

valahogy igy:
iptables -t filter -A FORWARD -i $LAN -o $INET -s $IP -m mac --mac-source $MAC -j ACCEPT
iptables -p FORWARD DROP

( hackac | 2005. 05. 03., k – 13:22 )

1. a switchek kis SOHO cuccok lesznek, azokon nem tudok matatni, és minden portra megadni a csatlakozó hálókatyi MAC addressét
2. mivel a MAC maszkolható, ha nincs semmi authentikáció csak átírja a címét egy "gépére" amelynek van jogosultsága és ki van kapcsolva, a DHCP-vel felveszi a címet és netezik
3. én is rájöttem, a korábbi DNS-es megoldás kilőve
4 nug: ez egy fokkal jobb, de ugyanúgy tűzfalnövelő buli, mint az előzőek, egy authentikációval megtámogatva

Amit most igazán jó megoldásnak találnék, az valami Kerberos szerű megvalósítás, ahol kap egy tokent, és ha authentikált akkor mehet minden. A gond az, hogy ilyen megoldásokhoz mindenképpen kell (tudtommal) kliensoldali támogatás.
Mindenesetre ha más nem megy, ez még talán megoldató, ha van valami platformfüggetlen free software erre.

Lehet hogy ez problémázásnak tűnik, de az ördög a részletekben van :twisted:
Ha nem megoldható amit szeretnék, akkor úgyis megy az itt elhangzottak közül valami, de amíg van ötlet nem megyek bele egy számomra kevéssé szimpatikus megoldásba.

( tamasna | 2005. 05. 04., sze – 19:55 )

OpenBSD authpf. Usereket kell felvenni, akiknek /usr/sbin/authpf a shellje. Auth utan barmilyen tuzfal szabalyt behuzhat. Amig nyitva tartja a kliens az ssh ablakot, addig ki tud menni a netre, ha bezarja, vege. Vagy ha megszakad a kapcsolat, stb. Ssh kliens meg van mindenre ingyen. Szerintem ez a legegyszerubb.

( hackac | 2005. 05. 03., k – 13:25 )

Golgota: Igen, ez lenne a legegyszerűbb...
...csak a userek gépéhez nem férek hozzá.
Mi (lakók) egy nagy épülettömbben szeretnénk közös netet kialakítani, és itt kellene megoldani a hozzáférés vezérlést. Sajna az nem megy, hogy bemegyek valakihez, és megszüntetem a jogait a gépén.

Hackac

( msandor v | 2005. 05. 03., k – 13:31 )

én squid proxyval oldottam meg a dolgot
akit felvettem fix "IP-re", azt engedélyeztem is a squidban
és tud felhasználó/jelszó párossal is azonosítani
a kliensekhez hozzá se kell nyúlni, maradjanak DHCP-n
mindenki más kap egy IP-t egy tartományból, amivel nem fog tudni netezni

( polya v | 2005. 04. 29., p – 16:51 )

hat igy teljessen kesz megoldas nem biztos hogy van(marmint arra hogy azok es csak azok mehessenek ki akik a dhcp-tol kaptak meg az ip-t, es nem maguknak allitottak be a helyesset) hat kesztermekrol meg nem hallottam viszont a dhcpd 3 az tud dns-t updatelni es ezt felhasznalhatod arra is hogy a tuzfaladat updatelje ha nem akarod cron-bol futtatot scriptekkel ellenorizni hogy epp kiknek van(vagy mar nincs) aktiv az ipjuk dhcp-tol, 3 hibaforras ha a gepnek nincsen neve nemjegyzi be dnsbe, ha resetels dhcpkliens nem kuld release-t, ha nagy max-lease-time akkor nem er semmit - ennek a tulloldala persze hack-et igenyel de leginkabb copy-past a bind9 forrasabol.

( golgota | 2005. 05. 03., k – 13:42 )

Tudom hülyén hangzik, de aki egy hálózatba belép, annak el kell fogadnia bizonyos szabályokat.
Beléphet a saját gépére, vagy egy domain-be, aminek van saját policy-je.

Amúgy ezen kívül én is a squid-et tudnám elképzelni mondjuk squidguard-dal kiegészítve.

( broven | 2005. 04. 29., p – 17:50 )

Mi azt csináljuk, hogy a routeren van egy lista IP/MAC párokról a /etc/ethers-ben, aztán egyszerűen arp -f. Ez azt csinálja, hogy statikusan beállítja, hogy melyik IP-hez melyik MAC tartozik. Így kimennek a csomagok netre, de ha jon a válasz IP csomag, akkor azt a router az előre megadott MAC addressre küldi el. Ha nemlétező IP, akkor valami kamu MAC-ra.

( hackac | 2005. 05. 03., k – 13:47 )

Gondoltam és is a Sqiudre, de az csak a http/ftp forgalomra nyújt megoldást. Ami még felmerült az a Zorp, és plug proxy minden szolgáltatásra - de itt a Satyr ami authentikálhatna nem free.

( nug | 2005. 05. 03., k – 14:10 )

ellenseges kornyezetben, hogyha nincs admin jogod a szamitogepekhez, ezt a problemat sose fogod tudni tokeletesen megoldani.

Akarmit csinalsz, aki ert egy kicsit az informatikahoz ki fogja tudni kerulni.

( hackac | 2005. 05. 03., k – 14:18 )

Hát ettől tartottam én is. Azért az utolsó kérdésem fenntartom:

"Amit most igazán jó megoldásnak találnék, az valami Kerberos szerű megvalósítás, ahol kap egy tokent, és ha authentikált akkor mehet minden. A gond az, hogy ilyen megoldásokhoz mindenképpen kell (tudtommal) kliensoldali támogatás.
Mindenesetre ha más nem megy, ez még talán megoldató, ha van valami platformfüggetlen free software erre."

Hackac

( nug | 2005. 05. 03., k – 14:46 )

[quote:79ac0b6da2="hackac"]Hát ettől tartottam én is. Azért az utolsó kérdésem fenntartom:

"Amit most igazán jó megoldásnak találnék, az valami Kerberos szerű megvalósítás, ahol kap egy tokent, és ha authentikált akkor mehet minden. A gond az, hogy ilyen megoldásokhoz mindenképpen kell (tudtommal) kliensoldali támogatás.
Mindenesetre ha más nem megy, ez még talán megoldató, ha van valami platformfüggetlen free software erre."

Hackac

A kerberos-szal vannak tapasztalataim - a kliensoldali tamogatas igencsak hianyos hozza ilyen kovetelmenyek eseten - es ha jol ertem akkor te szabad netelerest szeretnel biztositani nem pedig csak bizonyos protokollokat.

Tehat az azonositast egy reteggel lejjebb kell vinni.

Hirtelen tamadt egy jo otletem! Csinalj egy PPTP VPN szervert, es a klienseid csatlakozzanak arra (windowsban 3 kattintas beallitani).

Es kulso neteleres csak a bevpnezett gepeknek legyen.

Ezt meg meg lehet varialni mac cim figyelessel ip szetosztassal stb, hogy a visszaeleseket (masnak atadott jelszo) figyelni lehessen.

Ez nem is tunik tul bonyolultnak, egyszeruen megvalosithato, karbantarthato.
hmm?

Ha pakolsz hozza RADIUS backend-et akkor tudtommal egesz fejlett menedzsmentet lehet hozza varazsolni. (tobbszoros belepes tiltasa, idotartam figyeles, korlatozas pl. csak hetvegi eleres, stb.)

( robit v | 2005. 05. 05., cs – 09:38 )

Üdv!

szerintem mielött vpn el tornászol egy nagyot nézd meg ezt
http://nocat.net/
ezt kifejezetten ilyenre gyártották

Üdv Robit

( hackac | 2005. 05. 03., k – 16:16 )

Azt hiszem ez a hét ötlete. Most rávetem magad a Google-ra, mert VPN-t még soha nem gyártottam.
A win OK, de nem tudod véletlenül, hogy mennyire macerás belőni a VPN klienst MacOS és Linux alatt?

Hackac