--
BTW Blaine:
Go look that up in Google.
Fourth - It is called Netiqutte.
Third - It confuses the issue for many people.
Second - It makes it hard to see what exactly you are responding to.
First - it make you look like a complete and total wanker.
Please do not top post in response to and e-mail.
On Sat, 2004-01-31 at 08:12, 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.
Wow...Sure do get a lot of them, I am AMAZE-ED!!! /me falls over
> 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.
Do you really understand ssh?
> 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, but the binary still has the capability to do so).
Hmmm, I thought that... err... ummm... Privilege Separation took care of
that in more recent versions of openSSH. Shedding Privilege is one of
those things the openSSH teams has always been working for. But if you
don't compile it with Privilege Separation or even if you do, but don't
enable it... tis a bad thing.
> Compare that
> to Tomcat which can never be used to become root without also exploiting
> an OS/Pam/etc. vulnerability at the same time-- I like those odds. I
> would much rather have a hacker poking around my web pages looking for
> vulnerabilities than poking around with an OS shell (whether root or not).
Tomcat can be exploited just like anything else set to suexec.
> Using only static content and/or compiled active content (like C or Java)
> makes things much more secure than shell scripts (or dreaded CGI scripts).
Red Herring. Move along nothing here to see.
> This is another reason why Tomcat is a very secure product. I've done
> post breakin assessments for break-ins for all of these types for MCI and
> (recently defunct) Cable & Wireless. The web server breakin that I've
> seen most often is using http parameters to cause a bad script (php, perl
> etc.) to execute a "system" command. With compiled programs, you can't
> "system" a command unless the developer compiled the system command in.
> (I am saying "system" to refer to the capability... it could be a back-tick
> command, an "exec", etc., depending on the language).
Red Herring, please if you are going to say something... do so.
> 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. This means that if you have a static IP
> inside, you can run a web or web app server and access it from anywhere
> on the Internet.
Thank you very much, on making yourself look like a "Billy" goat.
Firewalls that have admins that are clue endowed, does not permit ALL
http and https incoming traffic (80 and 443 respectively). I have
configured transparent firewalls for Colleges and Universities. Services
I allowed, got through, nothing else. http* only for those sanctioned
machines, smtp* only for those sanctioned machines, ssh only sanctioned
machines... etc.
Gotta understand Rules of Execution. Interface Policy -> Fragments ->
NAT -> Mangle -> Global Policy. I have a feeling you have not one
single clue.
> We know that these servers are generally safe enough to
> leave security up to the people running the individual servers.
Hooo-eee. No comment. This alone tells me you have zero knowledge in
this area. Think: "CODE RED"
> On the
> other hand, ssh is usually prohibited from everywhere except specific IP
> addresses and/or VPN. (Http/Https vs. ssh traffic is differentiated by
> destination port or by checking high-level protocol packets. If the
> former, then internal users can circumvent their company's security by
> running sshd on port 80). Sshd access is not closed because it is not
> desired, because it causes great inconvenience, for exampe, for
> administrators to not have remote ssh access (as well as many other
> things that can be done over an ssh pipe).
I'd rather have it be ssh than VPN anyday. VPN can be and has been show
to use upto 50% of available bandwidth just doing house work, that of
course depends on the site settings. OpenSSH has had a share of
problems, but by far no worse than a garbage install of
RedHat/ManDrake/SuSE/Slackware/etc. Those garbage installs are typically
done by people NOT knowing what does and doesn't need to be there... and
of course, never keeps up to date anyway.
> I won't be spending my time replying to further objections like these.
> I hope that most people realize that, just like with Science, intuition
> about IT security is very unreliable unless built upon serious study or
> experience.
Indeed, no further need remove *ALL* doubt.
> Marc Haber wrote:
> > On Thu, 29 Jan 2004 11:16:27 -0500, Blaine Simpson
> > <blaine.simpson@???> wrote:
> >
> >>(Seriously-- don't unless you know
> >>that you have sshd patched and nailed down-- I won't take the time to
> >>break in, but somebody else reading this may).
> >
> >
> > Seriously, are there any current problems with openssh?
And to answer Marc Haber, OpenSSH does not have any problems that I am
currently aware of.
--
greg, greg@???
REMEMBER ED CURRY!
http://www.iwethey.org/ed_curry
--
Content-Description: This is a digitally signed message part
[ signature.asc of type application/pgp-signature deleted ]
--
