Probably once a week, I see posts like this in the r/Ubiquiti subreddit. Ubiquiti makes network gear that includes an "IDS/IPS" feature. I own some older Ubiquiti gear so I am familiar with the product.

When you enable this feature, you get alerts like this one, posted by a Redditor:



This is everything you get from Ubiquiti.
 
The Redditor is concerned that their system may be trying to compromise someone on the Internet.

This is my answer to how to handle these alerts.
 
==

This is another example of this sort of alert being almost worthless for most users.

The key is trying to understand what COULD have caused the alert to trigger. CVEs, whatever, are irrelevant at this point.

Here is one way to get SOME idea of what is happening.

Go to

https://rules.emergingthreats.net/open/suricata-7.0.3/rules/

Download the file that is named as the first part of the alert. Here that is EXPLOIT.

https://rules.emergingthreats.net/open/suricata-7.0.3/rules/emerging-exploit.rules

Find the rule that fired. This can take some digging. Here is what I ended up doing.

grep -i possible emerging-exploit.rules | grep -i log4j | grep -i obfuscation | grep -i udp | grep -i outbound

Here it is.

alert udp $HOME_NET any -> any any (msg:"ET EXPLOIT Possible Apache log4j RCE Attempt - 2021/12/12 Obfuscation Observed M2 (udp) (Outbound) (CVE-2021-44228)"; content:"|24 7b|"; content:"|24 7b 3a 3a|"; within:100; fast_pattern; reference:cve,2021-44228; classtype:attempted-admin; sid:2034805; rev:3; metadata:attack_target Server, created_at 2021_12_18, cve CVE_2021_44228, deployment Perimeter, deployment Internal, signature_severity Major, tag Exploit, updated_at 2023_06_05, mitre_tactic_id TA0001, mitre_tactic_name Initial_Access, mitre_technique_id T1190, mitre_technique_name Exploit_Public_Facing_Application;)

You can ignore 90% of this. The key is here:

content:"|24 7b|"; content:"|24 7b 3a 3a|"; within:100

and here:

udp $HOME_NET any -> any any

Now, you have to guess how likely it might be there you could have ANY UDP traffic from your home network to anywhere, on any ports, that contain this string

24 7b

followed by this string

24 7b 3a 3a

within the next 100 bytes?

I'm guessing there's a decent chance that could happen in random, normal traffic.

Therefore, without any other evidence, I think you can ignore this alert.

If you want to have a better chance at understanding this in the future, please feel free to check out anything I've written about network security monitoring. Good luck!
 
==

This problem is why I have promoted network security monitoring since 1998 and subtitled my first book "Beyond Intrusion Detection." Network intrusion detection, by itself, with no supporting data and without even rule explanations, is almost worthless.

Thankfully in this case the vendor is at least using an open rule set, enabling this feeble exploration.

 


I wrote this on 7 December 2018 but never published it until today. The following are the "key network questions" which "would answer many key questions about [a] network, without having to access a third party log repository. This data is derived from mining Zeek log data as it is created, rather than storing and querying Zeek logs in a third party repository."

This is how I was thinking about Zeek data in the second half of 2018.

1. What networking technologies are in use, over user-specified intervals?
   1. Enumerate non-IP protocols (IPv6, unusual Ethertypes)
   2. Enumerate IPv4 and IPv6 protocols (TCP, UDP, ICMP, etc.)
   3. What is the local IP network topology/addressing scheme?

2. What systems are providing core services to the network, over user-specified intervals?
   1. DHCP
   2. DNS
   3. NTP
   4. Domain Controller
   5. File sharing
   6. Default gateway (via DHCP inspection, other?)
   7. Web and cloud services

3. What tunnel mechanisms are in use, over user-specified intervals?
   1. IPSec or other VPNs
   2. SOCKS proxy
   3. Web proxy (port 3128)
   4. Other proxy

4. What access services are in use, over user-specified intervals?
   1. SSH
   2. Telnet
   3. RDP
   4. VNC
   5. SMB
   6. Other

5. What file transfer services are in use, over user-specified intervals?
   1. SCP or other SSH-enabled file transfers
   2. FTP
   3. SMB
   4. NFS

6. Encryption measurement, over user-specified intervals
   1. What encryption methods are in use?
   2. What percentage of network traffic over a user-specified interval is encrypted, and by which method?

7. Bandwidth measurement, over user-specified intervals
   1. Aggregate
   2. By IP address
   3. By service

8. Conversation tracking, over user-specified intervals
   1. Top N connection pairs
   2. Bottom N connection pairs

9. Detection counts, over user-specified intervals
   1. Provide a counter of messages from Zeek weird.log
   2. Provide a counter of messages from other Zeek detection logs

10. For each IP address (or possibly IP-MAC address pairing), over user-specified intervals, build a profile with the following:
   1. First seen, last seen
   2. Observed names via DNS, SMB, other
   3. Core services accessed and provided
   4. Tunnel mechanisms used and provided
   5. Access services used and provided
   6. File transfer services used and provided
   7. Encryption methods
   8. Bandwidth measurements
   9. Top N and bottom N conversation tracking
   10. Detection counts


 

Over the weekend I organized some old computing equipment. I found this beauty in one of my boxes. It's a Netgear EN104TP hub. I've mentioned this device before, in this blog and my books. This sort of device was the last of the true hubs. In an age where cables seem reserved for data centers or industrial facilities, and wireless rules the home and office, this hub is a relic of days gone past.

To give you a sense of how old this device is, the Netgear documentation (still online -- well done) offers a PDF created in August 1998. (Again, well done Netgear, not mucking about with the timestamps.) I'm not sure how old my specific device is. Seeing as I started working in the AFCERT in the fall of 1998, I could see this hub being easily over 20 years old. 

A hub is a network device that accepts traffic from its ports and repeats the traffic to all other ports. This is different from a switch, which maintains a table identifying which MAC addresses are in use on which ports. Before building this CAM (content addressable memory, IIRC) table, traffic to a new previously unforeseen MAC address will appear on all ports save the sender.

This is a "true hub" because all of the ports are 10 Mbps. Yes, that is 100 times "slower" than the Gigabit ports on modern devices, if they have Ethernet ports at all. Starting with 10/100 Mbps devices, they all became switches. I never encountered a 100 Mbps "hub." Every device I ever had hands on was a 10/100 Mbps switch. That meant you were unlikely to see traffic on all ports when using a 10/100 Mbps device or even a 100 Mbps device (which I never saw anyway). There were no Gigabit (1000 Mbps) hubs built. I don't think the specification even supports it.

These little boxes were network monitoring enablers. If you wanted to learn, or troubleshoot, or possibly even add monitoring to a production network, you could connect an upstream cable, a downstream cable, and a monitoring cable to the hub. The upstream could be a router and the downstream might be a firewall, and the monitoring would be your NSM server. If you were looking at traffic between two individual computers and needed visibility for a NSM laptop, you would plug all three into the hub, and plug your Internet upstream into the fourth port.

I haven't needed this device in years, but I plan to keep it as a physical artifact of a time long past. At least this one still powers on, unlike my first computer, a Timex Sinclair ZX-80.


This is a quick note to point blog readers to my Zeek in Action YouTube video series for the Zeek network security monitoring project

Each video addresses a topic that I think might be of interest to people trying to understand their network using Zeek and adjacent tools and approaches, like Suricata, Wireshark, and so on. 

I am especially pleased with Video 6 on monitoring wireless networks. It took me several weeks to research material for this video. I had to buy new hardware and experiment with a Linux distro that I had not used before -- Parrot

Please like and subscribe, and let me know if there is a topic you think might make a good video.