community.ui.com Open in urlscan Pro
2600:9000:24f3:2800:1f:7c20:b2c0:93a1  Public Scan

Form analysis
0 forms found in the DOM

Text Content

CommunityTopicsStoriesReleasesSupport


Sign upLog in

Back
Ask a related question
Posted 4 years agoLast Activity 6 months ago



IPS: THUNDERNETWORK

3
1311k
CommentFollow

I keep getting the following IPS alert. It's happened at at least two sites:

 

Message: IPS Alert 1: Potential Corporate Privacy Violation. Signature ET P2P
ThunderNetwork UDP Traffic. From: fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx:xxxxx,
to: ff02:0000:0000:0000:0000:0000:0001:0003:5355, protocol: UDP

 

the x's are variable.

 

These sites aren't using IPv6, and I have no idea how to track this down, or
what it's trying to tell me. Any ideas?


RESPONSES (13)

Sort by
NewestOldest
Page
1


L
littlewolf
4 years ago


They are using IPv6 at minimum on your LANs, even when you believe they are not
since you did not set up any IPv6 on your router. IPv6 has been the preferred
protocol in any decent OS for years. The above is LLMNR traffic. 

0
B
bsullo
4 years ago


Yes, I realize all the systems have IPv6 enabled. I meant that the router has no
IPv6 configured on its interfaces.

So, this is normal, internal traffic. Why is IPS detecting it as traffic to a
specific P2P service?

0
L
littlewolf
4 years ago


You are welcome to read the ET signature to determine
why. https://doc.emergingthreats.net/bin/view/Main/2009099

 

As for why is it hitting the USG - well, because it's multicast. 

 

IDS/IPS is not a set and forget feature, you need to whitelist obvious false
positives and broken signatures.

0
B
bsullo
4 years ago


Okay. How would I have ever connected that alert to the URL you provide? There's
nothing in the alert that says where to go for more information.

Also, when I open that URL, what am I looking at? It's all gibberish without
some sort of context.

0
L
littlewolf
4 years ago


There's extensive documentation available on the Suricata rules. Have fun. 😁

 

IMHO this feature lacks a big red warning that it's not intended for everyone.
You are going to have hard time tweaking the setup to not interfere with your
legitimate usage patterns when it's "all gibberish" to you.

-1
B
bsullo
4 years ago


You don't need to be condescending. I'm not an idiot, just not familiar with
this system yet.

 

There is nothing in the Ubiquiti IPS alerts that says they have anything to do
with the sites you referenced. How would anyone new to Ubiquiti IPS know this
unless someone tells them? Thank you for telling me.

 

The site you referenced is code. It would be gibberish to anyone without the
proper key. I'm guessing the Security Rules page holds that key (though I don't
know what Securita is, or how it factors into the Unifi IPS system).

4
L
littlewolf
4 years ago


Suricata is the IPS. That was not meant to be condescending, that was a
statement of fact. Do yourself a favour and run that as IDS only, not as IPS --
until you get a whole lot more familiar with that thing and false positives.
Takes weeks to tune, requires monitoring even after that since any buggy new or
updated rule can completely kill your internet access (e.g., by blocking
legitimate DNS servers). An overzealous choice of rule categories can be
disastrous as well.

 

If you are not willing to invest a lot of time into learning, you'll be a whole
lot better off disabling that feature altogether.

 

Suricata/Snort IDS/IPS are not a consumer level feature, at all. Turns into a
nightmare and useless resource hog and nuisance when used as such. There
absolutely should a big red warning about these facts.

0
B
bsullo
4 years ago


Forgive my jumping to interpretations.

 

So far, we're running IPS at 9 sites with all categories full on. We've had a
number of false positives, but nothing disruptive. In fact, I sometimes wonder
if it's actually blocking, since we get alerts for things like "GPL CHAT
Jabber/Google Talk Outgoing Traffic" and "ET CHAT Skype User-Agent detected",
yet no one has ever complained of Google Talk or Skype not working.

 

Now that I know that at least some of the signatures can be found at the
Emerging Threats site (Still not sure of the relationship between
EmergingThreats.net, Securita, and Unifi.), and now that I understand how to
interpret the signatures, I see "ET CHAT Skype User-Agent detected" has an
"alert" action, rather than a "drop" action. It would be really nice if Unifi's
alerts informed you of what it actually did with the traffic it's alerting you
to. Others on this forum have stated that having IPS turned on (as opposed to
IDS) it blocks everything it alerts for, but I wonder if that's acutally true.

 

I could not find the "GPL CHAT Jabber/Google Talk Outgoing Traffic" at
EmergingThreats.net, and I assume that has something to do with the "GPL" as
opposed to "ET" at the start of the message. If only I knew what GPL stood for .
. .

3
L
littlewolf
4 years ago


- Suricata - the IDS/IPS software. (Snort is the other major open-source
IDS/IPS).

 

- Emerging Threats (ET) - publishes some rulesets that can be used by
Snort/Suricata. There's a free ET ruleset, there's a paid (ET Pro) one. The free
one is basically one month behind the paid option. Then there are also other
rulesets available from Snort - community (GPL) and paid - made for Snort but
mostly compatible with Suricata (the incompatible ones will be simply ignored).
Finally, you can also write your own rules in case you have the knowledge.

 

- UBNT only plugs into those, provisioning YAML configuration for Suricata based
on your GUI configuration.

 

- IDS will only alert. Now with IPS, you can either use the policy keywords
defined in the rules (connectivity, balanced, security, none) to choose what to
block (e.g., the rule can have Block action defined for security policy, and
Alert action for the remaining policies), or choose your own rule actions.
What's exactly UBNT doing here, I don't know. You need to ask them directly or
dig into configuration via shell.

 

Understanding what's exactly being done here is of course critical. This needs
to be documented. Plus whole lot more configurable. And also absolutely requires
that you can define the interfaces where Suricata should run. With no HW
offloading possible, combined with lack of L3 switching, running Suricata on all
interfaces (which apparently is the case at the moment), this is totally a
network performance killer.

 

5
A
ablade75
7 months ago


Apologies for the bump, but I think this is a bug. We have exactly the same
alert, with exactly the same IPv6 addresses (it was a search for the IPv6 that
lead me here), generated 2 days ago.

1
G
gwatson1
7 months ago


@bsullo "You don't need to be condescending. I'm not an idiot, just not
familiar"

From someone who feels like he is in a similar position - sometimes the
cause/effect isn't always directly linked - I received the same threat alerts -
and I "perceive" that they disappeared when I unlinked port "Link Aggregation"
on multiple poe ports on a USW Pro 24 POE switch ...

Above someone basically told you that we have IPv6 dns multicast resolution
generating an error over one of our switches ...

I am sure someone much smarter than I could interpret that "fe80:xxx...."
address style source that you and I received in our alerts and probably tell us
that the device source isn't what you and I think of as a physical device on our
network ...

So - try what I did and see if you can did through what is happening on your
Layer 3 switches that can do the routing at that level - and then you can find
narrow the source ...

In my case - the solution was to configure the device on the other side of the
link-aggregation to only use IPv4 and my alerts went away ...

I am sure there are dozens of variations off this type of theme ... where the
source of the problem does not directly reflect the alert we receive - and the
alert we receive has what appears to be an unidentifiable source ...

DrG

0
G
genexpieguy
6 months ago


FWIW, I just had one of these as well. Exactly the same as indicated in the
first post. I'm not knowledgeable enough to know exactly what it is, but
knowledgeable enough not to panic over it.

0
acelis
6 months ago


I'm having the same issue. The UniFi Alert actually doesn't give you all of the
details.

I actually have an API call that pulls the full IPS alert record... which
actually includes the MAC addresses of the source and destination devices.

Here is an example of the full alert record:

UniFi Network Alarm at [REDACTED]

Date and time of alarm: 2022-04-30T00:33:36Z 
Message: IPS Alert 1: Potential Corporate Privacy Violation. Signature ET P2P ThunderNetwork UDP Traffic. From: fe80:0000:0000:0000:101e:6680:3b64:ae91:65077, to: ff02:0000:0000:0000:0000:0000:0001:0003:5355, protocol: UDP 
full alarm details: 


{
    "_id": "626c83e1788b2a1f300283d9",
    "archived": false,
    "timestamp": 1651278816,
    "flow_id": 1475589766651247,
    "in_iface": "eth1",
    "event_type": "alert",
    "src_ip": "fe80:0000:0000:0000:101e:6680:3b64:ae91",
    "src_mac": "a4:bb:6d:b9:d4:2e",
    "src_port": 65077,
    "dest_ip": "ff02:0000:0000:0000:0000:0000:0001:0003",
    "dst_mac": "33:33:00:01:00:03",
    "dest_port": 5355,
    "proto": "UDP",
    "app_proto": "failed",
    "host": "b4:fb:e4:cc:c6:20",
    "usgip": "[REDACTED]",
    "unique_alertid": "928214190-2022-04-29T19:33:36.073071-0500",
    "srcipGeo": [],
    "dstipGeo": [],
    "usgipGeo": {
        "continent_code": "NA",
        "country_code": "US",
        "country_name": "United States",
        "city": "Houston",
        "latitude": 29.69,
        "longitude": -95.2564,
        "asn": 7922,
        "organization": "COMCAST-7922"
    },
    "usgipCountry": "US",
    "usgipASN": "7922 COMCAST-7922",
    "catname": "emerging-p2p",
    "inner_alert_action": "allowed",
    "inner_alert_gid": 1,
    "inner_alert_signature_id": 2009099,
    "inner_alert_rev": 4,
    "inner_alert_signature": "ET P2P ThunderNetwork UDP Traffic",
    "inner_alert_category": "Potential Corporate Privacy Violation",
    "inner_alert_severity": 1,
    "key": "EVT_IPS_IpsAlert",
    "subsystem": "www",
    "is_negative": true,
    "site_id": "5cbf48bcf2d1ef0790fd55fc",
    "time": 1651278816000,
    "datetime": "2022-04-30T00:33:36Z",
    "msg": "IPS Alert 1: Potential Corporate Privacy Violation. Signature ET P2P ThunderNetwork UDP Traffic. From: fe80:0000:0000:0000:101e:6680:3b64:ae91:65077, to: ff02:0000:0000:0000:0000:0000:0001:0003:5355, protocol: UDP"
}




Here's the thing. I run a full UniFi stack and IPv6 is disabled on the WAN
interface and on the LAN and VLAN interfaces IPv6 is set to none.

I inspected the source PC of this traffic and couldn't find anything that might
trigger this. Even at the time of the alarm, the PC was idle with no under
intervention for some time.

I did see that the source PC did have IPv6 enabled in it's ethernet adapter
settings. I'm going to try disabling that and see if it stops these alarms.



0

Page
1


YOUR RESPONSE

Write your response here ...
Comment
B
bsullo
4 years ago


TAGS

UniFiUniFi Routing & Switching

UI.com

Community feedbackTerms of ServicePrivacy PolicyLegal
© 2022 Ubiquiti, Inc. All Rights Reserved.




PRIVACY PREFERENCE CENTER

When you visit any website, it may store or retrieve information on your
browser, mostly in the form of cookies. This information might be about you,
your preferences or your device and is mostly used to make the site work as you
expect it to. The information does not usually directly identify you, but it can
give you a more personalized web experience. Because we respect your right to
privacy, you can choose not to allow some types of cookies. Click on the
different category headings to find out more and change our default settings.
However, blocking some types of cookies may impact your experience of the site
and the services we are able to offer. More Information
Allow All


MANAGE CONSENT PREFERENCES

FUNCTIONAL COOKIES

Always Active

These cookies enable the website to provide enhanced functionality and
personalisation. They may be set by us or by third party providers whose
services we have added to our pages.    If you do not allow these cookies then
some or all of these services may not function properly.

PERFORMANCE COOKIES

Always Active

These cookies allow us to count visits and traffic sources so we can measure and
improve the performance of our site. They help us to know which pages are the
most and least popular and see how visitors move around the site.    All
information these cookies collect is aggregated and therefore anonymous. If you
do not allow these cookies we will not know when you have visited our site, and
will not be able to monitor its performance.

TARGETING COOKIES

Always Active

These cookies may be set through our site by our advertising partners. They may
be used by those companies to build a profile of your interests and show you
relevant adverts on other sites.    They do not store directly personal
information, but are based on uniquely identifying your browser and internet
device. If you do not allow these cookies, you will experience less targeted
advertising.

STRICTLY NECESSARY COOKIES

Always Active

These cookies are necessary for the website to function and cannot be switched
off in our systems. They are usually only set in response to actions made by you
which amount to a request for services, such as setting your privacy
preferences, logging in or filling in forms.    You can set your browser to
block or alert you about these cookies, but some parts of the site will not then
work. These cookies do not store any personally identifiable information.


BACK BUTTON PERFORMANCE COOKIES

Vendor Search Search Icon
Filter Icon

Clear
checkbox label label
Apply Cancel
Consent Leg.Interest
checkbox label label
checkbox label label
checkbox label label


 * 33ACROSS
   
   HOST DESCRIPTION
   
   VIEW COOKIES
   
   
    * Name
      cookie name


 * 33ACROSS
   
   View Privacy Notice
   
   

Confirm My Choices