Mac Filters
You set up mac filters by adding allowed device hardware addresses to your router. The switch then checks each network card address before it lets a device join. Network teams use this list to block unknown laptops and phones from local ports. Still, once a device passes this check, broad network roles let users reach everything. How mac filters work on local networks Every network card has a twelve-character hardware address baked into the chip. When a laptop asks to join a network, it sends
Filters: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up mac filters by adding allowed device hardware addresses to your router. The switch then checks each network card address before it lets a device join. Network teams use this list to block unknown laptops and phones from local ports. Still, once a device passes this check, broad network roles let users reach everything.
How mac filters work on local networks
Every network card has a twelve-character hardware address baked into the chip. When a laptop asks to join a network, it sends this address first. The switch or wireless controller reads the address from the incoming frame header. It compares that value against a saved list of allowed or blocked devices.
Teams build an allow list to let only approved office gear join the network. They can also build a block list to kick off specific noisy devices. If the address matches an allow rule, the switch opens the port for traffic. If the address is missing from the list, the switch drops the frame right away.
Admins often pair this setup with dynamic host assignment rules on the local server. That way, known devices always get the same network address each time they join. For small setups with twenty or thirty machines, typing these lists by hand works fine. As the team grows, tracking every new phone or laptop takes hours of manual work.
What hardware address checks solve and miss
Hardware address rules stop casual guests from plugging a personal laptop into a wall jack. They also help teams keep TVs and printers on separate network segments. This basic gate keeps random devices off your main office subnet without extra software.
Still, hardware addresses travel in plain text across wireless airwaves and local wires. Anyone with a basic packet tool can read an allowed address from the air. A user can then type that same address into their own laptop settings. Once they swap the address, the switch lets them onto the network right away.
More important, network port checks only decide which machine can join the local wire. They know nothing about the person sitting at the keyboard or their job role. Once a laptop joins the subnet, it can still reach internal databases and servers. The switch does not inspect the database queries or shell commands that run next.
Filters: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Why teams move past hardware lists for server rules
Modern engineering teams do not rely on network card lists to protect production data. People work from home, swap laptops, and use cloud hosts that change addresses daily. Keeping a static list of hardware cards across five hundred remote workers breaks down fast.
Even on a locked office network, an approved laptop can run a bad query. If an engineer logs into a database with a shared admin password, mistakes happen. A single command can still drop a table or pull thousands of customer emails. Knowing the laptop hardware address does not tell you who ran that command.
To fix this gap, teams move security checks up to the user and command level. They tie database and server logins to a central identity provider with multi-factor checks. They also inspect individual commands in flight and mask sensitive fields like card numbers. This shift gives security teams clear logs of every action across every database and host.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Can someone bypass a hardware address allow list?
Yes, a user can capture an allowed address from wireless traffic in minutes. They can then change their own network card settings to match that exact address.
Do mac filters encrypt traffic on a wireless network?
No, an address filter only checks if a device can join the access point. You still need strong wireless encryption keys to protect the data moving through the air.
How do teams protect databases if network checks are not enough?
Teams link database logins to user identities instead of trusting the local network wire. They also log every query and mask sensitive fields like phone numbers in results.