Kis munkahelyi hálózat kialakítása

Hálózatok általános

Sziasztok!

Összeállítottam (inkább összetákoltam) egy kisebb hálózatot, a munkánk megkönnyítése érdekében. A topológia itt látható. Nem kell semmi enterspájz cuccra gondolni, minden eszközt úgy kukáztam össze.
Ahol a rajzon a FreeBSD szerver szerepel, ott most egy Debian wheezy-vel megáldott régi P4-es asztali PC teljesít szolgálatot, egyelőre csak fájlszerverként. Ezt fogom most kiváltani egy FreeBSD-vel telepített, hasonló kategóriájú, csak kicsit combosabb HP xw4600 workstation-re (ebben legalább van RAID).
A lent látható router 1, a szolgáltatótól kapott "csoda". Ide csatlakoznak Wifi-n és UTP-n a munkára használt laptopok, egy asztali munkaállomás, egy nyomtató és a tervezett FreeBSD szerver. A szerver másik oldalán egy olyan hálózat van, amit szeretnék elszigetelni teljesen az internettől (App szerver 1-2, Kliens 1-3).
Amiért én oda gondoltam a FreeBSD szervert:

  • a fenti hálózatról kifelé senki nem mehet, csak a FreeBSD szerver Samba megosztását látják, és NTP-n időt szinkronizálnak a FreeBSD szerverrel
  • a lenti hálózatról mindenki mehet az internetre és a fenti hálózatban elérhetnek mindenkit

Amiért FreeBSD-re gondoltam (persze lehet linux is):

  • pf, ez szerintem magáért beszél
  • samba, mint fájlszerver
  • ntp szerver, a fenti hálózatnak
  • ZFS mirror
  • opcionálisan caching DNS szerver
  • OpenVPN szerver
  • és mert elfogult vagyok :)

A VPN ahhoz kellene a későbbiekben, hogy kívülről is el lehessen érni a fenti hálózatban található gépeket.
Nekem ez az elképzelésem elsőre. Érdekelne tapasztaltabb emberek véleménye, ötletek, hogyan lehetne esetleg egyszerűbbé tenni.
Hogy bonyolítsam a dolgot, gondoltam arra is, hogy a Wifi AP-t is a FreeBSD-re bíznám (van egy atheros PCI-E wifi kártyám), ill. a szolgáltató routerén PPPoE passthrough-t állítok be és a PPPoE kapcsolat is a FreeBSD-n menne. Viszont akkor kellene még bele Ethernet is.

*szerk.: írok még pár plussz infót. A fenti hálózatban lévő 2 rack (nem találtam más szimbólumot), 192.168.11.1-2, 2 "biztonságtechnikai rendszer". Ezekkel kommunikál a 2 app szerver (jobbat nem tudtam kitalálni), a 3 kliens az 1-es app szerverre csatlakozik, ezekről is kezelhető a rendszer. Az 1-es app szerver az 1-es hálózati nyomtatóra, a 2-es pedig a saját, 2-es számú nyomtatóra küldi az "eseményeket". Az app szerverek által megjelenített adatokat a munkaállomás 1-ről lehet módosítani, feltölteni, ezeket a FreeBSD szerveren tárolnám. A többi laptopról csak a 2 "rack"-et kell elérni, ill. a fájlszerver funkciókat (is) ellátó FreeBSD szervert, valamint a nyomtató 3-at. Az internet szolgáltatás a laptopoknak, a munkaállomásnak és FreeBSD szervernek jár, a fenti hálózatnak nem. Továbbá szeretném a későbbiekben, ha VPN-nel be lehetne csatlakozni kívülről is.
A vas adott, a projekt 0 Ft-os, így azzal kell megoldani ami van. Nem kell sokkilences rendelkezésre állás, meg őrölt gigabites sebesség.

  • 7322 megtekintés

( freeoli v | 2014. 12. 01., h – 16:55 )

Én Zetyalt javaslok Neked. Gyorsabban kész leszel vele és használj sw raidet.

A Zentyal tényleg egy jó megoldás, de kleinienek pont nem. Úgy veszem ki, hogy nem akar semmi Windows serverre hasonlító megoldást alkalmazni (pl AD tartomány) ezért felesleges egy Zentyallal bohóckodni, akkor már inkább Debian.

Az SW RAID-et meg ellehet felejteni, ha van esély HW RAID használatára. Igaz hogy manapság már biztonságos az SW-s, de ha összeomlik, akkor nagy bajok lesznek. Én is inkább veszek egy RAID kártyát, minthogy szoftveresre bízzam az adataimat :)

-----------------------------------------------------
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt...

Nemrégiben nézegettem a Zentyal-t, tetszett a dolog. Viszont ebben az esetben nincs szükség AD-re, így nem láttam célszerűnek. Windows-ból igazából csak a megosztás kell (ugyanis minden PC-n Windows van).
A HW vs. SW RAID téma viszont kétélű, ebben a kategóriában (semmi drága cumó, sima asztali PC-k, ócska SOHO router, switch...) szerintem bőven jó az SW, mi van ha elfüstöl az alaplap és nem tudok cserélni?
Azt az elején elfelejtettem leírni, hogy ez is egy 0 Ft-os projekt, csak azzal tudok dolgozni, ami van. Plussz HW beszerzése nem kivitelezhető, max. ha valaki megajándékoz.

( hendrick v | 2014. 12. 01., h – 17:16 )

A felső szakaszt le akarod vágni az internetről, de a FreeBSD alattiak laptopjai és workstationjei férjenek hozzájuk. Ebből úgy érzem, hogy szeretnétek erősen védeni a belső hálót.
A szolgáltató által biztosított router+wifi access point hozza a korszellem elvárásait biztonság tekintetében? Hozzáférsz, hogy patchelgesd ha kell? Egyébként neked szabad, vagy mindig várnod kellene a szolgáltatóra (ha netán lenne vele tennivaló)?
a 11.254-hez dugva egy síkágyas szkenner fut, ami a nas+firewall gép desktopjáról megy??!! Ez az a gép aminek közelébe se engednék szkennelgető kollegát.
Ha a freebsd alattiak mehetnek felfele és ők bekapnak valami csúnyát a netről, akkor már bent is van a csúnya kis kobold a védett gépeken is.

TODO
- szkenner1 valamelyik klienshez vagy munkaállomáshoz áttesz
- ha nem matathatod, akkor router1 wifi letilt és saját wifi access point valahova, de akár igen akár nem radius szerver a freebsd-re egy normálisabb auth érdekében
- ha nem a jó magyar szokás szerint mindenki rendszergazda akkor elég lehet, de ha igen, akkor lehet, hogy át kellene gondolni, hogy melyik gépről mihez is szükséges hozzáférni és ki mennyire tud biztonságcentrikusan dolgozni, és ennek megfelelően a ki mit érhet el játékot tovább finomítani
- a switchek sorbafűzését nem tudom mi indokolja +1 app szerver miatt ... biztos van valami részlet ami miatt ez neked jó csak nem fért bele
- a VPN-t lehet, hogy nem csak az internet felől érkezőkre használnám pl a wifi miatt ... akár radius helyett

OpenBSD? :)) Komolyabban: Én maradnék debiannál, systemd ide vagy oda, de a ZFS sokat nyomhat a latba, ha más nem is annyira... (remélem ez a forkolási láz hamar elmúlik kopp kopp)

A szolgáltatótól kapott ZTE szörnyetegre ilyen szempontból nincs ráhatásom. Egy szimpla ADSL2+ modem és router egyben Wifi-vel, tehát firmware-t nem tudok buherálni.
A szkennert úgy képzeltem el, hogy gombnyomásra beszkenneli a doksit egy, a hálózaton megosztott mappába (csak archiválás célzattal), nem kell GUI meg ilyen finomságok.
A switch-ek különböző szinten vannak, így alakították ki a végpontokat, ezért kellett.

( ggallo | 2014. 12. 01., h – 18:48 )

Részemről támogatom a FreeBSD-s elgondolásod (én mindenhol ezt használok szerver célra, plusz pf rulez), viszont kibővíteném a feladatait az összes hálózati funkcióval.
Tény, hogy egy Zentyal vagy Ubuntu szerver sokkal gyorsabban "kész van", de a BSD-nek kisebb lesz a gépigénye, bizonyos területeken sokkal jobb, mint a Linux-ok és ha ráadásul érdekel is, sokat tanulhatsz a hekkelése során (ha még nem vagy benne profi).

  • A szolgáltatói eszközt csak internet betápnak használnám a szerver egy lábán, így az összes, most arra csatlakozó eszközt is be tudnám vonni a központi kinek-mit-szabad játékba, de pl. szolgáltatót cserélni is könnyebb egy kábel kihúzásával
  • ZFS-t csak akkor indítanék, ha sok diszk és/vagy nagy kapacitás a cél, ugyanis a tényleges (nem minimális) hardver igénye messze túlmutat a 2 HDD-t kössünk tükörbe felhasználáson. Pl. komolyan kell venni, hogy csak ECC memóriával szabad használni, és abból is jó sokkal (8GB minimum, de inkább több). Persze ECC nélkül, 1GB-tal is működik, viszont olyan körülmények között biztosabb/gyorsabb minden más
  • Ha nem ZFS (tudom, nagyon be tudja szippantani az embert, de pl. nekem sincs az itthoni HP szerveremen ZFS, pedig van ECC RAM is, meg HDD-k is - de nem annyi, amit érdemes lenne ZFS alá tenni), akkor teljesen jó a gmirror, azon pedig UFS2 SoftUpdates+Journal beállítás. Sok-kilences eséllyel nem lesz soha adatvesztésed.
  • Az összes szegmenst rákötném annyi LAN kártyával amennyi kell az általad elvárt szeparációhoz, és így, egy géppel oldanám meg a hálózati tűzfal, router kérdését
  • A wifi-t nem húznám be a FreeBSD-be, arra tennék egy Ubiquiti UniFi AP-t. Ha szeretnél dolgozó/vendég SSID-t, akkor az UniFi tud VLAN-t (hozzájuk akár 4 SSID-t), a FreeBSD szintén tud VLAN-t, és egy szegmens hozzáadásával (ha nem akarsz VLAN-képes switch-et venni) meg tudod oldani a teljes szeparációt, szűrést, akármit - akár Captive Poral is mehet a vendégeknek (vagy mindenkinek).
  • OpenVPN nyilván menni fog, de ha több (sok) folyamatos klienssel tervezel, akkor erős CPU-t keress a gépbe
  • Ha 10-es FreeBSD-t választasz, akkor abban kapásból ott az unbound caching DNS-nek, teszel mellé egy dnsmasq-t DHCP+dinamikus helyi DNS ügyében, és máris szolgáltató-független vagy, belső jól működő DNS-sel (meg a Samba-ba kapcsolsz WINS szolgáltatást, és a Windows kliensek odáig lesznek)
  • Ha központi router lesz a FreeBSD, akkor tehetsz rá Squid-et (+Dansguardian) akár transzparens módban, és akkor remekül tudod szabályozni, hogy ki, mikor, milyen oldalt látogathat meg. Mert ugye a védett gépeknek is kelleni fognak frissítések, stb. (akár úgy is lehet, hogy Captive Portál kell bizonyos gépek net-eléréséhez, és csak akkor lépsz be, hogy legyen net, ha frissíteni akarod). Ha nagyon paranoiás vagy vírus/malware terén, akkor tehetsz rá HTTP forgalmat ellenőrző ClamAV-ot is.

Persze ezen felül ott a lehetőség, hogy csinálj egy pár jail-t, amivel remekül el tudod szeparálni az egyes szolgáltatásokat, és ezzel még egy lépést tennél a még nagyobb biztonság felé (ha megtörik valamelyik futó szolgáltatást egy frissen felfedezett exploit-tal, akkor csak az a jail kerül veszélybe, nem az egész gép/OS).

Egy dolog lehet fontos hardver terén: vegyél bele Intel vagy Broadcom chip-es hálózati kártyát azokhoz a szegmensekhez, amin Samba vagy egyéb elérést tervezel, meghálálja pl. egy Realtek helyett sebességben.

Ezen felül nyilván lennének még ötleteim, de elég lesz ez a lista első nekifutásra :-)

Elsődleges célom a munkánk megkönnyítése, a második szempont az ismerkedés a FreeBSD-vel szerver környezetben. Linux ellen sincs semmi kifogásom, ahogy írtam jelenleg Debian Wheezy a fájlszerver.

A szolgáltatói eszközt csak internet betápnak használnám a szerver egy lábán, így az összes, most arra csatlakozó eszközt is be tudnám vonni a központi kinek-mit-szabad játékba, de pl. szolgáltatót cserélni is könnyebb egy kábel kihúzásával
Gondoltam, hogy a FreeBSD szervert előrébb hozom és mindenki mögötte lesz, ehhez valahonnan le kellene akasztanom pár NIC-et. Viszont így valóban jobban lehetne irányítani a hálózati forgalmat.

Ha nem ZFS (tudom, nagyon be tudja szippantani az embert, de pl. nekem sincs az itthoni HP szerveremen ZFS, pedig van ECC RAM is, meg HDD-k is - de nem annyi, amit érdemes lenne ZFS alá tenni), akkor teljesen jó a gmirror, azon pedig UFS2 SoftUpdates+Journal beállítás. Sok-kilences eséllyel nem lesz soha adatvesztésed
ZFS-hez nem ragaszkodom, csak az adatbiztonság miatt gondoltam a MIRROR-ra. GEOM-mal még nem ismerkedtem.

Az összes szegmenst rákötném annyi LAN kártyával amennyi kell az általad elvárt szeparációhoz, és így, egy géppel oldanám meg a hálózati tűzfal, router kérdését
A wifi-t nem húznám be a FreeBSD-be, arra tennék egy Ubiquiti UniFi AP-t. Ha szeretnél dolgozó/vendég SSID-t, akkor az UniFi tud VLAN-t (hozzájuk akár 4 SSID-t), a FreeBSD szintén tud VLAN-t, és egy szegmens hozzáadásával (ha nem akarsz VLAN-képes switch-et venni) meg tudod oldani a teljes szeparációt, szűrést, akármit - akár Captive Poral is mehet a vendégeknek (vagy mindenkinek)
Ahogy írtam feljebb új eszköz sajna nem játszik, de egy Linksys WRT54GL-t még be tudok vonni a játékba (asszem most valami régi OpenWRT van rajta, lehetne AP). Vendég hozzáférés nem kell, ez csak nekünk készül.

OpenVPN nyilván menni fog, de ha több (sok) folyamatos klienssel tervezel, akkor erős CPU-t keress a gépbe
VPN-en max. 1-2 kliens jönne be, és csak ritkán.

Ha központi router lesz a FreeBSD, akkor tehetsz rá Squid-et (+Dansguardian) akár transzparens módban, és akkor remekül tudod szabályozni, hogy ki, mikor, milyen oldalt látogathat meg. Mert ugye a védett gépeknek is kelleni fognak frissítések, stb. (akár úgy is lehet, hogy Captive Portál kell bizonyos gépek net-eléréséhez, és csak akkor lépsz be, hogy legyen net, ha frissíteni akarod). Ha nagyon paranoiás vagy vírus/malware terén, akkor tehetsz rá HTTP forgalmat ellenőrző ClamAV-ot is.
ClamAV dolog tetszik. Oldalak elérését nem akarom szabályozni, mondjuk a Facebook-ot tiltanám legszívesebben :)

Köszönöm szépen az ötleteket. Jail-be milyen szolgáltatásokat lehetne bedobni?

Félre nem érts, én sem vagyok Linux ellenes, de ilyen célra (hacsak valami nem köt a Linux-hoz) én inkább a FreeBSD-t használom, és azt is javaslom másnak.
Persze ha jobban bejön a grafikus/gyárilag webes konfigurációs felület, akkor az erre épített Linux disztrókkal hamarabb eléred a célod. A FreeBSD a mai napig inkább klasszikus UNIX, parancssoros használattal, konfigurációs állományok szerkesztésével. Lehetőség persze mindenre van, de nem olyan out-of-the-box.

  • Ha ekkora hálózatotok van, akkor ez nem egy otthoni, családi vállalkozás (de ha az is lenne), így el kell bírnia egy-két pár ezer Forintos hálózati kártyát. Na jó, ne Intel kártyával indíts, hanem Realtek csipessel, és majd ha megjön az igény a 20-30 MB/s Samba elérés helyett a 100 MB/s sebességre, akkor cserélsz NIC-et.
  • GEOM-mal (ha nem ismered sem ezt, sem azt) talán még könnyebb is egy alap tükrözést csinálni, mint ZFS-t beüzemelni.
  • Azt a maradék WRT-t használhatod AP-nek nyugodtan, majd cseréled később, ha az igények úgy alakulnak. Ez végül is független a FreeBSD-től, a lényeg, hogy a szolgáltató eszközétől elszakadjatok.
  • 1-2 eseti VPN klienst egy Celeron is elvisz, így ezzel nem kell külön foglalkozni.
  • A HTTP cache/szűrés/ellenőrzés egy kalap, max. nem használod az összes szolgáltatást...
  • Jail-be azt rakod ki, amihez kedved van bekonfigurálni (ugyanis sok szolgáltatásnál telepítéskor/konfiguráláskor figyelembe kell venni, ha jail-ben fog futni, a jail jelentette korlátok miatt). Az a teljes megoldás, ha minden szolgáltatás külön jail-ben fut és IP kapcsolaton érik el egymást (mintha független gépek lennének). Tehát külön-külön van a DNS, DHCP, Apache, Samba, Squid, stb. Létezik olyan rendszer, amelyen 100-as, 1000-es nagyságrendő jail fut (pl. hosztolt webszerver szolgáltatás, minden ügyfél Apache környezete külön jail-ben megy). Az a jó benne, hogy nincs olyan overhead, mintha VM-eket futtatnál, mert a kernel közös. Viszont a Linux-on is elterjedt chroot-nál sokkal erősebb a szeparáció.
    Mondjuk nekem általában csak azok vannak jail-ben, amik kintről elérhetőek (pl. Apache, Tomcat, külön jail-ben Redmine Thin-en, stb.)

Ha ezt az utat választod, akkor én is és még biztos sokan mások segítünk, ha megakadsz.


Az a teljes megoldás, ha minden szolgáltatás külön jail-ben fut és IP kapcsolaton érik el egymást (mintha független gépek lennének). Tehát külön-külön van a DNS, DHCP, Apache, Samba, Squid, stb. Létezik olyan rendszer, amelyen 100-as, 1000-es nagyságrendő jail fut (pl. hosztolt webszerver szolgáltatás, minden ügyfél Apache környezete külön jail-ben megy).

Ez a freebsd jail tök jól hangzik! :) Sajnos egyszer sem volt vele dolgom, de mielőbb kipróbálom, amint tehetem. Ezek szerint a jail fizikailag egy szerver, egy hardver, közös kernellel. Viszont akkor a hálózati NIC is 1 db (max 2 redundancia miatt, ld. bonding). A hálózati forgalom ez esetben az összes jail-nek közös. Ez azt eredményezi, hogy minél több jail-t adsz hozzá, annál jobban szűkül a sávszélesség, jól értem?

--
qmi

( tompos v | 2014. 12. 02., k – 11:58 )

Ha zfs-t hasznalsz, akkor ne hasznald a HW raid vezerlot.

( skypper | 2014. 12. 02., k – 12:54 )

szia

én ubuntut ajánlanék szervernek samba4 társaságában. nem rossz cucc és win8.1-ről tudod állítgatni a megosztástól kezdve mindent. érdmes rákeresni, ha érdekel a megoldás tudok hozzá anyagot adni privátban

Nem rossz a samba4, de a legjobb, ha nem az ubuntu csomagjabol huzzatok, hanem forditjatok. Nekunk eleg sok helyen fut samba4-es tartomany, es sajnos az ubuntu nem eleg gyorsan portolja a fixeket, jobb ha kezzel forditott van. Dedikalt up-to-date samba4 PPA me'g egyelore nincs, es a csomagcsinalas elegge nightmare, jobb hijjan /opt -bol fut...
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Hat, ha egyszer nem leszek totalisan szarul, osszerakok egy Samba4 tutorialt a blogomra. Most epp influenzaval vagy mi a csoccsel haldoklok itthon, ugyhogy nezd el nekem, de... nem.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

A hatranya is pont ugyanez, a Samba4 tartomany kezelesehez mindenkepp kell egy mgmt windows is, mert nem mindent lehet parancssorbol csinalni (gpmc.msc pl)
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Igazából nem értem a felháborodásod, mert AD-t az ember Windows munkaállomások/szerverek számára csinál, ergo van Windows-os PC-je, amiről ez működik. Tisztán Windows környezetben sem az AD-n magán szerkesztik a GP-t, hanem az admin a saját desktop-ján.

Persze mondjuk az LDAP címtárat használhatod a többi OS-ről is (és ahhoz meg is van minden parancssoros utility), de mondjuk a Group Policy-nak nem sok haszna van egy Linux-os desktop esetén, nem baj, ha nincs hozzá szerkesztő.

"Tisztán Windows környezetben sem az AD-n magán szerkesztik a GP-t, hanem az admin a saját desktop-ján."

s/AD/DC/, de ezt legfeljebb csak te gondolod. Kis halozatokban igenis a szerveren szerkesztik a GPO-t, mert akkor nem kell kulon meg egy licenc a management gepre.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

ergo van Windows-os PC-je

De miért lenne ez a következtetés logikus? Van a hálózatban Windows-os PC, ez oké, hiszen azok laknak a domain/AD-ban, persze, de az adminisztrátor PC-je miért lenne az? Egy Linuxos szerverhalmaz nagyon jól elmenedzselhető Linuxról, ergó ezért nem kellene az adminnak Windows-t tartania. És az szép dolog, hogy "hát de úgyis van _ott_ Windows-os PC akkor", csak az Internet világában nem biztos, hogy az adminisztrátor szeretne ott ülni, ahol a Windows-os PC-k laknak. Pont arról szól ez az egész, hogy így valahol kell tartani egy Windows-os virtuális gépet, csak azért, hogy azon tudjon az admin adminkodni.

^ +1

Egyebkent meg annyira, de annyira vicces sokszor (nem), hogy ott kell kinlodni az amugy is szarra terhelt szerveren (nem kis ceg, de az IIS/SQL Servertol a DC-n at a WSUS-ig minden azon van), mert masfel perc az ADUC toltesi ideje, es tovabbi fel mire hasznalhato lesz (Exchange/WSUS admin felulet felejtos, majd a PowerShell...), ahelyett, hogy vennenek valami rettenetesen ocska gepet eloretelepitett WinPro-val es az lenne a mgmt gep...
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

igen samba4 mellé kell az AD :)

Wut?

A Samba4 köszöni szépen nagyon szépen elmegy standalone, NT DC és AD DC szerepben is - pl. az openSUSE/Fedora/RH Samba4 csomagjai a mai napig csak a fájlszervert (najó, meg a többi szutykot, amit MS úgy gondolt, hogy ott a helye, wins, netbios, nyomtatómegosztás, ésatöbbi) és talán NT DC-t tudnak (Heimdal kerberos libre épített az S4, ezek a disztrók meg MIT-t szállítanak, jó ideje megy a portolgatás - a Fedora/RH samba4-ad csomagja meg egy readme, hogy "ha lesz, majd csinálunk csomagot" :) )

És meg is éri a hármas/három és feles Sambákat négyesre cserélni, az SMB protokoll újabb verzióit már nem fogják visszaportolni (talán a 2-es még ott van és 2.1-től 4-only, de fejből írom), olyan klienssel, ami ismeri az újabb protokollokat jobb teljesítményt ad(hat).

Szerk.: Na, utánanéztem. A 3.6-ban van kezdeti 2 és 2.1 suppport, de a feature lista egy részét 4.0.0-tól tették bele, SMB3 tisztán 4.0

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( zrubi v | 2014. 12. 02., k – 13:15 )

Ha a security is szempont, akkor semmiképp ne bízz ugyan arra a szerverre szeparációs, és kiszolgáló feladatokat!

Egy ekkora hálózat szeparációját még akár egy SOHO router (szappantartó) is vígan elvégzi (ha a VLAN, mint szeparáció elfogadható kompromisszum)
De a topológiát mindenképp a következőképp alakítanám:

* tűzfal (router/Wifi AP/VPN GW)
(ez akár lehet egy kis router Openwrt-wel, de akár komolyabb hardver is)
Annyi interfésszel, amennyit szeparált hálózatot szeretnél. Szerintem a javasolt:
- wifi
- Kliensek
- VPN kapcsolatok
- Szerver(ek)
- hálózati nyomtatók

Ha ez megvan, akkor a tűzfalon ízlés szerint állíthatod ki mihez férjen hozzá. A lényeg, hogy a szeparációt megvalósító eszközön csak átmenő forgalom lesz, így ennek csak a management felületét kell biztonságban tartani, szemben azzal, amit te terveztél, a mindent egyben szerver+ tűzfal megoldással. Ott bizony, ha egy szolgáltatás kompromittálódik, akkor a szeparációd is oda, hiszen ugyan azon a gépen próbálod megoldani...

Amit még hardver kapacitás függvényében erre a tűzfalra lehet bízni:

- DNCP,
- DNS (relay)
- Proxy
- VPN kapcsolatok fogadása.

--
zrubi.hu

Az elgondolás nem alapjaiban rossz, de én két ponton is vitatkoznék az állításaiddal:

- Konkrétan FreeBSD-n a jail-es szeparáció lényege (és ezért jött az egész létre anno), hogy ha egy jail kompromittálódik, attól a többi érinthetetlen marad (megfelelő beállítások mellett, persze). Szóval emiatt nem kell a tűzfalat leválasztani.
- Egy kis szappantartó nem lesz elég helyi hálózati szegmensek útválasztására, tűzfalazására. Attól, hogy egy 10-20 Mbites internetet meg tud osztani a helyi kliensek felé, nem fogja tudni a szegmensenkénti 100 esetleg 1000 Mbit-et lekezelni. Tehát a helyi hálózat (szegmensei között) forgalmában ez lesz a szűk keresztmetszet (ha 100 Mbites eszköz, akkor nagyon szűk keresztmetszet). Ha tényleg külön tűzfallal/útválasztóval szeretné megoldani, akkor is egy erősebb eszközt kellene betennie, ha a helyi hálózatot is szétszedi szegmensekre.

ha egy jail kompromittálódik, attól a többi érinthetetlen marad
Ez nagyon jól hangzik elméletben. Azonban amint a kernel is kompromittálódik nem ér semmit.

+ ezen felül a hálózati stack is közös, a jail azellen sem véd.

A gyakorlatban még nem láttam egyetlen szervert/klienst sem, aminél 1Gb/s lett volna a korlátozó tényező. De nyilván, ha sávszélességre (is) kell gyúrni akkor ahhoz mérten kell tűzfal vasat is választani...

--
zrubi.hu

Igen, a hálózati stack közös, de a szeparáció alapból olyan erős, hogy pl. ping sem működik jail-ből a raw socket támogatás default tiltása miatt. Plusz a tűzfalon ki tudod szűrni a ddos támadások jó részét, a jail-ek kerülhetnek az lo0 interfészre (tehát a valódi kártyákat akárhogy támadva, a támadó forgalom alapból nem jelenik meg a jail-ben), stb.
Ráadásul nyilván minden rendszer törhető. De igen nagy számú, mindenféle OS-t futtató gép lát el tűzfal és egyéb feladatokat egyszerre, és ezek közül nem törik meg a többségüket (sőt, csak igen kis részüket, azt is jellemzően nem megfelelően megválasztott jelszó, stb. - tehát felhasználói hiba miatt). Ilyen alapon a WRT sem lehet tűzfal, mert mi van, ha a gyári webfelületen van egy sebeshetőség, amit kihasználva bejutnak... Ha ilyen mértékű a paranoia (tehát semmilyen védelem nem elég jó), akkor egyszerűen ki kell húzni a drótot...
A jail egy lehetőség a kombinált funkciójú gép és a külön gépek beüzemelése között.

A sávszélesség korlátot én úgy értettem, hogy ha van egy WRT54-e, ami 100 MBit-es, és arra tátesz 2 helyi szegmenst, akkor szegmensenként összesen lesz 100 MBit átjárás a másik oldalra, és ha van 10 munkaállomás, az már csak 10 Mbit egyenként (ideális, azonos terhelés mellett), de ezt még valószínű a hardvere elviszi (persze több szegmens között már nem vagyok benne biztos). Ha pedig szerez egy GbE képes router-t, akkor meg a CPU-ja, alaplapja nem tud 1 Gbites folyamatos áteresztést a két szegmens között (több között meg pláne nem). Így nem is kell iszonyú méretű hálózat, hogy egy ilyen SOHO eszköz határait elérd.
Itt a HUP-on in többen számoltak már be olyanról, hogy 100 MBit-es internetet nem tudott kiszolgálni ilyen jellegű eszköz pár felhasználó felé.

se BSD-hez se az ottani JAIL-hez nem volt szerencsém, de debian lxc-vel játszottam egy picit és bizony a kernelen kersztül lehet műteni a jószágot konténerből...
Akkor végigolvastam a dev listát ezzel kapcsolatosan és sürgősen elvetettem az lxc-t. (azóta nem követtem a fejleményeket)
Ugyanakkor nyilván jobb a helyzet ha jailelsz, mintha nem is lennének elkülönítve.. de persze a legjobb a külön fizikai gép... ugyanakkor szerintem az első fontos lépés egy klassz monitoring+remote logging ami ilyen üzemméretben még nem mindenhol van meg. Igaz eső után köpönyeg, de legalább tudsz róla ha van valami. Tökéletes biztonság nincs.

( szollosiimre | 2014. 12. 04., cs – 09:30 )

Ha már tűzfalnak szeretnél freeBSDt, akkor nézz rá a pfsensere. Van wifi kompatibilitási mátrixa is, bár tapasztalat, hogy a tűzfal nem szokott jó helyen lenni a lefedés szempontjából.

Fájl szerver ek trustban a helye. A többiek által említett zentyal nem az ad miatt tud jó lenni, hanem a kollaboráció, fájlelérés terén is. Nem véletlen, hiogy kipakolták belőle az utm funkciók nagy részét.
Cserébe van egy ldap címtárad, és push levelezésed activesync.el, ami amellett, hogy a vezetők szeretik, nyújt remote wipe szolgáltatást is.

Unifi wifivjó lehet. Maga tart fent guestet, ami már ap szinten szeparál a belső hálóról, ha szeretnél, de ez inkább a tűzfal dolga legyen.

Pfsense openvpn implementációja remek. Kliensnek én viscocityt használok.

A hálózat managementet a trustban szeretem tudni, mert igy a tűzfal kiesése a belső munkát nem befolyásolja. Nagyobb hálóban persze ez feltételez némi internal routingot.

( pike.killer v | 2014. 12. 03., sze – 17:08 )

Klienseken milyen oprendszer futt? Azt mert van AD azt nem muszaj hasznalni, maradhatnak a gepek ugyan ugy workgroup-ba max kesobb nem kell farigcsinalni, hanem csak be kell leptetni a gepeket.

Stop, ha van masik domain a rendszerben, az csak jo. Be tudsz allni, mint subdomain, vagy be tudod a samba4-et teljeserteku member szerverkent / domain controllerkent leptetni a masik domainba (megfelelo alahuzando).
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Nem szeretnék túl sok részletet felfedni az IT infrastruktúrájáról (mármint ha van ilyen). Annak a domain-nek én nem vagyok adminisztrátora (aki az admin, szerintem nincs a helyzet magaslatán, a céges szerver IP címét a böngészőbe beírva egy IIS7 üdvözlőképernyő fogad pl., de vannak még ilyen finomságok). A cég másik telephelyen működik, a laptopok onnan valók. Ezt a hálózatot attól függetlenül, egy másik telephelyen alakítottuk ki, hogy könnyebb legyen a mindennapi munkavégzés. Mindezt ilyen "itt maradt" vasakból, asztali pc, SOHO router, switch.

Csak reszben ertem amit mondasz.

Az, hogy milyen szedett-vedett hardverek vannak ott, az az AD felepitesetol tokeletesen irrelevans, maskepp fogalmazva: too much information.

Ha nekem van egy head office-m, meg egy telephelyem, akkor a ket helyen nem ket AD-t hozok letre, hanem letrehozok a branch office-ban egy DC-t, ami a HQ domainjebe tartozik, igy korlatlanul lehet eszkozoket vonszolni a ket telephely kozott. Akarmilyen korlatolt a HQ rendszergazdaja, meg kell vele ertetni, hogy ennek csak igy van ertelme, mert ha a vezig lejon a branch office-ba, ugyanugy akarja majd hasznalni a HQ es a branch office eroforrasait is, ami ket, maganyos AD eseteben nem fog mukodni. Es ez meg csak a legkissebb gond a maganyos AD-kkal. Az igazan fasza megoldas persze az lenne, ha kulon IP site is lenne, de ez mar lehet meghaladja a HQ gazda kepessegeit. A ket telephely kozott pedig fel kell huzni egy IPsec kapcsolatot.

Es semmi egyeb nem kell, mint egy Domain Admin erossegu user es az is csak a promotalas idejere.

Maga a Samba4 kepes teljes erteku tagja lenni egy meglevo AD-nek akar masodlagos DC-kent is, akar RODC-kent is.

Ha ezeket nem lepitek meg, a munkavegzes nem konnyebb lesz. Nehezebb. Mindket rendszergazdanak.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Egy rendszergazda van, már ha annak lehet nevezni, nekem vannak fenntartásaim a dologgal kapcsolatban. Annyi közünk van a cég hálózatához, hogy a laptopokat onnan kapjuk, amik annak az AD-nak tagjai. Én ettől függetlenül tákoltam össze az itteni hálózatot, ami egyelőre kimerül egy debian fájlszerverben, egy szolgáltatói routerben és a 2 switch-ben. Néha a laptopokról VPN-el felcsatlakozunk az ottani hálózatra dokumentumokért.
Amit leírtál az tetszik. Én is így csinálnám, ha értenék az AD-hoz, meg én lennék a rendszergazda, ami nem vagyok.

Tetszik vagy sem, belekerultel egy olyan szituacioba, amiben neked kell eljatszani a rendszergarazda szerepkoret. Ket lehetoseged van: megprobalod elfogadni a helyzeted, es kepezni magadat, akkor lesz egy normalis halozatod, vagy itt ulsz es sirankozol, ez esetben egy egerdrotnyit se fog javulni a helyzeted. A dontes a tied, en nem akarlak befolyasolni...
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Hat, ha a HQ rgazdaja nem segit, akkor neked kell a sarkadra allni. Mivel felig mar igy is radruhaztak a rendszergarazda feladatkoret, nem sok kell ahhoz, hogy atvedd az iranyitast. De ehhez hatarozottsag kell elsosorban.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Mar reg ota terveztem, hogy kicsit megismerkedek az Active Directory-val. Gondolom ezt itthon megtehetem par virtualis geppel is. Ha szervernek is windows-t valasztok, akkor az mi legyen? Windows-t csak szimpla felhasznalokent uzemeltettem idaig (3.1-tol a 10beta-ig). Kiprobalashoz csak nem kell licence-t vasarolni.
Szerk.: "szerezzen tapasztalatot a windows server probaverziojaval", akkor az utolso mondatom ervenytelen.