This article explains what Minimum RSSI is and how to configure it in the UniFi Network application. We only recommend using this if you are familiar with basic RF theory as misconfiguration may result in performance degradation of your network.
Received Signal Strength Indication (RSSI) is a value indicating the perceived signal level of a wireless client from the AP’s perspective. The Minimum RSSI value is set individually on each AP and indicates the minimum signal level required for a client to remain connected.
The main purpose of this is to assist with a client’s roaming between two nearby APs. It prevents a device getting “stuck” connected to the initial AP at a weaker signal strength as opposed to roaming to a new AP that may be more optimal. Once the signal drops below the Minimum RSSI value set, the initial AP will kick the client so that it can reconnect to the new AP.
Once an AP kicks a client (by sending a de-authentication packet), it is up to the client to find a better AP to connect to. It may connect back to the same AP, especially if it is the only one within range. Since the signal strength still does not meet the Minimum RSSI, it will again be booted. Improper tuning can thus result in network instability. For this reason, it is important to realize that there is no one size fits all and you should carefully test your configuration to avoid introducing connectivity problems.
How to determine and configure Minimum RSSI
Minimum RSSI is can be enabled within the UniFi Network Application by selecting an AP in UniFi Devices and then navigating to Settings in the side-panel of the selected device. Once enabled, this can be manually set for your 2G and 5G radios independently.
You can view the Signal Strength for your current wireless clients by clicking on a device in the Client Devices tab. The signal is measured in units of dbm (decibels per milliwatt). You will notice that this is a negative number because the power is less than 1 mW:
dbm = 10 log P1/1mW
0 dBm = 1 mW
-10 dBm = 0.1 mW
-20 dBm = 0.01 mW, and so forth
A value close to 0 indicates high signal quality, whereas a larger negative value indicates poor signal quality. Remember, you need to granularly select the appropriate value for each AP and avoid using a single value everywhere.
Other Considerations
There are many factors that can affect the a client’s RSSI at the AP side including distance, building materials, objects, interference, etc. As much as we would love to give a recommendation, it really isn’t this simple. It’s safe to say -80dBm would be a starting point for standard home or office configurations, but there are too many environmental variables so you should have caution at all times.
The best method to determine appropriate Minimum RSSI values is to perform a site survey. This can be done by testing the signal strength of various wireless clients at different distances. Each device will have different antenna configurations and will thus perform differently in the same geographic location. You want to connect to an SSID, make it specific to that AP (an override on that SSID), and then roam to what you would consider the outer edge of the desired coverage area. Mark the client’s RSSI, and then take a couple more points. The more data you gather, the better idea you’ll get for the minimum RSSI value to use.
Using Orange Pi R1+, Netfilter, AdGuard and CrowdSec to preserve your security & privacy. The third part is on how to set up a canary device that ‘tweets’ when unexpected events occur.
Welcome to the third and final part of our trilogy where the goal is to inspire and show you how to create a very efficient firewall to secure home network or your small business, which offers a serious level of security, at low cost.
The first part focuses on selecting hardware and installing the base OS.
The second part is dedicated to setting up firewall functionality, client VPN to protect your identity online, AdGuard for the entire network, DuckDNS if you don’t have a static IP as well as port knocking to close down your internet exposed services to anyone but you.
This third and final part is about how to secure your network even further with CrowdSec – how to set up a canary device that notifies you when unexpected events such as scanning occur; something you would typically never do yourself.
Part 3: Setting up a canary device with CrowdSec
The end goal of this third part is to show how CrowdSec can do cool stuff acting as a canary, but we need a few preliminary steps. We want to set up an alarming system so we know when a new system has been connected to our local network. That is a two-part thing consisting of installing ARP Watch and notifications via Pushover. After that we’ll talk about what CrowdSec can do in the sense of alarming you when odd things are happening on your network. First things first:
ARP Watch
To proceed further in securing ourselves, it would be cool to know whenever a new machine is connecting to the LAN. And since we can now get instant notifications with the above script, let’s send an alert every time a new device is detected in the LAN.
$ sudo apt-get install arpwatch
In the /etc/default/arpwatch file add lan0 (or whatever is the name of your LAN interface):
INTERFACES="lan0"
And create a file in /etc/arpwatch/lan0.iface (if lan0 is your LAN interface) to add some email addresses. Here, to reuse our pushover system, we can input the email address that is provided for your app in pushover. If you send an email to this address, it’ll be forwarded as a push notification to your phone.
$ cat | sudo tee /etc/arpwatch/lan0.iface
Paste:
IFACE_ARGS="-m xmmmm1fjoejf@pomail.net"
Where xmmmm1fjoejf@pomail.net should be replaced by the email address listed under your login. As usual, end with CTRL + D to return to your shell.
Setting up a notification system
Pushover is an iOS and Android app that allows you to send plenty of notifications to your phone for free (around 7500 per app per month). You can obviously use it wherever you feel, for whatever reason. In the above crontab script you can, for example, notify yourself when the machine boots. But we may also want to know when a new mac address is registering in our network or if a port scan was fired from within the LAN area (which is quite bad news, see below section “Protecting yourself even from (w)LAN devices”)
So, once you have set up your Pushover App and account online, you should have a user token and an app token:
Next, create an APP and locate your App token.
Create a script to send yourself notifications:
$ cat > /usr/local/scripts/pushover.sh
cut/paste the script below, finish it with CTRL+D and issue the classical chmod:
Now to send yourself a message, you just need to type in:
$ ./pushover.sh "Most kittens" "Are too cute"
And you should get this on your phone screen:
Protecting yourself even from (w)LAN devices
One thing you cannot really trust, but nevertheless like to have, are connected speakers like Sonos, your voice assistants like Alexa or even your IP cameras or just your smartphone. All those IoT devices make our life easier but also come with a substantial amount of potential security issues.
I’ve tried several approaches here, but none is at the same time realistic in terms of daily usage and secure enough. Segregating all those machines in a sub-lan (or rather a sub-wlan for most of them) using a different vlanid and trying to limit the exposure to your secure devices is a complicated task and usually cripples the usability we all appreciate as well.
One simple example would be your Sonos speakers. You want them to connect to online streaming systems like Deezer or Spotify and be able to control them with your phone through airplay. At the same time, if (when) a hacker is able to upload a rigged firmware by breaching into Sonos systems, they can infect your local speakers and establish a local presence in your LAN, scan, harvest, invade, etc. The same is true of most voice assistants, IP cameras, smartwatch, smartphone, TV, and generally speaking of *any* IoT devices.
Now if you isolate them in a sub (w)LAN, you’ll not really be able to control them comfortably since anytime a friend comes over you’d have to add a rule to your firewall as well as probably other cumbersome modifications.
So to be more realistic, I decided to proceed in a different way. Let’s not suspect those things right away but rather detect if (when) they start to behave suspicious. Apart from cameras that should not be able to access the Internet and send private video streams across the globe to god knows how, we can just monitor our IoT devices. Most of those devices could be let loose and if ever they are compromised a hacker will very likely use them to scan and compromise your network.
There are other more complicated ways, like having different, firewalled vlans, tag packets, and using multicast forwarding, but beyond complication, you’re not always sure not to lose functionalities of some of your IoT devices. Also this method is more generic (although less protective).
Using CrowdSec to setup a Canary device
The concept is fairly old and simple. Coal miners during the 19th century used to bring a canary with them down the mine and if a gas leak would occur (which was odorless) it’d kill the canary and miners would evacuate, hopefully before a potential blast.
Nowadays, and in an IT context, a canary is a device that is stealthy sitting in your network that should bever be queried. It’s doing nothing, hosts no service and there is no reason in the world it should ever be poked. If it is accessed, that means something/someone in your network is scanning it and 99.999% of the time, this is bad news.
If a hacker ever hijacks any of your IoT devices, no matter the method, it’s very likely that they’ll scan your LAN. In this case your canary should be triggered and alerting you. We have all the needed tools to do it already, either locally on the firewall we are building, or on a separate similar pi device with just one LAN interface. No matter how you choose to do it, CrowdSec will be a very useful tool to set up the canary and our pushover script can alert us. After all, our scenario is known : multiport scan and it already exists on the hub. The bouncer (the component that deals with the detect menace) also exists: we’ll simply use the one that triggers a script, here our script to send us a notification using pushover.
Remember we added those lines in our firewalling script:
Well, basically they say that if ports on the LAN interface are contacted on any other ports than 22:TCP and 8080:TCP (8080 is just an example), then someone is scanning you and you should drop the packets. But the trick here is that since we drop the packet, CrowdSec iptables multiscan scenario, crowdsecurity/iptables-scan-multi_ports , will catch the signal.will catch the signal.
CrowdSec
CrowdSec will spot hacking attempts by looking at the logs generated on the OPI. If you intend to run more services than just those in this tutorial, remember to reconfigure it (either by running the installation wizard again or by adding it manually to /etc/crowdsec/acquis.yaml). If you choose the latter method make sure to install a suitable scenario either using cscli or by visiting https://hub.crowdsec.net.
In one sentence, CrowdSec is crowd powered cyber security software. It’s an open source & free IPS system. It detects attacks in your logs, bans the IP and then shares the aggressive IP with the community so that everyone else is also protected against this aggressor. As well, your instance of CrowdSec benefits from the global sightings of the network.
While CrowdSec is available in Debian (but not Ubuntu) it’s highly recommended to add our own repo since the available package has been deprecated since last OS release. To do that follow the (easy) instructions at our documentation site. Once added, simply install the CrowdSec package and the nftables bouncer:
Installing both packages with one command can be a bit of a hassle since we can’t control the order of which packages are installed. So to make sure that the agent is installed first, we do it like this. This ensures that the bouncer is added automatically to the CrowdSec agent.
The installer will pretty much do all the job for you. After installing add the netfilter log collection by issuing this:
(note: In spite of the name, the collection is also valid for nftables)
Ok we’re all set on that front. CrowdSec will create two nftables IP sets named crowdsec and crowdsec6, containing ipv4 blocklist for the first one and ipv6 for the latter. Basically those sets are automatically banned by the firewall bouncer daemon residing in memory. If someone agresses your machine and tries to port scan it, scan your web server or bruteforce your ssh / ftp or other accesses, not only will it get banned, but its IP will also be reported to the central CTI. In return, we do benefit for free from the knowledge of the Crowd as well and our IP sets are automatically filled with new dangerous IPs sent by the central API of CrowdSec. We defend, we partake and in return we are even better defended by all the other members. Neat.
You can obviously block those IP sets yourself wherever you feel.
The configuration resides in /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml and is very straightforward:
Note: you won’t need to edit the file; this is the default configuration.
So not only will your (potential) services be protected, but your firewall output will also generate bans for people trying to hack you, share their IP to protect everyone else and CrowdSec will send you dangerous IPs constantly to be blocked directly in your firewall. One stone, three birds. Bingo!
Next, we need to set up the custom bouncer that comes with CrowdSec. Luckily it’s also available as binary package on arm-based devices running debian-based distros:
$ sudo apt install crowdsec-custom-bouncer
In its essence the custom bouncer simply executes a custom script whenever a scenario triggers.
Obviously, we’re using it to execute the pushover_crowdsec.sh script whenever a scenario triggers.
After installation, we need to edit the config file located in/etc/crowdsec/bouncers/crowdsec-custom-bouncer.yaml:
You would only need to edit the bin_path item in the configuration file above as everything else, even registering the bouncer with the agent has been taken care of by the install script run automatically upon installation.
Copy/paste the content of the script after this command to ensure that the script is added to the file system correctly:
$ cat | sudo tee /usr/local/scripts/pushover_crowdsec.sh
Remember to chmod 755to make the script executable.
Now, anytime a scan would be initiated from the LAN, we are notified directly on our Phone. Our Canary is alive and kicking!
Conclusion
For a marginal budget, you can protect your family, your work and your privacy. All it takes is 50€ and a couple of hours. You’ll learn a lot, be autonomous and better protected. Doesn’t it sound like a fair investment of your time in 2022?
How to set up an effective firewall and preserve your security & privacy with Orange Pi R1+, Netfilter, AdGuard and CrowdSec.
Welcome to the second part of our trilogy where the goal is to inspire you to create a very efficient firewall to protect your remote work environment, family, or your small business, which offers a serious level of security, at a low cost.
Have you not yet read the first part that focuses on selecting hardware and installing the base OS it’s not too late. Find it here.
This second part is focused on how to set up firewall functionality, setup client VPN to protect your identity online, setting up AdGuard for the entire network, DuckDNS if you don’t have a static IP as well as port knocking which is a cool way to close down your internet exposed services to anyone but you (or anyone else who knows the secret combination to enter). The third and final part will be about how to secure your network even more with CrowdSec – how to set up a canary device that ‘tweets’ when unexpected events like for instance port scanning occurs; something you would typically never do yourself.
It’s also being part of a larger project, CrowdSec, which is blocking Internet attacks and sharing IPs that launched them. You protect yourself and others at the same time. In essence, this comprehensive guide will show you how to:
Create security robust enough to resist even if passwords are compromised
Create a reliable hardware environment for your firewall
Install the OS on it and create a rock-solid Firewall to protect your activities
Add CrowdSec to protect your WLAN services you’d like to expose over the Internet and detect if any local IoT device is going rogue (e.g. cams, assistants, connected speakers, etc.)
Allow external access to DMZ-like services to control your home on distance and access your firewall
Add a VPN to protect your anonymity online
Add an anti-advertisement & anti-tracking system
Part 2: The Software stack
The firewall
It’s already in there, provided by the netfilter subsystem, which is integrated into the kernel. The nft (nftables) command is here to help us interact with the netfilter layer. The following script is commented so that you can easily modify it according to your needs and projects or even port it to iptables (nftable predecessor). All scripts can be found here.
Out of the box, it handles:
Multiple internet connection with a dynamic routing table capable of sending packets to one or the other connection based on your rules (destination port, src or destination IP, protocols, etc.)
Protection against usual network shenanigans
Inbound, forward and outbound traffic filtering
CrowdSec integration to defend your exposed services and have a Canary to detect if your LAN is being scanned
Port knocking integration so that you can simply use a port knocking app to unlock access to your network from wherever you are.
Just cut/paste it from this doc:
$ cat | sudo tee /etc/nftables.conf
Here is the script to adapt and copy/paste:
#!/usr/sbin/nft -f
#Part 1: Setting statics
define wan = eth0
define lan = lan0
define vpn = tun0
define localhost = lo
define vpn_net = 10.8.0.0/24
define vpnserver = tun1
define vpn_server_net = 10.0.0.0/24
define machine1 = 192.168.0.2
define machine2 = 192.168.0.3
define antilanscan = { 22, 8080 } #Part 8: Anti lan scan
define cameras = { 192.168.0.4, 192.168.0.5 }
define icmp_v6 = { destination-unreachable, echo-reply, echo-request, nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert, packet-too-big, parameter-problem, time-exceeded }
#Part 2: Reset nft tables
flush ruleset
#Part 3: NAT
table ip nat {
chain prerouting {
type nat hook prerouting priority -100; policy accept;
iif $wan tcp dport 2222 dnat to $machine1:22 # incoming connexion on port 2222 will be forwarded to 192.168.0.2 on 22
iif $wan tcp dport 5001 dnat to $machine2 # sames port 5001 and 192.168.0.3 but this time port is 5001 to 5001, no change
}
chain postrouting {
type nat hook postrouting priority 100; policy accept;
oif $wan snat to 192.168.1.1
oif $wan2 snat to 192.168.2.1
oifname $vpn masquerade # snat to $vpnip
oifname $vpnserver snat to 10.0.0.1
}
}
#Part 4: Creating IP sets
table inet filter {
set whitelist_candidates {
type ipv4_addr . inet_service
flags timeout
}
set whitelist {
type ipv4_addr
flags interval, timeout
}
set whitelist_portknockd {
type ipv4_addr
flags timeout
}
chain input {
type filter hook input priority 0; policy drop;
icmpv6 type $icmp_v6 accept
#Part 5: Portknocking (next 4 lines)
tcp dport 314 add @whitelist_candidates {ip saddr . 18 timeout 2s}
tcp dport 18 ip saddr . tcp dport @whitelist_candidates add @whitelist_candidates {ip saddr . 939 timeout 2s}
tcp dport 939 ip saddr . tcp dport @whitelist_candidates add @whitelist_candidates {ip saddr . 101 timeout 2s}
tcp dport 101 ip saddr . tcp dport @whitelist_candidates add @whitelist {ip saddr timeout 180s} log prefix "Portknocked: "
ct state related,established accept
iif $lan tcp dport != $fwopenports log prefix "LAN SCAN:" drop #Part 8: Anti lan scan
ip saddr @whitelist accept
ip saddr @whitelist_portknockd accept
iifname $lan accept
iifname $localhost accept
iifname $vpnserver accept
iifname $wan ip saddr != @whitelist drop
iifname $wan ip saddr != @whitelist_portknockd drop
iifname $wan ct state invalid log prefix "Invalid packet:" drop
iif != lo ip saddr 127.0.0.0/8 log prefix "Fake localhost:" drop
}
chain forward {
type filter hook forward priority 0; policy drop;
#Part 6: Prerouting (next two lines)
iifname $vpn meta l4proto udp ip daddr $machine1 udp dport 22 accept
iifname $vpn meta l4proto tcp ip daddr $machine2 tcp dport 5001 accept
#Part 4: Creating IP sets (next two lines)
ip saddr @whitelist accept
ip saddr @whitelist_portknockd accept
iif $lan accept
iifname $vpnserver accept
ct state established,related accept
ip saddr $cameras log prefix "Camera trying to exit:" drop
ct state invalid log prefix "Invalid packet:" drop
}
chain output {
type filter hook output priority 0; policy accept;
}
}
#Part 7: Mangling
table ip mangle {
chain prerouting {
type filter hook prerouting priority -150; policy accept;
mark != 0x0 meta mark set ct mark
ip saddr $machine1 tcp sport 10001 meta mark set 0x2
ip saddr $machine1 udp sport 10001 meta mark set 0x2
ip saddr $machine1 meta mark set 0x1
ip saddr $machine2 meta mark set 0x4
}
chain postrouting {
type filter hook postrouting priority -150; policy accept;
ct mark set mark
}
}
After inserting it, save the file by pressing CTRL+D.
This version is a simplified version of the firewall script available from the repo above, but the most important part is here already. This nftables.conf file would not be enough by itself to handle several possible routes. Be sure to also use the ip rules script to create your routing tables, see below, section IP route.
NFtables (netfilter) Firewall details
Part 1 are basic variable definitions.
Part 2 resets all nft tables. (Used to take 10 lines with Iptables)
In part 3 (NAT) we are defining what happens to packets that are incoming and destined to another machine behind the firewall. They are dealt with very early in the filtering process, in a prerouting chain. The postrouting chain is about telling what IP should be used for translating IPs coming from various subnets.
The second table, filter, is part 4 that create IP sets. They are tables that contain IP addresses, sometimes with expiry dates. Three sets are created, one for potential candidates to whitelisting, the second for confirmed whitelisted IPs and the third will be used in conjunction with port knocking. The reason for creating two different whitelists of IPs is that the port knocking integrated in this NFT configuration (part 5) will only store the IP that knocked. Logical? No, not really. But CGNAT, used by telecom operators to run 4G networks, ruins it all and usually, it’s not a 1:1 IP translation but a range of IP that is used. So when your phone is port knocking 3 ports quickly, it’s usually with one IP but then when you connect on your SSH port, another IP is used. Luckily, they often sit in the same /24 range. The problem doesn’t exist with IPv6 obviously. So knockd will fill the second set with a range and the first one is still useful when you connect from elsewhere like a hotel. (I didn’t find any way to add a range to the set directly from an nft configuration file)
Part 6 is related to prerouting. It’s not enough to redirect the connection since the packet is passing two interfaces, we also need to accept this in the forward rules.
Part 7 is mangling. This is where we instruct the firewall to mark packets according to our own rules. 0x03 is the VPN server you host yourself and where you receive inbound traffic, 0x02 is the VPN client which you use to establish an outbound tunnel through a VPN provider. It’s through here you send the traffic of machine 1. In this example, we want machine1 to be using connection 2 when it’s starting a connection on port UDP or TCP 10001, otherwise it will be using connection 1. Machine 2 will always use your alt connection (here marked as 0x4) and machine 1, except for ports 10001 will use connection 1. This can be adapted with ports, source addresses, destination addresses, protocols, etc. (Note that the table has the highest priority and will be “executed” first, before all other rules). Use cases are easy here: you can send your professional workstation packets through a dedicated connection for example. Or send all your peer-to-peer traffic through a VPN or your TV IP through a VPN to avoid Geo limitations, etc. See the IP route section to understand fully how nft mangle + IP route cooperate here.
Part 8, Anti lan scan will be covered later on in this guide, but the global concept is to watch for unusual port scans, coming from our LAN-facing ethernet adapter, that would denote an IoT device being compromised or a hacker doing a lateral move in your network (classic in Ransomware scenario). We’ll have a canary setup here, see below for a more detailed description.
Obviously, all those rules are given as examples but it should be fairly easy for you to adapt them to your own context.
Port knocking
So this script handles port knocking by itself with the lines tagged in yellow, but the CGNAT problem forces us to have a fallback plan. We’ll use knockd to handle the matter on our machine.
But why is port knocking in the first place?
Well, take for granted that any application you expose might have an unknown security flaw. Or that your passwords are compromised. If the attacker doesn’t have access to the application port in the first place, even if he knows your pass or has a secret “headshot” 0 days exploit to launch, with port knocking he cannot even try in the first place, except if he uses the exact same IP as you do. This very heavily limits the risks of getting compromised. Also, using your 4G connection is far less risky than connecting to a Hotel (or public place) Wifi. But how to just allow a temporary connection from those locations? Well, port knocking is the (very underrated) key.
So before connecting to your machine, you will just launch a little app that will port “knock” your machine, nicely whitelisting the public IP you’re using and give you access to VPN, SSH, RDP, whatever you want.
KnockonD will do nicely on iOS, Knock on Ports for Android). It sends a stream of packets, in a certain order, to add your current IP address in a set that is whitelisted in the firewall. (Careful, some ISPs (like broadband carriers) are doing CGNAT, which can cripple this technique, but we’ll try to put a workaround together)
On the OPI you just need to run:
$ apt-get install knockd
And edit the configuration file (/etc/knockd.conf) as follows. Modify to your own port sequence:
Two sequences here, one classic and another one that is compatible with heavily filtered networks that won’t allow you to access all ports freely. Both add not just your IP but your IP in a 24 range in the whitelisted set. This one is really made to address the pesky CGNAT problem.
IP Route
You also need a script that will create those multiple routing tables, and that will be able to use the marks we set in the script (part 7 in the nftables script).
Here is the script creating multiple routing tables, allowing different default routes for different usages. It’s also available from my GitHub:
Note: If you don’t have multiple wan connections like me, adjust accordingly by removing all occurrences of WAN2.
#!/bin/bash
### BEGIN INIT INFO
# Provides: multiroute
# Required-Start: $network
# Required-Stop: $network
# Should-Start:
# Should-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Multiroute manager
# Description: Manage multi-routing
### END INIT INFO
Set_variables()
{
WAN="eth0"
LAN="lan0"
WAN2="eth2"
VPN=`ifconfig|grep tun0`
VPNSERVER=`ifconfig|grep tun1`
[[ ! -z "$VPN" ]] && VPNIF="tun0" && VPN=1 && VPNCLIENTIP=`ip -o addr | grep -v inet6 | grep tun0 | awk '{split($4, a, "/"); print a[1]}'` && VPNCLIENTROUTE=`ip route show|grep -v inet6 | grep "tun0 proto" | cut -f 1 -d " "`
[[ ! -z "$VPNSERVER" ]] && VPNSERVERIF="tun1" && VPNSERVER=1 && VPNSERVERIP=`ip -o addr |grep -v inet6 | grep $VPNSERVERIF |awk '{split($4, a, "/"); print a[1]}'` && VPNSERVERROUTE=`ip route show |grep -v inet6 | grep $VPNSERVERIF | cut -f 1 -d " " | head -1`
}
Env_Cleanup()
{
ip rule del from all fwmark 1 2>/dev/null
ip rule del from all fwmark 2 2>/dev/null
ip rule del from all fwmark 3 2>/dev/null
ip rule del from all fwmark 4 2>/dev/null
ip rule del lookup maincnx 2>/dev/null
ip rule del lookup vpnclient 2>/dev/null
ip rule del lookup vpnserver 2>/dev/null
ip rule del lookup altcnx 2>/dev/null
ip route flush table maincnx
ip route flush table vpnclient
ip route flush table vpnserver
ip route flush table altcnx
for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > "$i"; done # To avoid packet drop
}
Routing_Init()
{
[[ $VPN ]] && echo -e "$ORANGE -> VPN IS UP (route: $VPNCLIENTROUTE, on dev: $VPNIF, ip: $VPNCLIENTIP) $END"
ip route add table maincnx default dev $WAN via 192.168.1.2
ip route add table maincnx 192.168.0.0/24 dev $LAN src 192.168.0.1
ip route add table maincnx 192.168.1.0/24 dev $WAN src 192.168.1.1
ip route add table maincnx 192.168.2.0/24 dev $WAN2 src 192.168.2.1
[[ $VPN ]] && ip route add table maincnx $VPNCLIENTROUTE dev $VPNIF src $VPNCLIENTIP
[[ $VPNSERVER ]] && ip route add table maincnx 10.0.0.0/24 dev $VPNSERVERIF src 10.0.0.1
ip rule add from 192.168.1.2 table maincnx
[[ $VPN ]] && ip route add table vpnclient default dev $VPNIF via $VPNCLIENTIP
[[ $VPN ]] && ip route add table vpnclient $VPNCLIENTROUTE dev $VPNIF src $VPNCLIENTIP
[[ $VPN ]] && ip route add table vpnclient 192.168.0.0/24 dev $LAN src 192.168.0.1
[[ $VPN ]] && ip route add table vpnclient 192.168.1.0/24 dev $WAN src 192.168.1.1
[[ $VPN ]] && ip route add table vpnclient 192.168.2.0/24 dev $WAN2 src 192.168.2.1
ip rule add from $VPNCLIENTIP table vpnclient
[[ $VPNSERVER ]] && ip route add table vpnserver default dev $VPNSERVERIF via $VPNSERVERIP
[[ $VPNSERVER ]] && ip route add table vpnserver 192.168.0.0/24 dev $LAN src 192.168.0.1
[[ $VPNSERVER ]] && ip route add table vpnserver 192.168.1.0/24 dev $WAN src 192.168.1.1
[[ $VPNSERVER ]] && ip route add table vpnserver 192.168.2.0/24 dev $WAN2 src 192.168.2.1
[[ $VPNSERVER ]] && ip route add table vpnserver 10.0.0.0/24 dev $VPNSERVERIF src 10.0.0.1
[[ $VPNSERVER ]] && ip rule add from $VPNSERVERIP table vpnserver
ip route add table altcnx default dev $WAN2 via 192.168.2.2
ip route add table altcnx 192.168.0.0/24 dev $LAN src 192.168.0.1
ip route add table altcnx 192.168.1.0/24 dev $WAN src 192.168.1.1
ip route add table altcnx 192.168.2.0/24 dev $WAN2 src 192.168.2.1
ip rule add from 192.168.2.2 table altcnx
ip rule add from all fwmark 1 table maincnx
[[ $VPN ]] && ip rule add from all fwmark 2 table vpnclient
[[ $VPNSERVER ]] && ip rule add from all fwmark 3 table vpnserver
ip rule add from all fwmark 4 table altcnx
ip route flush cache
for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > "$i"; done # To avoid packet drop
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward > /dev/null
}
case "$1" in
start)
Set_variables
[[ $VPN ]] && sleep 5 # Wait for VPN to be up if not yet started when the firewall script kicks in
/usr/bin/logger -t "Multi route" "Starting" -p4
/usr/bin/logger -t "Multi route" "VPN CLIENT DETECTED, ADDING RULES" -p4
/usr/bin/logger -t "Multi route" "VPN SERVER DETECTED, ADDING RULES" -p4
Env_Cleanup
Routing_Init
exit 0
;;
stop)
Set_variables
/usr/bin/logger -t "Multi route" "Stopped" -p4
echo 0 | sudo tee /proc/sys/net/ipv4/ip_forward > /dev/null
ip rule del from all fwmark 1 2>/dev/null
ip rule del from all fwmark 2 2>/dev/null
ip rule del from all fwmark 3 2>/dev/null
ip rule del from all fwmark 4 2>/dev/null
ip route flush cache
exit 0
;;
restart)
/usr/bin/logger -t "Multiroute" "restart initiated" -p4
$0 stop
sleep 1
echo -e '\n'
$0 start
;;
*)
echo -e "$YELLOW Usage: /etc/init.d/multiroute.sh {start|stop|restart}$END"
exit 1
;;
esac
exit 0
The script is an old-fashioned SysV init script that goes into /etc/init.d after you’ve made it executable with chmod 755 and will be executed during startup.
This script basically creates four different routing tables. So instead of having just one “default route” for all your machines, your firewall now has four different tables, each containing a set of specific routing rules. So if you mark a packet with 0x2, (see in the nftables configuration, the mangle part) the machine will ship it through the VPN connection. If you tag it with 0x4, it will use your alternate connection, say a 4G for example. The tag 0x3 will be for the VPN Server and the 0x2 for VPN client. It’s just magic how many opportunities this kind of IPtables / Nftables mangling system, coordinated with IP routing can open.
VPN
We speak here of a client VPN. A VPN that you subscribed to and want to be able to use in certain situations, or more precisely with certain packets. If you want to bypass a geographical lock from some TV broadcasters or Netflix or use some protocols rather on an anonymous connection than the usual one, or just to preserve your anonymity this is the way to do it.
Once you find your dream VPN provider, they will most likely give you files to set up your VPN connection, and usually, they are made for both Wireguard and OpenVPN. I will show you how to install and configure the latter. You will just need to install OpenVPN, upload those files (usually a .conf file also embedding all certificates and a user.pass file with the credentials) in the /etc/openvpn directory, enable openvpn in /etc/default/openvpn and you should be able to connect.
A typical OpenVPN client configuration looks like this:
client
dev tun
proto udp
remote [OPENVPN SERVER IP] 1194
resolv-retry infinite
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ping 15
ping-restart 0
ping-timer-rem
reneg-sec 0
comp-lzo no
log /var/log/openvpn.log
remote-cert-tls server
auth-user-pass /etc/openvpn/user.pass.vpn
route-nopull
verb 3
pull
fast-io
cipher AES-256-CBC
auth SHA512
script-security 2
up "/etc/init.d/firewall restart"
down "/etc/init.d/firewall restart"
-----BEGIN CERTIFICATE-----
[YOUR CERTIFICATE]
-----END CERTIFICATE-----
key-direction 1
#
# 2048 bit OpenVPN static key
#
[YOUR KEY]
CAUTION: There is a minor security vulnerability here. Using the auth-user-pass /etc/openvpn/user.pass.vpn file is not ideal. This file contains your credentials for connection in plaintext to avoid providing them manually during initialization of the VPN. This plaintext isn’t encrypted and could expose your credentials if your firewall is ever seized or you become prone to a very critical vulnerability, like a 0day buffer overflow of some sort, would successfully compromise your firewall. On my end, I live with it, but you’ve been warned.
PS: The firewall is automatically reloaded when the VPN goes up or down to add the proper rules.
Create the directory for custom scripts
We need a directory to save custom scripts. Create /usr/local/scripts and sudo chown it to your current user for convenience.
DuckDNS
While we are at it, let’s make this machine easy for you to locate online. Should you have a dynamic IP address, just crash by DuckDNS, create yourself an account and register your IP and duckdns.org subdomain for free. Here is a little script to help you update it on a regular basis:
The token is found under your login at duckdns.org after clicking the ‘>>> reCAPTCHA <<<’ button.
Use the script by saving it to e.g./usr/local/scripts/duckdns.sh, chmod 755 it and execute it every half an hour with a crontab like this:
$ crontab -e
$ crontab -e
It should look somewhat like this:
MAILFROM=[YOUR_SENDING_EMAIL]
MAILTO=[YOUR_RECEIVING_EMAIL]
#m h dom mon dow command
17 * * * * cd / && run-parts --report /etc/cron.hourly
45 10 * * * test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
30 * * * 6 /usr/local/scripts/duckdns.sh
Only the last line is added by us. The first lines are usually present default. YMMV.
Note: In order for the user who executes the duckdns.sh script to have permissions to write a log file in /var/log it needs to be part of the syslog group. This can easily be done by running sudo addgroup <user> syslog.
Adguard
Adguard is a really cool piece of software that is basically running a DNS that resolves all advertisement servers to 127.0.0.1 (resulting in many ads not being shown. Hooray!). You install it on your LAN and instead of connecting directly to 8.8.8.8 or your ISP DNS, you tell all your LAN users to rather use it.
If your request is not going toward an Ad server, it’s just resolved by the DNS you instructed Adguard to use. Otherwise, your client, say your mobile phone, will just ask this ad from 127.0.0.1 (himself), getting nothing in return. With this, a chrome plugin like Adblock as well as youtube Adblock and advertisement will be a thing of the past.
I highly recommend visiting their Github here. Installation is fairly easy:
Note: The script will obtain root permissions and ask for those as needed.
Now we have a DNS relay running on localhost.
You can also just use the DNS servers of Adguard directly. These are present at 94.140.14.14 and 94.140.15.15.
If you want to finalize your setup of Adguard, just connect with a browser to the firewall (likely on 192.168.0.1 at this stage), on port 3000. It should look like this:
Adguard wizard
Use the wizard to set up Adguard and continue the tutorial.
Adding a DHCP server to finalize our LAN setup
Well, now that most of the tools are up & running, let’s have a DHCP running to give addresses to machines in the LAN, which your ISP box won’t do anymore since it’s on the other side of the firewall. While we are at it, we can now ship IP addresses with the local Adguard DNS to get rid of ads.
Given as an example, I advise you to have static IPs directly like for machine 1 & 2 in this file if you can. This makes it easier to locate them later. We point the DNS to our local instance of Adguard and, as a backup also to their online DNS if our own is not replying fast enough.
So this was part 2 of our trilogy of how to install the CrowdWall. I hope you enjoyed reading it as much as I enjoyed writing it. Stay tuned for part 3 where things really start to get interesting once we add CrowdSec to the mix.
How to set up an effective firewall and preserve your security & privacy with Orange Pi R1+, Netfilter, AdGuard and CrowdSec.
Welcome to the first part of our trilogy where the goal is to inspire you to create a very efficient firewall to protect your remote work environment, family, or your small business, which offers a serious level of security, at a low cost.
This first part will be centered around the basics: choosing hardware and installing the operating system and doing basic configuration. Part two will be on how to set up firewall functionality, setup client VPN to protect your identity online, setting up AdGuard for the entire network, DuckDNS if you don’t have a static IP as well as port knocking which is a cool way to close down your internet exposed services to anyone but you (or anyone else who knows the secret combination to enter). The third and final part will be about how to secure your network even more with CrowdSec – how to set up a canary device that ‘tweets’ when unexpected events like for instance port scanning occurs; something you would typically never do yourself.
It’s also being part of a larger project, CrowdSec, which is blocking Internet attacks and sharing IPs that launched them. You protect yourself and others at the same time. In essence, this comprehensive guide will show you how to:
Create security robust enough to resist even if passwords are compromised
Create a reliable hardware environment for your firewall
Install the OS on it and create a rock-solid Firewall to protect your activities
Add CrowdSec to protect your WLAN services you’d like to expose over the Internet and detect if any local IoT device is going rogue (e.g. cams, assistants, connected speakers, etc.)
Allow external access to DMZ-like services to control your home on distance and access your firewall
Add a VPN to protect your anonymity online
Add an anti-advertisement & anti-tracking system
Needed skills
You should have basic knowledge of Linux and Shell. If you can download and install a Linux distribution by yourself, nothing should sound overly difficult.
Enough talk. Let’s get started!
Part 1: Choosing hardware and installing OS
Needed hardware
The CrowdWall is among the cheapest possible decent security setup you can get.
The components are correct but your networks will not be very isolated internally. The advanced version offers both better security and performance. The “expert” CrowdWall is made to protect a small business of tens of coworkers.
In the basic CrowdWall setup, you can also add cost-efficient Wifi Access Points like this Tenda (around 45€) or add a third Ethernet interfaceor Wifi connection (over USB).
Should you want to organize a large distribution of the CrowdWall, say equip all your remote working force with it, you can look at the GL Inet products line. They are nicely priced if you go for volumes and offer real good performances for the money.
Table 1: Possible variations
The Orange PI R1+ benefits from very interesting characteristics beyond its small price tag. It runs on a 1.5 GHzGhz SoC with 1 GB ram which is enough for the job. It also provides two ethernet ports, has marginal power consumption, and even provides a USB port and a GPIO. (The Rock Pi-E can also do the job nicely and offers a bigger GPIO but for slightly more money)
If you don’t have an Orange PI R1+ other similar single-board computers can be used instead: Orange PI R1+ LTS (Same SOC, slower, low power RAM), NanoPi R2S, NanoPi R4S, ROCK Pi E, or even a Raspberry Pi 3 or 4 with an extra ethernet plug. In the latter case, you probably want to use one connected via HAT. In either case, you won’t be able to use the same fancy case but would have to design your own or adapt mine.
Setting up your firewall
Going forward I will describe setting up using Orange PI R1+.
Physical setup
Just plug your Internet connection (usually the Box from your ISP) to the lower port (the one down, closest to the GPIO, on the above picture) and your LAN (usually your switch) to the left port above picture.
Plug the Orange Pi (from hereon ‘OPI’) to the Power supply, or if you want for redundant power supply, power up the OPI from the power bank and the bank from a regular power plug. This should give you some hours before the firewall shuts down and eventually give it time to notify you beforehand.
The physical setup should look like this:
Figure 1: The set-top box, local LAN & WAN setup, you can leave the Box Wifi for home & family use and dedicate the other Access Point to business.
Software initial setup
1/ At the time of writing the newest supported version of Armbian is Armbian 22.05 Jammy, based on Ubuntu 22.04 Jammy Jellyfish. It doesn’t matter too much if the version of Armbian you install on is based on Debian or Ubuntu as long as it’s a supported version. Download it here. Other Debian-based distros like https://dietpi.com/ should also work although this hasn’t been tested.
2/ Download a USB stick/SDcard flasher. Balena etcher is great for this. It’s very straightforward to use and runs on both Windows, Linux & macOS environments.
Remember we are on a headless device with no HDMI port, so we are going to use it in command-line (CLI) mode only. That being said you could get a serial TTY console, but the effort and complication is really not worth the time (unless you need it for debugging).
After flashing and booting your appliance you should connect it to the eth0/WAN ethernet plug (furthest away from the power connector). You will have to check your DHCP server which IP is assigned to your CrowdWall (it’s usually residing on the box you got from your internet provider). The default ssh login is root and the password is 1234. After connecting to it you will be walked through an installation wizard that will set you up with a personal user account and sudo.
The other ethernet interface will be called lan0. And for everything to work you will need to configure it.
Setting up lan0
Configure a static IP on lan0 by editing /etc/network/interfaces and adding the following:
auto lan0
iface lan0 inet static
address 192.168.0.1/24
Start lan0 with the new configuration by typing sudo ifup lan0. Verify that the lan0 interface is up by typing ip addr show lan0 in a terminal.
Setting up your Internet Box in DMZ mode (Full NAT)
No two providers have the same box, OS, hardware, interface etc. hence no universal cut/paste commands, or screenshots to help here.
The feature you’re looking for is usually named “DMZ IP”. Enabling this feature requires you to input a LAN IP address, which will be the one to which all the Internet traffic will be redirected, without filtering. This is essential if you later intend to accept connections from the Internet to your home by exposing some services, like your home automation, NVR / IP cameras, or even a VPN server.
There are other ways of doing this, like enabling ports one by one, probably in a “Network”, “NAT” or “Network Address Translation” tab, but this requires you to get into the box interface every time you need to update a port, it’s error-prone and less flexible.
Basically, where/when possible, one shouldn’t trust the ISP’s Box either. So if you can bypass it totally, do it. Often enough, specifically in an FDDI context, you can just use the little modem that connects to your fiber and connects with Ethernet to your box, and plug yourself right in instead of the ISP box. There are tutorials online, just Duckduckgo (same as Googling but with privacy) for “how to bypass [BOX PROVIDER NAME] box”.
Absolutely not mandatory and mainly interesting for paranoïd people, but if you can do it, this is an even safer setup, even though bringing back the TV and Phone feature (should you want them), could be slightly more complicated, but far from impossible for advanced users.
So this was part 1 of our trilogy of how to install the CrowdWall. Part 2 will continue with configuring your installation with essential firewall functionality like traffic filtering, anti-ad features, and much more. Stay tuned!
Securing a Microsoft 365 tenant must start with identity.
Protecting identities is a fundamental part of Zero Trust and it’s the first “target” that most attackers look for. We used to say that attackers hack their way in, now we say they log in, using bought, found or stolen/phished credentials. This article will show you why MFA is so important and how to implement advanced security features in Azure AD such as PIM, Password protection, Conditional Access policies (also a strong part of Zero Trust), auditing and more.
Below is the first chapter from our free Microsoft 365 Security Checklist eBook. The Microsoft 365 Security Checklist shows you all the security settings and configurations you need to know for each M365 license to properly secure your environment. Download the full eBook and checklist spreadsheet.
Multi-Factor Authentication
It should be no surprise that we start with identity, it’s the new security perimeter or the new firewall and having a strong identity equals strong security. The first step to take here is implementing Multi Factor Authentication (MFA). It’s free for all Office / Microsoft tenants. If you want to use Conditional Access (CA) to enforce it (rather than just enabling users “in bulk”), you need Azure AD Premium P1+ licensing. A username and a simple password are no longer adequate (it never was, we just never had a simple, affordable, easy to use alternative) to protect your business.
Hand-in-hand with MFA you need user training. If your business is relying on users doing the right thing when they get the prompt on their phone – they MUST also know that if they get a prompt when they’re NOT logging in anywhere, they must click Block / No / Reject.
To enable MFA on a per-user basis, go to aad.portal.azure.com, login as an administrator, click Azure Active Directory – Security – MFA and click on the blue link “Additional cloud-based MFA settings”.
Additional MFA settings
There are two parts (tabs) on this page, “service settings” where you should disable app passwords (a workaround for legacy clients that don’t support MFA, shouldn’t be necessary in 2022), add trusted public IP addresses (so that users aren’t prompted when they’re in the corporate office – we and Microsoft recommend not using this setting), disabling Call and Text message to phone and remember MFA on trusted devices setting (1-365 days), Microsoft recommends either using CA policies to manage Sign-In frequency or setting this to 90 days. Phone call / text message MFA are not strong authentication methods and should not be used unless there’s no other choice.
On the user’s tab you can enable MFA for individual users or click bulk update and upload a CSV file with user accounts.
If you have AAD Premium P1, it’s better to use a CA policy to enforce MFA, it’s more flexible and the MFA settings page will eventually be retired.
Enforcing MFA with a Conditional Access Policy
A few words of caution, enabling MFA for all your administrators is a given today. Seriously, if you aren’t requiring every privileged account to use MFA (or 2FA / passwordless, see below), stop reading and go and do that right now. Yes, it’s an extra step and yes, you’ll get push back but there’s just no excuse – it’s simply unprofessional and you don’t belong in IT if you’re not using it. For what it is worth, I’ve been using Azure MFA for over seven years and require it for administrators at my clients – no exceptions.
Enabling MFA for all users is also incredibly important but takes some planning. You may have some users who refuse to run the Microsoft Authenticator app on their personal phone – ask for it to be put in their hiring contract. You need to train them as to why MFA is being deployed, what to do, both for authentic logins and malicious ones. Furthermore, you need to have a smooth process for enrolling new users and offboarding people who are leaving.
You should also strongly consider creating separate (cloud only) accounts for administrators. They don’t require a license and it separates the day-to-day work of a person who only performs administrative actions in your tenant occasionally (or use PIM, Chapter 10).
MFA protects you against 99.9% of identity-based attacks but it’s not un-phishable. Stronger alternatives include biometrics such as Windows Hello for Business (WHFB) and 2FA hardware keys which bring you closer to the ultimate in identity security: passwordless.
Legacy Authentication
However, it’s not enough to enable MFA for all administrators and users, the bad guys can still get in with no MFA prompt in sight. The reason is that Office 365 still supports legacy protocols that don’t support modern authentication / MFA. You need to disable these; you can’t just turn them off, you need to check if there are legitimate applications / workflows / scripts that use any of them. Go to aad.portal.azure.com, login as a Global Administrator, click Azure Active Directory – Monitoring – Sign-in logs. Change the time to last one month, and click Add filters, then click Client app and then None Selected, in the drop-down pick all 13 checkboxes under Legacy Authentication Clients and click Apply.
Filtering Azure AD Sign-in logs for legacy authentication
This will show you all the logins over the last month that used any of the legacy protocols. If you get a lot of results, add a filter for Status and add Success to filter out password stuffing attacks that failed. Make sure you check the four different tabs for interactive / non-interactive, service principals and managed identity sign-ins.
You’ll now need to investigate the logins. In my experience there will be some users who are using Android / Apple mail on smartphones; point them to the free Outlook app instead (Apple mail can be configured to use modern authentication). There’s also likely to be line-of-business (LOB) applications and printers / scanners that send emails via Office 365, so you’ll need updates for these. Alternatively, you can use another email service for these such as smtp2go.
Once you have eliminated all legitimate legacy authentication protocol usage you can disable it in two ways, it’s best to use both. Start by creating a Conditional Access policy based on the new template to block it, also go to admin.microsoft.com, Settings – Org settings – Services – Modern authentication and turn off basic authentication protocols.
Disable legacy authentication protocols in the M365 Admin Center
Break Glass accounts
Create at least one, preferably two break glass accounts, also known as emergency access accounts. These accounts are exempted from MFA, all CA policies and PIM (see below) and have very long (40 characters+), complex passwords. They’re only used if AAD MFA is down, for example, to gain access to your tenant to temporarily disable MFA or a similar setting, depending on the outage.
A second part to this is that you want to be notified if these accounts are ever used. One way to do this is to send your Azure AD sign-in logs to Azure Monitor (also known as Log Analytics), with instructions here. Another option is to use Microsoft Sentinel (which is built on top of Log Analytics) and create an Analytics rule.
Microsoft Sentinel alert rule when a Break Glass account is used
Security Defaults
If yours is a very small business, with few requirements for flexibility, the easiest way to set up Azure AD with MFA for everyone, plus several other security features enabled, is to turn on Security Defaults. Note that you can’t have break-glass accounts or other service accounts with Security Defaults as there’s no way to configure exceptions. Go to Properties for your Azure AD tenant and scroll to the bottom, and click on Manage Security defaults, here you can enable and disable it.
Privileged Identity Management
It’s worth investing in Azure Active Directory (AAD) Premium P2 for your administrator’s accounts and enabling Privileged Identity Management (PIM). This means their accounts are ordinary user accounts who are eligible to elevate their privileges to whatever administrator type they are assigned (see Chapter 10).
If you’re not using PIM, create dedicated admin accounts in AAD only. Don’t sync these accounts from on-premises but enforce MFA and strong passwords. Since they won’t be used for day-to-day work, they won’t require an M365 license.
Password Protection
After MFA, your second most important step is banning bad passwords. You’re probably aware that we’ve trained users to come up with bad passwords over the last few decades with “standard” policies (at least 8 characters, uppercase, lowercase, special character and numbers) which results in P@ssw0rd1 and when they’re forced to change it every 30 days, P@ssw0rd2. Both NIST in the US and GHCQ in the UK now recommends allowing (but not enforcing) the use of upper / lowercase etc., but not mandating frequent password changes and instead of checking the password at the time of creation against a list of known, common bad passwords and blocking those. In Microsoft’s world that’s called Password protection which is enabled for cloud accounts by default. There’s a global list of about 2000 passwords (and their variants) that Microsoft maintains, based on passwords they find in dumps, and you should add (up to 1000) company-specific words (brands, locations, C-suite people’s names, local sports teams, etc.) for your organization.
You find Password protection in the AAD portal – Security – Authentication Methods.
Password protection settings
Remember, you don’t have to add common passwords to the list, they’re already managed by Microsoft, just add company / region specific words that your staff are likely to use.
If you’re syncing accounts from Active Directory on-premises to AAD, you should also extend Password protection to your DCs. It involves the installation of an agent on each DC, a proxy agent, and a reboot of each DC.
Continuous Access Evaluation
This feature has been in preview for quite some time but is now in general availability. Before Continuous Access Evaluation (CAE), when you disabled a user’s account, or they changed location (from the office to a public Wi-Fi for example) it could be up to one hour before their state was re-evaluated and new policies applied, or they were blocked from accessing services. With CAE, this time is much shorter, in most cases in the order of a few minutes. It’s turned on by default for all tenants (unless you were part of the preview and intentionally disabled it). Another benefit of CAE is that tokens are now valid for 28 hours, letting people keep working during a shorter Azure AD outage. You can disable CAE in a CA policy, but it’s not recommended.
Conditional Access policies
We’ve mentioned Conditional Access (CA) policies several times already as it’s a crucial component of strong identity security and Zero Trust. Unlike other recommendations, there isn’t a one size fit all set of CA policies we can give you, however (at a minimum) you should have policies for:
Require MFA for admins (see MFA above)
Require MFA for users (see MFA above)
Require MFA for Azure management
Block legacy authentication (see MFA above)
Require compliant or Hybrid AAD joined device for admins
Require compliant or Hybrid AAD joined device for users
Block access to M365 from outside your country
Require MFA for risky sign-ins (if you have AAD Premium P2)
Require password change for high-risk users (if you have AAD Premium P2)
This is all going to be a lot easier going forward with the new policy templates for identity and devices. Go to Azure AD – Security – Conditional Access – New policy – Create a new policy from templates. Another step to take is to create a system for managing the lifecycle of policies and there’s an API for backing up and updating policies, that you can access in several ways, including PowerShell. There’s even a tutorial to set up a backup system using a Logic App.
Conditional Access policy templates for identity
A common question is if there’s a priority when policies are evaluated and there isn’t, they’re all processed together for a particular sign-in, from a specific device and location to an individual application. If there are multiple policies with different controls (MFA + compliant device), all controls must be fulfilled for access. And if there are conflicting policies with different access (block vs grant), block access will win.
To get you started, here are the step-by-step instructions for a policy blocking access to M365 from outside your country, appropriate for most small and medium businesses that only operate in one or a few countries. Keep in mind that travelling staff may be caught out by this so make sure you align with business objectives and be aware that this won’t stop every attack as a VPN or TOR exit node can make it appear as if the attacker is in your country, but it’s one extra step they must take. Remember, you don’t have to run faster than the Fancy Bear, just faster than other companies around you.
Start by going to Azure AD – Security – Conditional Access – Named locations and click +Countries location and call the location Blocked countries. Leave Determine location by IP address, a new feature is using GPS location from the Microsoft Authenticator app which will be more accurate once all your users are using Azure AD MFA (and therefore can be located via GPS). Click the box next to Name to select all countries, then find the one(s) that you need to allow login from and click Create.
Creating a Named Location for a Conditional Access Policy
Go to Azure AD – Security – Conditional Access – New policy – Create new policy and name your policy with a name that clearly defines what the policy does and adheres to your naming standard. Click on All Users… and Include All users and Exclude your Break Glass accounts.
Click on No cloud apps… and select All cloud apps. Select 0 conditions… and click Not configured under Locations. Pick Selected locations under Include and select your newly created location. Finally, under Access controls – Grant, click 0 controls selected and then Block access.
CA policies can be either in Report-only mode where you can look at reports of what they would have blocked and control they would have enforced, or they can be turned on / off. Report-only can be handy to make sure you don’t get fired for accidentally locking everyone out but turn this policy on as soon as possible.
Conditional Access policy to block logins from outside Australia
A common question is, how can I control how often users are prompted for MFA or signing in again? While it might be counterintuitive, the default in Azure AD is a rolling windows of 90 days. Remember, if you change a user’s password, block non-compliant devices, or disable an account (plus any number of other CA policies you have in place that might affect the security posture of the session), it’ll automatically require new authentications. Don’t prompt the users for authentication when nothing has changed because if you do it too frequently, they’re more likely to approve a malicious login.
Branding Log-on Pages
While in the Azure AD portal, click on Company branding and add a company-specific Sign-in page background image (1920x1080px) and a Banner logo (280x60px). Note that these files have to be small (300 KB and 10 KB respectively) so you may have to do some fancy compression. This isn’t just a way to make users feel at home when they see a login page, in most cases when attackers send phishing emails to harvest credentials, they’ll send users to a fake login page that looks like the generic Office 365 one, not your custom one which is another clue that should alert your users to the danger. Also – Windows Autopilot doesn’t work unless you have customized AAD branding.
Edit Azure AD Company Branding images
Self Service Password Reset
The benefit of Self Service Password Reset (SSPR) is to lower the load on your help desk to manage password resets for users. Once enabled, users must register various ways of being identified when they’re resetting their password, mobile app notification/code, email (non-Office 365), mobile/office phone call, security questions (not available to administrators, plus you can create custom questions). If you are synchronizing user accounts from AD to Azure AD, take care in setting up SSPR as the passwords must be written back to AD from the cloud once changed.
Configuring Self Service Password Reset in Azure AD
Unified Auditing
Not restricted to security but nevertheless, a fundamental building block is auditing across Microsoft 365. Go to the Microsoft 365 Defender portal and find Audit in the left-hand menu (it’s almost at the end). If for some reason unified auditing isn’t enabled in your tenant a yellow banner will give you a button to turn it on (it’s on by default for new tenants). Once enabled, click the Audit retention policies tab, and create a policy for your tenant. You want to ensure that you have logs to investigate if there’s a breach and you want them kept for as long as possible.
With Business Premium you get a maximum of 90 days of retention and Microsoft 365 E5 gives you one year, but you want to make sure to create a policy to set this, rather than rely on the default policy (which you can’t see). Give the policy a name, a description and add all the record types, one by one. This policy will now apply to all users (including new ones that are created) for all activities. Only use the Users option when you want to have a specific policy for a particular user. Give the policy a priority, 1 is the highest and 10,000 is the lowest.
Create an audit retention policy for maximum retention
Integrating applications into Azure AD
One of the most powerful but often overlooked features (at least in SMBs) is the ability to use Azure AD to publish applications to your users. Users can go to myapps.microsoft.com (or office.com) and see tiles for all applications they have access to. But there’s more to that story. Say, for example, you have a shared, corporate Twitter account that a few executives and marketing staff should have access to. Instead of sharing a password amongst them all and having to remember to reset it if someone leaves the organization, you can create a security group in AAD, add the relevant users, link Twitter to the group and they’ll automatically have access – without knowing the password to the account. There are a lot more actions you can take here to simplify access and secure management of applications, here’s more information.
Azure AD Connect
If you’re synchronizing accounts from Active Directory to Azure Active Directory (AAD), check the configuration of AAD Connect and make sure you’re not replicating an entire domain or forest to AAD. There’s no reason that service accounts etc. should be exposed in both directories, start the AAD Connect wizard on the server where it’s installed and double-check that only relevant OUs are synchronized. One other thing to note here is the fact that any machine running Azure AD Connect should be treated with the same care (in terms of security) as a domain controller. This is because AAD Connect requires the same level of access as AD itself and has the ability to read password hashes. Making sure security best practices for access, patching, etc. are followed to the letter for the system running AAD connect is critically important.
The M365 Identity Checklist
Work through the Identity checklist.
Enable MFA for administrators
Enable MFA for users
Create cloud-only administrator accounts for privileged users / occasional administrators
Disable app passwords
(Configure trusted IPs)
Disable text message MFA
Disable phone call MFA
Remember MFA trusted devices 90 days
Train staff in using MFA correctly
Use Windows Hello where possible
Use FIDO2 / 2FA keys where possible
Investigate legacy authentication protocol usage in AAD Sign-in logs
Block legacy authentication with CA Policy
Block legacy authentication in M365 Admin Center
Create two Break glass accounts and exempt from MFA, CA Policies etc.
Configure alerting if a Break glass account is used
Enable Security Defaults in AAD (consider the limitations)
Enable PIM (AAD Premium P2) for all admin users
Add organization-specific words to Password protection
Deploy Password protection in AD on-premises
CA Policy Require MFA for admins
CA Policy Require MFA for users
CA Policy Require MFA for Azure management
CA Policy Block legacy authentication
CA Policy Require compliant or Hybrid AAD joined device for admins
CA Policy Require compliant or Hybrid AAD joined device for users
CA Policy Block access to M365 from outside your country
Require MFA for risky sign-ins [Only for E5)
Require password change for high-risk users [Only for E5)
Create custom branding logos and text in Azure AD
Enable and configure Self Service Password Reset, including password writeback
Go Further than Identity to Protect your M365 Tenant
There you have it, all the most important steps to take to make sure your users’ identities are kept secure, and therefore your tenant and its data also safeguarded. Keen to learn and do more?
The Microsoft 365 Security Checklist has another nine chapters of security recommendations each with its own checklist for:
The Internet of Things (IoT) is here, and we’re using it for everything from getting instant answers to random trivia questions to screening visitors at the door. According to Gartner, we were expected to use more than 25 billion internet-connected devices by the end of 2021. But as our digital lives have become more convenient, we might not yet have considered the risks involved with using IoT devices.
How can you keep yourself secure in today’s IoT world, where hackers aim to outsmart your smart home? First we’ll look at how hackers infiltrate the IoT, and then we’ll look at what you can do right now to make sure the IoT is working for you – not against you.
How hackers are infiltrating the Internet of Things
While we’ve become comfortable asking voice assistants to give us the weather forecast while we prep our dinners, hackers have been figuring out how to commandeer our IoT devices for cyber attacks. Here are just a few examples of how cyber criminals are already infiltrating the IoT.
Gaining access to and control of your camera
Have you ever seen someone with a sticker covering the camera on their laptop or smartphone? There’s a reason for that. Hackers have been known to gain access to these cameras and spy on people. This has become an even more serious problem in recent years, as people have been relying on videoconferencing to safely connect with friends and family, participate in virtual learning, and attend telehealth appointments during the pandemic. Cameras now often come with an indicator light that lets you know whether they’re being used. It’s a helpful protective measure, but not a failsafe one.
Using voice assistants to obtain sensitive information
According to Statista, 132 million Americans used a digital voice assistant once a month in 2021. Like any IoT gadget, however, they can be vulnerable to attack. According to Ars Technica, academic researchers have discovered that the Amazon Echo can be forced to take commands from itself, which opens the door to major mischief in a smart home. Once an attacker has compromised an Echo, they can use it to unlock doors, make phone calls and unauthorized purchases, and control any smart home appliances that the Echo manages.
Many bad actors prefer the quiet approach, however, slipping in undetected and stealing information. They can piggyback on a voice assistant’s privileged access to a victim’s online accounts or other IoT gadgets and make off with any sensitive information they desire. With the victim being none the wiser, the attackers can use that information to commit identity fraud or stage even more ambitious cyber crimes.
Hacking your network and launching a ransomware attack
Any device that is connected to the internet, whether it’s a smart security system or even a smart fridge, can be used in a cyber attack. Bad actors know that most people aren’t keeping their IoT gadgets’ software up to date in the same way they do their computers and smartphones, so they take advantage of that false sense of security. Once cyber criminals have gained access to an IoT device, they can go after other devices on the same network. (This is because most home networks are designed to trust devices that are already connected to them.) When these malicious actors are ready, they can launch a ransomware attack that brings your entire digital life to a halt – unless you agree to fork over a hefty sum in bitcoin, that is.
Using bots to launch a DDOS attack
Although most people never notice it, hackers can and do infect IoT devices with malware en masse, gaining control over them in the process. Having turned these zombie IoT devices into bots, the hackers then collectively use them to stage what’s called a botnet attack on their target of choice. This form of assault is especially popular for launching distributed denial of service (DDOS) attacks, in which all the bots in a botnet collectively flood a target with network requests until it buckles and goes offline.
How you can keep your Internet of Things gadgets safe from hackers
So how can you protect your IoT devices from these determined hackers? Fortunately, you can take back control by becoming just a little more cyber smart. Here are a few ways to keep your IoT gadgets safe from hackers:
Never use the default settings on your IoT devices. Although IoT devices are designed to be plug-and-play so you can start enjoying them right away, their default settings are often not nearly as secure as they should be. With that in mind, set up a unique username and strong password combination before you start using any new IoT technology. While you’re at it, see if there’s an option to encrypt the traffic to and from your IoT device. If there is, turn it on.
Keep your IoT software up to date. Chances are, you regularly install the latest software updates on your computer and phone. Hackers are counting on you to leave your IoT gadgets unpatched, running outdated software with vulnerabilities they can exploit, so be sure to keep the software on your IoT devices up to date as well.
Practice good password hygiene. We all slip into bad password habits from time to time – it’s only human – but they put our IoT security at risk. With this in mind, avoid re-using passwords and be sure to set unique, strong passwords on each of your IoT devices. Update those passwords from time to time, too. Don’t store your passwords in a browser, and don’t share them via email. A password manager can help you securely store and share your passwords, so hackers never have a chance to snatch them.
Use secure, password-protected WiFi. Cyber criminals are notorious for sneaking onto open, insecure WiFi networks. Once they’re connected, they can spy on any internet activity that happens over those networks, steal login credentials, and launch cyber attacks if they feel like it. For this reason, make sure that you and your IoT devices only use secure, password-protected WiFi.
Use multi-factor authentication as an extra layer of protection. Multi-factor authentication (MFA), gives you extra security on top of all the other measures we mentioned above. It asks you to provide one more credential, or factor, in addition to a password to confirm you are who you say you are. If you have MFA enabled and a hacker tries to log in as you, you’ll get a notification that a login attempt is in progress. Whenever you have the option to enable MFA on any account or technology, take advantage of it.
Protect your Internet of Things devices with smart password security
The IoT is making our lives incredibly convenient, but that convenience can be a little too seductive at times. It’s easy to forget that smart home devices, harmless-looking and helpful as they are, can be targeted in cyber attacks just like our computers and phones. Hackers are counting on you to leave your IoT gadgets unprotected so they can use them to launch damaging attacks. By following these smart IoT security tips, you can have the best of both worlds, enjoying your smart life and better peace of mind at the same time.
Learn how LastPass Premium helps you strengthen your password security.
QR codes link the offline to the online. What started as a way to streamline manufacturing in the automotive industry is now a widespread technology helping connect the physical world to digital content. And as the world embraced remote, no-touch solutions during the Covid pandemic, QR codes became especially popular. QR codes offer convenience and immediacy for businesses and consumers, but cybercriminals also take advantage of them. Here’s what you need to know about QR codes and how to stay safe when using them.
Why QR codes?
Due to their size and structure, the two-dimensional black and white barcodes we call QR codes are very versatile. And since most people carry a smartphone everywhere, they can quickly scan QR codes with their phone’s camera. Moreover, since QR codes are relatively easy to program and accessible for most smartphone users, they can be an effective communication tool.
They also have many uses. For example, QR codes may link to a webpage, start an app or file download, share contact information, initiate a payment, and more. Covid forced businesses to be creative with touchless experiences, and QR codes provide a convenient way to transform a physical touchpoint into a digital interaction. During Covid, QR codes became a popular way to look at restaurant menus, communicate Covid policies, check in for an appointment, and view marketing promotions, among other scenarios.
As a communication tool, QR codes can transmit a lot of information from one person to another, making it easy for someone to take action online and interact further with digital content.
What hackers do with QR codes
QR codes are inherently secure, and no personally identifiable information (PII) is transmitted while you’re scanning them. However, the tricky part about QR codes is that you don’t know what information they contain until you scan them. So just looking at the QR code won’t tell you if it’s entirely trustworthy or not.
For example, cybercriminals may try to replace or sticker over a QR code in a high-traffic, public place. Doing so can trick people into scanning a malicious QR code. Or, hackers might send malicious QR codes digitally by email, text, or social media. The QR code scam might target a specific individual, or cybercriminals may design it to attract as many scans as possible from a large number of people.
Once scanned, a malicious QR code may take you to a phishing website, lead you to install malware on your device, redirect a payment to the wrong account, or otherwise compromise the security of your private information.
In the same way that cybercriminals try to get victims to click phishing links in email or social media, they lure people into scanning a QR code. These bad actors may be after account credentials, financial information, PII, or even company information. With that information, they can steal your identity or money or even break into your employer’s network for more valuable information (in other words, causing a data breach).
Pay attention to context. Where is the code available? What does the code claim to do (e.g., will it send you to a landing page)? Is there someone you can ask to confirm the purpose of the QR code? Did someone send it unprompted? Is it from a business or individual you’ve never heard of? Just like with phishing links, throw it out when in doubt.
Look closely at the code. Some codes may have specific colors or branding to indicate the code’s purpose and destination. Many codes are generic black and white designs, but sometimes there are clues about who made the code.
Check the link before you click. If you scan the QR code and a link appears, double-check it before clicking. Is it a website URL you were expecting? Is it a shortened link that masks the full URL? Is the webpage secure (HTTPS)? Do you see signs of a phishing attack (branding is slightly off, strange URL, misspelled words, etc.)? If it autogenerates an email or text message, who is the recipient and what information is it sending them? If it’s a payment form, who is receiving the payment? Read carefully before taking action.
Practice password security. Passwords and account logins remain one of the top targets of cyber attacks. Stolen credentials give cybercriminals access to valuable personal and financial information. Generate every password for every account with a random password generator, ideally built into a password manager for secure storage and autofill. Following password best practices ensures one stolen password results in minimal damage.
Layer with MFA. Adding multi-factor authentication to logins further protects against phishing attacks that steal passwords. With MFA in place, a hacker still can’t access an account after using a stolen password. By requiring additional login data, MFA can prevent cybercriminals from gaining access to personal or business accounts.
QR codes remain a popular marketing and communication tool. They’re convenient and accessible, so you can expect to encounter them occasionally. Though cyber attacks via QR codes are less common, you should still stay vigilant for signs of phishing and social engineering via QR codes. To prevent and mitigate attacks via QR codes, start by building a solid foundation of digital security with a trusted password manager.
With its new SonicWave 641 and SonicWave 681 access points, SonicWall has combined the security and performance benefits of Wi-Fi 6 with our simplified management and industry-leading TCO.
Organizations are evolving — some more quickly, others more reluctantly. But over the past three years, the pace of change for everyone has accelerated to hyperspeed.
In early 2020, very few people could have foreseen the changes that were about to be unleashed on the world. And even fewer could have successfully predicted the long-term impact that COVID-19 would have on the way the world’s eight billion people live and work.
Prior to the pandemic, only about 2% of employees worked remotely. By May 2020, that number had risen to 70%, according to the Society for Human Resource Management. This pivot was possible because organizations were able to adjust their infrastructure to meet new working demands — and wireless technology played an important part in this solution.
The importance of wireless technology goes far beyond simply enabling employees to work remotely. According to a study, 87% of organizations believe that adopting advanced wireless capabilities can be a competitive advantage, because it allows them to innovate and increase agility. And 86% of networking executives believe advanced wireless will soon transform their organization.
But wireless technology impacts more than just how we work: It has changed the way we shop, watch movies, listen to music, navigate in our cars, or spend time with family and friends (some of whom may be a half a world away). And every one of us expects a good experience every single time we use wireless. That’s a tall order, especially given the sheer number of existing devices and the ever-growing amount of bandwidth being consumed.
The need for high-performing, secure wireless technology has never been greater — and Wi-Fi 6 is a massive next step toward this reality. SonicWall’s SonicWave 641 and SonicWave 681 access points provide the combination of performance and security that we all demand.
What is Wi-Fi 6?
Wi-Fi 6, also known as 802.11ax, is the successor to 802.11ac Wave 2, or Wi-Fi 5. While the primary goal of Wi-Fi 6 is to enhance throughput in complex environments, there are additional benefits:
OFDMA’s multi-user support can make Wi-Fi 6 access points more efficient than Wi-Fi 5’s single-user OFDM. This results in lower latency.
Wi-Fi 6 utilizes WPA3, which provides advanced security features to enable more robust authentication.
BSS coloring marks traffic on a shared frequency to determine if it can be used. The result is less interference and more consistent service in complex environments.
Target Wake Time (TWT) allows devices to determine how often to wake to send or receive data, improving battery life.
Wi-Fi 6’s multi-user, multiple input, multiple output (or MU-MIMO) supports multiple users within a single network environment. This allows multiple users to upload and download data at the same time, resulting in less wait time and faster network speed.
Some of these features are designed to improve performance, while some are designed to improve security. Any one of them can make a positive difference in an organization’s wireless network. Combined, however, the feature improvements provided by Wi-Fi 6 can create a significant wireless network advancement for any organization.
SonicWave 641 and SonicWave 681
SonicWall’s SonicWave 641 and SonicWave 681 are Wi-Fi 6 access points that deliver wireless performance and security that are superior to the 802.11ac standard.
But there are additional benefits available with the SonicWave 641 and SonicWave 681, such as SonicWall Capture Security Center, a scalable cloud security management system that helps you control assets and defend your entire network against cyberattacks.
SonicWave 600 series APs also integrate with Wireless Network Manager, an intuitive centralized network management system that leverages the cloud to make it easy to manage complex wireless and security environments with a single-pane-of-glass management portal.
WiFi Planner is a site-survey tool that allows you to optimally design and deploy a wireless network to get maximum coverage with the fewest number of APs, resulting in a lower TCO.
And the SonicExpress mobile app allows you to easily register and use the Wireless Network Manager to set up, manage and monitor SonicWall wireless appliances.
A strong wireless network is not a “nice to have” — it’s a necessity. What today’s organizations require is the high performance and security of the SonicWave 641 and SonicWave 681 access points.
To learn more about the SonicWave 641 and SonicWave 681 access points, as well as SonicWall’s entire wireless portfolio, visit www.sonicwall.com/wireless.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Monday added a security flaw impacting Palo Alto Networks PAN-OS to its Known Exploited Vulnerabilities Catalog, based on evidence of active exploitation.
The high-severity vulnerability, tracked as CVE-2022-0028 (CVSS score: 8.6), is a URL filtering policy misconfiguration that could allow an unauthenticated, remote attacker to carry out reflected and amplified TCP denial-of-service (DoS) attacks.
“If exploited, this issue would not impact the confidentiality, integrity, or availability of our products,” Palo Alto Networks said in an alert. “However, the resulting denial-of-service (DoS) attack may help obfuscate the identity of the attacker and implicate the firewall as the source of the attack.
The weakness impacts the following product versions and has been addressed as part of updates released this month –
PAN-OS 10.2 (version < 10.2.2-h2)
PAN-OS 10.1 (version < 10.1.6-h6)
PAN-OS 10.0 (version < 10.0.11-h1)
PAN-OS 9.1 (version < 9.1.14-h4)
PAN-OS 9.0 (version < 9.0.16-h3), and
PAN-OS 8.1 (version < 8.1.23-h1)
The networking equipment maker said it discovered the vulnerability after being notified that susceptible firewall appliances from different vendors, including Palo Alto Networks, were being used as part of an attempted reflected denial-of-service (RDoS) attack.
In light of active exploitation, customers of affected products are advised to apply the relevant patches to mitigate potential threats. Federal Civilian Executive Branch (FCEB) agencies are mandated to update to the latest version by September 12, 2022.
Before COVID-19, most corporate employees worked in offices, using computers connected to the internal network. Once users connected to these internal networks, they typically had access to all the data and applications without many restrictions. Network architects designed flat internal networks where the devices in the network connected with each other directly or through a router or a switch.
But while flat networks are fast to implement and have fewer bottlenecks, they’re extremely vulnerable — once compromised, attackers are free to move laterally across the internal network.
Designing flat networks at a time when all the trusted users were on the internal networks might have been simpler and more efficient. But times have changed: Today, 55% of those surveyed say they work more hours remotely than at the physical office. Due to the rapid evolution of the way we work, corporations must now contend with:
Multiple network perimeters at headquarters, in remote offices and in the cloud
Applications and data scattered across different cloud platforms and data centers
Users who expect the same level of access to internal networks while working remotely
While this is a complex set of issues, there is a solution. Network segmentation, when implemented properly, can unflatten the network, allowing security admins to compartmentalize internal networks and provide granular user access.
What is network segmentation?
The National Institute of Standards and Technology (NIST) offers the following definition for network segmentation: “Splitting a network into sub-networks; for example, by creating separate areas on the network which are protected by firewalls configured to reject unnecessary traffic. Network segmentation minimizes the harm of malware and other threats by isolating it to a limited part of the network.”
The main principle of segmentation is making sure that each segment is protected from the other, so that if a breach does occur, it is limited to only a portion of the network. Segmentation should be applied to all entities in the IT environment, including users, workloads, physical servers, virtual machines, containers, network devices and endpoints.
Connections between these entities should be allowed only after their identities have been verified and proper access rights have been established. The approach of segmenting with granular and dynamic access is also known as Zero Trust Network Access (ZTNA).
As shown in Figure 1, instead of a network with a single perimeter, inside which entities across the network are freely accessible, a segmented network environment features smaller network zones with firewalls separating them.
Achieving network segmentation
Implementing segmentation may seem complex, and figuring out the right place to start might seem intimidating. But by following these steps, it can be achieved rather painlessly.
1. Understand and Visualize
Network admins need to map all the subnets and virtual local area networks (VLANs) on the corporate networks. Visualizing the current environment provides a lot of value right away in understanding both how to and what to segment.
At this step, network and security teams also need to work together to see where security devices such as firewalls, IPS and network access controls are deployed in the corporate network. An accurate map of the network and a complete inventory of security systems will help tremendously in creating efficient segments.
2. Segment and Create Policies
The next step in the process is to create the segments themselves: Large subnets or zones should be segmented, monitored and protected with granular access policies. Segments can be configured based on a variety of categories, including geo-location, corporate departments, server farms, data centers and cloud platforms.
After defining segments, create security policies and access-control rules between those segments. These polices can be created and managed using firewalls, VLANs or secure mobile access devices. In most cases, security admins can simply use existing firewalls or secure mobile access solutions to segment and create granular policies. It’s best for administrators to ensure that segments and policies are aligned with business processes.
3. Monitor and Enforce Policies
After creating segments and policies, take some time to monitor the traffic patterns between those segments. The first time the security policies are enforced, it may cause disruption to regular business functions. So it’s best to apply policies in non-blocking or alert mode and monitor for false positives or other network errors.
Next, it’s the time to enforce policies. Once the individual policies are pushed, each segment is protected from cyber attackers’ lateral movements and from internal users trying to reach resources they are not authorized to use. It’s a good idea to continuously monitor and apply new policies as needed whenever there are changes to networks, applications or user roles.
Policy-based segmentation: A way forward for distributed networks
What today’s enterprises require is a way to deliver granular policy enforcement to multiple segments within the network. Through segmentation, companies can protect critical digital assets against any lateral attacks and provide secure access to remote workforces.
The good news is that, with the power and flexibility of a next-generation firewall (NGFW) and with other technologies such as secure mobile access and ZTNA solutions, enterprises can safeguard today’s distributed networks by enforcing policy-based segmentation.
SonicWall’s award-winning hardware and advanced technologies include NGFWs, Secure Mobile Access and Cloud Edge Secure Access. These solutions are designed to allow any network— from small businesses to large enterprises, from the datacenter to the cloud — to segment and achieve greater protection with SonicWall.
