Features
This Section will contain a list of all features and detections listed in the flowalerts section and the detection modules section and a brief description of how slips works.
Flow Alerts Module
The module of flow alerts has several behavioral techniques to detect attacks by analyzing the content of each flow alone.
The detection techniques are:
Long connections
Successful SSH connections
Connections without DNS resolution
DNS resolutions to IPs that were never used
Connections to unknown ports
Data exfiltration
Malicious JA3 hashes
Connections to port 0
Multiple reconnection attempts
Alerts from Zeek: Self-signed certs, invalid certs, port-scans and address scans, and password guessing
DGA
Connection to multiple ports
Malicious SSL certificates
Young domains
Bad SMTP logins
SMTP login bruteforce
DNS ARPA Scans
Multiple SSH versions
Incompatible CN
Weird HTTP methods
Non-SSL connections on port 443
Non-HTTP connections on port 80
Connection to private IPs
Connection to private IPs outside the current local network
High entropy DNS TXT answers
Devices changeing IPs
SSH version changing
The details of each detection follows.
Long Connections
Detect connections that are long, except the multicast connections.
By defualt, A connection in considered long if it exceeds 1500 seconds (25 Minutes).
This threshold can be changed config/slips.conf
by changing the value of long_connection_threshold
Incompatible CN
Zeek logs each Certificate CN in ssl.log
When slips enccounters a cn that claims to belong to any of Slips supported orgs (Google, Microsoft, Apple or Twitter) Slips checks if the destination address or the destination server name belongs to these org.
If not, slips generates an alert.
High entropy DNS TXT answers
Slips check every DNS answer with TXT record for high entropy strings. Encoded or encrypted strings with entropy higher than or equal 5 will then be detected using shannon entropy and alerted by slips.
the entropy threshold can be changed in slips.conf by changing the value of entropy_threshold
Devices changing IPs
Slips stores the MAC of each new IP it sees in conn.log.
Then for every source address in conn.log, slips checks if the MAC of it was used by another IP.
If so, it alerts “Device changing IPs”.
SMTP login bruteforce
Slips alerts when 3+ invalid SMTP login attempts occurs within 10s
Connection to private IPs
Slips detects when a private IP is connected to another private IP with threat level info.
But it skips this alert when it’s a DNS connection on port 53 UDP to the gateway
Connection to private IPs outside the current local network
Slips detects the currently used local network and alerts if it find a connection to/from a private IP that doesn’t belong to it.
For example if the currently used local network is: 192.168.1.0/24
and slips sees a forged packet going from 192.168.1.2 to 10.0.0.1, it will alert
Weird HTTP methods
Slips uses zeek’s weird.log where zeek logs weird HTTP methods seen in http.log
When there’s a weird HTTP method, slips detects it as well.
Non-SSL connections on port 443
Slips detects established connections on port 443 that are not using HTTP using zeek’s conn.log flows
if slips finds a flow using destination port 443 and the ‘service’ field in conn.log isn’t set to ‘ssl’, it alerts
Non-HTTP connections on port 80.
Slips detects established connections on port 80 that are not using SSL using zeek’s conn.log flows
if slips finds a flow using destination port 80 and the ‘service’ field in conn.log isn’t set to ‘http’, it alerts
Connections without DNS resolution
This will detect connections done without a previous DNS resolution. The idea is that a connection without a DNS resolution is slightly suspicious.
If Slips runs by capturing packets directly from a network device (as opposed to, for example, a PCAP file), this detection will ignore all connections that happen in the first 3 minute of operation of Slips. This is because most times Slips is started when the computer is already running, and many DNS connections were already done. So waiting 3 minutes decreases the amount of False Positives.
This detection will ignore certain IP addresses for which a connection without DNS is ok. The exceptions are:
Private IPs
Localhost IPs (127.0.0.0/8)
Reserved IPs (including the super broadcast 255.255.255.255)
IPv6 local-link IPs
Multicast IPs
Broadcast IPs only if they are private
Well known organizations
DNS resolutions of well known orgs might be done using DoH, in this case, slips doesn’t know about the DNS resolution because the resolved domain won’t be in dns.log so we simply ignore alerts of this time about well known org such as (facebook, apple, google, twitter, and microsoft)
Slips uses it’s own lists of organizations info (IPs, IP ranges, domains, and ASNs) stored in slips_files/organizations_info
to check
whether the IP/domain of each flow belong to a known org or not.
Slips doesn’t detect ‘connection without DNS’ when running on an interface except for when it’s done by this instance’s own IP.
check DoH section of the docs for info on how slips detects DoH.
Successful SSH connections
Slips detects successful SSH connections using 2 ways
Using Zeek. Zeek logs successful SSH connection to ssh.log by default
if all bytes sent in a SSH connection is more than 4290 bytes
DNS resolutions without a connection
This will detect DNS resolutions for which no further connection was done. A resolution without a usage is slightly suspicious.
The domains that are excepted are:
All reverse DNS resolutions using the in-addr.arpa domain.
All .local domains
The wild card domain *
Subdomains of cymru.com, since it is used by the ipwhois library to get the ASN of an IP and its range.
Ignore WPAD domain from Windows
Ignore domains without a TLD such as the Chrome test domains.
Connection to unknown ports
Slips has a list of known ports located in slips_files/ports_info/ports_used_by_specific_orgs.csv
It also has a list of ports that belong to a specific organization in slips_files/ports_info/ports_used_by_specific_orgs.csv
For example, even though 5223/TCP isn’t a well known port, Apple uses it in Apple Push Notification Service (APNS).
Any port that isn’t in the above 2 files is considered unknown to Slips.
Example of Spyware that uses custom ports are hermit using ports 58442/TCP and 8442/TCP.
Data exfiltration
Slips generate a ‘possible data exfiltration alerts when the number of uploaded files to any IP exceeds 700 MBs.
The number of MBs can be modified by editting the value of data_exfiltration_threshold
in config/slips.conf
Malicious JA3 and JA3s hashes
Slips uses JA3 hashes to detect C&C servers (JA3s) and infected clients (JA3)
Slips is shipped with it’s own zeek scripts that add JA3 and JA3s fingerprints to the SSL log files generated by zeek.
Slips supports JA3 feeds in addition to having more than 40 different threat intelligence feeds.
The JA3 feeds contain JA3 fingerprints that are identified as malicious.
The JA3 threat intelligence feed used by Slips now is Abuse.ch JA3 feed.
And you can add other JA3 TI feeds in ja3_feeds
in config/slips.conf
.
Connections to port 0
There has been a significant rise in the number of attacks listed as Port 0. Last year, these equated to 10% of all attacks, but now it’s up to almost 25%.
Slips detects any connection to port 0 using any protocol other than ‘IGMP’ and ‘ICMP’ as malicious.
Multiple reconnection attempts
Multiple reconnection attempts in Slips are 5 or more not established flows (reconnections) to the same destination IP.
Zeek alerts
By default, Slips depends on Zeek for detecting different behaviours, for example Self-signed certs, invalid certs, port-scans and address scans, and password guessing.
Some scans are also detected by Slips independently of Zeek, like ICMP sweeps and vertical/horizontal portscans. Check section for more info #todo
DGA
When the DNS server fails to resolve a domain, it responds back with NXDOMAIN code.
To detect DGA, Slips will count the amount of NXDOMAINs met in the DNS traffic of each source IP.
Then we alert when there is 10 or more NXDOMAINs.
Every 10,15,20 ..etc slips generates an evidence.
Connection to multiple ports
When Slips encounters a connection to or from a specific IP and a specific port, it scans previous connections looking for connection to/from that same IP using a different port.
It alerts when finding two or more connections to the same IP.
Malicious SSL certificates
Slips uses SSL certificates sha1 hashes to detect C&C servers.
Slips supports SSL feeds and is shipped with Abuse.ch feed of malicious SSL hashes by default.
And you can add other SSL feeds in ssl_feeds
in config/slips.conf
.
Young Domains
Slips uses whois python library to get the creation date of every domain met in the dns flows.
If a domain’s age is less than 60 days, slips sets an alert.
Not all domains are supported, here’s the list of supported TLDs.
['.ac_uk', '.am', '.amsterdam', '.ar', '.at', '.au',
'.bank', '.be', '.biz', '.br', '.by', '.ca', '.cc',
'.cl', '.club', '.cn', '.co', '.co_il', '.co_jp', '.com',
'.com_au', '.com_tr', '.cr', '.cz', '.de', '.download', '.edu',
'.education', '.eu', '.fi', '.fm', '.fr', '.frl', '.game', '.global_',
'.hk', '.id_', '.ie', '.im', '.in_', '.info', '.ink', '.io',
'.ir', '.is_', '.it', '.jp', '.kr', '.kz', '.link', '.lt', '.lv',
'.me', '.mobi', '.mu', '.mx', '.name', '.net', '.ninja',
'.nl', '.nu', '.nyc', '.nz', '.online', '.org', '.pe',
'.pharmacy', '.pl', '.press', '.pro', '.pt', '.pub', '.pw',
'.rest', '.ru', '.ru_rf', '.rw', '.sale', '.se', '.security',
'.sh', '.site', '.space', '.store', '.tech', '.tel', '.theatre',
'.tickets', '.trade', '.tv', '.ua', '.uk', '.us', '.uz', '.video',
'.website', '.wiki', '.work', '.xyz', '.za']
Bad SMTP logins
Slips uses zeek to detect SMTP connections, When zeek detects a bad smtp login, it logs it to smtp.log, then slips reads this file and sets an evidence.
SMTP bruteforce
Slips detects a SMTP bruteforce when 3 or more bad SMTP logins happen within 10 seconds.
With every generated evidence, Slips gathers as much info about the malicious IP and prints it with the alert.
So instead of having an alerts saying:
Detected SSL certificate validation failed with (certificate has expired) Destination IP: 216.58.201.70.
Slips gathers AS, hostname, SNI, rDNS and any available data about this IP and you get an alert saying:
Detected SSL certificate validation failed with (certificate has expired) Destination IP:
216.58.201.70. AS: GOOGLE, US, SNI: 2542116.fls.doubleclick.net, rDNS: prg03s01-in-f70.1e100.net
DNS ARPA Scans
Whenever slips sees a new domain in dns.log, if the domain ends with ‘.in-addr.arpa’ slips keeps trach of this domain and the source IP that made the DNS request.
Then, if the source IP is seen doing 10 or more ARPA queries within 2 seconds, slips generates an ARPA scan detection.
SSH version changing
Zeek logs the used software and software versions in software.log, so slips knows from this file the software used by different IPs, like whether it’s an SSH::CLIENT, an HTTP::BROWSER, or an HTTP::SERVER
When slips detects an SSH client or an SSH server, it stores it with the IP and the SSH versions used in the database
Then whenever slips sees the same IP using another SSH version, it compares the stored SSH versions with the current SSH versions
If they are different, slips generates an alert
Detection modules
Slips is a behavioral-based IPS that uses machine learning to detect malicious behaviors in the network traffic. It is a modular software that can be extended. When Slips is run, it spawns several child processes to manage the I/O, to profile attackers and to run the detection modules.
Here we describe what detection modules are run on the traffic to detect malicious behaviour.
Modules are Python-based files that allow any developer to extend the functionality of Slips. They process and analyze data, perform additional detections and store data in Redis for other modules to consume. Currently, Slips has the following modules:
Module | Description | Status |
---|---|---|
ARP Detection | Finds ARP scans and MITM with ARP in the local networrk. | ✅ |
Exporting | Exports Slips alerts to Slack servers and STIX servers. | ✅ |
IP_Info | Finds Geolocation country, and ASN for an IP address. | ✅ |
CESNET | Send and receive alerts from warden servers. | ✅ |
RiskIQ | Finds information from RiskIQ, such as passive DNS for domains and downloads the Threat Intelligence feed. | ✅ |
Update | Takes care of downloading each of the files used by Slips, but only if there is a need to update them. It stores and checks the ETags of remote files to know if they changed. It can be configured to update each file with a different frequency. Most importantly it updates all the Threat Intelligence feeds. | ✅ |
Threat Intelligence | Checks if any domain or IP is included in Threat Intelligence feeds. Domains include DNS requests, DNS replies, HTTP hostnames, and TLS SNI. IPs include source and destination IPs, both IPv4 and IPv6. | ✅ |
https | training&test of RandomForest to detect malicious https flows | ⏳ |
port scan detector | detects Horizontal and Vertical port scans | ✅ |
timeline | creates a timeline of what happened in the network based on all the flows and type of data available | ✅ |
rnn-cc-detection | detects command and control channels using recurrent neural network and the stratosphere behavioral letters | ✅ |
VirusTotal | module to lookup IP address on VirusTotal | ✅ |
flowalerts | Finds malicious behaviours by analyzing only one flow. Now detects: self-signed certificates, TLS certificates which validation failed, vertical port scans detected by Zeek (contrary to detected by Slips), horizontal port scans detected by Zeek (contrary to detected by Slips), password guessing in SSH as detected by Zeek, long connection, successful ssh | ✅ |
leak_detector | module to detect leaks of data in the traffic using YARA rules | ✅ |
ARP | module to check for ARP attacks in ARP traffic | ✅ |
http_analyzer | module to analyze HTTP traffic. | ✅ |
blocking | Blocks the alerted IPs in the Linux iptables Firewall. | ✅ |
flowmldetection | module to detect malicious flows using machine learning | ✅ |
Virustotal Module
This module is used to lookup IPs, domains, and URLs on virustotal
To use it you need to add your virustotal API key in config/vt_api_key
RiskIQ Module
This module is used to get different information (passive DNS, IoCs, etc.) from RiskIQ
To use this module your RiskIQ email and API key should be stored in config/RiskIQ_credentials
the format of this file should be the following:
example@domain.com
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
The hash should be your 64 character API Key.
The path of the file can be modified by changing the RiskIQ_credentials_path
parameter in config/slips.conf
Leak Detection Module
This module on runs on pcaps, it uses YARA rules to detect leaks.
You can add your own YARA rule in modules/leak_detector/yara_rules/rules
and it will be automatically compiled and stored in modules/leak_detector/yara_rules/compiled
and matched against every pcap.
Blocking Module
To enable blocking in slips, start slips with the -p
flag.
This feature is only supported in linux using iptables natively and using docker.
Exporting Alerts Module
Slips supports exporting alerts to other systems using different modules (ExportingAlerts, CESNET sharing etc.)
For now the supported systems are:
Slack
TAXII Servers (STIX format)
Warden servers
IDEA JSON format
Logstash
Refer to the exporting section of the docs for detailed instructions on how to export.
Flowalerts Module
This module is responsible for detecting malicious behaviours in your traffic.
Refer to the Flowalerts section of the docs for detailed explanation of what Slips detects and how it detects.
Disabled alerts
All Slips detections are turned on by default, You can configure which alerts you want to enable/disable in config/slips.conf
Slips support disabling unwanted alerts, simply add the detection you want to disable in
the disabled_detections
list and slips will not generate any alerts of this type.
for example:
disabled_detections = [MaliciousJA3, DataExfiltration, SelfSignedCertificate]
Supported detections are:
ARPScan, ARP-outside-localnet, UnsolicitedARP, MITM-ARP-attack, SSHSuccessful, LongConnection, MultipleReconnectionAttempts, ConnectionToMultiplePorts, InvalidCertificate, UnknownPort, Port0Connection, ConnectionWithoutDNS, DNSWithoutConnection, MaliciousJA3, DataExfiltration, SelfSignedCertificate, PortScanType1, PortScanType2, Password_Guessing, MaliciousFlow, SuspiciousUserAgent, multiple_google_connections, NETWORK_gps_location_leaked, Command-and-Control-channels-detection, ThreatIntelligenceBlacklistDomain, ThreatIntelligenceBlacklistIP, MaliciousDownloadedFile, DGA, MaliciousSSLCert, YoungDomain, MultipleSSHVersions DNS-ARPA-Scan, SMTPLoginBruteforce, BadSMTPLogin, IncompatibleUserAgent, ICMP-Timestamp-Scan, ICMP-AddressScan, ICMP-AddressMaskScan
Threat Intelligence Module
Slips has a complex system to deal with Threat Intelligence feeds.
Slips supports different kinds of IoCs from TI feeds (IPs, IP ranges, domains, JA3 hashes, SSL hashes)
File hashes and URLs aren’t supported.
Matching of IPs
Slips gets every IP it can find in the network and tries to see if it is in any blacklist.
If a match is found, it generates an evidence, if no exact match is found, it searches the Blacklisted ranges taken from different TI feeds
Matching of Domains
Slips gets every domain that can find in the network and tries to see if it is in any blacklist. The domains are currently taken from:
DNS requests
DNS responses
HTTP host names
TLS SNI
Once a domain is found, it is verified against the downloaded list of domains from the blacklists defined in ti_files
in the configuration file config/slips.conf
.
If an exact match is found, then an evidence is generated.
If an exact match is not found, then Slips verifies if the verified domain is a subdomain of any domain in the blacklist.
For example, if the domain in the traffic is here.testing.com, Slips first checks if the exact domain here.testing.com is in any blacklist, and if there is no match, it checks if the domain testing.com is in any blacklists too.
Matching of JA3 Hashes
Every time Slips encounters an TLS flow,
it compares each JA3 and JA3s with the feeds of malicious JA3 and alerts when
there’s a match.
Slips is shipped with the Abuse.ch JA3 feed by default
You can add your own SSL feed by appending to the file defined by the ja3_feeds
key in
config/slips.conf
, which is by default config/JA3_feeds.csv
Matching of SSL SHA1 Hashes
Every time Slips encounters an SSL flow, it tries to get the certificate hash from zeek ssl.log, then it compares the hash with our list of blacklisted SSL certificates
Slips is shipped with the Abuse.ch SSL feed by default,
You can add your own SSL feed by appending to the file defined by the ssl_feeds
key in config/slips.conf
, which is by default
config/SSL_feeds.csv
Local Threat Intelligence files
Slips has a local file for adding IoCs of your own,
it’s located in config/local_data_files/own_malicious_iocs.csv
by default,
this path can be changed by changing download_path_for_local_threat_intelligence
in config/slips.conf
.
The format of the file is “IP address”,”Threat level”, “Description”
Threat level available options: info, low, medium, high, critical
Refer to the architecture section of the docs for detailed explanation of Slips threat levels.
Example:
"23.253.126.58","high","Simda CC"
"bncv00.no-ip.info", "critical", "Variant.Zusy"
Local JA3 hashes
Slips has a local file for adding JA3 hashes of your own,
it’s located in config/local_data_files/own_malicious_JA3.csv
by default.
The format of the file is “JA3 hash”, “Threat level”, “Description”
Threat level available options: info, low, medium, high, critical
Refer to the architecture section of the docs for detailed explanation of Slips threat levels.
Example:
"e7d705a3286e19ea42f587b344ee6865","medium","Standard tor client"
"6734f37431670b3ab4292b8f60f29984", "high", "Trickbot Malwar"
Adding your own remote feed
We update the remote ones regularly. The list of remote threat intelligence files is set in the variables ti_files
variable in config/slips.conf. You can add your own remote threat intelligence feeds in this variable. Supported extensions are: .txt, .csv, .netset, ipsum feeds, or .intel.
Each URL should be added with a threat_level and a tag, the format is (url,threat_level,tag)
tag is which category is this feed e.g. phishing, adtrackers, etc..
Threat level available options: info, low, medium, high, critical
Refer to the architecture section of the docs for detailed explanation of Slips threat levels.
TI files commented using # may be processed as they’re still in our database.
Use ;
for commenting TI files in config/slips.conf
instead of #
.
Commented TI files (lines starting with ;) will be completely removed from our database.
The remote files are downloaded to the path set in the download_path_for_local_threat_intelligence
. By default, the files are stored in the Slips directory modules/ThreatIntelligence1/remote_data_files/
Commenting a remote TI feed
If you have a remote file link that you wish to comment and remove from the database
you can do so by adding ‘;’ to the line that contains the feed link in config/slips.conf
, don’t use the ‘#’
for example to comment the bruteforcelogin
feed you should do the following:
;https://lists.blocklist.de/lists/bruteforcelogin.txt,medium,['honeypot']
instead of:
#https://lists.blocklist.de/lists/bruteforcelogin.txt,medium,['honeypot']
Update Manager Module
To make sure Slips is up to date with the most recent IoCs in all feeds, all feeds are loaded, parsed and updated periodically and automatically by Slips every 24 hours, which requires no user interaction.
The 24 hours interval can be changed by changing the TI_files_update_period
key in config/slips.conf
Update manager is responsible for updating all remote TI files (including SSL and JA3 etc.)
By default, local slips files (organization_info, ports_info, etc.) are cached to avoid loading and parsing them everytime we start slips. However, they are updated automatically by the update manager if they were changed on disk.
IP Info Module
The IP info module has several ways of getting information about an IP address, it includes:
ASN
Country by Geolocation
Given a MAC, its Vendor
Reverse DNS
ASN
Slips is shipped with an offline database (GeoLite2) in databases/GeoLite2-ASN.mmdb
to search for ASNs, if
the ASN of a given IP is not in the GeoLite2 database, we try to get the ASN online
using the online database using the ipwhois
library.
However, to reduce the amount of requests, we retrieve the range of the IP and we cache the whole range. To search and cache the whole range of an IP, the module uses the ipwhois library. The ipwhois library gets the range of this IP by making a connection to the server cymru.com
using a TXT DNS query. The DNS server is the one set up in the operating system. For example to get the ASN of the IP 13.32.98.150, you will see a DNS connection asking for the TXT record of the domain 150.98.32.13.origin.asn.cymru.com
.
Country by Geolocation
Slips is shipped with an offline database (GeoLite2) in databases/GeoLite2-Country.mmdb
to search for Geolocation.
Mac Vendors
Slips is shipped with an offline database databases/macaddress-db.json
for
MAC address vendor mapping.
This database is a combination of 2 different online databases, but the format of them is changed to a format slips understands and to reduce the size of the db.
Slips gets the MAC address of each IP from dhcp.log and arp.log and then searches the offline database using the OUI.
If the vendor isn’t found in the offline MAC database, Slips tries to get the MAc using the online database https://www.macvendorlookup.com
The offline database is updated manually and shipped with slips, you can find it in
the databases/
dir.
Slips makes sure it doesn’t perform duplicate searches of the same MAC Address either online, or offline.
Reverse DNS
This is obtained by doing a standard in-addr.arpa DNS request.
ARP Module
This module is used to check for ARP attacks in your network traffic.
By default, zeek doesn’t generate and log ARP flows, but Slips is shipped with it’s
own zeek scripts that enable the logging of ARP flows in arp.log
The detection techniques are:
ARP scans
ARP to a destination IP outside of local network
Unsolicited ARP
MITM ARP attack
ARP Scans
Slips considers an IP performing an ARP scan if it sends 5 or more non-gratuitous ARP to different destination addresses in 30 seconds or less.
ARP to a destination IP outside of local network
Slips alerts when an ARP flow is being sent to an IP outside of local network as it’s a weird behaviour that shouldn’t be happening.
Unsolicited ARP
Unsolicited ARP is used to update the neighbours’ ARP caches but can also be used in ARP spoofing, we detect it with threat level ‘info’, so we don’t consider it malicious, we simply notify you about it.
MITM ARP attack
Slips detects when a MAC with IP A, is trying to tell others that now that MAC is also for IP B (ARP cache attack)
CESNET sharing Module
This module is responsibe for importing and exporting alerts from and to warden server
Refer to the exporting section of the docs for detailed instructions on CESNET exporting and the format of the configuration files.
To enable the importing alerts from warden servers,
set receive_alerts
to yes
in config/slips.conf
Slips imports 100 alerts from warden servers each day, and automatically stores the aleerts in our database
Time to wait before receiving alerts from warden server is 1 day by default, you can change this
by chaning the receive_delay
in config/slips.conf
These are the categories we import: [’Availability’, ‘Abusive.Spam’,’Attempt.Login’, ‘Attempt’, ‘Information’, ‘Fraud.Scam’, ‘Information’, ‘Fraud.Scam’]
HTTP Analyzer Module
This module handles the detections of HTTP flows
Available detection are:
Multiple empty connections
Suspicious user agents
Incompatible user agents
Multiple user agents
Downloads from pastebin
Executable downloads
Multiple empty connections
Due to the usage of empty connections to popular site by malware to check for internet connectivity, We consider this type of behaviour suspicious activity that shouldn’t happen
We detect empty connection to ‘bing.com’, ‘google.com’, ‘yandex.com’, ‘yahoo.com’, ‘duckduckgo.com’ etc.
Suspicious user agents
Slips has a list of suspicious user agents, whenever one of them is found in the traffic, slips generates and evidence.
Our current list of user agents has: [’httpsend’, ‘chm_msdn’, ‘pb’, ‘jndi’, ‘tesseract’]
Incompatible user agents
Slips uses and offline MAC address database to detect the type of device based on the MAC OUI.
First, Slips store the MAC address and vendor of every IP it sees (if available)
Second, When slips encounters a user agent in HTTP traffic it performs an online query to http://useragentstring.com to get more info about this user agent, like the os type, name and browser.
Third, When slips has both information available (MAC vendor and user agent), it compares them to detect incompatibility using a list of keywords for each operating system.
Available keywords for Apple: (’macos’, ‘ios’, ‘apple’, ‘os x’, ‘mac’, ‘macintosh’, ‘darwin’)
Available keywords for Microsoft: (’microsoft’, ‘windows’, ‘nt’)
Available keywords for Android: (’android’, ‘google’)
Multiple user agents
Slips stores the MAC address and vendor of every IP it sees (if available) in the redis database. Then, when an IP iss seen using a different user agent than the one stored in the database, it tries to extract os info from the user agent string, either by performing an online query to http://useragentstring.com or by using zeek.
If an IP is detected using different user agents that refer to different operating systems, an alert of type ‘Multiple user agents’ is made
for example, if an IP is detected using a macOS user agent then an android user agent, slips detects this with ‘low’ threat level
Pastebin downloads
Some malware use pastebin as the host of their malicious payloads.
Slips detects downloads of files from pastebin with size >= 700 bytes.
This value can be customized in slips.conf by changing pastebin_download_threshold
When found, slips alerts pastebin download with threat level low because not all downloads from pastebin are malicious.
Executable downloads
Slips generates an evidence everytime there’s an executable download from an HTTP website.
Leak Detector Module
This module work only when slips is given a PCAP
The leak detector module uses YARA rules to detect leaks in PCAPs
Module requirements
In order for this module to run you need:
- to have YARA installed and compiled on your machine
- yara-python
- tshark
You can install YARA by running
sudo apt install yara
You can install tshark by running
sudo apt install wireshark
How it works
This module works by
Compiling the YARA rules in the
modules/leak_detector/yara_rules/rules/
directorySaving the compiled rules in
modules/leak_detector/yara_rules/compiled/
Running the compiled rules on the given PCAP
Once we find a match, we get the packet containing this match and set evidence.
Extending
You can extend the module be adding more YARA rules in modules/leak_detector/yara_rules/rules/
.
The rules will be automatically detected, compiled and run on the given PCAP.
If you want to contribute, improve existing Slips detection modules or implement your own detection modules, see section :doc:Contributing <contributing>
.
Network service discovery Module
This module is responsibe for detecting scans such as:
Vertical port scans
Horizontal port scans
PING sweeps
DHCP scans
Vertical port scans
Slips checks both TCP and UDP connections for port scans.
Slips considers an IP performing a vertical port scan if it scans 6 or more different destination ports
We detect a scan every threshold. So we detect when there is 6, 9, 12, etc. destination ports per destination IP.
Horizontal port scans
Slips checks both TCP and UDP connections for horizontal port scans.
Slips considers an IP performing a horizontal port scan if it contacted more than 3 destination IPs on a specific port with not established connections.
We detect a scan every threshold. So we detect when there is 6, 9, 12, etc. destination destination IPs.
PING Sweeps
PING sweeps or ICMP sweeps is used to find out which hosts are alive in a network or large number of IP addresses using PING/ICMP.
We detect a scan every threshold. So we generate an evidence when there is 5,10,15, .. etc. ICMP established connections to different IPs.
We detect 3 types of ICMP scans: ICMP-Timestamp-Scan, ICMP-AddressScan, and ICMP-AddressMaskScan
Slips does this detection using Slips’ own zeek script located in zeek-scripts/icmps-scans.zeek for zeek and pcap files and using the portscan module for binetflow files.
Connections Made By Slips
Slips uses online databases to query information about many different things, for example (user agents, mac vendors etc.)
The list below contains all connections made by Slips
useragentstring.com -> For getting user agent info if no info was found in Zeek macvendorlookup.com -> For getting MAC vendor info if no info was found in the local maxmind db ip-api.com/json/ -> For getting ASN info about IPs if no info was found in our Redis DB ipinfo.io/json -> For getting your public IP virustotal.com -> For getting scores about downloaded files, domains, IPs and URLs cymru.com -> For getting the range of a specific IP to cache the ASN of this range. TXT DNS queries are made to this domain.
By default, slips whitelists alerts from or to any of the above domains, witch means that if an alert was detected to one of the above alerts, slips does not detect it assuming it’s a false positive and the connection was made internally by slips.
You can change this behaviour by updating whitelist.conf
.
Ensembling
Ensembling in Slips is done by the Evidence Process.
Every time the evidence process gets a new evidence from the detection modules, it retrieves all the past evidence by this the source IP, in the current timewindow from the datbase.
Then, Slips uses the following equation to get the score of each evidence
threat_level = threat_level * confidence
Slips accumulates the threat level of all evidenc, then, it checks if the accumulated threat level reached a certain threshold or not.
If the accumulated threat level reached the threshold specified in
evidence_detection_threshold
, Slips generates and alert.
If not, slips waits for the next evidence, accumulates threat levels, and checks again until the threshold is reached.
Controlling Slips Sensitivity
The threshold that controls Slips sensitivity is determined
by the evidence_detection_threshold
key in config/slips.conf
,
by default it is set to 3.46
.
This threshold is the minimum accumulated threat level per time window needed to generate an alert.
The default threshold of 3.46 gives you balanced detections with the optimal false positive rate and accuracy.
The Optimal range is from 3.1 to 3.89. The higher the value in this range, the less false positives and the less accuracy you get.
Here are more options
0.2: Use this threshold If you want Slips to be super sensitive with higher FPR, using this means you are less likely to miss a detection but more likely to get false positives.
6.3: Use this threshold If you want Slips to be insensitive. meaning Slips will need so much evidence to trigger an alert. May lead to false negatives.
3.1: The start of the optimal range, has more false positives but more accurate.
3.86: The end of the optimal range, has less false positives but less accurate.
Zeek Scripts
Slips is shipped with it’s own custom zeek scripts to be able to extend zeek functionality and customize the detections
Detect DoH
In the detect_DoH.zeek
script, slips has it’s own list of ips that belong to dns/doh servers,
When slips encouters a connection to any IP of that list on port 443/tcp, it assumes it’s a DoH connetion,
and times out the connection after 1h so that the connection won’t take too long to appear in slips.
Detect ICMP Scans
In the zeek-scripts/icmps-scans.zeek
script, we
check the type of ICMP in every ICMP packet seen in the network,
and we detect 3 types of ICMP scans: ICMP-Timestamp-Scan, ICMP-AddressScan, and ICMP-AddressMaskScan based on the icmp type
We detect a scan every threshold. So we generate an evidence when there is 5,10,15, .. etc. ICMP established connections to different IPs.
CPU Profiling
Slips is shipped with its own tool for CPU Profiling, it can be found it slips_files/common/cpu_profiler.py
CPU Profiling supports 2 modes: live and development mode
Live mode:
The main purpose of this mode it to show live CPU stats in the web interface. “live” mode publishes updates during the runtime of the program to the redis channel ‘cpu_profile’ so that the web interface can use them
Development mode:
Setting the mode to “dev” outputs a JSON file of the CPU usage at the end of the program run. It is recommended to only use dev mode for static file inputs (pcaps, suricata files, binetflows, etc.) instead of interface and growing zeek dirs, because longer runs result in profiling data loss and not everything will get recorded. The JSON file created in this mode is placed in the output dir of the current run and can be viewed by running the following command
vizviewer results.json
then going to http://127.0.0.1:9001/ in your browser for seeing the visualizations of the CPU usage
Options to enable cpu profiling can be found under the [Profiling] section of the slips.conf
file.
cpu_profiler_enable
set to “yes” enables cpu profiling, or “no” to disable it.
cpu_profiler_mode
can be set to “live” or “dev”. Setting to
cpu_profiler_multiprocess
can be set to “yes” or “no” and only affects the dev mode profiling. If set to “yes” then all processes will be profiled. If set to “no” then only the main process (slips.py) will be profiled.
cpu_profiler_output_limit
is set to an integer value and only affects the live mode profiling. This option sets the limit on the number of processes output for live mode profiling updates.
cpu_profiler_sampling_interval
is set to an integer value and only affects the live mode profiling. This option sets the duration in seconds of live mode sampling intervals. It is recommended to set this option greater than 10 seconds otherwise there won’t be much useful information captured during sampling.
Memory Profiling
Memory profiling can be found in slips_files/common/memory_profiler.py
Just like CPU profiling, it also has supports live and development mode.
Set memory_profiler_enable
to yes
to enable this feature.
Set memory_profiler_mode
to live
to use live mode or dev
to use development mode profiling.
Live Mode
This mode shows memory usage stats during the runtime of the program.
memory_profiler_multiprocess
controls whether live mode tracks all processes or only the main process. If set to no, the program will wait for you to connect from a different terminal using the command memray live <port_number>
, where port_number is 5000 by default. After connection, the program will continue with its run and the terminal that is connected will receive a feed of the memory statistics. If set to yes, the redis channel “memory_profile” can be used to set pid of the process to be tracked. Only a single process can be tracked at a time. The interface is cumbersome to use from the command line so multiprocess live profiling is intended to be used primarily from the web interface.
Development Mode
When enabled, the profiler will output the profile data into the output directory. The data will be in the memoryprofile
directory of the output directory of the run. Each process during the run of the program will have an associated binary file. Each of the generated binaries will automatically be converted to viewable html files, with each process converted to a flamegraph and table format. All generated files will be denoted by their PID.
If you want to contribute: improve existing Slips detection modules or implement your own detection modules, see section :doc:Contributing <contributing>
.