Zaujal ma popis implementácie IPv6 v BIRDe čo je alternatíva k dobre známemu software routovaciemu enginu Quagga. BIRD je Český projekt, taktiež pod záštitou CZ.NICu.

Knihu je možné stiahnúť v pdf formáte (3MB) na tejto linke:
http://knihy.nic.cz/files/nic/edice/pavel_satrapa_ipv6_2011.pdf

V prípade, že hľadáte kvalitný, stabilný a lacný router s podporou IPv6 vyrobený na Slovensku a s implementáciou BIRD aj Quagga, môžete si ho kúpiť v  mojom obchode na linke:
http://shop.erikkirschner.sk/routers/router-3f/

K routru automaticky poskytujem aj konfiguračné práce spolu s návrhom kompletného riešenia, implementácie a prevádzkového servisu.

Ako to začalo.

Požadovaný cieľový stav.
Hotel Sebastian najviac trápila telefónia. Primárnym cieľom bolo mať v každej hotelovej izbe telefón. Automaticky s primárnym cieľom sa objavili otázky o bezpečnosti, keďže je jednoduché vytiahnúť ethernet kábel z telefónu a zasunúť do počítača a hosť je na jednej sieti kde aj pokladňa, atď…. Prišla teda na rad debata o bezpečnosti, segmentácie LAN siete a poriadnom firewalle.

Riešenie.
Všetky IT riešenia závisia vo veľkej miere od kabeláže. V hotely Sebastian majú v každej izbe dve RJ45 zásuvky (ethernet porty). Jeden sa teda automaticky využil pre pripojenie VoIP telefónu. V každej izbe je teda VoIP telefón a hosť má možnosť sa pripojiť na internet cez WiFi, ktoré je dostupné na izbách a vo všetkých priestoroch hotela. Telefóny sa inštalovali aj do ďalších prevádzkových priestorov hotela. Dodaný systém VoIP telefónie má dostupné web rozhranie cez obyčajný internetový prehliadač, cez ktoré je možné na recepcii pri odhlasovaní hosťa zistiť koľko minút a teda aj peňazí prevolal.

Už na začiatku som spomenul segmentáciu LAN siete a bezpečnosť. V hotely sú tri segmenty siete:
1) VoIP telefónia
2) WiFi hot spoty (verejný internet pre hotelových hostí)
3) interná/privátna sieť hotela (pokladne, recepcia, kuchyňa,….)

Každý segment sieťe slúži na niečo iné a teda musí mať vlastné bezpečnostné pravidlá pre komunikáciu. Napr. zo segmentu VoIP telefónie nie je potrebný prístup do interentu, do internej siete hotela ani na WiFi hot spoty. Je to uzavretá sieť, kde prebieha komunikácia len medzi VoIP zariadeniami (VoIP telefóny a VoIP telefónna ústredňa). WiFi hot spoty zas potrebujú mať povolenú komunikáciu len do Internetu, ale už nie do internej siete alebo k VoIP telefónom.

Tieto pravidlá komunikácie jednotlivých segmentov siete zabezpečuje nový dodaný firewall pfSense. Každý segment LAN siete je pripojený k firewallu a tento je pripojený aj do internetu. Ovládanie firewallu je cez web rozhranie a je veľmi intuitívne a jednoduché. Aj zamestnanci hotela čo nie sú technici, si vedia pozrieť v prípade problémov vyťaženosť jednotlivých segmentov siete a zistiť ak nejaký hosť sťahuje napr. 4GB film cez hotelové WiFi a samozrejme následne riešiť situáciu.

Čo a odkial bolo dodávané do riešenia (odkazy):
- cez 30 VoIP telefónov
- VoIP telefónna ústredňa Elastix 500
- pfSense 3F Firewall

Záver
Samotná inštalácia aj so zaškolením trvala 2 dni. Zamestnanci hotela a aj majitelia sú spokojný a ak sa chcete presvedčiť o kvalite riešenia, navštívte Hotel Sebastian. Hotel je naozaj krásny s výbornou reštauráciou a v peknom prostredí.

Ak Vás moje riešenie zaujalo a potrebujete riešiť pre Vašu firmu niečo podobné (nemusí to byť iba hotel), napíšte/zavolajte. Veľmi rád pomôžem.

Úvod

Tento dokument ti prezradí, ako kontrolovať prístup vzdialených užívateľov z internetu cez OpenVPN a pfSense firewall do privátnej siete pomocou PKI certifikátov a overovaním mena/hesla cez radius protokol proti Microsoft Windows 2008 R2 Active Directory.

Základný popis riešenia

OpenVPN v pfSense firewalle je veľmi dôležitá funkcia. Najčastejšie sa pre authentifikáciu do OpenVPN používajú PKI certifikáty, ktoré je možné vygenerovať certifikačnou authoritou alebo aj lokálne cez EasyRSA (EasyRSA for pfSense).
Prístup cez OpenVPN do privátnej siete, alebo DMZ cez certifikát je pohodlný. Pri odcudzení notebooku užívateľa je jednoduché vygenerovať CRL zoznam, ktorý dohráte do pfSense a konkrétny užívatelia majú zablokovaný prístup.

Overview of a pfSense-CARP setup

You need one real IP address for every CARP cluster host. So, if you want to have 2 cluster members, you will need 2 IP addresses for the real interfaces and then an IP for each virtual IP address. So in this case it would amount to 3. In the example shown to the right, the primary CARP clusters WAN IP address is 127.29.29.1 and the backup firewalls WAN IP address is 127.29.29.2. The primary clusters LAN IP address is 192.168.1.2 and the backup firewall’s LAN IP address is 192.168.1.3.

Setting up dedicated pfsync interface

We strongly advise using a dedicated interface for pfsync.

Set up each cluster sync interface, give it an IP address in the same subnet. Example: on the master cluster member enter 192.168.4.1 and on the backup cluster member enter 192.168.4.2 for the IP address. Use a /24 subnet.

Enable pfSync

Enable pfSync in Firewall -> Virtual IPs -> CARP settings -> Synchronize Enabled (check it) on all cluster members.
-> Synchronize Virtual IPs [ X ]
-> Synchronize to IP [ insert Slave IP ONLY on Master! ]
-> Remote System Password [ do not forget! ]

Select the dedicated Sync interface with the Synchronize Interface dropdown on all cluster members.

Afterward visit Firewall -> Rules and add an allow all from any to any rule on each cluster member for the newly created pfsync interface.

Adding CARP shared virtual IP addresses

Now on the master cluster member add a virtual IP addresses of the CARP type in Firewall -> Virtual IPs. Make sure that the virtual IP addresses fall within the same subnet of an IP address defined on real interface (WAN, LAN, OPT1, etc.). You need to dedicate a unique VHID per shared virtual IP address. The lowest skew states that the host should be a master. The XMLRPC process will automatically add +100 to each host while syncing. So we recommend setting the skew to 0 on the master hosts CARP virtual IPs. pfSense will handle the rest.

Preparing for XMLRPC Sync

Now set the same Admin password and protocol for the webConfigurator (HTTP/HTTPS) on each cluster member

On the master cluster member, visit Firewall -> Virtual IPs -> CARP Settings and enter the 2nd cluster members sync ip address (earlier in example was 192.168.4.2). Afterwards, enable all sections you want to sync (Synchronize rules, Synchronize aliases, Synchronize nat, ..*). This will automatically push configurations from the master cluster member to the backups. Click save. You should see the virtual ip addresses automatically synchronized to the backup hosts

Setting up advanced outbound NAT

Enable advanced outbound NAT in Firewall -> NAT -> Outbound -> Enable advanced outbound NAT. Click save.

Edit the automatically added rule for LAN. Pick a shared CARP virtual IP address as the Translation IP address. Give the item a description and click Save.

Setting DHCP Server to use CARP LAN IP Address

On both firewalls, visit Services -> DHCP Server. Click on the LAN tab. Set the default gateway to 192.168.1.3. Click save.

It also may be a good idea to enable failover DHCP. Enter 192.168.1.2 in the failover peep box on the primary and 192.168.1.1 on the backup server. Click save.

Checking that XMLRPC sync worked

Visit the backup cluster member and verify that NAT, Virtual IP’s and rules have been synchronized correctly.

Finally on the backup host, visit Firewall -> Virtual IPs -> CARP settings -> and enable “Synchronize Enabled” and make sure that your pfSync interface is correct. Click save.

You should read the hardware redundancy chapter in the pfSense book before configuring CARP.

From the Tutorials page:

• Building a fully redundant Cluster with 2 pfSense-systems between WAN/LAN with CARP & pfsync / pfSense CARP & pfsync failover-simulation

http://www.pfsense.org/mirror.php?section=tutorials/carp/carp-cluster-new.htm

I have many pfSense Firewall appliances in my shop, which you can buy.

That’s it! Enjoy your failover firewall solution.

15 apríla 2010 sa uskutočnil v Club Penati Bratislava prvý ročník konferencie ISACA Professional Day 2010. Konferencia bola zameraná na tému IT Security, Outsourcing, Governance. Hovorilo sa aj na tému Cloud Computing.

Konferencia bola organizovaná ISACA Slovakia hlavne pre ľudí zaujímajúcich sa o audit, bezpečnosť a poradenstvo. Ja som dostal pozvánku od Ivana Kopáčika prednášať na tejto konferencii na tému Cloud Computing. Moja prezentácia bola naplánovaná na poobedie a tak som pozorne celé doobedie počuvál, aký majú názor na tému Cloud Computing ľudia z oblasti auditov.

Musím sa priznať, že bolo naozaj zaujímavé sledovať, ako sa na túto tému pozerá Palo Adamec z KPMG a aké riziká vidí KPMG v tejto oblasti. Na druhej strane musím povedať, že aj týmto ľudom je jasné, že pre zákazníkov je to atraktívna služba a oni nemôžu brániť businessu, ale sčasti sa prispôsobiť trendu a hlavne minimalizovať riziká s týmito službami spojené.

Verím, že moja prezentácia ľuďom ukázala ako sa na vec Cloud Computing služieb pozerá service provider a taktiež zákazník. Prezentácia bola prípadová štúdia zákazníka Cloud Computing služieb v našom data centre Perpetuus. Prezentovaný bol názor service provider-a a tiež uhoľ pohľadu zákaznika. Čo bolo pre neho dôležité pri výbere, na čo všetko sa pýtal a na základe čoho sa rozhodol.

Reakcie ľudí po panelovej diskusii ma presvedčili, že o túto tému je veľký záujem, pretože sa o nej veľa píše, ale málo ľudí počulo o zákazníkoch, ktorí takúto službu reálne na Slovensku využívajú.

ISACA Professional Day mala pre mňa nesmierny prínos a verím, že aj ja som prispel svojou troškou prezentovaním prípadovej štúdie Cloud Computing služieb k pozitívnym náladam v tejto organizácii na túto tému.

Považujem sa za stabilného účastníka konferencie Cisco Expo a musím povedať, že tento rok opäť splnila očakávania, ale aj prekvapila. A to hneď na začiatku príhovorom generála Cisco Slovensko, že v budúcnosti plánujú Cisco Expo robiť virtuálne. Nebude to samozrejme hneď plne virtuálna konferencia na budúci rok, ale asi je to len otázka času. Je to prirodzené, keďže Cisco kúpilo WebEx a trend tiež ukazuje jasný smer, kam sa táto oblasť uberá.

Týmto nechcem Cisco-u nič vyčítať. Len si myslím, že okrem zaujímavých prednášok tam ľudia chodia aj z dôvodu stretnutia sa s inými ľuďmi osobne, s ktorými sa v mojom prípade stretávam len na tejto akcii. Jednoducho sú to kamaráti, bývalí kolegovia, ľudia z fachu, atď… z celého Slovenska a toto je ideálna príležitosť na takéto stretnutie a poklábosenie ako ide život, ako sa darí, čo nové. V tomto prípade mi určite nebude stačiť video konferencia. Veď uvidíme čo prinesie ďalší rok.

Z prednášok bol veľmi zaujímavý IPv6 Deployment od Štefana Kollára. Prednáška bola v podstate o tom, že nás čaká kopec roboty a dôležitých rozhodovaní pri migrácií na IPv6. Ak nájdem prednášku na nete, tak sem určite pridám linku.

Bolo zaujímavé sledovať akých ľudí poslala na konferenciu jedna Slovenská IT firma. Konferencia je vysoko odborná, určená hlavne pre technikov. Registrácia na konferenciu je pomerne nákladná, ale táto spoločnosť neváhala poslať na Cisco Expo celé svoje obchodné oddelenie. Pričom technik bol na konferencii len jeden a druhý technik bol len druhý deň na lístok generála danej spoločnosti (technické oddelenie má niekoľko desiatok ľudí). Do teraz nechápem prečo tam bolo toľko obchodníkov, keď na konferencii sú hlavne technicky zameraný ľudia (nemajú možnosť ovplyvniť obchod), konkurencia a partnerské spoločnosti. Z môjho pohľadu žiadny potencionálny zákazník. Osobne by som tam niektorých technikov poslal povinne a nie viac ako 10 obchodníkov tam zbytočne zabíja čas a čo sa týka nákladov, to radšej ani nehovorím. Ale možno je to v tejto spoločnosti určitý štandard. Tak želám tejto firme veľa úspechov a kvalitných obchodníkov vždy na správnom mieste v správnom čase.

Potešilo ma stretnutie s jedným človekom, ktorý mi dokonca povedal, že číta tento blog. Pre takéto momenty sa naozaj oplatí napísať pár riadkov, ktoré ľuďom môžu pomôcť, alebo im aspoň ukázať smer, akým sa vydal niekto iný pri riešení podobného problému.

Verím, že sa na tejto konferencii budeme stretávať osobne, alebo aspoň do času pokiaľ si nebudem môcť podať s tebou ruku cez video konferenciu.

Today I passed recertification exam 642-524 Securing Networks with ASA Foundation. My CCSP certicate is valid for next 3 years. I’m realy happy. Thank you for your congratulations.

K finálnej štandardizácii prišlo sedem rokov od štartu vývoja nového štandardu a viac ako dva roky od spustenia certifikácie zariadení s druhým návrhom štandardu. V súčasnosti sa už denne predáva viac ako milión zariadení kompatibilných s druhým návrhom WiFi 802.11n certifikovaných WiFi alianciou.

Oproti druhému návrhu štandardu, s ktorým sú kompatibilné súčasné zariadenia, prišlo vo finálnej verzii k menším zmenám najmä u voliteľných funkcií a vlastností.

Zariadenia certifikované WiFi alianciou pre súlad s finálnou verziou štandardu budú interoperabilné s doterajšími zariadeniami a podľa oznámenia WiFi aliancie doterajšie zariadenia kompatibilné s druhým návrhom štandardu získajú dokonca právo používať logo kompatibility s finálnou verziou štandardu, keďže sú kompatibilné zo základnými požiadavkami aj finálneho 802.11n.

U viacerých 802.11n čipsetov je zároveň možné, že výrobcovia iba aktualizáciou firmvéru zabezpečia aj u už predaných zariadení úplnú kompatibilitu s finálnou verziou štandardu.

Verzia 802.11n je na rozdiel od doteraz bežne používaných verzií WiFi 802.11b a 802.11g určených len pre 2.4 GHz pásmo určená pre 2.4 GHz alebo 5 G GHz pásmo.

Oproti verzii 802.11g nová verzia 802.11n výrazne zrýchlila, z maximálnej fyzickej komunikačnej rýchlosti 54 Mbps až na 600 Mbps, teda 11.1-násobne. Časť zrýchlenia je dosiahnutá vďaka voliteľnému zdvojnásobeniu šírky využívaného komunikačného kanálu z 20 MHz na 40 MHz, o ďalšie takmer 5-násobné zrýchlenie sa už postarala efektívnejšia technológia.

Zdvojnásobenie šírky kanálu na 40 MHz poskytuje 108 frekvencií v OFDM namiesto 52 frekvencií, bitrate sa tak zvyšuje presne 2.25-násobne. Aj 802.11n môže ale stále používať aj 20 MHz kanály.

802.11n používa efektívnejšie opravné kódy, keď na ne pripadá len 1/6 prenášaných bitov namiesto 1/4, rýchlosť tak zvyšujú o devätinu. Rýchlosť zvyšuje aj skrátený ochranný interval proti rušeniu oneskoreným odrazeným signálom z 800 ns na 400 ns, čo umožňuje zvýšiť rýchlosť o ďalšiu jednu devätinu.

Najväčšie zrýchlenie ale prináša technológia Multiple Input Multiple Output, MIMO. Pri použití MIMO dve zariadenia komunikujú na jednej frekvencii nie jedným ale viacerými, dvomi až štyrmi, dátovými streamami a rýchlosť sa tak zdvoj, stroj alebo zoštvornásobuje.

Pre každý dátový stream potrebujú mať obe zariadenia samostatnú anténu. U zariadení certifikovaných podľa druhého návrhu štandardu 802.11n bola overovaná kompatibilita s MIMO s maximálne dvomi streamami, ktoré umožňujú maximálnu rýchlosť 300 Mbps. Súčasné čipsety podporujú typicky maximálne dva dátové streamy, najlepšie zatiaľ predstavené čipsety popredných výrobcov tri prípadne prototypy plné štyri streamy s maximálnou rýchlosťou 450 Mbps respektíve 600 Mbps.

802.11n zároveň okrem výrazného zvýšenia fyzickej prenosovej rýchlosti zvyšuje aj efektívnosť prenosu samotných dát pomocou napríklad spájania potvrdzovacích framov, podľa dostupných informácií môžu u 802.11n dáta tvoriť v ideálnych podmienkach až približne 75% fyzickej rýchlosti oproti menej ako 50% pri 802.11g.

Plné znenie schválenej finálnej verzie štandardu bude zverejnené v októbri, certifikácia nových zariadení s finálnou verziou štandardu vrátane testovania interoperability nových voliteľných funkcií začne už tento mesiac.

Článok je prevzatý z www.dsl.sk.

V článkoch je rozoberaná téma základného zabezpečenia routra, switchu a L2 úrovni na switchi. Tu sú spomýnané dva članky uverejnené na blackhole.sk:

Bezpečnosť sieťových zariadení, časť I.

Bezpečnosť sieťových zariadení, časť II.

Možno v budúcnosti, keď tu bude pár pozitívnych príspevkov, napíšem pokračovanie. Takže, ak Vás články zaujali, napíšte mi prosím Váš názor na pár riadkov.

Update 1.4.2009
Tento článok číta pomerne veľké množstvo ľudí. Rozhodol som sa uprobiť prepis prvých dvoch častí na tento blog. Doplním aj tretiu časť, ktorá sa bude venovať designu LAN sietí a návrhu management segmentu pre správu aktívných zariadení (routrov a switchov).