Qradar Support

The MSS now fully supports the Qradar SIEM from IBM in CEF log format. Qradar is an excellent SIEM but requires classifying and mapping every event type it sees to an internal category. Qradar comes with a large number of common IDS rules (~50,000) already classified but not mapped.  Besides having to manually map all these rules  Qradar-MSS users  would also need to continuously create additional Qradar IDs (Qids) to map to the much larger rule set used by the MSS (which  changes daily). All this required a mechanism to update Qradar dynamically as new rules are published. With this update released today, no manual classification or mapping operations are necessary.

The MetaFlowsCEF log source automatically parses the 13 event types generated by the MSS and presents them in the Qradar default view. All MSS events are automatically mapped to new or existing Qids without any user manual operations. This makes the Qradar SIEM much easier to use.

To setup Qradar for the MSS perform the following steps:

    1. Download the MetaFlowsCEF log source https://nsm.metaflows.com/sensordevicetype-search-ContentExport-20180809173340.zip to the Qradar box
    2. Import it with the command /opt/qradar/bin/contentManagement.pl -action import -f sensordevicetype-search-ContentExport-20180809173340.zip
    3. Verify the import was successful and assign the MetaFlows sensors to this log source. Also make a note of the log source ID assigned by Qradar to the MetaFlowsCEF log source (something like 400[1-9]).
    4. Edit the file mss.sh of all sensors and add the line export QRADAR=1.
    5. On one of the sensors you designate as the main Qradar updater, create the file /nsm/etc/qradar.ini to allow the sensor to communicate to the Qradar server (see an example below). Also add the line export QRADARLOGSOURCEID=<logsourceid>; where <logsourceid> is the number you noted in step 3. Probably something like 4001, or 4002, etc..
    6. Restart the sensors

Sample qradar.ini:

[DEFAULT]
certificate_file = /nsm/etc/qradar.pem
auth_token = f3f1201b-3562-46d1-9b8b-9a1623870000
server_ip = 123.52.215.20

Where:

/nsm/etc/qradar.pem is a copy of the file located at /etc/httpd/conf/certs/cert.cert on your Qradar box
auth_token is obtained from your QRADAR application
server_ip is the IP address of your Qradar box.

The Qradar updater sensor will automatically add to Qradar new IDS rules added by the sensor’s rule update  (which will be the same across all your sensors). This will happen through the Qradar API in the background as the sensor is running. The first time, the updater is run, it will have to catch up with about 50,000 definitions; so it will take many hours. Subsequent updates will take less time.

After each Qradar update, the email associated with the sensor owner will receive a summary of the update process.

Qradar integration is a bit complex; so do not hesitate to contact support@metaflows.com for any questions.

 

Search In Packet Logs

You can now search for arbitrary strings in the historical packet logs directly. The only requirements for this search is at least 1 IP address in addition to the search string.

For example in the search below we are looking for the IP address 139.182.44.203 in any packet either sent or received by the host 23.208.142.28. The search is also restricted to an hour worth of packets on 5/7/2018.

searchpayload

So why would you look for an IP address string in the packets? Well, this is normally done when there is more than one proxy and the system is not able to properly identify the proxy chain. In that case the offending IP will be recorded in the x-forwarded-for field of the http headers. Once you find the headers, you can find the real flows and then search again to get the data exchanged specifying the source and destination ports.

But this search feature is much more powerful than that; in fact you can also look retroactively in your packet history using full PERL regular expressions!

If you reached this far in this post, and you are an expert user, you will be wondering about the example above. The search string above would actually match more than  139.182.44.203 because the dots really mean any character (for example 139a182b44c203 would also match). To be more precise you would need to enter:

 139\.182\.44\.203

But suppose you wanted to match a specific set of IP addresses

139.182.44.203
139.182.44.205
139.182.44.206

Using a regular expression you could search for:

139\.182\.44\.20[356]

Just imagine what you could search for when you are hunting down specific strings or patterns.  So, this little new feature (also available through the CLI interface as the option -Q) should really expand the power of our historical packet logging system. It will let you easily dig in your network history for hidden clues of what happened in the past.

Websockets in server mode

You can now use Websockets and disable flash for good. We added support for Websockets instead of Flash for direct real time connection to our sensors to retrieve real time data and payloads. Sensors can be configured in client mode or server mode. In client mode sensors and browser both connect outbound as clients and get connected at the network level by our forwarder. Websockets have been working in this mode for quite sometime. Sensors can also be configured in server mode where the browser needs to connect to the sensor which acts a websocket server.  Since sensors only have a self-signed SSL certificate, secure Websockets would not work. To get around this, we added a small (probably the smallest web server you will ever see) that only serves a root certificate authority to be installed in your browser. Go to:

http://<yours sensor ip> for non-Windows systems

http://your sensor ip>:81 for Windows systems

and install the certificate.

Then configure your sensor as a server and make sure to add its static IP address in the sensor configuration. After restarting the sensor, you will be able to connect in server mode using Websockets.

Proxy Detection Support

This has been awaited for some time. The MetaFlows Security System now detects proxied connections. The original IP is swapped with the proxy IP so that it can be correctly identified in the events. This has a dramatic effect on correlation since most proxied hosts only proxy http and use their real IP for DNS and other communications. Using the real IP for correlation and analysis will correctly correlate IDS http events and file downloads with IDS events and  service discoveries triggered by different protocols.

When a proxied host is detected, a message of the forms xff=<realip><-<proxyip> is appended to the event and the proxy IP is replaced. So, you will see the real IP not the proxy.

When you analyze  the packets data, the system automatically switches back to the proxy IP to look for the packets containing the proxy IP rather than the real IP (since the packets are stored before the IP is replaced).

Here is a real example of two events related to 139.182.192.18 (the real IP) downloading  suspicious content through the proxy 139.182.248.230:

proxied2

Notice that when we detect a proxy a P is associated with the proxied host.

This feature will be available as soon as your sensor is restarted or self-updates. Let us know if you have questions.

Happy hunting!

Your dedicated MetaFlows Team.

 

Splunk App

We have developed a Splunk network security app available at https://splunkbase.splunk.com/app/3603

or http://nsm.metaflows.com/SplunkforMetaFlows.tgz.

It receives events generated by the MetaFlows sensors and breaks them down by the following types:

  • Multisession Analysis
  • High Priority Events
  • IDS Events
  • Network Logs (3rd party logs sent to the sensors)
  • File Transmission Analysis
  • User Discovery
  • Service Discovery
  • Host Discovery
  • Mac Discovery
  • Suspicious URL Transmission Analysis
  • IPS Notifications
  • User Rankings
  • Modsecurity

From the app you can either drill down on Splunk itself or jump to the MetaFlows console to gather more forensic information like packet payloads.

You can install the app by using the Splunk application management tools. In order to send event to Splunk you need to add a configuration line in your /nsm/etc/mss.sh startup script of your sensors.  The SSL-encrypted syslog messages are sent to the MetaFlows Splunk App through TCP port 3015 (please make sure you sensor can communicate on this port).

It is a early beat version, please let us know how you like it.

Please see more details at https://docs.metaflows.com/Log_Management#Splunk_App

Happy Hunting!

The MetaFlows Team.

WannaCry Ransomware Advisory

It has been all over the news this weekend, a surge in Ransomware under the name ‘wannacry’ that has the potential to cripple large portions of networks due to the way that it spreads.

This is a pretty stealthy piece of malware at the network level, little to no CnC has been confirmed, but at an individual level it doesn’t behave much differently from any other Ransomware that we have seen in the past.

What distinguishes WannaCry is that it has a secondary infection vector that prior Ransomware variants lacked. Like any other, the primary infection vector appears to occur via email attachment (zipped javascript). However, once a machine is compromised it begins to behave more like a worm, able to exploit SMB (windows file sharing) on any systems that it can reach in order to spread its self.

This worm like behavior makes it particularly dangerous. While usually* smb (port 445) is not accessible from the outside world, it is often completely unrestricted within a local network, allowing one infected machine to spread the Ransomware across an entire site.

* This is your reminder to do double check firewall rules and run some external scans to make absolutely certain your windows file shares are not reachable from the outside world.

 

The following signatures are currently indicators to look out for:

2024218: ET EXPLOIT Possible ETERNALBLUE MS17 Echo Response
2024291: ET TROJAN Possible WannaCry DNS Lookup (trojan.rules)
2024292: ET INFO Bitcoin QR Code Generated via Btcfrog.com (info.rules)

MetaFlows has added 2024291 to our priority alerts category, and may also add 2023218 to add an extra level of alerting for these events.

 


Many of the windows related scan rules have been updated, and may be treated with greater suspicion, but are not alone indicators of this malware:

2001569 – ET SCAN Behavioral Unusual Port 445 traffic Potential Scan or Infection (scan.rules)
2001579 – ET SCAN Behavioral Unusual Port 139 traffic Potential Scan or Infection (scan.rules)
2001580 – ET SCAN Behavioral Unusual Port 137 traffic Potential Scan or Infection (scan.rules)
2001581 – ET SCAN Behavioral Unusual Port 135 traffic Potential Scan or Infection (scan.rules)
2001582 – ET SCAN Behavioral Unusual Port 1434 traffic Potential Scan or Infection (scan.rules)
2001583 – ET SCAN Behavioral Unusual Port 1433 traffic Potential Scan or Infection (scan.rules)

There are likely to be more updates and more information soon as researchers have time to study the samples collected so far.
Our primary signature provider, Emerging Threats, maintains a mailing list where these issues are discussed as they unfold.
http://lists.emergingthreats.net/pipermail/emerging-sigs/2017-May/028122.html
http://lists.emergingthreats.net/pipermail/emerging-sigs/2017-May/028113.html

Watch your MACs

We added a feature to alert you whenever a new MAC address is seen by the system. The system learns about MAC addresses either through analyzing the DHCP protocol or finding new MAC addresses in the normal network traffic (if you are mirroring/spanning the endpoints’ MAC addresses).

It generates messages of the form:

MACwatch <IP_ADDRESS> <MAC_ADDRESS> <Flow information>

Every time the system sees a new MAC address.

Where:
IP_ADDRESS is the address using the newly discovered MAC
MAC_ADDRESS is the new MAC
<Flow Information> is the flow information we used to discover the new MAC (typically a DHCP lease, but it could also be a UDP or TCP packet if you will span the MAC addresses from the switch).

See a screen shot from our lab firewall sensor.

gkncclkbamnidklp

After the update, you will start getting messages of MAC addresses never seen before. After a while, only new MAC addresses never seen before will start showing up and you can setup a classification matching MACwatch to email yourself, block communication, or both.

The MAC addresses are available for search in the assets page under a new column called MAC. The same IP address can have multiple MACs simultaneously; and MACs can move around from IP to IP due to DHCP leasing.  But, no matter what, a previously unseen MAC will generate a MACwatch message. Some devices (like printers) can go to sleep for days; so you might see some legitimate MACwatch messages for a while.

As always, let us know if you have any questions at support@metaflows.com.

Happy hunting!

 

The MetaFlows Team

Got MAC?

We recently added the MAC addresses to the event messages. The system gets the MAC addresses in two orthogonal ways:

  • We sniff the MAC headers from the passive tap. If the MSS sees more than 5 IP addresses with the same MAC, it stops recording because it means you are mirroring the connection between the switch and the next routing hop (probably the firewall) where the MAC addresses are not available.
  • We sniff  DHCP lease messages  when the IP is assigned dynamically. In order to do this, you probably need to instruct the switch to specifically mirror DHCP traffic in order for the sensor to process it.  The sensor expects DHCP UDP traffic using the pcap expression udp and (port 68 or port 67).

Please contact us at support@metaflows.com if you need help in setting up DHCP traffic monitoring.

 

 

 

Websockets Are Here

Adobe Flash is one of the original sins. It is everywhere and yet it is a huge security risk. Websockets is an HTML5 standard that, for us, provided an alternative to Adobe Flash.

For now we support both. The browser will try to use Adobe Flash first, and if it is not present or it is disabled, it will try using Websockets (which are hard-coded in your Browser). I you want to keep using Adobe Flash, you do not have to do anything; things should keep working as before.

If your sensors are configured as clients, and you do not want to use Flash anymore, just disable it and the Browser will do the rest. You will be using MetaFlows SSL certificate.

If your sensors are configured as servers, and you do not want to use Flash anymore, well, it’s a bit of work to use Websockets because current Browser implementations do not allow self-signed SSL certificates (this is probably a good thing). To use Websockets on sensors configured as servers:

  1. Add your sensors’ static IPs to the DNS (like: <sensorname1>@mydomain.com)
  2. Generate a valid SSL certificates  that matches the DNS name in step 1 (cannot be self-signed). If you do not want to generate a separate certificate for each sensor, you can also buy a *.mysensordomain.com certificate to share by all your sensors.
  3. Bundle the certificates with the command:

# cat my_certificate.crt my_certificate.key bundle_certificate.crt > sensorcert

  1. Copy sensorcert to /usr/local/etc/ntop/sensor-server.pem on your sensors’ hard disk.
  2. Go to nsm.metaflows.com and replace the static IP address of your sensors as a server with the names you setup in step 1
  3. Make sure your browser can reach the sensors on ports 3009 and 3010
  4. Restart your sensors as a server with the command:

#/nsm/etc/mss.sh restart

Adding Websockets support was a fairly extensive change in our system; so there could still be some issues. As always feel free to contact us if you have any questions or you see any problems.

Thank you for exploring the unknown with us!

The MetaFlows Team.

Product Update: Reconsider Event Classifications

Recently, the engineers at MetaFlows have improved the Event Classification Menu within the MetaFlows software, allowing each user to further customize events through actions and event views.  This introduces four key features to the Event Classification Menu that users will find helpful in employing the MetaFlows IDS.

Classifications Window.png

The first improvement allows users to see a comprehensive list of their classifications.  Now, users can access a new classification interface that breaks the classifications down by action.  There are seven action types:  Highlight, Block, E-mail, Ignore, Delete, Rank, and Disabled.  The Highlight function matches the records in the Real-Time, Historical, and Reports with the selected color.  The Block action triggers the Soft IPS for matching records, causing connections matching the classification to be blocked.  The E-mail function produces a PDF report of matching records that will be sent every ten minutes, or as frequently as possible.  The Ignore action ignores events that match the classification.  The Delete function removes matching records from the browser in order to free up memory.  The Rank action increases the priority/rank of the records that match the classification.  The Disable function allows a user to disable a classification without deleting it.

Classifications_list.png

The Search functionality of the classification interface now allows users to search against a classifications’ name, category, IP address, IDS alerts, service alerts, and log message values.  All a user has to do is type a value into the Search field to find classifications to match that query.  The search will match against values in the classification name, category, addresses, and events field.

Classification_options_panel.png

Once upon a time, deleting a classification was an irreversible action.  Now, that can be undone.  If the user deletes a classification only to realize later that they need it, they can restore the classification from the Trashed Classifications list.

Transferring classifications is now much easier.  By employing the Upload Classifications feature, a user can transfer classifications in bulk between two different domains.  The option is listed as the Upload Classifications button and selecting this opens the uploader.  Classifications must be in JSON format and contain all the required information for the classification.

More information regarding the recent improvements in the Event Classification menu can be viewed on the MetaFlows User Manual.  If using any of the four new features causes any confusion, or if there are any questions, do not hesitate to contact the MetaFlows team for assistance.