[LUAU] Excellent SSH advice

[Tom_Gordon/RISE/HIDOE at notes.k12.hi.us]

Isn't libwrap the old way of doing things?  Would using iptables not be 
faster?

Tom




Dwight Victor <dwight.victor at gmail.com> 
Sent by: luau-bounces at lists.hosef.org
12/01/2005 02:27 PM
Please respond to
Dwight Victor <dwight.victor at gmail.com>; Please respond to
LUAU <luau at lists.hosef.org>


To

LUAU <luau at lists.hosef.org>
cc





Subject
Re: [LUAU] Excellent SSH advice








Are you sure about that Vince?

The way I understand how tcp_wrappers works is that the wrapper is
actually listening on the service port and when the attempt is
successfully authenticated against the /etc/hosts.allow and
/etc/hosts.deny files, the wrapper passes control to the actual
service.

A quick google gives me this from Red Hat:
http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/ref-guide/ch-tcpwrappers.html

The tcpd manpage says this:
---
TCPD(8)                                                   TCPD(8)

NAME
       tcpd - access control facility for internet services

DESCRIPTION
       The  tcpd  program  can be set up to monitor incoming requests
for telnet, finger, ftp, exec, rsh, rlogin, tftp, talk, comsat and
other services
       that have a one-to-one mapping onto executable files.

       The program supports both 4.3BSD-style sockets and System
V.4-style TLI.  Functionality may be limited when the protocol
underneath TLI  is  not
       an internet protocol.

       Operation  is  as  follows:  whenever  a  request  for service
arrives, the inetd daemon is tricked into running the tcpd program
instead of the
       desired server. tcpd logs the request and does some additional
checks. When all is well, tcpd runs the appropriate server program and
goes away.

       Optional  features are: pattern-based access control, client
username lookups with the RFC 931 etc. protocol, protection against
hosts that pre­
       tend to have someone elses host name, and protection against
hosts that pretend to have someone elses network address.

LOGGING
       Connections that are monitored by tcpd are reported through the
syslog(3) facility. Each record contains a time stamp, the client host
name  and
       the  name  of the requested service.  The information can be
useful to detect unwanted activities, especially when logfile
information from sev­
       eral hosts is merged.

       In order to find out where your logs are going, examine the
syslog configuration file, usually /etc/syslog.conf.

ACCESS CONTROL
       Optionally, tcpd supports a simple form of access control that
is based on pattern matching.  The access-control software provides
hooks for the
       execution of shell commands when a pattern fires.  For details,
see the hosts_access(5) manual page.

HOST NAME VERIFICATION
       The  authentication  scheme  of some protocols (rlogin, rsh)
relies on host names. Some implementations believe the host name that
they get from
       any random name server; other implementations are more careful
but use a flawed algorithm.

       tcpd verifies the client host name that is returned by the
address->name DNS server by looking at the host name and address that
are returned by
       the name->address DNS server.  If any discrepancy is detected,
tcpd concludes that it is dealing with a host that pretends to have
someone elses
       host name.

       If the sources are compiled with -DPARANOID, tcpd will drop the
connection in case of a host name/address mismatch.  Otherwise, the
hostname can
       be matched with the PARANOID wildcard, after which suitable
action can be taken.

HOST ADDRESS SPOOFING
       Optionally,  tcpd  disables source-routing socket options on
every connection that it deals with. This will take care of most
attacks from hosts
       that pretend to have an address that belongs to someone elses
network. UDP services do not benefit from this protection. This 
feature  must  be
       turned on at compile time.

RFC 931
       When  RFC  931 etc. lookups are enabled (compile-time option)
tcpd will attempt to establish the name of the client user. This will
succeed only
       if the client host runs an RFC 931-compliant daemon.  Client
user name lookups will not work for datagram-oriented connections, 
and  may  cause
       noticeable delays in the case of connections from PCs.
---

If I'm wrong, then I'm wrong...but I don't think so.

Dwight...

On Wed, 12 Jan 2005 10:39:35 -1000, Vince Hoang <vince at litrium.com> wrote:
> On Wed, Jan 12, 2005 at 09:31:56AM -1000, Dwight Victor wrote:
> > If you know the IP addresses of the machines that you'll be
> > SSHing from...it's best to compile your version of SSH to
> > support tcp_wrappers and configure your /etc/hosts.allow and
> > /etc/hosts.deny files to only allow SSH access from your know
> > IP addresses.
> 
> I believe most packaged versions of OpenSSH come prebuilt with
> tcp-wrappers, so no recompilation is needed.
> 
> > This also helps cut down on those irritating automated SSH
> > attacks.
> 
> When using the built-in tcp-wrapper support, the attack will
> still hit the sshd before the attack host is dropped, and
> potentially leave you open to an undocumented buffer overflow.
> 
> Instead, if you limit host access at the firewall level, the
> attack will never reach the sshd.
> 
> Another alternative is to move your sshd to a different port.
> This will thwart the attacks that only look at tcp/22 for a
> running SSH server, but this relies on security through obscurity
> alone.
> 
> -Vince
> _______________________________________________
> LUAU at lists.hosef.org mailing list
> http://lists.hosef.org/cgi-bin/mailman/listinfo/luau
> 


-- 
Dwight Victor
Resident Mad Scientist and All Around Good Guy
dwight.victor at gmail.com
_______________________________________________
LUAU at lists.hosef.org mailing list
http://lists.hosef.org/cgi-bin/mailman/listinfo/luau