Fedora Core 5: How do I use tcpd and conrolling access to my server?

I run a Fedora Core 5 server on a cablemodem and often find in my logs,
like vsftpd, for example, numerous attempts of people trying to hack into
the system. Here is an example:

Sun Nov 19 16:30:48 2006 [pid 31424] [Administrator] FAIL LOGIN: Client
"196.44.193.166"
Sun Nov 19 16:30:51 2006 [pid 31424] [Administrator] FAIL LOGIN: Client
"196.44.193.166"
Sun Nov 19 16:30:55 2006 [pid 31424] [Administrator] FAIL LOGIN: Client
"196.44.193.166"
Sun Nov 19 16:30:57 2006 [pid 31424] [Administrator] FAIL LOGIN: Client
"196.44.193.166"
Sun Nov 19 16:31:04 2006 [pid 31424] [Administrator] FAIL LOGIN: Client
"196.44.193.166"
Sun Nov 19 16:31:06 2006 [pid 31424] [Administrator] FAIL LOGIN: Client
"196.44.193.166"
Sun Nov 19 16:31:09 2006 [pid 31424] [Administrator] FAIL LOGIN: Client
"196.44.193.166"
Sun Nov 19 16:31:13 2006 [pid 31424] [Administrator] FAIL LOGIN: Client
"196.44.193.166"

....and this just goes on an on, ad infinitum. When I find stuff like
this, I can watch the hackers go with the tail command:

tail -f /var/log/vsftpd.log

I usually spot this behavior with the iftop program, then I can see that
there is an FTP connection but hardly any data flowing. This is my tip
that someone is probably trying to hack the server. They do this with ssh
as well.

I will then stop them by putting their IP address into my
/etc/xinetd.conf file like so:

no_access = 211.152.65.* 221.12.41.* 221.12.41.32 219.150.32.* 124.0.208.
* 196.44.193.*

Then restart xinetd:
service xinetd restart

And kill any running vsftpd process:
killall vsftpd

Now when I go back and tail the vsftpd.log file, I can see that the
hacker is now blocked. I generally choose to block the IP address and
leave the last part as a wildcard so that when the hacker logs back in
and gets a different IP address, this should have it all covered.

I think that I can do this with my /etc/hosts.deny file instead of piling
my xinetd.conf file with tons of IP addresses. I am not quite sure of the
hosts.deny syntax however. I tried doing this:

[root@ohmster etc]# cat hosts.deny
#
# hosts.deny This file describes the names of the hosts which are
# *not* allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow. In particular
# you should know that NFS uses portmap!

ALL: 211.152.65.* 221.12.41.* 221.12.41.32 219.150.32.* 124.0.208.*
196.44.193.*
[root@ohmster etc]#

But am not sure if this is the correct syntax or how to tell if it will
work or not. I found with google that one can use a program called
tcpmatch to check if your hosts.deny and hosts.allow files are setup
right but I do not have tcpmatch on my FC5 system. I do have installed
tcp_wrappers and this might help:

[root@ohmster etc]# rpm -ql tcp_wrappers
/usr/include/tcpd.h
/usr/lib/libwrap.a
/usr/lib/libwrap.so
/usr/lib/libwrap.so.0
/usr/lib/libwrap.so.0.7.6
/usr/sbin/safe_finger
/usr/sbin/tcpd
/usr/sbin/try-from
/usr/share/doc/tcp_wrappers-7.6
/usr/share/doc/tcp_wrappers-7.6/BLURB
/usr/share/doc/tcp_wrappers-7.6/Banners.Makefile
/usr/share/doc/tcp_wrappers-7.6/CHANGES
/usr/share/doc/tcp_wrappers-7.6/DISCLAIMER
/usr/share/doc/tcp_wrappers-7.6/README
/usr/share/doc/tcp_wrappers-7.6/README.IRIX
/usr/share/doc/tcp_wrappers-7.6/README.NIS
/usr/share/man/man3/hosts_access.3.gz
/usr/share/man/man5/hosts.allow.5.gz
/usr/share/man/man5/hosts.deny.5.gz
/usr/share/man/man5/hosts_access.5.gz
/usr/share/man/man5/hosts_options.5.gz
/usr/share/man/man8/tcpd.8.gz
[root@ohmster etc]#

Now there is a program called tcpd and another one called try-from but I
cannot understand how to use these programs, even with the man pages.

Can someone please help me to figure out how to make a good hosts.deny
file and how to check it so that I know it works? I would rather have my
server open and then deny specific, troublesome IP addresses, rather than
deny everyone and then let them in per IP address as I might need to
access my own server from anywhere and might have to give FTP access to
others in the future.

Please help me make a hosts.deny file and tell me how I can check it.
Thank you.
--
~Ohmster
theohmster at comcast dot net
Put "messageforohmster" in message body
to pass my spam filter.

On Sun, 19 Nov 2006 13:42:39 -0600, Ohmster rearranged some electrons to
form:

> I run a Fedora Core 5 server on a cablemodem and often find in my logs,
> like vsftpd, for example, numerous attempts of people trying to hack into
> the system. Here is an example:
>
> Now when I go back and tail the vsftpd.log file, I can see that the
> hacker is now blocked. I generally choose to block the IP address and
> leave the last part as a wildcard so that when the hacker logs back in
> and gets a different IP address, this should have it all covered.
>
> I think that I can do this with my /etc/hosts.deny file instead of piling
> my xinetd.conf file with tons of IP addresses. I am not quite sure of the
> hosts.deny syntax however. I tried doing this:
>
> [root@ohmster etc]# cat hosts.deny
> #
> # hosts.deny This file describes the names of the hosts which are
> # *not* allowed to use the local INET services, as decided
> # by the '/usr/sbin/tcpd' server.
> #
> # The portmap line is redundant, but it is left to remind you that
> # the new secure portmap uses hosts.deny and hosts.allow. In particular
> # you should know that NFS uses portmap!
>
> ALL: 211.152.65.* 221.12.41.* 221.12.41.32 219.150.32.* 124.0.208.*
> 196.44.193.*

The syntax is OK, but you don't need the asterisk.

>
> Can someone please help me to figure out how to make a good hosts.deny
> file and how to check it so that I know it works?

man hosts.deny


--
David M (dmacchiarolo)
http://home.triad.rr.com/redsled
T/S 53
sled351 Linux 2.4.18-14 has been up 3 days 11:23

On Sun, 19 Nov 2006, in the Usenet newsgroup comp.os.linux.networking, in
article <Xns988095A515083MyBigKitty@216.196.97.136>, Ohmster wrote:

>I usually spot this behavior with the iftop program, then I can see that
>there is an FTP connection but hardly any data flowing. This is my tip
>that someone is probably trying to hack the server. They do this with ssh
>as well.

which is why I use the firewall instead

>Now when I go back and tail the vsftpd.log file, I can see that the
>hacker is now blocked. I generally choose to block the IP address and
>leave the last part as a wildcard so that when the hacker logs back in
>and gets a different IP address, this should have it all covered.

That assumes the bad guy is actually located on the "attacking" hosts.
Most of the attacks are zombies or worms, controlled elsewhere. You are also
assuming the ISP to be using a /24 for customer blocks. I wouldn't put much
faith in that.

>I think that I can do this with my /etc/hosts.deny file instead of piling
>my xinetd.conf file with tons of IP addresses. I am not quite sure of the
>hosts.deny syntax however.

man 5 hosts_access

Very briefly - if a service/address is permitted in /etc/hosts.allow, then
the connection is allowed. OTHERWISE, /etc/hosts.deny is checked to see if
the service/address should be denied. If it's not denied, then the service
is allowed. HOWEVER - this only applies to services that use tcp_wrappers
or are compiled with libwrap. NOT THAT MANY ARE.

So the syntax depends on how you want to allow people. If you want to allow
everyone _except_ A, B, and C - then nothing in /etc/hosts allow, and a line
saying

daemon_name: address,address,address

(I use commas, but a space also works as a separator in the list.) This
logic says "none explicitly allowed, some explicitly denied, default
allow". You can have multiple lines listing a specific daemon, and I
vaguely recall a line length problem (I'm thinking 255 characters including
the terminating newline - watch the text editor you are using), but haven't
used tcp_wrappers that much since the late 1990s. That 'hosts_access(5) man
page above shows address structure 123.45.67. (note the ending dot) would
block 123.45.67.x. It also shows the 'n.n.n.n/m.m.m.m' (net/mask) syntax to
handle non-octet ranges. I do NOT recommend blocking using host or domain
_names_because that depends on the remote hosts having a working PTR record
for the IP address attempting connection.

The more normal choice is to allow _some_ and deny all others. That requires
the same syntax in /etc/hosts.allow, and a block all in /etc/hosts.deny (the
syntax being "ALL: ALL"). This logic says "allow explicitly some addresses,
deny all the rest - and we don't hit the default".

However, I prefer a simpler solution. The _firewall_ blocks all, except those
ports and addresses that I explicitly want to allow. This way, I don't have
to worry that the daemon uses tcp_wrappers or libwrap, because the daemon
never sees the unwanted attention. Also, while I doubt it's a problem for
you at this time, tcp_wrappers doesn't do IPv6.

>I found with google that one can use a program called tcpmatch to check if
>your hosts.deny and hosts.allow files are setup right but I do not have
>tcpmatch on my FC5 system.

You are pushing my memory kinda hard... tcpmatch was part of tcp_wrappers,
but was removed several years ago... it was a compatibility problem either
with xinetd, or the 2.2 kernel, and I can't find my notes on that. There
was also a program called 'tcpdchk' included, and it got dropped for the
same problems I believe. OK, found old man pages on a Red Hat 5.2 system,
and those two worked with /etc/inetd.conf, not the xinetd replacement.
For perspective, FC6 has tcp_wrappers-7.6-40.2.1 (the -40.2.1 is the version
of the rpm), and version 7.6 was originally released in late 1997. I'm pretty
sure Wietse Venema hasn't touched it since then.

>I would rather have my server open and then deny specific, troublesome IP
>addresses, rather than deny everyone and then let them in per IP address as
>I might need to access my own server from anywhere and might have to give
>FTP access to others in the future.

Your system, your rules. I wouldn't go that way. I know a whole bunch of
IP space that I will never be using to connect to, and blocking that reduces
the noise figure (and wasted bandwidth) a lot.

Old guy