Why defence in depth matters

I think the biggest mistake a small business makes is to rely on a single security control and hope it will catch everything. Attackers are clever, they look for the weakest link and they move fast. A layered approach makes every step harder for them, and it gives us more chances to notice something odd before it turns into a breach.

In my view a basic defence in depth plan has three pillars: network segregation, host hardening, and monitoring. Each pillar is a set of small pieces that fit together. When one piece fails the others can still block the attack.

Network segmentation

Start by breaking the office LAN into separate VLANs. Put the public‑facing router, the guest Wi‑Fi, the workstations, and the server room each on their own broadcast domain. That way a compromised laptop cannot just talk to the file server without passing a gateway.

On a typical small office router you can create VLANs with a few lines. For example on a Cisco‑style device:

interface GigabitEthernet0/1
  switchport mode access
  switchport access vlan 10  ! workstations
interface GigabitEthernet0/2
  switchport mode access
  switchport access vlan 20  ! guest Wi‑Fi
interface GigabitEthernet0/3
  switchport mode access
  switchport access vlan 30  ! servers

On a Linux bridge you can use iptables or nftables to enforce inter‑VLAN policies. A simple rule that drops traffic from the guest VLAN to the server VLAN looks like this:

iptables -A FORWARD -i eth0.20 -o eth0.30 -j DROP

This rule is cheap, it is easy to audit, and it stops a rogue guest device from reaching the critical servers. The same idea works for Windows Server with the built‑in firewall.

Perimeter firewall basics

Even a cheap commercial firewall can be a strong first line. Make sure you block inbound traffic that you do not need. In most small offices the only inbound ports are 80/443 for a web server and maybe 22 for remote admin. Anything else should be denied.

On a Ubuntu box running ufw the easiest rule set is:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp comment 'SSH for admin'
ufw allow 80/tcp comment 'HTTP web server'
ufw allow 443/tcp comment 'HTTPS web server'
ufw enable

That is it. No need for fancy zones. The default deny gives you a clean slate, then you add only the ports you really need.

Host hardening and patch management

Every machine on the network should have automatic updates turned on. If a patch is delayed, the attacker gets a window to exploit a known flaw. For Windows you can enable Windows Update for Business and set a 7‑day grace period. On Linux you can enable unattended-upgrades:

apt-get install unattended-upgrades
dpkg-reconfigure unattended-upgrades

Make sure you also lock down unnecessary services. A common mistake is to leave RDP open to the internet. Turn it off unless you need it, and if you do, put it behind a VPN.

Strong authentication

Passwords are still the first line of defense. Enforce a minimum length of 12 characters, include mixed case, numbers, and a symbol. Better yet, require two‑factor authentication for any remote access. Google Authenticator or Microsoft Authenticator work fine for a small team.

If you use a VPN, configure it to require a certificate plus a TOTP code. That way a stolen password does not give a attacker a foothold.

Detecting lateral movement

Attackers who get into one workstation often try to hop to a server. The easiest sign of that is an unexpected SMB connection from a client that never talks to a file share. Enable logging on the file server and watch for new source IPs.

On a Windows server you can turn on audit logging for object access:

auditpol /set /subcategory:"File System" /success:enable /failure:enable

Then export the logs to a central syslog server. A sudden spike in failed logons is a red flag.

Intrusion detection on the edge

A lightweight IDS such as Suricata or Snort can run on the same box as the firewall. The rule set does not have to be massive; a few key signatures for ransomware, credential dumping, and port scans are enough to catch the basics.

To install Suricata on Ubuntu:

apt-get update
apt-get install suricata
suricata -c /etc/suricata/suricata.yaml -i eth0

When Suricata sees a match it logs to /var/log/suricata/fast.log. You can pipe that file into a simple alert script that sends an email to the admin.

Logging and centralized review

All the pieces above generate logs. If you leave them on each box, you will miss the bigger picture. Set up a central log collector – a small Elastic Stack instance or even a free Graylog VM works.

In my view the most valuable dashboard shows failed logons, new device connections, and firewall denials. Anything that spikes above the normal baseline deserves a quick check.

Here is a quick way to forward Windows Event logs to a syslog server using nxlog:

<Input in>
    Module      im_msvistalog
</Input>
<Output out>
    Module      om_udp
    Host        192.168.1.100
    Port        514
    Exec        to_syslog_bsd();
</Output>
<Route r>
    Path        in => out
</Route>

The same can be done on Linux with rsyslog:

*.* @192.168.1.100:514

Regular testing and drills

Even the best controls need verification. Run a simple port scan from inside the network and see if the firewall blocks it. Use nmap:

nmap -sS -p 1-65535 192.168.1.0/24

If you find open ports that should be closed, tighten the rules. Also schedule a quick tabletop exercise: walk through a scenario where a phishing email lands on a workstation, the attacker tries to move laterally, and your detection steps fire. The exercise takes about twenty minutes and it surfaces gaps you didn’t notice.

Wrapping it up

All of these steps are cheap, they are mostly configuration changes, and they add up to a network that is harder to breach. The key is to treat each control as a layer, not a silver bullet. When one layer fails, another still stands.

Start with a simple firewall rule today.

Photo by Christina Morillo on Pexels