Hi,
Would it make sense to add the rpm version-release strings in the OpenSSH, Apache, etc. banners, e.g. like..:
SSH-1.99-OpenSSH_3.5p1 3.5p1-11
instead of just:
SSH-1.99-OpenSSH_3.5p1
.. this should be rather straightforward for the build process.
The gain would be that if you e.g. perform security scans in your network you could identify whether a patched version has been installed in the systems in question..
On Fri, 26 Sep 2003 12:30:00 +0300 (EEST) Pekka Savola pekkas@netcore.fi wrote:
Hi,
Would it make sense to add the rpm version-release strings in the OpenSSH, Apache, etc. banners, e.g. like..:
SSH-1.99-OpenSSH_3.5p1 3.5p1-11
instead of just:
SSH-1.99-OpenSSH_3.5p1
.. this should be rather straightforward for the build process.
The gain would be that if you e.g. perform security scans in your network you could identify whether a patched version has been installed in the systems in question..
The problem is, so can anyone else.
On Fri, 2003-09-26 at 06:51, Vincent wrote:
On Fri, 26 Sep 2003 12:30:00 +0300 (EEST) Pekka Savola pekkas@netcore.fi wrote:
Hi,
Would it make sense to add the rpm version-release strings in the OpenSSH, Apache, etc. banners, e.g. like..:
SSH-1.99-OpenSSH_3.5p1 3.5p1-11
instead of just:
SSH-1.99-OpenSSH_3.5p1
.. this should be rather straightforward for the build process.
The gain would be that if you e.g. perform security scans in your network you could identify whether a patched version has been installed in the systems in question..
The problem is, so can anyone else.
However security through obscurity is not security. The people who are looking for 'unpatched' servers are going to run the 4 line hack anyway with their autoscripts.
The more interesting question would be if adding these strings would actually help you because each backdoor would just change the string to a 'patched' version so that your quick scanners would pass it over.
On Fri, 26 Sep 2003, Stephen Smoogen wrote:
Would it make sense to add the rpm version-release strings in the OpenSSH, Apache, etc. banners, e.g. like..:
SSH-1.99-OpenSSH_3.5p1 3.5p1-11
instead of just:
SSH-1.99-OpenSSH_3.5p1
.. this should be rather straightforward for the build process.
The gain would be that if you e.g. perform security scans in your network you could identify whether a patched version has been installed in the systems in question..
The problem is, so can anyone else.
However security through obscurity is not security. The people who are looking for 'unpatched' servers are going to run the 4 line hack anyway with their autoscripts.
My point exactly. People who look for these to exploit them have the exploits anyway, and use them in any case!
The more interesting question would be if adding these strings would actually help you because each backdoor would just change the string to a 'patched' version so that your quick scanners would pass it over.
I think this is a separate discussion. In these environments, you typically first do a port scan, and then check the ports with more detail.
1) such backdoors could be found in the port scan, and 2) if the box has already been compromised, you're out of luck already. These procedures are meant to *prevent* that, not to detect compromised hosts.
On Fri, 26 Sep 2003 09:21:45 -0600 Stephen Smoogen smoogen@lanl.gov wrote:
However security through obscurity is not security. The people who are looking for 'unpatched' servers are going to run the 4 line hack anyway with their autoscripts.
Agreed, Obscurity does not work for most things but what if that 4 line script doesn't work? They'll know exactly what to look for. Not to mention alot of the people who want in do not want flags going off everywhere so they enumerate services first then apply exploits based on that information. It's kind of a moot point in this example though because I'm pretty sure that the SSH protocol needs valid banners to work correctly anyway.
The more interesting question would be if adding these strings would actually help you because each backdoor would just change the string to a 'patched' version so that your quick scanners would pass it over.
Yep, Also I'm pretty sure that nmap's new -sV switch doesn't just grab banners but fingerprints other responses like actually using SSL or whatever to get past encryption and find protocol numbers. Maybe this is what he needs instead of a custom daemon where being lied to by backdoors is much easier.
-- Stephen John Smoogen smoogen@lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka --
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
On Fri, 26 Sep 2003, Vincent wrote:
On Fri, 26 Sep 2003 09:21:45 -0600 Stephen Smoogen smoogen@lanl.gov wrote:
However security through obscurity is not security. The people who are looking for 'unpatched' servers are going to run the 4 line hack anyway with their autoscripts.
Agreed, Obscurity does not work for most things but what if that 4 line script doesn't work? They'll know exactly what to look for. Not to mention alot of the people who want in do not want flags going off everywhere so they enumerate services first then apply exploits based on that information. It's kind of a moot point in this example though because I'm pretty sure that the SSH protocol needs valid banners to work correctly anyway.
You're already in pretty deep shit if you're worried about someone exploiting your SSH services and they get to see the banner. This means you haven't firewalled away the port or put in TCP Wrappers for it.
Banners are used to enable bug workarounds for broken versions, so they're pretty useful.. :-)
There is an option in OpenSSH so you can set the Version string yourself if you want, btw.
So, IMHO, version strings could seem quite handy. AFAIK, Debian already does this, and FreeBSD as well. (These two examples from OpenSSH.)
On Fri, 26 Sep 2003 20:11:27 +0300 (EEST) Pekka Savola pekkas@netcore.fi wrote:
You're already in pretty deep shit if you're worried about someone exploiting your SSH services and they get to see the banner. This means you haven't firewalled away the port or put in TCP Wrappers for it.
Yeah I only have a selected few with SSH access so access is pinched with those but there are times when I'll be moving to a machine the host address is not known untill I get there. So open for all happens sometimes. There are a few things I can do to side step this but Its not completly written yet.
Banners are used to enable bug workarounds for broken versions, so they're pretty useful.. :-)
There is an option in OpenSSH so you can set the Version string yourself if you want, btw.
If you mean setting the banner in sshd config that wont work. it is more like an MOTD. if you netcat to 22 it will still spit everything out same as before. If you ment something else, let me know. I'd like to try it out.
So, IMHO, version strings could seem quite handy. AFAIK, Debian already does this, and FreeBSD as well. (These two examples from OpenSSH.)
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
On Fri, 26 Sep 2003, Vincent wrote:
You're already in pretty deep shit if you're worried about someone exploiting your SSH services and they get to see the banner. This means you haven't firewalled away the port or put in TCP Wrappers for it.
Yeah I only have a selected few with SSH access so access is pinched with those but there are times when I'll be moving to a machine the host address is not known untill I get there. So open for all happens sometimes. There are a few things I can do to side step this but Its not completly written yet.
Right, of course people need login servers and such which are open.
However, you will keep special attention to those boxes, keep them up-to-date, even more so than other "protected" servers.
So, if your SSH version is always up-to-date, it doesn't give attackers anything even if you release the release number.
Banners are used to enable bug workarounds for broken versions, so they're pretty useful.. :-)
There is an option in OpenSSH so you can set the Version string yourself if you want, btw.
If you mean setting the banner in sshd config that wont work. it is more like an MOTD. if you netcat to 22 it will still spit everything out same as before. If you ment something else, let me know. I'd like to try it out.
Sorry, it seems I was misremembering this. Someone must have proposed it but it had been rejected. I thought you could forge the version number completely with a config option.
-
Pekka Savola -
Stephen Smoogen -
Vincent