On January 22, 2026, an automated routing policy configuration error caused us to leak some Border Gateway Protocol (BGP) prefixes unintentionally from a router at our data center in Miami, Florida. While the route leak caused some impact to Cloudflare customers, multiple external parties were also affected because their traffic was accidentally funnelled through our Miami data center location.

The route leak lasted 25 minutes, causing congestion on some of our backbone infrastructure in Miami, elevated loss for some Cloudflare customer traffic, and higher latency for traffic across these links. Additionally, some traffic was discarded by firewall filters on our routers that are designed to only accept traffic for Cloudflare services and our customers.

While we’ve written about route leaks before, we rarely find ourselves causing them. This route leak was the result of an accidental misconfiguration on a router in Cloudflare’s network, and only affected IPv6 traffic. We sincerely apologize to the users, customers, and networks we impacted yesterday as a result of this BGP route leak.

We have written multiple times about BGP route leaks, and we even record route leak events on Cloudflare Radar for anyone to view and learn from. To get a fuller understanding of what route leaks are, you can refer to this detailed background section, or refer to the formal definition within RFC7908. 

Essentially, a route leak occurs when a network tells the broader Internet to send it traffic that it’s not supposed to forward. Technically, a route leak occurs when a network, or Autonomous System (AS), appears unexpectedly in an AS path. An AS path is what BGP uses to determine the path across the Internet to a final destination. An example of an anomalous AS path indicative of a route leak would be finding a network sending routes received from a peer to a provider.

During this type of route leak, the rules of valley-free routing are violated, as BGP updates are sent from AS64501 to their peer (AS64502), and then unexpectedly up to a provider (AS64503). Oftentimes the leaker, in this case AS64502, is not prepared to handle the amount of traffic they are going to receive and may not even have firewall filters configured to accept all of the traffic coming in their direction. In simple terms, once a route update is sent to a peer or provider, it should only be sent further to customers and not to another peer or provider AS.

During the incident on January 22, we caused a similar kind of route leak, in which we took routes from some of our peers and redistributed them in Miami to some of our peers and providers. According to the route leak definitions in RFC7908, we caused a mixture of Type 3 and Type 4 route leaks on the Internet. 

On January 22, 2026, at 20:25 UTC, we pushed a change via our policy automation platform to remove the BGP announcements from Miami for one of our data centers in Bogotá, Colombia. This was purposeful, as we previously forwarded some IPv6 traffic through Miami toward the Bogotá data center, but recent infrastructure upgrades removed the need for us to do so.

This change generated the following diff (a program that compares configuration files in order to determine how or whether they differ):

[edit policy-options policy-statement 6-COGENT-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-COMCAST-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-GTT-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-LEVEL3-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-PRIVATE-PEER-ANYCAST-OUT term ADV-SITELOCAL from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-PUBLIC-PEER-ANYCAST-OUT term ADV-SITELOCAL from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-PUBLIC-PEER-OUT term ADV-SITELOCAL from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-TELEFONICA-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-TELIA-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;

While this policy change looks innocent at a glance, only removing the prefix lists containing BOG04 unicast prefixes resulted in a policy that was too permissive:

policy-options policy-statement 6-TELIA-ACCEPT-EXPORT {
    term ADV-SITELOCAL-GRE-RECEIVER {
        from route-type internal;
        then {
            community add STATIC-ROUTE;
            community add SITE-LOCAL-ROUTE;
            community add MIA01;
            community add NORTH-AMERICA;
            accept;
        }
    }
}

The policy would now mark every prefix of type “internal” as acceptable, and proceed to add some informative communities to all matching prefixes. But more importantly, the policy also accepted the route through the policy filter, which resulted in the prefix — which was intended to be “internal” —  being advertised externally. This is an issue because the “route-type internal” match in JunOS or JunOS EVO (the operating systems used by HPE Juniper Networks devices) will match any non-external route type, such as Internal BGP (IBGP) routes, which is what happened here.

As a result, all IPv6 prefixes that Cloudflare redistributes internally across the backbone were accepted by this policy, and advertised to all our BGP neighbors in Miami. This is unfortunately very similar to the outage we experienced in 2020, on which you can read more on our blog.

When the policy misconfiguration was applied at 20:25 UTC, a series of unintended BGP updates were sent from AS13335 to peers and providers in Miami. These BGP updates are viewable historically by looking at MRT files with the monocle tool or using RIPE BGPlay. 

➜  ~ monocle search --start-ts 2026-01-22T20:24:00Z --end-ts 2026-01-22T20:30:00Z --as-path ".*13335[ d$]32934$*"
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f077::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f091::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f16f::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f17c::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f26f::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f27c::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f33f::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113583.095278|2001:504:d::4:9544:1|49544|2a03:2880:f17c::/48|49544 1299 3356 13335 32934|IGP|2001:504:d::4:9544:1|0|0|1299:25000 1299:25800 49544:16000 49544:16106|false|||route-views.isc
A|1769113583.095278|2001:504:d::4:9544:1|49544|2a03:2880:f27c::/48|49544 1299 3356 13335 32934|IGP|2001:504:d::4:9544:1|0|0|1299:25000 1299:25800 49544:16000 49544:16106|false|||route-views.isc
A|1769113583.095278|2001:504:d::4:9544:1|49544|2a03:2880:f091::/48|49544 1299 3356 13335 32934|IGP|2001:504:d::4:9544:1|0|0|1299:25000 1299:25800 49544:16000 49544:16106|false|||route-views.isc
A|1769113584.324483|2001:504:d::19:9524:1|199524|2a03:2880:f091::/48|199524 1299 3356 13335 32934|IGP|2001:2035:0:2bfd::1|0|0||false|||route-views.isc
A|1769113584.324483|2001:504:d::19:9524:1|199524|2a03:2880:f17c::/48|199524 1299 3356 13335 32934|IGP|2001:2035:0:2bfd::1|0|0||false|||route-views.isc
A|1769113584.324483|2001:504:d::19:9524:1|199524|2a03:2880:f27c::/48|199524 1299 3356 13335 32934|IGP|2001:2035:0:2bfd::1|0|0||false|||route-views.isc
{trimmed}

^{In the monocle output seen above, we have the timestamp of our BGP update, followed by the next-hop in the announcement, the ASN of the network feeding a given route-collector, the prefix involved, and the AS path and BGP communities if any are found. At the end of the output per-line, we also find the route-collector instance.}

Looking at the first update for prefix 2a03:2880:f077::/48, the AS path is 64112 22850 174 3356 13335 32934. This means we (AS13335) took the prefix received from Meta (AS32934), our peer, and then advertised it toward Lumen (AS3356), one of our upstream transit providers. We know this is a route leak as routes received from peers are only meant to be readvertised to downstream (customer) networks, not laterally to other peers or up to providers.

As a result of the leak and the forwarding of unintended traffic into our Miami router from providers and peers, we experienced congestion on our backbone between Miami and Atlanta, as you can see in the graph below. 

This would have resulted in elevated loss for some Cloudflare customer traffic, and higher latency than usual for traffic traversing these links. In addition to this congestion, the networks whose prefixes we leaked would have had their traffic discarded by firewall filters on our routers that are designed to only accept traffic for Cloudflare services and our customers. At peak, we discarded around 12Gbps of traffic ingressing our router in Miami for these non-downstream prefixes. 

We are big supporters and active contributors to efforts within the IETF and infrastructure community that strengthen routing security. We know firsthand how easy it is to cause a route leak accidentally, as evidenced by this incident. 

Preventing route leaks will require a multi-faceted approach, but we have identified multiple areas in which we can improve, both short- and long-term.

In terms of our routing policy configurations and automation, we are:

• Patching the failure in our routing policy automation that caused the route leak, and will mitigate this potential failure and others like it immediately 

• Implementing additional BGP community-based safeguards in our routing policies that explicitly reject routes that were received from providers and peers on external export policies 

• Adding automatic routing policy evaluation into our CI/CD pipelines that looks specifically for empty or erroneous policy terms 

• Improve early detection of issues with network configurations and the negative effects of an automated change

To help prevent route leaks in general, we are: 

• Validating routing equipment vendors’ implementation of RFC9234 (BGP roles and the Only-to-Customer Attribute) in preparation for our rollout of the feature, which is the only way independent of routing policy to prevent route leaks caused at the local Autonomous System (AS)

• Encouraging the long term adoption of RPKI Autonomous System Provider Authorization (ASPA), where networks could automatically reject routes that contain anomalous AS paths

Most importantly, we would again like to apologize for the impact we caused users and customers of Cloudflare, as well as any impact felt by external networks.

Read more here: https://blog.cloudflare.com/route-leak-incident-january-22-2026/

The post Route leak incident on January 22, 2026 appeared first on IPv6.net.

M5Stack StickS3 is a miniature ESP32-S3 WiFi and BLE IoT development kit/controller powered by an Espressif Systems ESP32-S3-PICO-1-N8R8 system-in-package with 8MB flash and 8MB PSRAM, and equipped with a 1.14-inch display, built-in microphone and speaker, as well as an integrated IR receiver and transmitter. It’s an update to the ESP32-PICO-V3 based StickC-Plus2 with a more powerful ESP32-S3 module, a USB Type-C OTG port, improved audio integrating an ES8311 mono audio codec, a slightly larger 250 mAh battery, as well as a 4-pin Grove connector and a 16-pin female GPIO header for expansion. M5Stack StickS3 specifications: SiP – Espressif ESP32-S3-PICO-1-N8R8 as found on the M5Stack ATOMS3R and ATOMS3R Cam IoT controllers SoC – ESP32-S3 CPU – Dual-core Tensilica LX7 up to 240 MHz Memory – 512KB SRAM, 16 KB RTC SRAM Wireless – 2.4 GHz WiFi 4 and Bluetooth 5 LE + Mesh Memory – 8MB QSPI PSRAM Storage – 8MB QSPI […]

The post M5Stack StickS3 ESP32-S3 Mini IoT Dev Kit features 1.14-inch color display, speaker and mic for voice interaction appeared first on CNX Software – Embedded Systems News.

Read more here: https://www.cnx-software.com/2026/01/23/m5stack-sticks3-esp32-s3-mini-iot-dev-kit-features-1-14-inch-color-display-speaker-and-mic-for-voice-interaction/

The post M5Stack StickS3 ESP32-S3 Mini IoT Dev Kit features 1.14-inch color display, speaker and mic for voice interaction appeared first on IPv6.net.

We’ve seen people try to make MCU development boards as breadboard-friendly as possible by leaving plenty of space to connect wires and components. lhm0 tackled the issue from the opposite direction and designed 3D printed breadboards optimized for Raspberry Pi Pico and ESP32 development boards. The Pico typically only leaves two rows of each side of a typical breadboard, and some ESP32 boards are wide enough to take all rows and, as a result, are unusable. The trick here was to design the breadboard for each board with an opening in the middle, so that they only take two rows (one on each side) on the 3D printed breadboard, and the user still has four rows on each side to play with, plus the top and bottom rows. We only have photos for two variants of the breadboard (highlighted in bold below), but a total of five breadboard designs are […]

The post 3D printed breadboards optimized for Raspberry Pi Pico and ESP32 boards appeared first on CNX Software – Embedded Systems News.

Read more here: https://www.cnx-software.com/2026/01/23/3d-printed-breadboards-optimized-for-raspberry-pi-pico-and-esp32-boards/

The post 3D printed breadboards optimized for Raspberry Pi Pico and ESP32 boards appeared first on IPv6.net.

A new Internet-of-Things (IoT) botnet called Kimwolf has spread to more than 2 million devices, forcing infected systems to participate in massive distributed denial-of-service (DDoS) attacks and to relay other malicious and abusive Internet traffic. Kimwolf’s ability to scan the local networks of compromised systems for other IoT devices to infect makes it a sobering threat to organizations, and new research reveals Kimwolf is surprisingly prevalent in government and corporate networks.

Image: Shutterstock, @Elzicon.

Kimwolf grew rapidly in the waning months of 2025 by tricking various “residential proxy” services into relaying malicious commands to devices on the local networks of those proxy endpoints. Residential proxies are sold as a way to anonymize and localize one’s Web traffic to a specific region, and the biggest of these services allow customers to route their Internet activity through devices in virtually any country or city around the globe.

The malware that turns one’s Internet connection into a proxy node is often quietly bundled with various mobile apps and games, and it typically forces the infected device to relay malicious and abusive traffic — including ad fraud, account takeover attempts, and mass content-scraping.

Kimwolf mainly targeted proxies from IPIDEA, a Chinese service that has millions of proxy endpoints for rent on any given week. The Kimwolf operators discovered they could forward malicious commands to the internal networks of IPIDEA proxy endpoints, and then programmatically scan for and infect other vulnerable devices on each endpoint’s local network.

Most of the systems compromised through Kimwolf’s local network scanning have been unofficial Android TV streaming boxes. These are typically Android Open Source Project devices — not Android TV OS devices or Play Protect certified Android devices — and they are generally marketed as a way to watch unlimited (read:pirated) video content from popular subscription streaming services for a one-time fee.

However, a great many of these TV boxes ship to consumers with residential proxy software pre-installed. What’s more, they have no real security or authentication built-in: If you can communicate directly with the TV box, you can also easily compromise it with malware.

While IPIDEA and other affected proxy providers recently have taken steps to block threats like Kimwolf from going upstream into their endpoints (reportedly with varying degrees of success), the Kimwolf malware remains on millions of infected devices.

A screenshot of IPIDEA’s proxy service.

Kimwolf’s close association with residential proxy networks and compromised Android TV boxes might suggest we’d find relatively few infections on corporate networks. However, the security firm Infoblox said a recent review of its customer traffic found nearly 25 percent of them made a query to a Kimwolf-related domain name since October 1, 2025, when the botnet first showed signs of life.

Infoblox found the affected customers are based all over the world and in a wide range of industry verticals, from education and healthcare to government and finance.

“To be clear, this suggests that nearly 25% of customers had at least one device that was an endpoint in a residential proxy service targeted by Kimwolf operators,” Infoblox explained. “Such a device, maybe a phone or a laptop, was essentially co-opted by the threat actor to probe the local network for vulnerable devices. A query means a scan was made, not that new devices were compromised. Lateral movement would fail if there were no vulnerable devices to be found or if the DNS resolution was blocked.”

Synthient, a startup that tracks proxy services and was the first to disclose on January 2 the unique methods Kimwolf uses to spread, found proxy endpoints from IPIDEA were present in alarming numbers at government and academic institutions worldwide. Synthient said it spied at least 33,000 affected Internet addresses at universities and colleges, and nearly 8,000 IPIDEA proxies within various U.S. and foreign government networks.

The top 50 domain names sought out by users of IPIDEA’s residential proxy service, according to Synthient.

In a webinar on January 16, experts at the proxy tracking service Spur profiled Internet addresses associated with IPIDEA and 10 other proxy services that were thought to be vulnerable to Kimwolf’s tricks. Spur found residential proxies in nearly 300 government owned and operated networks, 318 utility companies, 166 healthcare companies or hospitals, and 141 companies in banking and finance.

“I looked at the 298 [government] owned and operated [networks], and so many of them were DoD [U.S. Department of Defense], which is kind of terrifying that DoD has IPIDEA and these other proxy services located inside of it,” Spur Co-Founder Riley Kilmer said. “I don’t know how these enterprises have these networks set up. It could be that [infected devices] are segregated on the network, that even if you had local access it doesn’t really mean much. However, it’s something to be aware of. If a device goes in, anything that device has access to the proxy would have access to.”

Kilmer said Kimwolf demonstrates how a single residential proxy infection can quickly lead to bigger problems for organizations that are harboring unsecured devices behind their firewalls, noting that proxy services present a potentially simple way for attackers to probe other devices on the local network of a targeted organization.

“If you know you have [proxy] infections that are located in a company, you can chose that [network] to come out of and then locally pivot,” Kilmer said. “If you have an idea of where to start or look, now you have a foothold in a company or an enterprise based on just that.”

This is the third story in our series on the Kimwolf botnet. Next week, we’ll shed light on the myriad China-based individuals and companies connected to the Badbox 2.0 botnet, the collective name given to a vast number of Android TV streaming box models that ship with no discernible security or authentication built-in, and with residential proxy malware pre-installed.

Further reading:

The Kimwolf Botnet is Stalking Your Local Network

Who Benefitted from the Aisuru and Kimwolf Botnets?

A Broken System Fueling Botnets (Synthient).

Read more here: https://krebsonsecurity.com/2026/01/kimwolf-botnet-lurking-in-corporate-govt-networks/

The post Kimwolf Botnet Lurking in Corporate, Govt. Networks appeared first on IPv6.net.

Read more here: https://blog.apnic.net/2026/01/23/rscs-are-now-supported-in-myapnic/

The post RSCs are now supported in MyAPNIC appeared first on IPv6.net.

Singapore deep-tech startup launches an edge-native infrastructure layer that enables multi-vendor robots and AI agents to coordinate instantly and securely without centralized servers. SINGAPORE, Jan. 22, 2026 /PRNewswire-PRWeb/ — As autonomous systems proliferate across robotics, IoT,…

Read more here: https://www.prweb.com/releases/tashi-unveils-a-coordination-fabric-for-autonomous-systems-solving-the-critical-interoperability-bottleneck-for-industry-4-0–302668451.html

The post Tashi Unveils a Coordination Fabric for Autonomous Systems, Solving the Critical Interoperability Bottleneck for Industry 4.0 appeared first on IPv6.net.

Advantech MIO-5355 is a 3.5-inch SBC based on Qualcomm QCS6490 or QCS5430 Edge AI processor. The board features up to 8GB of LPDDR5 memory, 128GB of UFS storage, and supports various operating systems, including Windows 11 IoT Enterprise, Ubuntu 24.04 LTS, and Yocto Linux. We have seen other QCS6490-based hardware in the past, such as the Radxa Dragon Q6A, the Quectel QSM560DR SBC, or the Rubik Pi 3, most of which come in compact form factors. The Advantech MIO-5355 takes a different approach, using a standard industrial 3.5-inch form factor (146 × 102 mm) and targeting industrial deployments with support for –20°C to 70°C operation and long-term availability. Advantech MIO-5355 specifications: SoC (one or the other) Qualcomm DragonWing QCS6490 CPU – Octa-core Kryo 670 with 1x Gold Plus core (Cortex-A78) @ 2.7 GHz, 3x Gold cores (Cortex-A78) @ 2.4 GHz, 4x Silver cores (Cortex-A55) @ up to 1.9 GHz GPU […]

The post Advantech MIO-5355 3.5-inch SBC features Qualcomm QCS6490 or QCS5430 SoC for industrial edge AI appeared first on CNX Software – Embedded Systems News.

Read more here: https://www.cnx-software.com/2026/01/22/advantech-mio-5355-3-5-inch-sbc-features-qualcomm-qcs6490-or-qcs5430-soc-for-industrial-edge-ai/

The post Advantech MIO-5355 3.5-inch SBC features Qualcomm QCS6490 or QCS5430 SoC for industrial edge AI appeared first on IPv6.net.

ESPHome 2026.1.0 open-source firmware has just been released with new features like automatic WiFi roaming and Zigbee support for Nordic Semi nRF52 targets, as well as memory optimization for ESP32/ESP8266 hardware, among many other changes. Other notable changes include security updates with the project replacing API password authentication with API encryption and requiring SHA256 authentication for OTA updates, better support for non-ASCII configuration, and updates to LibreTiny platforms (BK72xx, RTL87xx, LN882x), which received thread-safe WiFi, atomics, and deep sleep support. ESPHome developers used to advise users not to use ESP8266, not because it was not suitable for the task, but because the runtime heap on ESP8266 routinely dropped below 10k, and devices were unreliable. Since millions of ESP8266 devices were already deployed in homes, they decided to do something about it. The project was greatly helped thanks to increased support from the Open Home Foundation, which allows the project to […]

The post ESPHome 2026.1.0 optimizes memory usage on ESP32/ESP8266, adds Zigbee support on nRF52, WiFi roaming, and more appeared first on CNX Software – Embedded Systems News.

Read more here: https://www.cnx-software.com/2026/01/21/esphome-2026-1-0-optimizes-memory-usage-on-esp32-esp8266-adds-zigbee-support-on-nrf52-wifi-roaming/

The post ESPHome 2026.1.0 optimizes memory usage on ESP32/ESP8266, adds Zigbee support on nRF52, WiFi roaming, and more appeared first on IPv6.net.

Als je vandaag een nieuwe applicatie aansluit of een extra vestiging toevoegt, denk je waarschijnlijk na over netwerksegmentatie. De vraag is alleen of de manier waarop je segmenteert nog past bij wat je probeert te beschermen. De oplossing? Microsegmentatie.

Vrijwel elk netwerk heeft segmentatie. VLAN’s hier, een firewallregel daar, en ergens een diagram dat de architectuur goed weergeeft. Dat werkt meestal. Tot het netwerk verandert, het gebruik verschuift, of een incident ineens laat zien hoe breed sommige segmenten eigenlijk zijn. In de praktijk blijkt segmentatie vaak grover dan het op basis van het risicoprofiel zou moeten zijn. Terwijl dreigingen steeds specifieker worden, blijven netwerken opvallend vaak ingericht rond brede zones en vaste aannames over vertrouwen. Die spanning wordt vooral zichtbaar buiten het datacenter. Op vestigingsniveau, waar gebruikers, IoT, OT en cloudapplicaties samenkomen, lopen klassieke segmentatiemodellen tegen hun grenzen aan.

VLAN’s zijn niet meer genoeg

Het punt is namelijk dat VLAN’s zijn ontworpen voor overzicht en schaal, niet voor context. Ze delen een netwerk op in logische blokken, gebaseerd op locatie, functie of afdeling. Dat is prima, zolang alle systemen binnen zo’n blok vergelijkbare risico’s hebben en zich voorspelbaar gedragen. Maar dat is steeds minder vaak het geval:

• Werkplekken, printers, camera’s en SaaS-connectors delen hetzelfde VLAN omdat ‘dat zo gegroeid is’.
• Een applicatieomgeving is logisch gescheiden, maar gebruikers krijgen via VPN alsnog breed netwerktoegang.
• Nieuwe cloudapplicaties vereisen uitzonderingen op bestaande firewallregels, en zo verdwijnt langzaam het overzicht.

Het probleem zit niet in VLAN’s zelf, maar in het feit dat ze geen rekening houden met identiteit, gedrag of context. Alles binnen een VLAN wordt in principe vertrouwd, terwijl risico’s juist per device, per gebruiker of per applicatie verschillen.

Daar komt bij dat aanvallen zelden netjes binnen één zone blijven. Laterale beweging, privilege-escalatie en misbruik van legitieme accounts maken klassieke netwerkgrenzen poreus. Als één endpoint binnen een VLAN wordt gecompromitteerd, ligt de rest vaak open.

Microsegmentatie buiten het datacenter

Microsegmentatie wordt vaak geassocieerd met datacenters en cloudomgevingen, bijvoorbeeld bij workload-isolatie, east-west traffic control en software-defined networking. Maar hetzelfde principe is minstens zo relevant op vestigingsniveau. Daar verschuift de focus van de klassieke vraag waar iets zich in het netwerk bevindt naar wat het precies is en welke rol het vervult.

Niet de netwerkpoort of het VLAN is leidend, maar de identiteit van een gebruiker, device of applicatie. Wat mag dit systeem doen, met welke andere onderdelen mag het communiceren en onder welke voorwaarden is die toegang toegestaan? Context zoals locatie, status van het apparaat, authenticatie en gedrag weegt mee, waardoor toegang niet langer impliciet is, maar telkens opnieuw wordt afgedwongen.

In plaats van brede netwerkzones werk je met policies die verkeer toestaan op basis van identiteit, rol en context. Een werkplek krijgt dan niet ‘toegang tot het netwerk’, maar toegang tot specifieke diensten. Een camera mag alleen praten met zijn videoplatform. Een applicatiecomponent mag alleen communiceren met zijn backend, en zo voort.

Technisch kan dat op verschillende manieren:

• Network Access Control (NAC) op basis van device-identiteit en posture
• Host-based firewalls met centrale policy
• Software-defined networking in campus- of WAN-omgevingen
• Cloud-native policies die on-prem en cloud verbinden

Het belangrijke verschil met klassieke segmentatie is dat de scheiding niet meer primair aan de netwerklaag hangt, maar aan beleid.

Segmentatie op device-, rol- en applicatieniveau

En daarbij wordt microsegmentatie nog interessanter wanneer je verschillende invalshoeken combineert.

Device-niveau
Niet elk apparaat is gelijk. Een beheerde werkplek met EDR en actuele patches vormt een ander risico dan een IoT-sensor of een BYOD-apparaat. Door devices te classificeren en daar policies aan te koppelen, beperk je wat ze überhaupt mogen.

Rol-niveau
Gebruikers hebben verschillende verantwoordelijkheden. Iemand van finance heeft andere applicaties nodig dan iemand in productie. Segmentatie op rolniveau voorkomt dat netwerktoegang breder is dan functioneel noodzakelijk, ook als gebruikers van locatie wisselen.

Applicatieniveau
Steeds meer verkeer is applicatiegericht en versleuteld. Door policies te baseren op applicatie-identiteit in plaats van IP-adressen, sluit segmentatie beter aan bij moderne omgevingen. Dat geldt zowel voor on-prem applicaties als voor SaaS en cloud-native diensten.

De niveaus versterken elkaar. Een onbekend device met een geldige gebruikerslogin krijgt dan alsnog beperkte toegang. Een bekende werkplek buiten compliance valt automatisch in een restrictiever profiel.

De relatie met zero trust

Microsegmentatie is een praktisch onderdeel van zero trust-architecturen. Het uitgangspunt blijft hetzelfde: vertrouw niets impliciet, verifieer continu en beperk toegang tot wat strikt noodzakelijk is.

Terwijl zero trust vaak abstract blijft, maakt microsegmentatie het concreet. Policies worden afdwingbaar op netwerk- en applicatieniveau, ook buiten het datacenter. Dat betekent dat ‘binnen’ en ‘buiten’ steeds minder relevant worden. Het gaat dus om de context.

Een veelgehoorde zorg is dat fijnmazige segmentatie beheercomplexiteit toevoegt. En dat is inderdaad een risico, vooral als je microsegmentatie benadert als een technisch kunstje in plaats van als een architectuur.

Met de juiste segmentatie wordt het beheer juist overzichtelijker. Verkeersstromen liggen expliciet vast in beleid, waardoor duidelijk is welk verkeer wordt verwacht en welk niet. Afwijkingen vallen sneller op en zijn eenvoudiger te herleiden tot een specifieke oorzaak.

Tegelijk blijven incidenten beter afgebakend, omdat verstoringen of compromittering zich niet automatisch door grote delen van de omgeving kunnen verspreiden. De sleutel zit in zichtbaarheid en tooling.

Hoe ver ga je zonder het onnodig complex te maken?

Pas op met de verleiding om alles tegelijk te segmenteren. Dat werkt zelden. Effectieve microsegmentatie begint klein en groeit mee met inzicht.

Een paar praktische uitgangspunten:

• Start met de meest risicovolle assets of processen
• Segmenteer op basis van daadwerkelijk verkeer, niet op aannames
• Automatiseer waar mogelijk, handmatig beheer schaalt slecht
• Documenteer intentie, niet alleen regels

Belangrijker nog: microsegmentatie is geen project met een einddatum. Het is een structurele maatregel die meebeweegt met veranderingen in applicaties, werkvormen en dreigingen. Nieuwe vestiging? Nieuwe applicatie? Dan hoort segmentatie daar standaard bij, niet als sluitstuk, maar als ontwerpprincipe.

Van netwerkontwerp naar gedragsmodel

VLAN’s brengen vooral orde in infrastructuur, microsegmentatie over controle op gedrag. Dat vraagt een andere manier van denken. Minder focus op fysieke of logische grenzen, meer op context en intentie. Op vestigingsniveau is die verschuiving misschien wel het meest zichtbaar. Juist daar komen oude netwerkmodellen en nieuwe realiteit hard met elkaar in aanraking. Wie daar durft los te laten dat alles binnen één locatie vertrouwd is, zet een belangrijke stap. De bottom line: het netwerk wordt er niet simpeler van, maar wel een stuk realistischer.

Het bericht Microsegmentatie: denk klein! verscheen eerst op ChannelConnect.

Read more here: https://www.channelconnect.nl/telecom-en-voip/microsegmentatie-denk-klein/

The post Microsegmentatie: denk klein! appeared first on IPv6.net.

OnLogic CL260 is an ultra-compact, fanless industrial mini PC powered by an Intel Processor N150 or N250 Twin Lake SoC with features such as an RS232/RS485 terminal block and 12-24V wide DC input. The mini PC ships with up to 8GB LPDDR5 memory and 128GB to 2TB M.2 SSD. It also features two Gigabit Ethernet RJ45 ports, an M.2 Key-E socket for an optional WiFi 6E module, four USB 3.2 ports, and two USB-C ports with DisplayPort Alt mode for dual display setups. The CL260 is suitable for data collection, gateway applications, and edge computing deployments. OnLogic CL260 mini PC specifications: Twin Lake SoC (one of the other) Intel Processor N150 quad-core processor @ 800 MHz / 3.6 GHz (Turbo) with 6MB cache, 24EU Intel UHD graphics @ 1.0 GHz; TDP: 6W Intel Processor N250 quad-core processor @ 1.3 GHz / 3.8 GHz (Turbo) with 6MB cache, 32EU Intel UHD […]

The post OnLogic CL260 fanless Intel N150/N250 industrial mini PC offers RS232/RS485 terminal block, 12-24V DC input appeared first on CNX Software – Embedded Systems News.

Read more here: https://www.cnx-software.com/2026/01/21/onlogic-cl260-fanless-intel-n150-n250-industrial-mini-pc-offers-rs232-rs485-terminal-block-12-24v-dc-input/

The post OnLogic CL260 fanless Intel N150/N250 industrial mini PC offers RS232/RS485 terminal block, 12-24V DC input appeared first on IPv6.net.