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 without a connection
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
Pastebin downloads
Young domains
Bad SMTP logins
SMTP login bruteforce
DNS ARPA Scans
SSH version changing
Incompatible CN
CN URL Mismatch
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
Invalid DNS answers
Tor exit nodes 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 slips.yaml by changing the value of long_connection_threshold
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 type when connected to well known organizations. In particular Facebook, Apple, Google, Twitter, and Microsoft.
Slips uses it’s own lists of organizations and information about them (IPs, IP ranges, domains, and ASNs).
They are stored in slips_files/organizations_info and they are used to check whether the IP/domain
of each flow belong to a known org or not.
Slips also doesn’t detect connection without DNS to any domain in the tranco whitelist.
Slips doesn’t detect ‘connection without DNS’ 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 DNS resolution of these connections did happen before slips started).
check the 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.
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
If the port is in the list of well known ports in
services.csv.If Slips has that port’s info in
ports_used_by_specific_orgs.csvand the source and destination addresses belong to that organization.
Slips considers an IP belongs to an org if:
Both
saddranddaddrhave the organization’s name in their MAC vendor (e.g. Apple.)Both
saddranddaddrbelong to the range specified in theports_used_by_specific_orgs.csvfor that organization.If the SNI, hostname, rDNS, ASN of this IP belong to this organization.
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 Upload
Slips generates ‘possible data upload’ alerts when the number of uploaded bytes to any IP exceeds 100 MBs over the timewindow period which is, by default, 1h.
See detailed explanation of timewindows here.
The number of MBs can be modified by changing the value of data_exfiltration_threshold in slips.yaml
Slips also detects data upload when an IP uploads >=100MBs to any IP in 1 connections.
Tor Exit Nodes
Slips generates informational evidence when it detects a tor exit node from the list https://check.torproject.org/torbulkexitlist.
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 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 on the same destination port.
Zeek alerts
By default, Slips depends on Zeek for detecting different behaviours, for example Self-signed certs, invalid certs, port-scans, and address scans.
Some scans are also detected by Slips independently of Zeek, like ICMP sweeps and vertical/horizontal portscans. Check PING Sweeps section for more info
SMTP login bruteforce
Slips alerts when 3+ invalid SMTP login attempts occurs within 10s
SSH brute_force_detector
SSH brute force detector is documented in the dedicated brute_force_detector module page:
The flow_alerts module still detects successful SSH sessions, but SSH password guessing is no longer owned by flow_alerts.
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 slips.yaml.
Pastebin downloads
Slips detects downloads from pastebin using SSL and HTTP
It alerts when a downloaded file from pastebin exceeds 700 bytes
This value can be customized in slips.yaml by changing pastebin_download_threshold
Slips detects the pastebin download once the SSL connection is over , which may take hours.
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
Incompatible CN
Zeek logs each Certificate CN in ssl.log
When slips encounters 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 evidence.
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
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
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.
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.
Login log entries
Slips reads Zeek login.log entries generated by zeek-scripts/login.zeek. It can detect telnet, rlogin, or rsh logins.
For each entry in the zeek logs, the profiler publishes a new_login message and
flow_alerts sets informational evidence for the server receiving the login.
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”