[Rasmus]

Tere

Kuna mul on esmakordselt käsil tulemüüri seadistamine suht suures ettevõttes, siis olen asja uurinud ja mõelnud, ning mõtlesin, et tekitaks selleteemalise arutelu. Seda just selleks, et erinevate üldlevinud teenusega seotud portide avamine/sulgemine on kohati suht peavalu ja näpukad võivad tundideks lisatööd teha. Mina alustasin oma tööd sellega, et kaardistasin kõik teenused, mida tulemüür vahendab ning siis sidusin teenused vajaminevate portidega ja koostasin nimekirja.

Üldisest tulemüürimise loogikast olen mina aru saanud nii, et kõigepealt keeratakse kõik asjad kinni ja siis vastavalt vajadusele tehakse lahti. Samuti on levinud loogika, et sisevõrgust välisvõrku piiranguid ei tehta. Kuna minu puhul on tegemist võrguga, kus seda siiski rakendada tuleb, olen võrgu segmenteerinud VLAN-ideks ja nende vahel saab kenasti reegleid luua.

Kogu teema eesmärk on see, et head kasutajad, kelle abile ma siinkohal natuke loodan, tekitavad arutelu ja viitsivad ehk süveneda asjasse. Annavad nõu, kas mul ehk midagi kahe silma vahele pole jäänud ja kas üldine loogika on õige.

Teenused, mida tulemüür vahendab või blokeerib (vastavalt vajadusele)

icmp (ping)
ftp
ssh
smtp
dns
tftp
http
https
pop3
Windows file sharing
Windows AD replication
Windows Netbios services
LDAP services
Kerberos
imap
rdp

Vastavalt nendele teenustele otsisin välja protokollid ja pordid, mida tuleks avada/suunata nii välisvõrgust sisevõrku, kui sisevõrgus erinevate VLAN-ide vahel. Nimekiri portidest sai selline.

ICMP Ping
TCP 20 FTP Data
TCP 21 FTP Control
TCP 22 SSH
TCP 25 SMTP
UDP 57 DNS
TCP 57 DNS
UDP 69 tftp
TCP 80 http
UDP 88 Kerberos
TCP 88 Kerberos
TCP 110 POP3
TCP 135 W-DCE/RPC
UDP 135 W-DCE-RPC
UDP 137 W-NetBios NS
TCP 137 W-NetBios NS
UDP 138 W-NetBios DS
TCP 138 W-NetBios DS
UDP 139 W-NetBios SS
TCP 139 W-NetBios SS
TCP 443 https
TCP 445 W-DS AD, W-Sharing
UDP 445 W-DS SMB Sharing
UDP 143 IMAP
TCP 143 IMAP
UDP 389 LDAP-Ping
TCP 389 LDAP
TCP 514 cmd
UDP 636 LDAP over SSL
TCP 3268 LDAP Global Catalog
TCP 3269 LDAP Global Catalog SSL
TCP 3389 RDP

Rohkemat ei oskaks mina esialgu midagi teha või on äkki midagi veel, millele ma peaks tähelepanu pöörama?

[Drake]

Tavaliselt näebki corporate policy ette et piiratakse ka väljuvaid ühendusi, et oleks väga selgelt piiritletud mis teenused saavad välja. Koduvõrgus võib lubada mis iganes asju endale, vähegi mõistlikumas ettevõttes sellist asja et kõik on välja lubatud ei tunnistata.

See loetelu mis on välja kirjutatud ei ütle otseselt mitte midagi - kõik sõltub võrgu hierarhiast ja teenuste vajadusest.
Alustame loogikast, et tavapärases maailmas pannakse müür sisevõrgu ja välisilma vahele ja samuti nt dmz ja välisilma vahel jne.
Võtame kasvõi näiteks windows file sharing teenuse - välisilmale seda ilmselgelt lahti ei tee ja midagi piirata kah pole sest FW policy dropib juba nagunii kõik muud ühendused. Selle teenuse majandamisel tuleb mängu müüri torkimine nt siis kui on vpniga partnerfirma võrk seotud aga tahetakse teenust piirata. Vlanide vaheline ruutimine on siis suht ainus asi vast mida teha.

Üldine loogika on tegelt õige, küll aga huvitab, et millega seda rõõmu siis müüritakse ja mis mastaabis võrgust me räägime üldse ?

1000 Masinat 25-s eri geogr. asukohas ?
15 000+ masinat 100+ eri geograafilises asukohas ?
Või eesti mastaabis 100 ja vähem masinat peamistes linnades ?

d.

[vaegkuulja]

Eks muidugi igal asutusel omad reeglid. Lisaks veel mõningad turvaaugud mida rahutumad ja igavlevad töötajad testima võivad hakata. Failisikutamise tarbeks portide piiramisest ei piisa, vaja ka layer7 tuge. Isegi siis on ette tulnud et võetakse kasutusele kogu kanali krüptimine, jälle võit nende ja jälle vastumeetmed portide ja aadresside blokimisega.
Siis on ette tulnud et üritatakse hõivata mõnda ilma väljapoole piiranguta masinat ja istutada talle proxy-serverit (seda muidugi ilma õigusteta ei saa teha). Siis kasutatakse väljapoolt sisse ühenduse saamiseks mõnda tarkvara, mis alustab sessiooni seest välja ja ongi kogu sisevõrk sissetungijale nagu peopeal (isegi naljakas on et reeglid näevad ette VPNi ja pin-kalkulaatorit, mille turvaeesmärk muutub ümmarguseks nulliks). Turvalisusele aitab kaalu ka proxy-server koos autentimisega, võisiis tulemüür domeenikasutajate autentimisega.

[Rasmus]

Tegemist on haridusasutusega.

Võrgus on vastavalt kasutusele 200-300 hosti (avalik wifi on muutuja). Võrk on struktueeritud VLAN-idega vastavalt sihtotstarbele. Kasutusel on Windows 2003 Server platvormil asuv AD koos terminalilahendusega.

VLAN-id on jagatud hetkel nii:

VLAN1 - serverid, võrgu aktiivseadmed suletud wifi.
VLAN2 - terminalid
VLAN3 - avalik wifi
VLAN4 - tööjaamad

Reeglistik on selles suhtes paigas, et VLAN-ide vahelised tulemüürireeglid on paberil poliitikana paika pandud ja on täpselt teada, milliseid teenuseid üks või teine VLAN teineteise suhtes rakendada saab. Üldiste teenuste kirjeldamisega (a la http, ftp jms sodi) olen ma ilusti kursis, kuid teatavasti käivad teenustega kaasa ka kõrvalteenused. On elementaarne teada, et kui tahad kasutada veebi, siis võiks olla ka DNS, sest muidu on natuke keeruline .

Minu küsimus on rohkem selline, et ega ma ei ole midagi olulist teenuste kirjeldamisel kahe silma vahele jätnud, mis võiks erinevate teenuste serveerimisel takistuseks saada, kui mõni juhuslik port tulemüürist avamata/suunamata on jäänud.

Tulemüüriks on muidu Cisco 1841, millel IOS 12.4

[kurask]

pigem oleks muid üldisemaid soovitusi:D
*nagu et vaheta pop3 välja (kasvõi ssl pop3)
*ei saanud nüüd täpselt aru mis pidi sul windows file sharing käib - a kui kellelgi väljastpoolt on selle kaudu mingit moodi access, siis see ei ole normaalne lahendus.
*failifahetamistel juuruta või arenda mingi kindel meetod, näiteks kogu firma väline failivahetus käib maili ja mingi https teenuste kogumike baasil (extranet-intranet) st samamoodi nagu windows file sharing, ei ole ka ftp turvaline lahendus.

Pmst windows file sharingut tolereeritakse vpni kasutades, aga su pordi nimekirjas pole ühtegi vpni porti.

Võibolla minuga hakatakse nüüd vaidlema (ala vaegkuulja), sest ma olen liiga paranoiline (olen jah), aga ma soovitan siiralt vähendada erinevate teenusetüüpide ja platformide arvu (eriti sama eesmärgiga teenuste osutamiseks) - on tore kui töötaja saab 5te erinevat kanalit pidi oma asju saata, aga veel toredam minu vaatevinklist on, kui dmz serveerib vaid xhtmli :õ

[vaegkuulja]

Võibolla jäi mul midagi märkamata, kuid tulemüüri reeglid olenevad mitte sellest mis "peab" olema turvalisuse seisukohast, vaid ikka sellest mis sealt läbi hakkab jooksma, et siis mis teenused kuhu poole piiri jäävad, see paneb asja ise paika.

[Rasmus]

No teenuste vahetamine ei ole selles suhtes üleüldse küsimus, sest kui klient, kes näiteks avalikku Wifi-t kasutab, tahab pop3 protokolli kasutada, siis mina ei saa küll piiranguid seada, mida tema kasutab. Mina pean sellega lihtsalt arvestama, et ta seda kasutab ja üldtuntud teenuseid peaksin ka võimaldama. P2P muidugi sinna hulka ei kuulu

Ei ei, ärge vaadelge asja nii konkreetselt. Ma olen täiesti a täie mõistuse juures ja ei hakka igasugu imelikke teenuseid väljast sisse lubama, kui neid pole vaja. Küsimus on rohkem selles, et teatud teenuste pakkumiseks (näiteks http jaoks on vaja ka DNS-i muidu on vähe jama ) on vaja teatud porte juurde, millel teatud teenuseid käitatakse. Selles on küsimus, et kas kogu portide nimekiri on selles mõistes terviklik või võib juhtuda see, et midagi on kahe silma vahele jäänud ja selle tõttu mõni teenus eriti hästi töötada ei taha.

[mikk36]

DNS'i relay võib asuda ka kohalikus serveris, seda infot ei pea pärima välisvõrgust.

[Angrist]

Üks oluline aspekt on see ka veel, et SMTP teenust lubada välja ainult sinu meiliserverist. mitte igast masinast. Samamoodi sa ei taha, et keegi hakkaks masinast omale koduvõrku VP N-i tegema niiet PPTP ja L2TP, ja muud teenuste pordid ka kinni seest välja.

Aga rakenda ikka loogiliselt nii, et lubad ka seestpoolt väljapoole ainult vajalikke porte.

[Sk8Rax]

[kurask]

dns käib läbi 53 ikka.


http://vahupidu.planet.ee/archive/port-numbers_13_January_2005.txt

[Rasmus]

Täiendaksin teemale juurde, et kes puutub kokku Windowsi AD replikeerimisega ja domeenis olevate masinatega tulemüüriga seotult, siis tasub tähele panna, et RPC Endpoint Mapper-i TCP port tuleb DC-s käsitsi defineerida ja siis ka avada, muidu on sisselogimine domeenimasinasse (näiteks) vägagi vaevaline.

[HacaX]

DNSi võiks ka siduda konkreetsete serveritega, s.o. lubatud pöördumine vaid kindla masina sellesse porti (kas sisevõrgus paiknev või siis teenusepakkuja DNS). Välistab võimaluse, et mõni kavalpea läbi tolle pordi torrentama/VPNi ehitama hakkaks.

[Etz]

[Rasmus]

[Etz]

[Rasmus]

[Angrist]

Paned võrgu C teise vahemkku ja siis toksid sisse selle C vahemikule ruuteris route F-i, ning ABD route C se. Mis seal rasket om ?

Kui on windowsi põhine keskkond siis anna tuld käskudeks Route add /route deletete (olid vist need) kui netscreen siis naca teisiti. Kui trendneti ruuter, siis osta midagi normaalsemat.

Kui sul on võrgus 2 ruuterit siis konfid erinevad võrguvahemikud ning vahemikule C paned default gatewayks F-i ning ABD le default gatewayks E.

Kuidas konfida 1 DHCP andma kindlatele masinatele erinevaid IP vahemikke või panna võrgus tööle 2 dhcp-d ma kahjuks õpetada ei oska.

PS.

Sorry ei lugenud et tegu CISCO -ga. aga pmst põhimõte sama. Kas sa ei saa suunata mingit subetti porti A ja teist subnetti Porti B ? (või E ja C vist olid need ?).

Vahel CISCO -d ei võimalda ka selliseid lihtsaid asju. uuri manuaalist järgi.

[Etz]

[Angrist]

[Rasmus]

No nii, räägin siis asjast lähemalt.

On 4 võrku, A, B, C, D. Kõik võrgud on eraldi VLAN-ides ja eraldi subnettides. Iga VLAN-i jaoks on olemas oma võrgukaart. On olemas 2 staatilise IP-ga välisühendust E ja F. Hetkel on tehtud asi nii, et on olemas default route:
Prefix Prefix mask Interface Distance Permanent Route Track No
0.0.0.0 0.0.0.0 E (IP) 1 Yes None

NAT-i poole pealt täpselt samamoodi - iga võrk on eraldi suunatud.

Kui ma korjan Default Route ära, et kõik võrgud ei ruuditaks läbi konkreetse interface, vaid teen igale võrgule eraldi ruutingu, kus võrgud A, B, ja D lähevad läbi interface E ning võrk C läheb läbi interface F, läheb asi katki. Loomulikult teen parandused ka NAT-i osas, et asi oleks õige, kuid liiklus enam ei liigu.

Loomulikult

[Angrist]

Mõlemal väljuval interfeisil peab sul olema minuarust 0.0.0.0 route. ja kogu väljuva liikluse pead sa sinna suunama. A praegu ma olen juba hallil alal mida ma enam niitäpselt ei mäleta ja võin eksida. kunagi sai netscreenidega sama asjaga jamatud.

http://www.lns.com/papers/netload/
Seal kirjeldatakse kuidas teha load balancingut, a ilmselt sealt saad juba edasi mõtiskleda, kuidas üks kanal ühte suunata ning teine teise jne.