Hi,
One of my customers has had a visit by a security consultant.
The report indicates that the following should be addressed:
Anybody who can comment on these issues and preferably come up with “How-To” or directions?
PS.: Upgrading is not an option at this moment.
Thank you
can you try this?
https://isc.sans.edu/forums/diary/NTP+reflection+attack/17300/
also for the DH thing you can check out /etc/ssh/moduli file
you can generate your own using ssh-keygen
f.e
ssh-keygen -G moduli-2048.candidates -b 2048
ssh-keygen -T moduli-2048 -f moduli-2048.candidatesMichael.
On 09/24/2015 06:14 AM, moldin wrote:[color=blue]
One of my customers has had a visit by a security consultant.
The report indicates that the following should be addressed:
- NTP monlist command should be deactivated[/color]
I’m guessing your customer paid good money for good recommendations from
the “security consultant”, and unfortunately it seems like they had a
pretty typical (meaning poor) result. The problem with these
practitioners is that they come in, run their default tool that often just
looks for open ports or queries services to find their versions, and then
print out a list of issues known to, at one time, possibly impact those
services on, maybe on those versions. They do not usually test for actual
vulnerabilities (that would require a real security expert) on boxes
(preferably isolated boxes for penetration testing) and so the results are
usually a nice long list of false positives.
Case in point, this existed a couple of years ago. Of course, a couple of
years is a long time in computing, so it was also fixed a couple of years
ago, including for your customer as long as they’re on SLES 11 SP3 plus
patches, or any subsequent version/SP of SLES (11 SP4, 12, etc.). You can
find information on this vulnerability here:
https://www.suse.com/security/cve/CVE-2013-5211.html
As the site shows, it was fixed long ago, and also has workarounds you can
implement for systems that cannot yet be patched for whatever reason. If
you query the ‘ntp’ package as shown below you can also search for the CVE
number in the RPM’s changelog to verify the fix is included in there.
The reason this matters on many systems, particularly enterprise
distributions of Linux, is that major/minor version number changes imply
new features, which imply more risk because of less-tested code. In
Enterprise Linux that’s the opposite of what we want, but we still want
fixes. As a result, vendors like SUSE take fixes and backport them into
older packages so you get the stability of the old with the fixes of the
new; this is why we pay for things like patches/updates, as SUSE spends a
lot of effort playing that constant-backporting game for us. It also
throws off scanners from less-accomplished security scanners, causing
false positives (meaning an issue is reported when it is not really there)
regularly.
[color=blue]
- Diffie-Hellman MODP size should be set to a number higher than 2048[/color]
SSL-specific recommendations like anything to do with Diffie-Hellman are
necessarily tied to a service, so you’ll need to let us know which
service, for example an Apache httpd service, or an Apache Tomcat service,
or an PostgreSQL service, etc. Often those services are the places to
control things like ciphersuites, key sizes, etc., but it may also be
controlled by openssl or other libraries which could then be the domain of
the operating system like SLES.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…