RE: [webmin-l] security issues

[George D. <ge...@ou...>]

Hello Everyone,
I'm getting ready to install Webmin back on my servers that were
compromised.
I have updated to redhat 7.3. I have Les Bell's install directions from
his site.
Any other suggestions before I start the install? We were using 1.7.
Thanks,
George

 	 	 	 George Dickman
954.792.9254 (Office)
954.583.8646 (fax)
ge...@ou... <mailto:ge...@ou...>


-----Original Message-----
From: web...@li...
[mailto:web...@li...]On Behalf Of Les Bell
Sent: Friday, May 23, 2003 10:40 PM
To: web...@li...
Subject: Re: [webmin-l] security issues



"George Dickman" <ge...@ou...> wrote:

>>
We have been told by a professional security team that running webmin on a
hosting server,
poses a serious security problem. One of the reasons stated, was it was a
known port.
I love Webmin, but these guys are professionals and provide security for
over 2,000 servers.
I would like your comments. I need a good argument to keep my webmin.
<<

Apologies for coming into this late, but I've been travelling and just got
back to my office. But after reading some of the responses, I thought I'd
better drop my $0.02c in. Actually, I *am* a security professional, so you
can take this as being $2.00 worth, not $0.02c. <g>

1) When installed with the defaults, Webmin listens on port 10,000 and
this
is known to many threat agents. However, it is not a "well known port" in
the technical sense.

So what? Knoweldgeable hackers don't depend on the port number to identify
what is listening on a given port. Instead, they use nmap to scan all the
interesting ports on the target machine, and then they use telnet and
other
tools to get a banner back from the remote system. For example, if I
telnet
to Webmin running on one of my systems and issue a "GET / HTTP/1.1"
request, I get back:

HTTP/1.0 200 Bad Request
Server: MiniServ/0.01
Date: Sat, 24 May 2003 02:49:11 GMT
Content-type: text/html
Connection: close

<h1>Error - Bad Request</h1>
                            <pre>This web server is running in SSL mode.
Try the
 URL <a
href='https://192.168.168.11:1000/'>https://192.168.168.11:1000/</a> ins
tead.<br></pre>


Connection to host lost.

It doesn't matter *what* port Webmin is running on - it identifies itself
by the "Server: MiniServ/0.01" line. Ergo, running Webmin on another port
in an attempt to benefit from "security by obcurity" is a fool's paradise.

2) There is, however, a benefit to running Webmin on a port below 1024.
These are the so-called "privileged" ports on a UNIX box, and an
application launched by an ordinary user can't create a socket on them.
So,
if your Webmin server is running on a non-privileged port, a user could
somehow kill it, then put up his own replacement on that port, which you
would naively connect to and supply your credentials to. That's not
possible with a privileged port.

3) There's always the possibility of someone using a sniffer to capture
your credentials if you log in with a plain-text authentication. So use
SSL: Net::SSLeay is usually quick and painless to install (except on RH
9.0
. . . <g>) Best of all, use digital certificates for authentication,
appropriate firewall rules and a VPN tunnel where possible and
appropriate.
Since TCP sequence prediction is so difficult on current Linux kernels,
controlling access on source address is a good approach, too. These
controls provide a good defense against sniffing and some other attacks.

4) Actually, it's not true to say that "all servers listen on well known
ports". People do move them as described above in an attempt to disguise
them, plus many other services don't have a fixed port at all, such as
those which depend on the portmapper (but then, those apps mostly
shouldn't
be exposed on the Internet for other reasons). Or they could use DNS WKS
records.

In summary, I wouldn't attempt to manage an online banking server using
Webmin, but I don't see any problem with using it for SME's with
low-criticality and low-sensitivity assets, when appropriately configured.

In whatever you are doing, remember that you should attempt to put
multiple
layers of defence in place. 100% security is actually never achievable -
especially from just one control, such as a firewall - so you should set
out to use a combination of firewall filtering, encryption,
authentication,
address-based access control, etc. to put in place as many layers as
possible for the attackers to hack their way through. And then, while
they're doing that, you monitor their progress with your intrusion
detection system and provide all logs to the authorities, who will arrange
delivery of their prize . . .<g>

Best,

--- Les Bell, RHCE, CISSP
[http://www.lesbell.com.au]




-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
-
Forwarded by the Webmin mailing list at
web...@li...
To remove yourself from this list, go to
http://lists.sourceforge.net/lists/listinfo/webadmin-list