- Link Source Compatibility Type, Technology Created Updated Rating; Template Sophos UTM v 9.6 over API Template to monitor configuration changes on Sophos UTM devices with v 9.6.
- This is a complete list of technologies currently supported by Devo. This means that Devo is prepared to ingest event data from these technologies and parse the events for display.
- SNMP (Simple Network Management Protocol) allows you to configure Sophos XG Firewall as an SNMP agent. The device responds to multiple SNMP managers within the predefined communities. You can monitor multiple firewall devices on IP networks for device availability, CPU, memory and disk utilization, availability of critical services, and more.
Sophos is a jaw-dropping UTM, and its free home version license is surprisingly generous. The feature set and web-based GUI easily place it up there with my other 2 top UTM choices-Untangle and PFSense, so it's certainly worth a try-out. My criticisms are few and admittedly strict.
- Plugin version: v4.2.1
- Released on: 2018-12-30
For other versions, see theVersioned plugin docs.
For questions about the plugin, open a topic in the Discuss forums. For bugs or feature requests, open an issue in Github.For the list of Elastic supported plugins, please consult the Elastic Support Matrix.
The 'netflow' codec is used for decoding Netflow v5/v9/v10 (IPFIX) flows.
This codec supports:
- Netflow v5
- Netflow v9
- IPFIX
The following Netflow/IPFIX exporters have been seen and tested with the most recent version of the Netflow Codec:
Netflow exporter | v5 | v9 | IPFIX | Remarks |
---|---|---|---|---|
Barracuda Firewall | y | With support for Extended Uniflow | ||
Cisco ACI | y | |||
Cisco ASA | y | |||
Cisco ASR 1k | N | Fails because of duplicate fields | ||
Cisco ASR 9k | y | |||
Cisco IOS 12.x | y | |||
Cisco ISR w/ HSL | N | Fails because of duplicate fields, see: https://github.com/logstash-plugins/logstash-codec-netflow/issues/93 | ||
Cisco WLC | y | |||
Citrix Netscaler | y | Still some unknown fields, labeled netscalerUnknown<id> | ||
fprobe | y | |||
Fortigate FortiOS | y | |||
Huawei Netstream | y | |||
ipt_NETFLOW | y | y | y | |
IXIA packet broker | y | |||
Juniper MX | y | y | SW > 12.3R8. Fails to decode IPFIX from Junos 16.1 due to duplicate field names which we currently don’t support. | |
Mikrotik | y | y | ||
nProbe | y | y | y | L7 DPI fields now also supported |
Nokia BRAS | y | |||
OpenBSD pflow | y | N | y | |
Riverbed | N | Not supported due to field ID conflicts. Workaround available in the definitions directory over at Elastiflow https://github.com/robcowart/elastiflow | ||
Sandvine Procera PacketLogic | y | v15.1 | ||
Softflowd | y | y | y | IPFIX supported in https://github.com/djmdjm/softflowd |
Sophos UTM | y | |||
Streamcore Streamgroomer | y | |||
Palo Alto PAN-OS | y | |||
Ubiquiti Edgerouter X | y | With MPLS labels | ||
VMware VDS | y | Still some unknown fields | ||
YAF | y | With silk and applabel, but no DPI plugin support | ||
vIPtela | y |
Example Logstash configuration that will listen on 2055/udp for Netflow v5,v9 and IPFIX:
For high-performance production environments the configuration below will decode up to 15000 flows/sec from a Cisco ASR 9000 router on a dedicated 16 CPU instance. If your total flowrate exceeds 15000 flows/sec, you should use multiple Logstash instances.
Note that for richer flows from a Cisco ASA firewall this number will be at least 3x lower.
To mitigate dropped packets, make sure to increase the Linux kernel receive buffer limit:
Setting | Input type | Required |
---|---|---|
a valid filesystem path | No | |
No | ||
No | ||
a valid filesystem path | No | |
a valid filesystem path | No | |
No | ||
No |
- Value type is path
- There is no default value for this setting.
Enables the template cache and saves it in the specified directory. Thisminimizes data loss after Logstash restarts because the codec doesn’t have towait for the arrival of templates, but instead reload already receivedtemplates received during previous runs.
Template caches are saved as:
- path/netflow_templates.cache for Netflow v9 templates.
- path/ipfix_templates.cache for IPFIX templates.
- Value type is number
- Default value is
4000
Netflow v9/v10 template cache TTL (seconds)
- Value type is boolean
- Default value is
false
Only makes sense for ipfix, v9 already includes thisSetting to true will include the flowset_id in eventsAllows you to work with sequences, for instance with the aggregate filter
- Value type is path
- There is no default value for this setting.
Override YAML file containing IPFIX field definitions
Very similar to the Netflow version except there is a top level PrivateEnterprise Number (PEN) key added:
There is an implicit PEN 0 for the standard fields.
See https://github.com/logstash-plugins/logstash-codec-netflow/blob/master/lib/logstash/codecs/netflow/ipfix.yaml for the base set.
- Value type is path
- There is no default value for this setting.
Override YAML file containing Netflow field definitions
Each Netflow field is defined like so:
See https://github.com/logstash-plugins/logstash-codec-netflow/blob/master/lib/logstash/codecs/netflow/netflow.yaml for the base set.
- Value type is string
- Default value is
'netflow'
Sophos Utm 9 Netflow
Specify into what field you want the Netflow data.
- Value type is array
- Default value is
[5, 9, 10]
Specify which Netflow versions you will accept.
Most Popular
Blacknurse is a low bandwidth ICMP attack that is capable of doing denial of service to well known firewalls.
Most ICMP attacks that we see are based on ICMP Type 8 Code 0 also called a ping flood attack.
BlackNurse is based on ICMP with Type 3 Code 3 packets. We know that when a user has allowed ICMP Type 3 Code 3 to outside interfaces, the BlackNurse attack becomes highly effective even at low bandwidth.
Low bandwidth is in this case around 15-18 Mbit/s. This is to achieve the volume of packets needed which is around 40 to 50K packets per second. It does not matter if you have a 1 Gbit/s Internet connection.
The impact we see on different firewalls is typically high CPU loads. When an attack is ongoing, users from the LAN side will no longer be able to send/receive traffic to/from the Internet. All firewalls we have seen recover when the attack stops.
Sophos Firewall Netflow
Please provide us with information on firewalls and routers that are affected by BlackNurse - you can send information toinfo@blacknurse.dk, and we will maintain a list of products on BlackNurse.dk.
The best way to test if your systems are vulnerable, is to allow ICMP on the WAN side of you firewall and do some testing with Hping3. When attacking the outside wan, try to do some internet surfing from the inside and out. In our test we used an Ubuntu installation with Hping3 installed. When testing, you have to be able to reach outbound internet speed of at least 15-18 Mbit/s.
Use Hping3 with one of the following commands:
hping3 -1 -C 3 -K 3 -i u20 <target ip>
hping3 -1 -C 3 -K 3 --flood <target ip>
Based on our test, we know that a reasonable sized laptop can produce approx. a 180 Mbit/s DoS attack with these commands. We have also made tests using a Nexus 6 mobile phone with Nethunter/Kali which only can produce 9.5 Mbit/s and therefore cannot single-handedly perform the BlackNurse attack.
Please read the full report for help to mitigate the attack, including detection rules, details of the testing done so far and more nice knowlegde.