Hi everyone,
I have a question. We are processing nearly all the shadowserver feeds now (VNC is still missing) and we stumbled across a problem that we can not 100% solve currently: how do you deal with 'accessible and only potentially vulnerable' devices?
Let me elaborate. Usually we sent out notifications on vulnerable devices (ENISA taxonomy: "Vulnerable". Examples: open recursive DNS, open NTP, anything mis-useable for UDP amplification attacks, etc).
However, at some point, accessible and (only potentially vulnerable) devices came into the game. I.e. a device running telnet (or something on the telnet port). Or VNC. The VNC server might be protected by a pwd.
So, how to deal with that? An ISP might rightfully say that this telnet port is there intentionally and we should not complain?
So, we now have two types that we are talking about: 1. Vulnerable and openly accessible ports 2. Potentially vulnerable (but not proven) and accessible ports
Candidates for the second type would be: * VNC * telnet * RDP * (maybe) Redis * (maybe) ES * (maybe) memcached * (maybe) Mongo
What's your stance on this? How do you deal with it?
Note that we are sending out * a lot* as a national CERT and we would not like an ISP to be swamped by our mails if it does not have to be the case.
Best, a.
-- // L. Aaron Kaplan kaplan@cert.at - T: +43 1 5056416 78 // CERT Austria - http://www.cert.at/ // Eine Initiative der nic.at GmbH - http://www.nic.at/ // Firmenbuchnummer 172568b, LG Salzburg
Am Montag 13 März 2017 13:02:47 schrieb L. Aaron Kaplan:
So, we now have two types that we are talking about: 1. Vulnerable and openly accessible ports 2. Potentially vulnerable (but not proven) and accessible ports
It depends, there are probably ISP/network owner who would want to be notified of some potentially vulnerable situation and others would rather not.
This challenge could be approached with * make automatic handling a lot easier, so ofr example if everything gets xarf files the recievers could more easily just ignore stuff on their end. Conclusion some notification should only be send out if their automated handling is easy.
* When it is not clearly vulnerable, a notifcation is a service. Maybe the isps/network owner can subscribe or unsubscribe to details of the service on their own. Like "Go to URL to opt out of the "potentially interesting" ports group".
Just my 2 Euro-¢, Bernhard
Hi Aaron,
We're processing a couple of shadowserver feeds daily (drone report, sinkhole etc) others we do only on an incidental basis. Last week I send out notifications for the VNC feed with the following context. It might be an open VNC server and you should fix that, if it's not, we as NCSC have published some guidelines on how to secure your networks and you should prevent having a management interface (Open VNC) open on the internet. So please use VNC over a VPN or a different countermeasure.
Also we have specific mail templates that we send out with each feed in which you can give specific context per feed.
Hope this helps!
Cheers, Jop
Jop van der Lelie Security Specialist ................................................................. National Cyber Security Centre P.O. Box 117 | 2501 CC | The Hague | www.ncsc.nl ................................................................. T +31 70 751 55 36 E jop.vanderlelie@ncsc.nl PGP BAD3 8576 5B73 82A4 5E31 572B 9430 93ED 294E 7F0A .................................................................
-----Original Message----- From: L. Aaron Kaplan [mailto:kaplan@cert.at] Sent: maandag 13 maart 2017 13:03 To: intelmq-dev@lists.cert.at; ihap@lists.trusted-introducer.org Subject: [IHAP] How do you notify ISPs/network owners about accessible (open) devices?
Hi everyone,
I have a question. We are processing nearly all the shadowserver feeds now (VNC is still missing) and we stumbled across a problem that we can not 100% solve currently: how do you deal with 'accessible and only potentially vulnerable' devices?
Let me elaborate. Usually we sent out notifications on vulnerable devices (ENISA taxonomy: "Vulnerable". Examples: open recursive DNS, open NTP, anything mis-useable for UDP amplification attacks, etc).
However, at some point, accessible and (only potentially vulnerable) devices came into the game. I.e. a device running telnet (or something on the telnet port). Or VNC. The VNC server might be protected by a pwd.
So, how to deal with that? An ISP might rightfully say that this telnet port is there intentionally and we should not complain?
So, we now have two types that we are talking about: 1. Vulnerable and openly accessible ports 2. Potentially vulnerable (but not proven) and accessible ports
Candidates for the second type would be: * VNC * telnet * RDP * (maybe) Redis * (maybe) ES * (maybe) memcached * (maybe) Mongo
What's your stance on this? How do you deal with it?
Note that we are sending out * a lot* as a national CERT and we would not like an ISP to be swamped by our mails if it does not have to be the case.
Best, a.
-- // L. Aaron Kaplan kaplan@cert.at - T: +43 1 5056416 78 // CERT Austria - http://www.cert.at/ // Eine Initiative der nic.at GmbH - http://www.nic.at/ // Firmenbuchnummer 172568b, LG Salzburg
Hello Aaron,
From: "L. Aaron Kaplan" kaplan@cert.at, Date: Mar 13, 2017
I have a question. We are processing nearly all the shadowserver feeds now (VNC is still missing) and we stumbled across a problem that we can not 100% solve currently: how do you deal with 'accessible and only potentially vulnerable' devices?
Let me elaborate. Usually we sent out notifications on vulnerable devices (ENISA taxonomy: "Vulnerable". Examples: open recursive DNS, open NTP, anything mis-useable for UDP amplification attacks, etc).
However, at some point, accessible and (only potentially vulnerable) devices came into the game. I.e. a device running telnet (or something on the telnet port). Or VNC. The VNC server might be protected by a pwd.
So, how to deal with that? An ISP might rightfully say that this telnet port is there intentionally and we should not complain?
So, we now have two types that we are talking about:
- Vulnerable and openly accessible ports
- Potentially vulnerable (but not proven) and accessible ports
Candidates for the second type would be:
- VNC
- telnet
- RDP
- (maybe) Redis
- (maybe) ES
- (maybe) memcached
- (maybe) Mongo
What's your stance on this? How do you deal with it?
we are using eCSIRT.net taxonomy (actually mkII from Don Stikvoort), and we have stumbled into this. eCSIRT.net is two level, so we have decided to add another "distinctive" level - Vulnerable.Config and Vulnerable.Open, where the former is "just" open (your case, I believe), and the latter is the confirmed vulnerability. (See [1].) Regarding the "uncertainty" problem - in my opinion that is another type of information, orthogonal to classification, as any info can be uncertain or in some way unverified. In Idea we have the "Confidence" key, which may be the indicator that the event is not completely reliable.
Note that we are sending out * a lot* as a national CERT and we would not like an ISP to be swamped by our mails if it does not have to be the case.
I feel your pain. :) Been there (heck, mostly we still are). We (at Czech NREN level) have ended with marking the varieties of events we are sending out with "severity" (low, med, high, crit), and deciding how often to send reports based on that. (End admins are also able to mark some services as "legitimate" to filter out false positives, but that might not be good approach at national level, where you usually want to take careful stance).
Cheers -- Pavel Kácha, CESNET
Hi Aaron,
to German network operators/providers, we are reporting openly accessible UDP-based services which are commonly abused for DRDoS attacks as well as openly accessible databases (MongoDB, etc.) on a regular basis.
HOWTOs for affected system owners are provided in German and English language at https://reports.cert-bund.de/ https://reports.cert-bund.de/en/
We are currently NOT reporting services like Telnet or VNC for the reasons you mention.
However, we process the data on other services for our primary constituencies (agencies on gov/state level, critical infrastructure).
- Thomas
CERT-Bund Incident Response & Malware Analysis Team
On 13.03.2017 13:02, L. Aaron Kaplan wrote:
Hi everyone,
I have a question. We are processing nearly all the shadowserver feeds now (VNC is still missing) and we stumbled across a problem that we can not 100% solve currently: how do you deal with 'accessible and only potentially vulnerable' devices?
Let me elaborate. Usually we sent out notifications on vulnerable devices (ENISA taxonomy: "Vulnerable". Examples: open recursive DNS, open NTP, anything mis-useable for UDP amplification attacks, etc).
However, at some point, accessible and (only potentially vulnerable) devices came into the game. I.e. a device running telnet (or something on the telnet port). Or VNC. The VNC server might be protected by a pwd.
So, how to deal with that? An ISP might rightfully say that this telnet port is there intentionally and we should not complain?
So, we now have two types that we are talking about:
- Vulnerable and openly accessible ports
- Potentially vulnerable (but not proven) and accessible ports
Candidates for the second type would be:
- VNC
- telnet
- RDP
- (maybe) Redis
- (maybe) ES
- (maybe) memcached
- (maybe) Mongo
What's your stance on this? How do you deal with it?
Note that we are sending out * a lot* as a national CERT and we would not like an ISP to be swamped by our mails if it does not have to be the case.
Best, a.
-- // L. Aaron Kaplan kaplan@cert.at - T: +43 1 5056416 78 // CERT Austria - http://www.cert.at/ // Eine Initiative der nic.at GmbH - http://www.nic.at/ // Firmenbuchnummer 172568b, LG Salzburg
Intelmq-dev mailing list Intelmq-dev@lists.cert.at http://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev