Husstandens sidste Soekris

Du kan vælge mellem:
- 10-15 år gammel teknologi, med fin serielport, compact-flash storage, osv.
- ny teknologi som i arkitektur ligner en PC.

For 6 år siden pensionerede jeg min soekris net5501 og erstattede den med en compulab fit-pc3 med ekstra 4 ethernetporte. Den var ganske vist dyrere end en soekris, men jeg slap for serielkabler og fik rigelig CPU-kraft. Jeg har ikke fortrudt.
Vi har også installeret dem hos en del kunder (til bygningsautomatisering) og de har overvejedende været stabile. Jeg vil dog holde mig fra hvad end M.2-diske compulab tilbyder - de er simpelhent for ringe.

Jeg har lige taget mine to sidste net5501-kasser ud af drift. Mine to net6501 kom aldrig tilbage i produktion efter garantiombytning pga. frygt for Red-LED-of-Death syndromet.

net6801 ville have været helt perfekt, hvis den var blevet til noget. Bortset fra at Avoton/Rangeley også lider af LPC clock-problemet, altså.

Det er trist, at der ikke er tilsvarende produkter på markedet. Der er i stedet gået inflation i, hvor mange 4K displays man kan hænge på en SoC. Det er endda svært at finde en chip uden grafik.

PC Engines APU2 er nok det nærmeste, vi kan komme til en arvtager. Men ophavsmanden er principiel modstander af remote power management via serielporten ala Soekris. Trist!

...lavede de kasser Checkpoint firewalls kører på, men de har meget andet.
Forhandlere har jeg ikke kunnet opspore men deres website er http://www.portwell.com.tw

Hvad med at vlan-tagge (IEEE 802.1Q) porten på en Raspberry Pi? Så kan man i princippet lave op til 4096 vlans på ethernet-porten:
https://opensource.com/life/16/3/firewall-your-home-network-raspberry-pi
https://raspberrytips.com/raspberry-pi-firewall/

https://en.wikipedia.org/wiki/IEEE_802.1Q

Via en switch, der understøtter IEEE 802.1Q kan man dedikere specifikke porte til hvert vlan.

....hvis den stadig virker?

LPC fejlen på Atom - Erdet ikke kun under særlige omstændigheder den brick'er efter et par år - Noget med høj datatransfer på USB bl.a.?

Hey phk

Har du kigget på om Turris projektet har noget du kan bruge istedet for? https://www.turris.cz/en/

Jeg har et par stykker af ovenstående

• Moderne sepcs (Intel i3, i5, Op til 32 GB RAM, M2 storage, etc.)
• Er passivt kølet
• Har 2 netværks interfaces
• Har 2 serielle porte

De er ikke billige. De har en Intel Management Engine. De har kun 2 netværks interfaces. Jeg løser dette ved at have et WAN interface og et antal VLANs på LAN siden. På LAN siden sider så en 24 port managed switch der deler VLANs ud de steder hvor de skal bruges.

Computere der kan køre uden binære blobs synes at uddø. Der er efterhånden altid en blob i stil med Intels ME. Disse giver en automatisk end-of-life på hardwaren, fordi de kan indeholde sikkerhedshuller som ejeren ikke kan fikse.

PS: En Raspberry PI kan køre Power over Ethernet. På den måde kan man power-cycle den fra switchen der leverer strøm.

[VLAN tagging og managed switch]

Jeg tror at PHK er ude efter een boks som kan disse ting, så boksen er nødt til at have flere fysiske ethernetporte.

Men ja, hvis man aligevel har en switch i sin opsætning, så er det oplagt at bruge en managed switch og IEEE 802.1Q VLAN-tagging, og så have en boks med kun en ethernetport. Det vil dog begrænse switching/routingbåndbredden til 50% af den ene ethernetport. En raspberri pi har kun 100Mbps port, og til de services som PHK vil more sig med er 50Mbps fordelt ikke synderlig meget.

Som nævnt tidligere bruger jeg en compulab fit-pc med et ekstra "face"-modul med 4x1Gbps porte, og det er ikke en switch - al trafikken skal forbi CPUen. Sidst jeg målte kunne jeg trække 850Mbps igennem den med komplicerede iptables aktiveret. Jeg er sikker på at PHK med freebsd kunne hive mere performance ud af den, men det er rigeligt til mine formål (http://i1.dk/misc/network_setup/)

"Vis mig en managed switch uden CVE'er og jeg skal vise dig en managed switch ingen har undersøgt ordentligt endnu."

Jeg synes at det er en lidt for billig kommentar. Jeg forstår din kommentar som at du mener at alle managed switches har sikkerhedsfejl. Jeg savner en kildeangivelse. Bevisbyrden ligger på dine bane.

Overvej dette:
De meste kendte managed switches er nok dem der bliver solgt mange af. Hvis der bliver solgt mange af dem, så bliver de lavet af et større firma, formodentlig med primær fokus på næste 3 mdrs bundlinje. Vi ved circa hvordan arbejdsmiljøet såan et sted kan være, når fokus er på bundlinjen, dele af firmwaren at købt udefra, eller bliver outsourcet, og den vigtigste nye feature i den næste switch er at få de blå lysdioder til at blinke.
Hvis der er findes en samvittighedsfuld udvikler med fokus på korrekt opførsel, sikkerhed, standardoverholdelse mm, så er det næppe i sådan et miljø man kan finde ham. Så man skal kigge på managed switches som ikke er så alment kendte, og så får man, som du hentyder, problemet at der ingen CVEer er, så man ved ikke om nogen har kigget på dem med sikkerhedsbrillerne på. Så når man står med en mindre kendt switch i hånden så ved man ikke om firmwaren er lavet af en klaphat-udvikler eller en omhyggelig udvikler. Så man skal gætte det ud fra andre faktorer (Har de sat deres navn på eller er det no-name? Passer manualen? Ligner det en rebrandet billig dims?).

Min hypotese er at der findes fejlfri managed switches, men at man næppe finder dem blandt de meste udbredte.

De meste kendte managed switches er nok dem der bliver solgt mange af. Hvis der bliver solgt mange af dem, så bliver de lavet af et større firma, formodentlig med primær fokus på næste 3 mdrs bundlinje. Vi ved circa hvordan arbejdsmiljøet såan et sted kan være, når fokus er på bundlinjen, dele af firmwaren at købt udefra, eller bliver outsourcet, og den vigtigste nye feature i den næste switch er at få de blå lysdioder til at blinke.

Hvis du køber en switch fra en af de store leverandører, så er "tab af goodwill" ved sikkerhedsproblemer signifikant og volumen kan bære markante udviklingsomkostninger.

Problemet er nærmere at det er closed source. Indenfor virksomheden er der sandsynligvis relativt få der kigger på en given stump source for at lede efter sikkerhedsproblemer. Der er grund til at tro kræfter udenfor virksomheden vil være villige til at investere betydelige ressourcer i at finde huller og at disse enten vil kunne reverse engineere koden/hardware eller på anden vis vil få fat i sourcen. Vi ser dette ifbm. mobiltelefoner. Der er ingen grund til at tro at det samme ikke skulle være tilfældet for switche.

Desværre er man reelt i samme situation hvis man køber en computer med Wifi. Highperformance drivers er altid closed source. Og en ethernet NIC har også en del embedded software ... closed source software som ingen reviewer. Det er i dag ikke muligt at købe en moderne computer eller netværkskomponent uden store mængder embedded closed source.

Heldigvis kræver ovenstående betydelige ressourcer. Dem der bruger tid og penge på at lede efter fejl i reverse engineeret kode eller kode der er tilvejebragt med alternative metoder, de vil ikke lægge dette ud sådan at tilfældige teenagere kan bruge det til at hacke skolen. Det er heller ikke noget der bliver brugt på må og få til masseovervågning. Det er det ganske enkelt for værdifuldt til. I mine øjne skal man lave noget der tiltrækker opmærksomhed fra efterretningstjenester eller meget store organisationer før det er værd at bekymre sig over.

"Vis mig en managed switch uden CVE'er og jeg skal vise dig en managed switch ingen har undersøgt ordentligt endnu."

Min erfaring er at hvis du kan firewalle layer 3 adgang helt væk, så er det ikke så sandsynligt at du kan finde en angrebsvektor. Og dem du finder er mere sandsynligt af denial of service typen end noget der giver dig utilsigtet adgang.

Eksempelvis i vores netværk bliver kundernes trafik transporteret i layer 2 tunneler på et MPLS netværk. Kunderne kan end ikke pinge switchene. Det mindsker angrebsfladen væsentligt.

Kunderne kan end ikke pinge switchene. Det mindsker angrebsfladen væsentligt.

Gør det :-)

Og en tracert hjælper ikke på det. Eller et DNS opsalg, også port scan.

Men du mener at tilgang til jeres switch er på samme fysik netværk, men der bruges et andet IP segment til adm. ?

Men vil da mene at evnen til at pinge den nærmet port, er en uundværlige hælp i fejlretning og daglige brug, og at gemme switchen ikke hjælper meget.

Hvis man virkeligt er nervøs for den, så skal man skifte til Switch, som man sætter op, så de kun bliver man. fra en separat seriel/usd port

Pilfinger samt fysisk adgang til netværk. skal også være i orden. Altså aflåst, evt med alarm og video overvågning.
.
I det dagligt synes jeg det værste, fyske problem på større netværk, er at nogle tager deres "egne" routere eller switche med, som kan begynde at argere DNS på net, eller der bliver pillet i den fysik kabling. Hvis vi taler steder som som skoler eller kontorfælesskaber.

Jeg synes at det er en lidt for billig kommentar. Jeg forstår din kommentar som at du mener at alle managed switches har sikkerhedsfejl. Jeg savner en kildeangivelse. Bevisbyrden ligger på dine bane.

Det er meget få firmaer som har musklerne til at udvikle og vedligeholde deres eget OS.
De fleste anvender Linux, eller xBSD, og nogle få anvender QNX, eller VxWorks..
Ifølge nedenstående liste anvender Cisco QNX i nogle af deres produkter. Listen er ikke correkt mht. om noget er et selvstændig OS, eller afledt af open source OS. F.eks. er VYOS baseret på linux påsmurt et tykt lag GitHub.
https://packetpushers.net/virtual-toolbox/list-network-operating-systems/

Du vil vel ikke påstå at der ikke er CVE'er i Linux, BSD, eller QNX?.
Se dette eksempel fra BSD hvor der er et problem i netværks stakken som gør at en router vil kunne rammes udefra, også selvom den ikke har exponeret management GUI (Den største sikkerheds risiko)
https://www.cvedetails.com/cve/CVE-2019-5597/

Jeg har dag en Ubiquiti Router med EdgeOS.
Før den havde jeg en kort overgang en OpenWRT med performance problemer, og software der ikke blev vedligeholdt til det pågældende chipset.
Jeg havde så valget mellem PC Hardware og f.eks. pfSence, eller en færdig router.
Jeg valgte Ubiquiti pga. det lavere strømforbrug end PC hardware.
EdgeOS er baseret på VYOS/Vyatta som igen bruger Linux + GitHub.
https://wiki.vyos.net/wiki/Vyatta

Men jeg er afhængig af at Ubiquiti fortsætter med at udgive patches.
Det er de desværre ikke særlig hurtig til...

Ang. EdgeOS og CVE'er
Jeg køre v1.10.10 som er det latest and gratest https://www.ui.com/download/#!edgemax

Ifølge https://www.cvedetails.com/version-list/12765/44469/1/Ubnt-Edgeos.html er der ikke fundet nogle problemer siden v1.9.1

Men der er installeret version 1.19.0 (nyeste 1.31.0) af BusyBox som har 5 sårbarheder. https://www.cvedetails.com/vulnerability-list/vendor_id-4282/product_id-...

bash --version
GNU bash, version 4.2.37(1)-release (mips-unknown-linux-gnu)
Her er der måske 9 sårbarheder.
https://www.cvedetails.com/version/112321/GNU-Bash-4.2.html

Python 2.7.3
Her er der 15 sårbarheder.
https://www.cvedetails.com/version/132982/Python-Python-2.7.3.html

OpenSSH_6.6.1p1 Debian-4~bpo70+1, OpenSSL 1.0.1t 3 May 2016
Her er der 5 sårbarheder.
https://www.cvedetails.com/version/188831/Openbsd-Openssh-6.6.html

lighttpd/1.4.35 (ssl) - a light and fast webserver
Her er der 1 sårbarhed.
https://www.cvedetails.com/version/183598/Lighttpd-Lighttpd-1.4.35.html

Jeg har ikke modet til at cross Compilere til MIPS64..
Skulle nok have valgt en PC arkitektur til routeren..

Det gjorde jeg til min NasBox, det har ikke været problem fri.
CPU'en døde pga. den famøse Intel Atom Time Bomb... (Fik nyt MB på garanti)
Og FreeNAS er langt bagefter den FreeBSD distribution de er baseret på.
I øjeblikket er der 16 unpatched CVE'er på mit system, selvom jeg køre nyeste stable release 11.2
Om 2 uger stopper FreeBSD supporten for 11.2, det betyder at jeg ikke engang kan patche mine jails, hvoraf 2 har forbindelse til internettet. (De er idag helt opdaterede og har ingen CVE'er jfr. pkg audit)
Det er selvfølgelig ikke muligt at have en nyere OS version af jail, end af host.

Så nej, jeg stoler simpelthen ikke på at alle pakker kommer igennem CPU'en, for jeg har set det modsatte ske for mange gange.

Og det er en velbegrundet frygt. Men hvis man bruger en rigtig switch på bagsiden af en dual-NIC firewall, så vil firmwaren i NIC'en på wan siden af din firewall være det mest oplagte mål. Som Bardur skriver så er det rigtigt svært at være kreativ på bagsiden hvis man kommer udefra. Men selvfølgeligt: Hvis du også skal beskytte mod indefrakommende angreb så er det en anden sag.

Gør det :-)

Og en tracert hjælper ikke på det. Eller et DNS opsalg, også port scan.

Men du mener at tilgang til jeres switch er på samme fysik netværk, men der bruges et andet IP segment til adm. ?

Men vil da mene at evnen til at pinge den nærmet port, er en uundværlige hælp i fejlretning og daglige brug, og at gemme switchen ikke hjælper meget.

Jeg fortæller bare hvordan vores (Gigabit) netværk fungerer. Forestil dig at der en slags VPN fra slutkunden til den router der aggerer "default gateway". Du kan godt pinge vores router men du kan ikke pinge de mange switche ind imellem. De har simpelthen ikke en IP adresse.

Der er en masse udstyr som er managed men som ikke har en IP adresse på det offentlige internet og hellere ikke ude hos kunderne. Kundens fibermodem, GPON access switchen som er i centralenden af kundens fiberforbindelse, core switche som transporterer trafikken fra access switch og afleverer det til BNG routeren. Alt det er meget svært at angribe fordi du end ikke kan adressere udstyret.

Det er ikke nødvendigvis helt umuligt. Selvom en core switch ikke gør andet end at transportere VPN trafik fra port 1 til port 2, så behandler den stadig en smule information. CRC genberegnes, TTL korrigeres og diverse længde felter kunne være en vej til at angribe med korrupt data. Men det er svært idet det er så lidt den faktisk gør med pakken, andet end at kopiere den fra port 1 til port 2.

Hvordan manager vi så udstyret? Du kan forestille dig at det foregår på et andet VLAN selvom det ikke er helt korrekt. Vi har opbygget et net der ikke er forbundet til Internet. Selvom intet udstyr på dette net er tilgængeligt fra Internet, så kan det stadig lave VPN forbindelser mellem en slutkunde, som er på internet, og en BNG router, der også er på internet.

Der er mange grunde til at opbygge nettet på denne måde. Men en af de vigtige er at vi ikke stoler på udstyret og på denne måde er angrebsfladen mindst mulig. Det er ligemeget at noget af udstyret kører med en gammel hullet SSH implementation for der er ingen der kan komme i kontakt med SSH porten. Det er bedre end en firewall.

Med hensyn til fejlretning, så er det rigtigt at kunderne ikke har mulighed for at se hvor i vores net, der eventuelt sker et pakketab eller et loop. Vi kan selv lave den fejlsøgning da vi har adgang til det bagvedliggende net, så det er en ikke begræsning for udbyderen. Der er i øvrigt mange transportnet der bruger MPLS, eller en anden tunnelteknologi, så en traceroute fortæller ofte kun en lille del af historien.

Hvis du køber en switch fra en af de store leverandører, så er "tab af goodwill" ved sikkerhedsproblemer signifikant og volumen kan bære markante udviklingsomkostninger.

Jeg er stort set enig. De store leverandører har dog også råd til spindoctors. Jeg var ved at skrive at man også skal se på om levenradøren primært laver netværksudstyr eller om det blot er en mindre del af forretningen, men jo mere jeg tænker på Ciscos FeatureritisOS vs. Dells <whatever>, jo mindre sikker er jeg på at de er en vigtig faktor.

>Jeg forstår din kommentar som at du mener at alle managed switches har sikkerhedsfejl.

Ja, det mener jeg er en meget fornuftig null-hypotese, ser du grund til at tro andet ?

Vi ved at der findes mindst een switch med sikkerhedsproblemer, men at derfra antage at alle switche har sikkerhedsproblemer er et stort spring. Vi mangler data. Her ville de være rart hvis f.eks. C't kom på banen og testede 100 switches med tysk grundighed.

I den aktuelle sammenhæng er det dog helt nede i bunden af "managed switch" segmentet vi bevæger os: Chips bygget til at håndtere LAN siden af en skod-billig CPE.

Ah, den slags switches. Der må jeg erklære mig enig - jeg har ikke en disse tillid til dem. De har næppe en MAC-tabel pr. VLAN, så MAC-spoofing kan nemt omgå VLAN-segmenteringen, og guderne må vide om de håndterer broadcasts korrekt.

Hej Poul-Henning,

Det er en værre historie med Søren fra Snoldelev og hans små grønne kasser, men den er vigtig og burde udgives i bogform... vi må finde en der kan den slags.

Måske vil det glæde dig, at du engang hjalp mig med at få bootet min 5501 så jeg kunne få en FreeBSD på. Den kører endnu og har blandet været med til at spærre for YouTube i mit hjem, da jeg blev lidt træt af ulovlige reklamer på mit børns foretrukne legetøj...

Men i dag - 20 år senere - er jeg mindre bekymret for firmwaren i Intels lakridser (skal vist lige have patchet nogle Ethernetkort), og mere bekymkret for indsamlingen af data hos private aktører.

Da jeg ville kommentere her, var der lige en ny login tjeneste... som gerne lige ville vide lidt mere om mig... og jeg kendte ikke lige lige mit password, for måske var det blevet erstattet da jeg fik en prøveperiode som medlem af en fagforening...

Jeg tror den store trussel nærmere er størrelsen af virksomheder. Det er meget svært for mig at se adskillelsen mellem en fagforening, et mediehus og et forum hvor vi frit kan diskutere udviklingen og anvendelse af regnemaskiner.

Og ja, PHK... du har gættet rigtigt ;-)

Vi skal have holdt det møde og startet den lokal afdeling. Du vælger tid og sted og jeg kommer med resten!

Min hypotese er at der findes fejlfri managed switches, men at man næppe finder dem blandt de meste udbredte.

Fedt, mon ikke de bliver udviklet af samme firma der skriver fejlfri kode?

Min hypotese er at der findes fejlfri managed switches, men at man næppe finder dem blandt de meste udbredte.

Fedt, mon ikke de bliver udviklet af samme firma der skriver fejlfri kode?

Jo de bliver leveret, af den fejlfrie levendører.

https://www.pondesk.com/product/Intel-J1900-4-LAN-HD-Dual-Display-4G-Fan... her burde være 4 uafhængige netkort, men J1900 er vel noget af intels usikre ware