|
Contents:
=======
1-
Basic Introduction to TCP Wrappers
Logging
Finding TCP Wrappers(links)
2-
Configure/setting up TCP Wrappers
Configure the inetd.conf file
hosts.allow
hosts.deny
Optional variables for shells commands
3-
Conclusion
4-
Greetz
Well here is another guide on a topic not covered by many
tutorial writers. This guide is somewhat intermediate so
many concepts won't be discussed cause they have been
covered in other articles. You can always check
http://blacksun.box.sk/ for the concepts not covered here.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
1-Basic Introduction to TCP Wrappers
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Many of you guys reading this tutorial are not old enough
to remember the development of the TCP/IP protocols many
years ago in the plan to help join the variety of networks
connected to the first Internet. Those first systems to
implement the TCP/IP protocols were government sites and
academic sites run by scientists, academics and government
individuals. During the early days, the need for security
was nothing like the need we have today. The User Datagram
Protocol (UDP), Transmission Control Protocol (TCP) and the
Internet Protocol (IP) were all created with security as the
least important aspect in mind. The utilities that were
developed later like Telnet and FTP share the same faulty
security, ie, both utilities enforce "security" by making
the user input a username and password that is valid on the
remote system. This security is faulty because both the
username/password are sent on the network as clear text and
anyone with little experience can sniff the user/pass with
great ease. As advancements in technology and TCP/IP
progressed, TCP/IP became the most popular protocol when it
was implemented on Novell Netware and the UNIX operating
system. As the Internet came into our homes, the default
network protocol package has become adopted on all major
computers and software vendors.
With this sudden surge in technology there is always the
little thing called "security" that has to be satisfied. Now
there are many different products that can be used by an
admin to enhance his network security, hence the idea of a
firewall and its components, one of them is " TCP
wrappers." Dealing with constant hacker attacks against his
University's computers, Wietse Venema from Eindhoven
University of Technology was the first person to develop TCP
wrappers. So now you ask what are they? Well TCP Wrappers
restrict which networks services can be used and which hosts
are going to be allowed to use these services. TCP Wrappers
can be configured to handle many of the basic netowrk
services found our on your unix box, ie, Finger, FTP,
Telnet, Rlogin,TFTP and the list goes on and on. Well we
have to answer what do these services share in common, well
if you haven't noticed they all share a one-to-one mapping
between the service name and the executable program that
provides the service, so that sets us up on the intro, on to
how TCP wrappers work.
-=-=-=-=-=
Logging
-=-=-=-=-=
On a linux box, when the inetd daemon gets a network
request, it first determines which service to startup based
on the port number the service runs from. In the file
/etc/services a mapping of port numbers to service names can
be found. After inetd has processed which service to start
up, it then reads inetd.conf to know what program it should
run to answer the network request. Now for the TCP Wrappers
Daemon (tcpd) to make access/deny control decisions and to
perform its duties of logging, you must first edit the
inetd.conf file to specify that the tcpd runs instead of the
executable that normally satisfies the service request. tcpd
performs its job by allowing the host that is making the
request to use the service, if allowed tcpd starts the
executable for that specific service, so in all TCP wrappers
really work by putting itself between inetd and the network
service requested.
In the last paragraph i mentioned something about the
logging ability of TCP wrapper, well that will be explained
here. TCP Wrappers allow you to log who is using the service
on your box so you can trace and halt any suspicious
activity waiting. Logging information is sent to the
syslogd, which also provides the core logging facility for
the unix box. To tell syslogd what to do with these log
enteries, you can control what is done by editing the
/etc/syslog.conf file. Setup on default, TCP wrappers sends
its logging info to the same place as the transaction logs
of the sendmail daemon, so syslogd can log info to one or
more files, either the system or user console.
Since I am guessing your an intermediate linux user, you
might have already come across TCP wrappers before as part
of your linux/unix package. TCP Wrappers usually come in .c
code so you have to compile it, you should be familiar with
compiling code on your box. TCP wrappers are very popular
among security people and paranoid hackers so first check
your linux package cause you might already have one and if
you don't here are some links.
-=-=-=-=-=
Links
-=-=-=-=-=
ftp://ftp.porcupine.org/pub/security/index.html * get
everything at this page!
Here are some more significant links if you wish to learn
more about the tcp wrapper package!
ftp://cert.org:/pub/tools/tcp_wrappers/tcp_wrappers.*
ftp.win.tue.nl:/pub/security/long_tcp.shar.Z
http://packetstormsecurity.org/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
2-Configure/Setting up TCP Wrappers
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Now that you have found the TCP wrapper source
code/compiled successfully you will need to config/setup TCP
wrappers. When you have the tcpd executable, you now have to
go to the second job, editing inetd.conf, hosts.allow, and
hosts.deny!
Configure the inetd.conf file
Lets configure the inetd daemon first!
to edit this file at the prompt type the following
root@mike:~# pico /etc/inetd.conf
that will bring up the configuration file up in pico, here
is a sample of an entery that can be found in your
inetd.conf file.
wait/nowait
if wait, inetd starts up
a process for a
request then waits till
done to start another
request. If nowait
starts up a process and
stream doesn't wait till it starts
another process,
dgram, or datagram but simply goes and does the
next.
\ \
ftp stream tcp nowait root /usr/sbin/wu.ftpd
wu.fptd -l -i -o
/ \ \
\ \
name of service protocol Uid either
\ \
like telnet, finger tcp or udp root or another
\ |
defined in
user \ |
/etc/protocols name
of server |
file
program inetd |
starts up |
|
command line argument
Now you have got a simplified view of the entery this is
the entery used to start the ftp service for the example i
showed above. In this entery /usr/sbin/wu.ftpd so for the
TCP wrapper proggie to become involved this line above needs
to be edited, so simply add this. /usr/sbin/tcpd the rest
can stay as they were. You need to do this change in each
line found in inetd.conf that starts the service that you
want to use with the TCP wrapper. If you want to close that
service simply add a # in from of ftp all the way to the
left and your ftp service port (21) should now be closed.
Now for the changes you have done to take effect you must
either reboot your box or restart the inetd by typing:
root@mike:~# killall -HUP inetd
If you don't really know what your really doing, a good
idea is to chattr the inetd.conf, this command stops any
changes being made by accident and stops renaming and
linking.
root@mike:~# chattr +i /etc/inetd.conf
to edit inetd.conf you just got to do the reverse
root@mike:~# chattr -i /etc/inetd.conf
Now that we configured the tcpd to mangage network
services by editing inetd.conf, we now have to edit the two
filz i mentioned above, host.allow and hosts.deny, which are
for allowing/denying which hosts are allowed/denied access
to your box.
-=-=-=-=-=-=-=-=-=-=-=-
Configure hosts.allow
-=-=-=-=-=-=-=-=-=-=-=-
Now after configureing the internet deamon, we have to
configure the hosts.allow file which gives access to which
hosts you are going to allow access. The configuration of
hosts.allow/hosts.deny is very similar. The basic syntax for
these filz is
The daemon list : Client list : shell command
Lets start with the daemon list, this syntax is used to
give the name of the service to which the rule applies. To
place more than one service you seperate each sevice with a
comma. The Client list you are going to use an IP address,
host name or a dns to which your going to allow, and to
allow more than one simply put a comma after each. It is
very important if you can to allow certain ip's instead of a
DNS, because host spoofing if easier than ip spoofing so
keep that in mind. The shell command is optional yet very
vital/usefull, keep reading to find out why.
One thing that many people always forget about TCP wrappers
is that the first matching rule that tcpd finds when it
seaches is the one that it is going to use, so in other
words once a match is found it stops looking. This is very
bad because if no match is found in either allow/deny files
then access by default will be granted. TCP wrappers first
check hosts.allow first so its is very important to halt any
ip's you don't want in that file first instead of putting
them in hosts.deny, so one way to solve this fault in TCP
wrappers is to deny access to all then select/grant access
to those who need access(people/hosts your trust).
Operator key words
==============
Here some some key words you can use for these parameters
so you can make configureing these two filz easier. Examples
will follow.
LOCAL = This key word will match any host whose name
doens't have a dot character.
UNKNOWN =This key word will match the host whose name or
address is not known.
ALL = This key word will match all hosts and services used.
KNOWN = This key word matches any host/user whose address
is known.
EXCEPT = This key word acts as an if/or ie, group1 EXCEPT
group2
---------
Here is an example of an hosts.allow file (this is fake)
ALL : All@127.0.0.1 : ALLOW
in.sshd : zopa.com
inet.ftpd : roster.zopa.com
ALL : .zopa.com EXCEPT cracker.zopa.com
Here all the hosts in the zopa.com domain are allowed to
use sshd, but roster is the only subdomain which will have
access to use ftpd, and the others can't access ftpd. In the
last line all hosts of zopa.com's domain will be allowed
access to use all services but except the subdomain
cracker.zopa.com . Notice it is more important to deny
access in hosts.allow cause till TCP wrapper checks
hosts.deny the access will be given access to the host
because I had allowed access to zopa.com which is a match
for the host thus it will grant access before even checking
cracker.zopa.com if i had placed it in the hosts.deny
folder. So its is obvious that to use the 'EXCEPT' keyword
in hosts.allow is better than putting the host in host.deny!
Now we don't want to leave hosts.deny empty we should place
this command.
Here is an of hosts.deny
ALL : ALL
==========
This will put a security that will deny access to all that
isn't explicitly granted access will be denied any access.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Optional variables for shells commands
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
You can also implement the optional shell command
variables. Many people don't use this optional feature cause
its becomes too technical but if you understand it can lead
you to forshadow any incoming attack.
I will tell you some variables to use with shell commands
here.
{-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=}
%u This variable will return the client username
%d This variable will return the daemon process
%p This variable will return the daemon process ID
%a This variable will return the client host address.
%c This variable will return information about the
client, like host name or user@host.
%h This variable will return the server hostname, and
if it can't find it, it will return the address.
{-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=}
Okay this is enough let me show you an example.
Thic could be an example of a line you might want to put in
your hosts.deny
ALL : ALL spawn (echo Attempt from %h %a to %d %p at 'date'
| tee /var/log/tcp.deny.log | mail rammal81@hotmail.com )
or something like the bottom but the above is preferred!
in.fptd : .zopa.com : (/usr/bin/fingerd -l @%h |
/usr/ucb/mail -s %d %c %h root)
so if access was denied to hosts from .zopa.com root would
recieve an email with info that are parallel to the variable
description.
Conclusion
One thing you should always keep in mind is that if a
hacker wants to root your box TCP wrappers will help but are
not the 100% inpenetrable line of defence. If you are going
to use tcp wrappers as the only means of protecting yourself
via hosts.deny as your only means of blocking inbound
traffic you better use ipchains or block the traffic before
it reaches your host via a hardware firewall or a router.
Now lets get serious we can't afford that so we have to use
ipchains as our real world option, and if you can I am
coming over to your house, hehe. Ipchains is very
good/flexible because it blocks traffic at the kernel level
before the packet is read by inetd or tcpd. I won't bother
going further into ipchains because way better tutorials
have been written on the topic so search of them at the
security sites. Back to tcp wrappers, you should use the
utilities called tcpdchk and tcpmatch, which come with the
TCP wrapper package and are explained pretty well in the
links given. Also IP's can be spoofed so always keep that in
mind with a lot of time an attacker can know which hosts you
allow and can spoof as them. One other thing you should keep
in mind is that TCP wrappers are only used to start up the
correct daemon that will be satisfying the correct request
so don't use it for services like NFS which deal with
multiple clients requests when started. Okay i hope you
learned something here, if you have anything to add to this
phile or have found some errors, plz email me and i'll fix
it up. thx
Credits and Greetz
Well there are just too many to give greetz to, but
everyone from Box Network, the kewl members of Blacksun, the
wonderful visitors who come everyday and the peeps who
answer the daily post don't think i forgot ya! Ohh and
everyone on irc.box.sk in all #channels. Ahh before i
forget, a huge greetz also goes out to Cube and Kript0n for
always being there. Thx!
Author: Mr. Mikkkeee <rammal81@hotmail.com>
http://blacksun.box.sk/
EOF |