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

  • 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

  • Connection to private IPs

  • Connection to private IPs outside the current local network

  • High entropy DNS TXT answers

  • Devices changing IPs

  • GRE tunnels

  • GRE tunnel scan

  • SSH version changing

  • Invalid DNS resolutions

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.yaml 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.

CN URL Mismatch

Zeek logs each Certificate CN in ssl.log For each CN Slips encounters, it checks if the server name is the same as the CN Or if it belongs to the same org as the CN. if not, slips triggers an evidence

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.yaml 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”.

GRE tunnels

Slips uses zeek tunnel.log to alert on GRE tunnels when found. Whenever one any action other than “Tunnel::DISCOVER” is found, slips sets an evidence with threat level low

GRE tunnel scans

Slips uses zeek tunnel.log to alert on GRE tunnels scan. Slips considers any log with “Tunnel::DISCOVER” action a GRE scan.

The threat level of this evidence is low.

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 or a DHCP connection on port 53, 67 or 68 UDP to the gateway IP.

Slips also skips this alert for DNS traffic on port 53 and for DHCPv6 traffic on ports 546 and 547. When Slips sees a private DNS flow in the analyzed traffic, it records that destination address as a DNS server and prints it to the display and to slips.log.

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

Slips detects the current local network by using the local network of the private ips specified in client_ips parameter in slips.yaml

If no IPs are specified, slips uses the local network of the first private source ip found in the traffic.

This threat level of this detection is low if the source ip is the one outside of local network because it’s unlikely. and high if the destination ip is the one outside of local network.

Slips ignores evidence of this type when the destination IP is a private IP outside of local network and is communicating on port 53/UDP. Slips marks that destination address as the DNS server as soon as it sees a private DNS flow in dns.log and prints Detected DNS server by traffic heuristic: <ip> to the display and slips.log. The same heuristic applies to private IPv4 and IPv6 DNS servers. this is likely a DNS misconfiguration hence a FP.

Slips also ignores this evidence when the checked IP is one of the DNS servers detected from the analyzed DNS traffic and the matching DNS server port is 53. This applies to both IPv4 and IPv6 resolver addresses and covers requests sent to the resolver and replies coming back from it.

For CONNECTION_TO_PRIVATE_IP, Slips suppresses DHCPv6 traffic on ports 546 and 547. This avoids false positives when the same local network device provides both DNS and DHCPv6 services but answers with a different IPv6 address, such as a link-local address.

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 SSL 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.

Sometimes zeek detects a connection from a source to a destination IP on port 443 as SSL, and another connection within 5 minutes later as non-SSL. Slips detects that and does not set an evidence for any of them.

Here’s how it works

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 sets and evidence.

If a flow without http as a service is found, slips first checks past and future flows from the same src ip + dst ip + port to see if there’s a flow with http as a service, if there is, slips ignores the alert. This is done to avoid FPs coming from zeek.

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

  1. Using Zeek. Zeek logs successful SSH connection to ssh.log by default

  2. 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.

  • WPAD domain from Windows

  • domains without a TLD such as the Chrome test domains.

  • DNS resolutions of any type other than AAAA and A

Slips doesn’t detect ‘DNS resolutions without a connection’ when running on an interface except for when it’s done by this instance’s own IP and only after 30 minutes has passed to avoid false positives (assuming the connection did happen and yet to be logged).

When running on interface and files. For each DNS flow found, slips waits 30 mins zeek time for the connection to be found before setting an evidence.

This is done by comparing each ts of every new dns flow to the pending detection, once 30 mins difference between the 2 flows is detected, slips sets the evidence.

To avoid accumulating so many pending DNS flows for 30 mins, slips checks if the connection of the pending DNS flows arrived every 10 and 20 mins too, if not found, slips waits extra 10 mins (so that would be 30 mins total) and sets the evidence.

Connection to unknown ports

Slips has a list of known ports located in slips_files/ports_info/services.csv

and a list of ports that belong to a specific organization in slips_files/ports_info/ports_used_by_specific_orgs.csv

These are the cases where Slips marks the port as known and doesn’t trigger an alert

  1. If the port is in the list of well known ports in services.csv.

  2. If Slips has that port’s info in ports_used_by_specific_orgs.csv and the source and destination addresses belong to that organization.

Slips considers an IP belongs to an org if:

  1. Both saddr and daddr have the organization’s name in their MAC vendor (e.g. Apple.)

  2. Both saddr and daddr belong to the range specified in theports_used_by_specific_orgs.csv for that organization.

  3. If the SNI, hostname, rDNS, ASN of this IP belong to this organization.

  4. If the IP is hardcoded in any of the organizations IPs in slips_files/organizations_info/.

Otherwise, Slips triggers and “unknown port” evidence.

For example, even though 5223/TCP isn’t a well known port, Apple uses it in Apple Push Notification Service (APNS).

The threat level of this evidence depends on the state of hte flow. established connections have higher threat levels.

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.yaml

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.yaml.

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.yaml.

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

Invalid DNS resolutions

Some DNS resolvers answer the DNS query to adservers with 0.0.0.0 or 127.0.0.1 as the ip of the domain to block the domain. Slips detects this and sets an informational evidence.

This detection doesn’t apply to queries ending with “.arpa” or “.local”

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 one flow at a time. It detects self-signed certificates, invalid TLS certificates, Zeek vertical and horizontal port-scan notices, long connections, successful SSH, DNS and connection heuristics, SMTP bruteforce, and related per-flow behaviours. ✅
bruteforcing Detects SSH bruteforcing from repeated SSH sessions, SSH authentication metadata, client banners from software.log, and Zeek SSH password-guessing notices. ✅
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.yaml

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.yaml

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.yaml. 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.yaml, 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.yaml, 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.yaml.

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.yaml. 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.yaml 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.yaml, 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.yaml

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 IP and MAC address, it includes:

  • ASN

  • Country by Geolocation

  • MAC Vendors

  • 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.yaml

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.yaml

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.

If Google is whitelisted in whitelist.conf, this detection will be suppressed.

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.yaml 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

  1. Compiling the YARA rules in the modules/leak_detector/yara_rules/rules/ directory

  2. Saving the compiled rules in modules/leak_detector/yara_rules/compiled/

  3. Running the compiled rules on the given PCAP

  4. 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

Slips reports evidence of a vertical portscan based on a log scale. meaning every 10, 100, 1000 ports scanned will generate an evidence. This avoids generating one port scan alert per flow in a long scan.

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.

Slips reports evidence of a horizontal portscan based on a log scale. meaning every 10, 100, 1000 ports scanned will generate an evidence. This avoids generating one port scan alert per flow in a long scan.

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 copying config/whitelist.conf, updating the copy, and pointing whitelists.local_whitelist_path in your copied slips.yaml file to that copied whitelist.

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.yaml, by default it is set to 0.25.

This threshold is used in slips according to the following equation

threshold per width = detection_threshold * width / 60

For example, if you’re using the default slips width 3600, the threshold used in slips will be

0.25 * 3600 / 60 = 15

This equation’s goal is to make it more sensitive on smaller tws, and less sensitive on longer tws

When the accumulated threat levels of all evidence detected in a timewindow exceeds 15, slips will generate an alert.

In simple terms, it means slips will alert when users get the equivalent of 1 alert per minute.

The default threshold of 0.25 gives you balanced detections with the optimal false positive rate and accuracy.

Here are more options

  • 0.08: 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

  • 0.25: Optimal threshold, has the most optimal FPR and TPR.

  • 0.43: Use this threshold If you want Slips to be insensitive. Using this means Slips will need so many evidence to trigger an alert. May lead to false negatives

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.yaml 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>.