Marc Haber wrote:
> On Sat, 31 Jan 2004 08:12:24 -0500, Blaine Simpson
> <blaine.simpson@???> wrote:
>
>>Try doing a web search engine for "ssh exploit" or "ssh advisory" or go
>>to any security advisory site like cvs.mitre.org.
>
>
> Well, thanks. So you are not aware of any current problems with
> openssh. Thanks for talking about this.
>
> Can you spell FUD?
You're arguing with the wrong person I think. I love ssh. Try reading the
"If you apply" paragraph below, from the email you replied to. I run
tons of automation over ssh pipes, cvs, etc.
Openssh exploits are very rare and get fixed quickly. That does not
stop that fact that there are a huge number of servers running old versions
of ssh that have not been patched in years. I know of web server farms of
hundreds of servers where nothing ever gets patched unless some software
"stops working". I know lots of home users who are too busy to patch
anything unless something stops working.
I'm speaking from the perspective of somebody who deals with security breakins,
not a social commentator.
>>If you apply security patches regularly and lock down with tcp wrappers or
>>some other form of ip filtering, it's excellent. Otherwise it's not. Both
>>ssh and http can be secure or insecure. The differentiation is that a
>>break in to sshd is generally a much more serious thing than a break in to
>>a web site.
>
>
> ssh needs to be installed anyway. But there are, however, many mail
> servers that do not have, and do not need, a web server.
Correct. Is there a point to this insightful observation?
>>First off, the purpose of sshd is to use some authentication mechanism to
>>give a login, including a root login. (Configuring sshd to prevent this
>>is safer,
>
>
> ... and the default on all machines I install.
>
> [Tomcat advertisement snipped]
>
>
>>You may notice that the normal procedure at nearly every large IT company
>>is as follows: The main firewalls from the Internet permit all incoming
>>traffic on http and https ports.
>
>
> There is no excuse for stupid firewall rules.
Agreed, but that has no effect on my argument that leaving http sites open
to public is no more unsafe than leaving the sshd port open to the public.
>>On the
>>other hand, ssh is usually prohibited from everywhere except specific IP
>>addresses and/or VPN.
>
>
> That's a typical suit stance. "If we don't use it, it must be
> dangerous".
>
> And no, I would never leave an exim admin interface open to the
> general public over any access way - ssh or http.
Good. I see that we both appreciate restricting access by source IP.
> ssh can be closed down with a packet filter or tcp wrappers since you
> know from where your admins ssh in.
Sometimes, but often not. I know lots of Admins, including myself, who
like to administer their home network from various work locations which
change, and many, like myself, who need to work remotely from dynamic
home IP addresses during on-call hours. There are various good
solutions for these problems, including VPN. Quite an assumption: "since
you know where your admins ssh in."
If you have a public and a
> non-public http service on the same machine, you'll need to rely on
> the web swerver to separate the privileges.
Very wrong. Have you ever heard of dnat? Have you ever heard of
redirectors? But there is nothing wrong with doing filtering via
IP with Apache or other web/app server. A lot of commerce
occurs doing exactly that.
You can filter via source IP on firewalls or on target servers. It is
often convenient for the firewall to permit access only to specific
ports on specific target servers and leave it to the target server admin
to restrict by source IP. I don't think you'd disagree because you
mention tcp wrappers. Well, guess what, restricting incoming traffic
with Apache or Tomcat or WebSphere accomplishes the same thing as
restricting with tcp wrappers. All of these programs are used in
thousands of installations and are used to safeguard millions of
dollars worth of assets.
Since you like to jump to over-simplifications, I'll point out that
using ip filtering facilities built into a tested and proven server
application like Apache is far different from opening that application
up and doing the authentication checking with your own app. As I
said in an earlier post, it makes no difference how bad your web app
is, if the Web/app server restricts by source IP, then your app is
safe because unauthorized traffic will never reach the app. See how
far you can get by banging on my Exim Webapp port at
http://africafocus.org:8180, which is protected by Tomcat's
IP access valve.
> Greetings
> Marc
>
> --
> -------------------------------------- !! No courtesy copies, please !! -----
> Marc Haber | " Questions are the | Mailadresse im Header
> Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
> Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
>
> --
>
> ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##
>
--
ICF: 703-934-3692 Cell: 703-944-9317
