Ntopng SSLv3 and TLSv1.0
-
In respect to your other thread talking about vulnerabilities your scanning from outside pointed out… Why would you have this open to the public internet anyway?
-
Actually, I don't have it open (entirely) to the public, just for the scanning (Qualys) and then I disable the rule when the scanning is done. If I don't allow the scans to penetrate, results show that they are being prevented from scanning OR that the target doesn't exist which violates the compliance level we wish to maintain.
So the port 3000 isn't actually allowed via the WAN but their scans are incredibly thorough.
Also, the two involves different hosts. This post covers all my FW but the other one only involves a non production FW that we test configs on prior to production deployments.
-
"If I don't allow the scans to penetrate"
What?? BS where did you get that information?? Now if you created a specific rule that BLOCKED their IP then that would be an invalid test. But if this is suppose to be an assessment what is open/vulnerable from the public internet.. You sure and shit shouldn't create rules that give them more access then what your normal rules allow for. If you don't allow ping, then they can not freaking even ping you, etc.
If you created specific rules that gave access to wan that is different than your normal rules then the whole test is just BS…
Are you saying you modified your wan rules that ALLOW access that is locked to specific IP/Ranges to include their IP? That might have legit use, but to be honest not a real test of anything. If I say had a rule that allowed my remote site to hit my vpn port.. And you allowed them to hit the port for their scan.. And they came back and said hey that vpn is open to xyz.. Ok might be of some value - but you have to take into account that only specific IP abc can even talk to it, so from a security assessment you would have to take that into consideration, etc.
-
Point taken and in the context that it was read, extremely valid.
The scanning isn't to prove that the firewall works. That is entirely different scanning and conversation. The scanning that I'm performing right now is for Vulnerabilities, Malware, and SSL/TLS issues. a.k.a; If the attack did penetrate (which our first scans show we were pretty good there), what would attackers have to work with from the inside which everyone should assume is the most vulnerable.
Lastly, I was sold on Qualys in the past and my evaluations now haven't changed that. The next level of evaluations has a virtual appliance that does the scanning from the inside out so NO rule manipulation needs to happen on the firewall. But to get to that next step, I needed proof for the higher ups that the time spent would be worth it.
I respect your post because I'm on the forum enough (can't say a lot but…) to know that you have posted to a number of 'not so bright' individuals that don't know what their doing. Me, I would like to believe that I'm doing pretty good with what I've learned thus far AND that I've got a HECK of a lot more to learn (and I can't wait).
So... with ALL that said, and that I believe for the most part my WAN and DMZ are locked down pretty good, what are my options to limiting access to only the most secure versions SSL / TLS on ntopng?
-
Create an OpenVPN instance and then view your metrics through the secure connection. Never expose your firewall internals on WAN.
-
I have used Qualys many times over the years for many different companies.. Have gone through multiple audits for security… Never do I recall or for that matter doing anything to the wan rules!! Opening up the wan rules like that is not a valid test by any means..
I can understand scanning for vulnerabilities.. Have used qualys for this and nessus, now tenable, etc.. Scanning for vulnerabilities after you have opened the ports to expose something is not a valid test.. It just isn't in what context does it make sense to do that. If your saying someone has already gained access to your firewall what is the point in saying that the redis your running on it is not current? Your already F'd ;)
If you have the web gui exposed and they say hey your SSL version is bad.. Ok then.. But if its not exposed then its moot...
Now if they scan it from one of your local networks and tell you hey this is bad, then sure you need to mitigate that.. You either update the something, or patch it. Or lock it down to limited access.. Like a management machine would be the only machine able to access the web gui, etc.
-
Scans. No Scans. How I came about finding out that an older insecure version of SSL/TLS is being used is moot. The fact that its true isn't.
Are there plans in future versions of ntopng to make it more secure? More specifically removing the option to use the less secure versions of SSL/TLS.
-
From my understanding from this
https://github.com/pfsense/FreeBSD-ports/pull/172It uses the same settings as your webgui.. You can for sure used to be able to edit what the webgui uses in the /etc/inc/system.inc back prior to nginx.. I have not looked into changing this since back in march.. Here
https://forum.pfsense.org/index.php?topic=107775.0When I scan my pfsense webgui for ssl I don't see it present ssl3 or tls 1.. What are you saying is not secure in presented ciphers?
> sslscan pfsense.local.lan Version: 1.11.0 Windows 64-bit (Mingw) OpenSSL 1.0.2 22 Jan 2015 Testing SSL server pfsense.local.lan on port 443 TLS renegotiation: Session renegotiation not supported TLS Compression: Compression disabled Heartbleed: TLS 1.2 not vulnerable to heartbleed TLS 1.1 not vulnerable to heartbleed TLS 1.0 not vulnerable to heartbleed Supported Server Cipher(s): Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve P-256 DHE 256 Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve P-256 DHE 256 Accepted TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384 DHE 4096 bits Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256 DHE 4096 bits Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA384 Curve P-256 DHE 256 Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve P-256 DHE 256 Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA256 DHE 4096 bits Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA DHE 4096 bits Preferred TLSv1.1 256 bits ECDHE-RSA-AES256-SHA Curve P-256 DHE 256 Accepted TLSv1.1 256 bits DHE-RSA-AES256-SHA DHE 4096 bits SSL Certificate: Signature Algorithm: sha512WithRSAEncryption RSA Key Strength: 4096 Subject: pfsense.local.lan Altnames: DNS:pfsense.local.lan, IP Address:192.168.9.253, DNS:pfsense.wlan.local.lan, IP Address:192.168.2.253 Issuer: pfsense-ca Not valid before: Jul 9 10:41:16 2016 GMT Not valid after: Jul 7 10:41:16 2026 GMTNow I do use my own cert and not self signed but this really wouldn't have anything to do with it. So what exactly are the issues with the ssl/tls that seeing. Guess I could install the ntop package and take a look see. But from that above pull ssl/tls was even available before and they adjusted it to use the same settings as the webgui.
edit: So need to find out if ntop package is using same as the webgui. I just tested the webugi from outside with qualys.. Now clearly they are not going to trust my selfsigned.. But notice the A rating if you don't take into account the lack of trust. To do so had to allow 443 into my wan rules..
-
Ntopng runs its own web engine on port 3000, separate from the pfSense ui. I expect the issue of obsolete protocols will be resolved when the ntopng version moves to 2.4.
Regardless of what protocol and encryption is being used, one should not assume that the ntopng interface is secure. Under no circumstance should it be exposed to the internet.
-
"Under no circumstance should it be exposed to the internet."
Exfreackingactly!!!
