Eens.
Fysieke link onderbreking zie je wel. Dat doe je niet met SNMP monitoring in 5min intervallen en de volgende ochtend checken, maar met een trap die je device stuurt. In ons geval naar een SMS gateway. Dan ligt er <10sec een SMSje bij de diensdoende collega
Onze interne ICT afdeling, that is, het deel dat verantwoordelijk is voor het operationeel beheer van alle systemen, is 2 man groot. Ik en mijn directe collega. (Er zijn nog 2 functioneel beheerders maar die beheren precies 1 applicatie.) Geen 24/7 standby diensten dus. We monitoren wel 24/7 maar na werktijd liggen onze werktelefoons in een hoekje en zijn we in principe niet bereikbaar, laat staan dat we onze monitoring in de gaten houden.
Dat is ook waarom we 's ochtends wat checks doen om te zien wat er in de nacht gebeurt is en op die manier alsnog reactief actie kunnen ondernemen. Niet ideaal maar bij zo'n kleine afdeling is 24/7 standby niet realistisch.
Kwa security is een eigen vezel aardig veilig. Je kan iig niet zomaar erop. Encryptie is idd nog beter, maar wordt relatief weinig gedaan ivm de benodigde performance. De dingen die er uiteindelijk overheen gaan zijn zelf wel weer encrypted meestal. Ook al zit men dus in dat L2 domein, dan nog is de meeste payload al encrypted door de onderliggene protocollen (SSH, HTTPS, SFTP of wat dan ook)
De benodigde performance is in dit geval niet anders dan de performance die we op de L2 verbinding tussen HQ en DC2 nodig hebben. Hooguit zijn de verkeersstromen tussen DC1 en DC2 iets veeleisender maar in beide gevallen willen we de volledige bandbreedte kunnen benutten als dat nodig is.
[...]
Ik zou niet naar 120km optics kijken, maar naar 80km. Als je daar niet mee af kunt, zul je moeten versterken. Met 1Gbit kun je idd wel wat verder, maar dan zit je in de toekomst met problemen, omdat je dan met 10Gb alsnog een probleem hebt.
We kijken naar optics die minimaal 80Km aan kunnen. Dat is ook wat ze vragen. De werkelijke afstand zal iets afwijken en zij versterken of dempen naar behoefte. Ze hebben liever dat we met optics werken die 120Km kunnen belichten dan optics die *net* de 80Km halen of zelfs daar onder zitten.
Welke optics het exact worden weten we nog niet, er zijn meerdere opties waaronder die van Solid, maar ook die van SmartOptics. In geval van de laatste zijn het optics met een 120Km range, blijkbaar hebben ze geen optics die 80Km of net daar boven aan kunnen.
Fortinet heeft die wel, 90Km optics. Verschil is de prijs. Fortinet kost dik 1500 EUR, SmartOptics net 280. Met dat prijsverschil is de keuze doodsimpel.
Voordeel van Solid is dat ze programmeable zijn en de programmer een paar tientjes kost. Dus gewoon universele optics op de plank leggen en programmeren as we go.
[...]
Met rancid kun je idd wel iets fixen, het is gewoon SSH en een CLi, je kan de config zo via TFTP of wat dan ook exporteren. Of gewoon een show-running afvangen over SSH, dan blijft het encrypted (itt tftp of ftp)
Kwa CLI: Anders..
enable -> System-view
show running-configuration -> display current-configuration
show interface x -> display interface x
write -> save
exit -> quit
En zo kun je heel lang doorgaan
Meh. Das een tegenvaller.
Het is vast af te vangen en desnoods pas ik zelfde scripts aan als niet iemand als eens een script heeft geschreven. Op de eoa manier was ik er vanuit gegaan dat ze bijna 100% Cisco-compatible zouden zijn, CLI-wise. Cisco is eigenlijk geen optie, 3x zo duur voor gelijke functionaliteit. (Snap ook wel dat ze afwijken, zoals iemand anders ook zei, Cisco vind het ws niet heel leuk als je hun volledige CLI jat.)
"Vertrouwen is goed, controle is beter" zeggen ze toch?
Mijn ISP vertrouw ik wel maar ook daar kunnen f*ckups gemaakt worden en de afstanden zijn zo groot dat ergens in de keten vrij makkelijk een knip gemaakt kan worden zonder dat we het direct zien.
Met een encryptie op je lijnen voorkom je iig dat bij de eerste de beste f*ckup van de ISP al je data op straat ligt.
Daarnaast probeer ik mij voor te stellen hoe je uit 1Gbps data die je capturen data gaat halen en daar iets zinnigs uit kan halen. Zonder diepgaande kennis van het bedrijf en de processen wordt het erg lastig om er innige data uit te halen. Waarschijnlijk zijn er veel simpelere methodes om die data te krijgen. Wat ik bedoel te zeggen is wel kijk verder en breder dan de theoretische mogelijkheid van een ding. Ik geloof namelijk niet dat je voor de NAVO, politie of andere zwaar geheime organisatie werkt.
Er gaat replicatieverkeer over de lijn. Lijkt me typisch iets waarbij het waarschijnlijk niet heel lastig is d'r bruikbare data uit te halen. Sure, de kans is niet groot maar als het gebeurt heb je wel een probleem, zeker met de nieuwe wet datalekken. Het kan op -tig plekken fout gaan, for sure, ik heb alleen een donkerbruin vermoeden dat als we deze stromen niet encrypten en het gaat daar mis, de rechter niet zo mild is en zegt "geen encryptie toegepast, boete". (Terecht. Eigenlijk de enige echte reden waarom we twijfelen over encryptie is het geld dat er mee gemoeid is. Da's een excuus waar de rechter ws gehakt van maakt.)
En nee, ik werk niet bij zo'n organisatie, heb wel te maken met persoonsgegevens. (Zoals zo veel bedrijven.) Dus vereisten daar op een zinvolle manier mee om te gaan.
johnkeates schreef op dinsdag 30 mei 2017 @ 20:12:
Is het niet een stuk praktischer om met een VXLAN en OpenVSwitch te werken? Dat kan je prima over een IPSec of OpenVPN verbinding tunnelen en zolang je AES acceleratie hebt kan je de pijp wel vol trekken. Neem bijvoorbeeld een Xeon-D based pfSense doosje en je komt er wel.
Zijn er hardware implementaties van VXLAN en OpenVSwitch?
We zijn hier nl. heel specifiek op zoek naar een off-the-shelf hardware oplossing. Sure, onder water zit daar ook vrij standaard techniek in en het *kan* prima met een HP server en wat netwerkpoorten, maar ik betwijfel of ik daar heel erg gelukkig van word en of dat in the end goedkoper gaat zijn. Een beetje HP server met genoeg poorten kost ook 2000 EUR of meer. (En voor dat geld heb ik dus die 100E's van FortiNet.)
Wat je ook kan doen is L2 vergeten en 'ouderwets' routeren. Daar is niks mis mee.
De onderliggende verbindingen zijn sowieso L1 (DC1 - DC2) en L2 (HQ - DC2). Daar overheen zullen we in eerste instantie en primair routeren. Voor sommige dingen is L2 handiger en het is prettig als we de mogelijkheid voor L2 houden en kunnen inzetten waar dat nuttig / wenselijk is. (We denken aan een IP range die op 2 of meer locaties leeft waardoor we bijvoorbeeld eenvoudig HA setups over WAN verbindingen kunnen doen.)
Alleen, wat levert L3 op gebied van deze case voor voordelen op? Wat ik verder in de reacties lees is het juist efficiënter om je IPsec op L2 te zetten. Dan heeft L2 dus voordelen en kunnen we daar overheen alsnog routeren als we dat willen. (En dat willen we dus.)
Ná Scaoll. - Don’t Panic.
:strip_exif()/u/101509/Avatar.gif?f=community){kind=avatar}
/u/517001/crop610128fa1e7fb_cropped.png?f=community)
:strip_icc():strip_exif()/u/6607/klootviool2.jpg?f=community)
/u/34216/avatar-60x60.png?f=community){kind=avatar}
:strip_exif()/u/16622/121823.gif?f=community)
