[KLUG Members] SWAT?

[Bryan-TheBS-Smith]

Bryan-TheBS-Smith wrote:
> On newer Linux distributions that use Xinetd, by default, you can
> _only_ access SWAT on the server itself.

Deeper discussion ...

If you haven't figured out, the smbd/nmbd "server" processes of
Samba are independent daemons (or almost always run as independent
daemons with the -D switch) which is different (and separate) from
the SWAT service.  SWAT is controlled by the Internet Daemon (inetd
or Xinetd in newer distros).

If you don't know what I'm talking about, understand that most
services can be run two ways:
  1)  As its own, self-contained service that is always running
  2)  As an [X]inetd service that is only started when the port is
accessed

In the case of #1, the software _must_ be written in a fashion that
it can do its own port servicing routines.  Much software is written
this way, either by design, or with an option -- e.g., smbd/nmbd
uses the "-D" switch to designate to run as a standalone daemon
(look at the /etc/rc.d/init.d/smb init script to see what I'm
talking about).  Some other software has a separate executable based
on whether or not it is run as a standalone daemon (usually with a
"d" suffix on the binary) or called as a regular streaming I/O
program via [X]Inetd.  Other software can _only_ be run as a
standalone daemon (so #2 is not an option).

In the case of #2, even software not designed to be run as a daemon
can be called via [X]inetd.  In fact, just about _any_ piece of
software that does streaming I/O _can_ be setup to run on a TCP/IP
or UDP/IP port by configuration in [X]inetd -- even "cat"!  Samba,
Sendmail, Apache and many other programs can be setup to be called
via [X]inetd so they are started/run _only_ when the port is
accessed.  Of course this can be grossly inefficient when the
programs are heavily utilized (the software starts up then shuts
down, then up again, etc...), hence why Samba, Sendmail, Apache,
etc... are usually setup as standalone deamons.  SWAT lacks its own
port servicing routines (it is just a simple streaming I/O program
for HTTP) so it _must_ be called via [X]inetd.

INCREASING SWAT SECURITY

SWAT runs as a clear-text HTTP connection.  As such, someone _could_
"sniff" your root password.  Remember, 70% of all transgressions on
networks are _internal_.  So unless you trust your co-workers
completely, or none of them understand what you are doing (although
most script kiddies don't either ;-), you might want to either use
SWAT on _only_ the system console.

If that is not an option, for increased security, any [X]inetd
services, or even standalone program daemons, can use a SSL
tunneling program, like stunnel, to make a service into an SSL-based
service on a different port.  Of course the client must understand
how to do this as well, but many services are SSL-aware -- from SSL
web clients to IMAP-SSL and POP-SSL.  There are standard port
assignments for many SSL'ized services.  In the case of SWAT,
"security through obscurity" is probably best so using stunnel to
SSL'ize SWAT to any arbitrary port above 1024 (like 8901 or another)
is up to you.

See "man 8 stunnel" to setup an stunnel for a service.  In the case
of SWAT, once you setup an stunnel port for it, you just pull up
your web browser to "https://server:sslport" (note the "s" suffix to
"http").

Of course you can also SSH-tunnel SWAT's 901 port for security, and
it is _preferred_ when tunneling across remote connections.  I.e.,
it is _much_more_secure_ to SSH-tunnel (using DES or Blowfish)
connections when administering your systems remotely than to setup
an SSL'ized port via stunnel (using RC4 **) and punch a hole through
your firewall for it.  SSH has much better session negotiation,
which makes it much better than most other protocols.

[ ** Note:  You can use other ciphers than RC4, including DES and
Blowfish, but your web browser may not support them and/or use
another by default.  RC4 is a simple, low-overhead cipher that is
used in many applications because it doesn't require much
horsepower.  E.g., the IEEE 802.11 Wireless-LAN (WLAN) Wireless
Encryption Protocol (WEP) standard uses RC4 simply because the
_great_majority_ of WLAN "access points" don't have enough
horsepower to drive anything but RC4.  There *ARE* alternatives to
using WEP's RC4 that the IEEE has proposed and/or approved of for
WLAN, but 99.99% of the networks out there just cannot support the
cipher overhead.  RC4 is always chosen for speed, _never_ security
-- hence its preference in SSL for high-trafficed e-commerce
servers. ]

-- TheBS

-- 
Bryan "TheBS" Smith     mailto:b.j.smith@ieee.org     chat:thebs413
Engineer   Absolute Value Systems, Inc.   http://www.linux-wlan.org
President     SmithConcepts, Inc.      http://www.SmithConcepts.com