On 01/07/2012 12:31 AM, Reindl Harald wrote: > > Am 07.01.2012 06:13, schrieb Stephen John Smoogen: >> On 6 January 2012 21:46, Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: >>> Reindl Harald wrote: >>>> would it not be a good idea to NOT disclosure service versions? >>>> https://bugzilla.redhat.com/show_bug.cgi?id=718133 >>>> >>>> you will more and more have the "problem" of 3rd party >>>> security scans to your servers and currently in the case >>>> of openssh the only solution is to tkae the F16-src-rpm >>>> and rebuild it for your F15 machines >>> >>> If the scan is looking at the version to determine vulnerability, it is >>> completely broken, useless and unsupportable, because fixes can be >>> backported. > > if you have a big customer which hires a 3rd party auditor > you are NOT in the poisiton to give such arguments or > you can give them but you can not change ANYTHING in > the fact that finally "fix it or shutdown the service" > is what you have to do If you have a "security expert" who can't grasp the concept of back-ported bug fixes, and is unwilling to test for specific vulnerabilities' existence, it's time to get a new expert. >> I am going with Kevin on this one. The real hacking tools check to see >> if a vulnerability works or not. The broken "audit" scanners only >> check to see if a header is this or that. Not putting the header only >> gets you past the auditors and doesn't stop the real hacker from >> getting in if the vulnerability is there. > > that is not the point > the point is why in the wolrd must we spit out versions? > > yes, i know it is security by obscurity > but does it hurt? > > if i need to know my version of sshd or any other service > i make a "rpm -qa | grep package", if somebody else likes > to know he has to tell the question as i have for foreign > servers Connecting programs don't have the luxury of 'rpm -q', and must rely on the version returned by the server to know how to pass data. Things change over time, and you certainly can't expect a server to behave the same over (sometimes long) periods of time. -- Digimer E-Mail: digimer@xxxxxxxxxxx Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org "omg my singularity battery is dead again. stupid hawking radiation." - epitron -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
