4:30 a.m.
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..
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
7:51 a.m.
On Fri, 26 Sep 2003 12:30:00 +0300 (EEST)
Pekka Savola <pekkas(a)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.
10:21 a.m.
On Fri, 2003-09-26 at 06:51, Vincent wrote:
On Fri, 26 Sep 2003 12:30:00 +0300 (EEST)
Pekka Savola <pekkas(a)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.
--
Stephen John Smoogen smoogen(a)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 --
10:59 a.m.
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.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
11:42 a.m.
On Fri, 26 Sep 2003 09:21:45 -0600
Stephen Smoogen <smoogen(a)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(a)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(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
12:11 p.m.
On Fri, 26 Sep 2003, Vincent wrote:
On Fri, 26 Sep 2003 09:21:45 -0600
Stephen Smoogen <smoogen(a)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.)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
12:32 p.m.
On Fri, 26 Sep 2003 20:11:27 +0300 (EEST)
Pekka Savola <pekkas(a)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(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
1:02 p.m.
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 "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
7517
days inactive
7517
days old
7 comments
3 participants
participants (3)
-
Pekka Savola -
Stephen Smoogen -
Vincent