After reading this article users should gain the knowledge to be able to configure and maintain the IPS/IDS functionality on their UniFi networks.
NOTES & REQUIREMENTS:
Some IPS/IDS features that are shown in this article are features included in Early Access versions of the UniFi Controller. Ubiquiti Support cannot assist with questions relating to those features until a stable version of the controller has been released.
Devices used in this article:
Table of Contents
- Network Diagram
- How to Configure IPS/IDS in the UniFi Controller
- Testing & Verification
- Privacy Statement
- Related Articles
What is an intrusion prevention system?
An intrusion prevention system (IPS) is an engine that identifies potentially malicious traffic based on signatures. The signatures contain known traffic patterns or instruction sequences used by malware. This type of signature-based engine can only detect anomalies based on known malicious traffic patterns.
How to Configure IPS/IDS in the UniFi Controller
To enable intrusion detection or intrusion prevention navigate to the Settings > IPS section of the UniFi Controller.
*Values are rough estimates and can vary depending on configuration.
- Disabled: Disables both the detection and prevention systems.
- IDS: When set will automatically detect, and alert, but will not block potentially malicious traffic.
- IPS: When set will automatically detect, alert, and block potentially malicious traffic.
- Restrict Access to Tor: When enabled will block access to The Onion Router.
- Restrict Access to Malicious IP Addresses: When enabled will block access to IP addresses or blocks of addresses that have been recognized as passing malicious traffic.
Categories and Their Definitions
Click Here to Expand the IPS/IDS Categories Section
- Activex: Attacks and vulnerabilities(CVE, etc.) regarding ActiveX.
- Attack Response: Responses indicative of intrusion—LMHost file download, certain banners, Metasploit Meterpreter kill command detected, etc. These are designed to catch the results of a successful attack. Things like "id=root", or error messages that indicate a compromise may have happened.
- Botcc (Bot Command and Control)*: These are autogenerated from several sources of known and confirmed active Botnet and other Command and Control hosts. Updated daily, primary data source is Shadowserver.org. Bot command and control block rules generated from shadowserver.org, as well as spyeyetracker, palevotracker, and zeustracker. Port grouped rules offer higher fidelity with destination port modified in rule.
- Chat: Identification of traffic related to numerous chat clients, IRC, and possible check-in activity.
- CIArmy: Collective Intelligence generated IP rules for blocking based upon www.cinsscore.com.
- Compromised: This is a list of known compromised hosts, confirmed and updated daily as well. This set varied from a hundred to several hundred rules depending on the data sources. This is a compilation of several private but highly reliable data sources. Warming: Snort does not handle IP matches well load-wise. If your sensor is already pushed to the limits this set will add significant load. We recommend staying with just the Botcc rules in a high load case.
- DNS*: Rules for attacks and vulnerabilities regarding DNS. Also the category for abuse of the service for things such as tunneling.
- DOS: Denial of Service attempt detection. Intended to catch inbound DOS activity and outbound indications.
- Dshield*: IP based rules for Dshield Identified attackers. Daily updated list of the DShield top attackers list. Also very reliable. More information can be found at http://www.dshield.org.
- Exploit*: Exploits that are not covered in a specific service category. Rules to detect direct exploits. Generally, if you're looking for a Windows exploit, Veritas, etc, they'll be here. Things like SQL injection and the like, while they are exploits, have their own category.
- FTP: Rules for attacks, exploits, and vulnerabilities regarding FTP. Also includes basic none malicious FTP activity for logging purposes, such as login, etc.
- Games: Rules for the Identification of gaming traffic and attacks against those games. World of Warcraft, Starcraft, and other popular online games have sigs here. We don't intend to label these things evil, just that they're not appropriate for all environments.
- ICMP: Rules for attacks and vulnerabilities regarding ICMP. Also included are rules detecting the basic activity of the protocol for logging purposes.
- ICMP Info: Rules to log ICMP protocol specific events, typically normal operation.
- IMAP: Rules for the identification, as well as attacks and vulnerabilities regarding the IMAP protocol. Also included are rules detecting the basic activity of the protocol for logging purposes.
- Inappropriate: Rules for the identification of pornography related activity. Includes Porn, sites you shouldn't visit at work, etc. Warning: These are generally quite Regex heavy and thus high load and frequent false positives. Only run these if you're really interested.
- Malware*: Malware and Spyware related, no clear criminal intent. The threshold for inclusion in this set is typically some form of tracking that stops short of obvious criminal activity. This set was originally intended to be just spyware. That's enough to several rule categories really. The line between spyware and outright malicious bad stuff has blurred too much since we originally started this set. There is more than just spyware in here, but rest assured nothing in here is something you want running on your net or PC. There are URL hooks for known update schemed, User-Agent strings of known malware, and a load of others.
- Misc.: Miscellaneous rules for those rules not covered in other categories.
- Mobile Malware*: Specific to mobile platforms: Malware and Spyware related, no clear criminal intent.
- Netbios: Rules for the identification, as well as attacks, exploits, and vulnerabilities regarding Netbios. Also included are rules detecting the basic activity of the protocol for logging purposes.
- P2P*: Rules for the identification of Peer-to-Peer traffic and attacks against. Including torrents, edonkey, Bittorrent, Gnutella, Limewire, etc. We're not labeling these things malicious, just not appropriate for all networks and environments.
- Policy: Application Identification category. Includes signatures for applications like DropBox and Google Apps, etc. Also covers off port protocols, basic DLP such as credit card numbers and social security numbers. Included in this set are rules for things that are often disallowed by a company or organizational policy. Myspace, Ebay, etc.
- POP3: Rules for the identification, as well as attacks and vulnerabilities regarding the POP3 protocol. Also included are rules detecting the basic activity of the protocol for logging purposes.
- RPC: RPC related attacks, vulnerabilities, and protocol detection. Also included are rules detecting the basic activity of the protocol for logging purposes.
- SCADA: Signatures for SCADA attacks, exploits and vulnerabilities, as well as protocol detection.
- Scan: Things to detect reconnaissance and probing. Nessus, Nikto, portscanning, etc. Early warning stuff.
- Shellcode*: Remote Shellcode detection. Remote shellcode is used when an attacker wants to target a vulnerable process running on another machine on a local network or intranet. If successfully executed, the shellcode can provide the attacker access to the target machine across the network. Remote shellcodes normally use standard TCP/IP socket connections to allow the attacker access to the shell on the target machine. Such shellcode can be categorized based on how this connection is set up: if the shellcode can establish this connection, it is called a "reverse shell" or a connect-back shellcode because the shellcode connects back to the attacker's machine.
- SMTP: Rules for attacks, exploits, and vulnerabilities regarding SMTP. Also included are rules detecting the basic activity of the protocol for logging purposes.
- SNMP: Rules for attacks, exploits, and vulnerabilities regarding SNMP. Also included are rules detecting the basic activity of the protocol for logging purposes.
- SpamHaus*: This ruleset takes a daily list of known spammers and spam networks as researched by Spamhaus.
- SQL: Rules for attacks, exploits, and vulnerabilities regarding SQL. Also included are rules detecting the basic activity of the protocol for logging purposes.
- TELNET: Rules for attacks and vulnerabilities regarding the TELNET service. Also included are rules detecting the basic activity of the protocol for logging purposes.
- TFTP: Rules for attacks and vulnerabilities regarding the TFTP service. Also included are rules detecting the basic activity of the protocol for logging purposes.
- TOR*: IP Based rules for the identification of traffic to and from TOR exit nodes.
- Trojan: Malicious software that has clear criminal intent. Rules here detect malicious software that is in transit, active, infecting, attacking, updating, and whatever else we can detect on the wire. This is also a highly important ruleset to run if you have to choose.
- User Agents*: User agent identification and detection.
- VOIP: Rules for attacks and vulnerabilities regarding the VOIP environment. SIP, h.323, RTP, etc.
- Web Client: Web client-side attacks and vulnerabilities.
- Web Server: Rules for attacks and vulnerabilities against web servers.
- Web Apps: Rules for very specific web applications.
- WORM*: Traffic indicative of network-based worm activity
* Identifies categories that can be enabled on the USG3.
The link to the PDF where these categories are described can be found here.
The whitelisting function of the IPS engine allows a UniFi Administrator to create a list of trusted IP's. The traffic, depending on the direction selected, will not get blocked to or from the identified IPs.
In the screenshot below traffic to or from the subnet 100.64.0.0/16 will not be tracked by the IPS engine.
The signature suppression function of the IPS engine allows a UniFi Administrator to mute the alerting on certain signatures. This will also disable blocking on traffic matching the designated suppression rule.
- Adding a signature suppression rule for all traffic will suppress the signature regardless of host IP.
- Adding a signature suppression rule with packet tracking based on traffic direction and by single IP, defined UniFi Network, or subnet of choice.
How to Read the Controller Alert
This is an example of a controller alert that a UniFi Administrator may see in their "Alerts" section.
Breaking Down the Alert
- What was detected: A network trojan
- Which signature detected the anomaly: Emerging Threats (ET) User Agents
- Why: Suspicious user agent called "BlackSun".
- Source: A host with the IP 192.168.5.43
- Destination: A host with the IP 126.96.36.199 on TCP port 80
NOTE: This alert was generated with the method found in Testing & Verification.
Intrusion Prevention Dashboard
The overview section of the IPS dashboard shows a quick glance at IPS/IDS events. Timeframe filtering can be adjusted in the top right of the page.
The map is populated with IPS events. The geo-location of the start and end points are approximate and may not represent the city locale.
The traffic log section of the IPS dashboard allows UniFi Administrators to be able to see a historical table listing out previous IDS/IPS alerts.
By clicking on an individual event record a threat detail popup is triggered. In this view, all of the information about the event is listed along with the ability to define actions based on this event.
- Suppress signature: The signature suppression function of the IPS engine allows a UniFi Administrator to mute the alerting on certain signatures. This will also disable blocking on traffic matching the designated suppression rule.
- Block: This option blocks traffic between the two hosts that were at fault in the IPS/IDS event. This blocking can be undone by going to the WAN_IN firewall section. Settings > Firewall and Routing > Firewall > WAN_IN.
- Blacklist IP: This option will blacklist the source IP listed in the event.
- Whitelist IP: This option will whitelist the source IP listed in the event. A similar popup to what is seen in Settings > IPS is triggered in this option.
Testing & Verification
Linux or macOS
curl -A "BlackSun" www.google.com
IPS Alert 1: A Network Trojan was Detected. Signature ET USER_AGENTS Suspicious User Agent (BlackSun). From: 192.168.5.43:58343, to:188.8.131.52:80, protocol: TCP
The DNS category must be enabled
nslookup @184.108.40.206 blacklistthisdomain.com
IPS Alert 1: A Network Trojan was Detected. Signature ET DNS Reply Sinkhole - 220.127.116.11 blacklistthisdomain.com. From: 192.168.5.1:53, to: 192.168.5.3:64231, protocol: UDP
What information does the IPS/IDS engine send to the cloud?
1. When a UniFi Administrator enables IPS or IDS on the controller and encrypted token is generated for the UniFi Security Gateway (USG) on the site. The information listed below is sent over a TLS 1.2 encrypted connection whenever there is an IPS/IDS signature match.
2. Every 120-seconds there is a keepalive to the ips1.unifi-ai.com hostname. This connection is to ensure reliable delivery of the violation message. The keepalive is a connection to our cloud using port 443 so it is not just an ICMP ping or DNS resolution but a complete 3-way handshake, and SSL Key exchange to make sure the cloud is working and can receive alerts.
What information is kept on our servers regarding IPS/IDS?
Data is only stored into IPS Cloud until the controller downloads the information. After that data is deleted from our cloud. The only information retained that pertains to the IPS/IDS violation is the attacker IP. This attacker IP information helps Ubiquiti retain an up to date and effective list that benefits USG users around the world.