In short, TCP-wrappers allow connections to the machine on which they are running to be restricted to those coming from approved domains or machines, e.g., if you would prefer that only telnet requests from within umist.ac.uk should be accepted then use TCP-wrappers!
Let me quote from the blurb that comes with these:
TCP/IP Wrappers help you to monitor and filter incoming requests for the
SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other
network services.
The package provides tiny daemon wrapper programs that can be installed
without any changes to existing software or to existing configuration
files. The wrappers report the name of the client host and of the
requested service; the wrappers do not exchange information with the
client or server applications, and impose no overhead on the actual
conversation between the client and server applications.
TCP-Wrappers are not installed on Solaris 8 as part of the distribution from Sun.
The main site (or more accurately page) is:
ftp://ftp.porcupine.org/pub/security/index.html
|
make
|
The best way to install the TCP-wrapper is as follows. Copy the utilties you have built into /usr/sbin, then edit (create) two text files. The following examples can be used as a model:
in.telnetd: ALL
in.ftpd: ALL
in.rexecd: ALL
in.rlogind: ALL
in.rshd: ALL
|
in.telnetd: .umist.ac.uk, .mcc.ac.uk, .liv.ac.uk
in.ftpd: .umist.ac.uk, .mcc.ac.uk
in.rshd: .umist.ac.uk
|
rsh host /some/where/try-from
|
Obtain the RPMs for both Port Sentry and Log Check from any RedHat mirror, within the contrib directory, or at rpmfind.net, or its UK mirror at www.mirror.ac.uk. Then install them in the usual way, i.e., as root, rpm -Uvh <file>.rpm. This process installs the necessary files, starts the daemons and ensures the necessary entries are placed in the initialisation tables so that the daemons are started on subsequent boots.
Download the .tar.gz file from Psionic's site (see above).
There are two files, /etc/hosts.allow and /etc/hosts.deny.
If a mostly-closed configuration is desired, then hosts.deny should consist of simply
ALL: ALL |
# hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # # in.telnetd: .liv.ac.uk : ALLOW ###ALL : .liv.ac.uk ###ALL : .umist.ac.uk ALL : talby.csu.umist.ac.uk ALL : boiler.csu.umist.ac.uk ALL : pinback.csu.umist.ac.uk in.telnetd : cosmos.umist.ac.uk ALL : rcpc.csu.umist.ac.uk ALL : listserv.umist.ac.uk
If a mostly-open configuration is desired the /etc/hosts.allow consists of simply ALL: ALL so that hosts are allowed to connect by default and /etc/hosts.deny will list services and corresponding IP addresses which should be denied access, for example:
in.telnetd : knownoffender.domain ALL : .dodgy.domain |
Whilst many services run by listening on "well known" ports, others such as NIS and NFS use RPC (Remote Procedure Call). Instead an arbitrary port is chosen on initialisation and this is then registered with a Portmapper service running on the same machine. Only the Portmapper needs to run on the "well-known" port; when clients want access to the service, they first contact the Portmapper, and it tells them which port they should then contact in order to reach the service. This second port may be for TCP or UDP access, depending on the client.
On Linux, portmap provides the portmapper service. Whilst it runs separately from inetd, Version 4 (and above), written by Wietse Venema, provides TCP Wrappers-style access-control via the same hosts.allow and hosts.deny files. On Solaris rpcbind provides the portmapping service; an enhanced version is available and which provides access control.
Most Linux distibutions come with portmap. If it is unavailable with your distribution dowbload the source code from coast.cs.perdue.edu or ftp.porcupine.org. Before compilation, edit the Makefile to reflect your choice of value for the various flags (these include where to log events, the location of libwrap.a, the TCP Wrappers library which must be installed first) then build and install in the usual way.
portmap uses the same files as TCP Wrappers, /etc/hosts.allow and /etc/hosts.deny. To taste the flavour of configuration consider the following example entries in hosts.allow:
# -- hosts.allow :
portmap: 172.19.0.0/255.255.240.0: deny
portmap: 255.255.255.255, 0.0.0.0: spawn (/usr/sbin/safe_finger \
-lp @%a | logger -p local5.warn)&
# -- allow the rest of our internal network :
portmap: 172.17.
# deny everyone else :
portmap: ALL: deny
|
By default only failed requests are logged. If successful requests are to be logged invoke portmap with the -v option.
The source code for the replacement rcpbind which includes access control may be obtained from ftp.porcupine.com.
RedHat 6.2 and earlier versions of Linux handle internet sockets through inetd. When running, inetd listens for connections on certain internet sockets. When a connection is found on one of its sockets, it looks up which service the socket corresponds to, and invokes a program (server) to service the request. In recent versions of Linux inetd has been replaced with xinetd.
xinetd provides: access-control similar to that offered by inetd with TCP Wrappers --- one can control both tcp and udp unlike Wrappers; improved logging compared to inetd; improved defense against denial of service attacks --- in addition to specifying the rate of connections to a service that is permitted, one can specify the maximum number accepted.
xinetd can provide access-control for both inetd-style services and RPC services.
In starting xinetd you can specify both the configuration file and the file to be used for logging. For example
/usr/sbin/xinetd -filelog /var/log/xinetd.log -f /etc/xinetd.conf
|
prompt>ps -ax | grep xinetd
root 644 0.0 0.7 2240 956 ? S 08:57 0:00 xinetd -pidfile...
prompt>kill -SIGUSR1 644
|
/etc/init.d/xinetd restart
|
The configuration file is usually /etc/xinetd.conf. One can either modify the supplied file or create one from an inetd.conf file using itox or xconv.pl (supplied --- the latter is to succeed the former).
Each service controlled by xinetd has a corresponding section in the configuration file. Each section looks something like this:
service ssh1
{
socket_type = stream
protocol = tcp
instances = 10
nice = 10
wait = no
user = root
server = /usr/local/sbin/sshd1
server_args = -i
log_on_failure += USERID
only_from = 192.168.0.0
no_access = 192.168.54.0
no_access += 192.168.33.0
}
TCP-wrappers-like access control is given by the only_from and
no_access directives; the maximum number of instances of the server
which can run simultaneously is given by instances (preventing DoS
attacks).
On some systems, including RedHat 7.1, there is a master configuration file, /etc/xinetd.conf, which includes the line
includedir /etc/xinetd.d
|
# default: on
# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
disable = no
only_from = 130.88.100.77
only_from += 130.88.100.87
}
Using logging directives (e.g., log_on_failure += USERID) one can log various attrributes of attempted connections including process-id, remote host and duration of session; one can specify distinct directives for success and failure, for example, one can log the reason why a connection failed.
No system is impregnable. Intrusion Detection systems provide a final safety net which will help minimise damage from a successful root crack of your system. The principle used is simple: often a system cracker, after "rooting" will install their own versions of system utilities such as ls, ps and netstat, in order to hide their activities --- these new versions will fail to list particular files, processes or connections. Intrusion detection systems (integrity checkers) create databases of hashes/checksums of important utilities and configuration files. By periodically checking those files against the checker's database we should be able to spot such activity.
FCheck is an open source PERL script providing intrusion detection and policy enforcement of Windows 95/98/NT/3.x and Unix server administration through the use of comparative system snapshots. FCheck can provide notification of any differences found through use of your event management system, printer, and/or email when any monitored files or directories are altered, including any additions and/or deletions.
FCheck has been tested and is known to run on the following platforms with Perl installed:
Let me quote from the RPM: Tripwire answers the fundamental question: "Is my system the same today as it was yesterday?" Tripwire creates a cryptographically-secured database of files and their characteristics based on the specifications of your configurable policy file. This database is then used to determine if any unauthorized changes have been made to your system.
There three versions of Tripwire:
We describe the configuration of the version of Tripwire that comes with RedHat Linux 7.1.
Most distributions of Linux come with an rpm. After installing the rpm (rpm -ivh tripwire-<version>.rpm) Tripwire is not yet configured. To do this:
If you wish to subsequently change the use the twadmin utility:
This example should give the flavour of Tripwire. For details, see the resources given below.
WEBROOT=/home/simonh/public_html;
CGIBINS=/home/simonh/public_html/cgi-bin;
TWPOL="/etc/tripwire";
TWDB="/var/lib/tripwire";
BINS = $(ReadOnly) ;
SEC_INVARIANT = +tpug ;
SIG_MED = 66 ;
# Simon's web rules:
(
rulename = "MickWeb"
severity = $(SIG_MED)
emailto = simon.hood@umist.ac.uk
)
{
$(TWPOL) -> $(ReadOnly) ;
$(WEBROOT) -> $(ReadOnly) (recurse=1) ;
!$(WEBROOT)/guestbook.html ;
$(CGIBINS) -> $(BINS) ;
/var/log/httpd -> $(Growing) ;
}
The first four lines of this script set some variables in a similar way to scripting under most shells. The fifth line sets a synonym for a pre-defined mask. A mask defines what properties should not change, such as file owner, time-stamp and file size.
SEC_INVARIANT = +tpug defines a mask for directories that should not change permissions or ownership (t: file type, p: permissions, u: file owner's user ID, g: file owner's group ID).
SIG_MED = 66 defines a severity level of the rule.
The remainder of the example defines a group of rules: first the name and severity are set; then the action to take (email to simon.hood). This rule group consists of 5 rules: the first says that TWPOL must be readonly; the second that WEBROOT should be readonly, including one level of subdirectories; the third (beginning with an exclamation mark) tells tripwire to ignore changes to guestbook.html; the fourth sets the cgi-bin scripts to be readonly; and the last says that the web-server log file is expected to grow (monotonically).
A good way to use Tripwire is to have it compare files on your system to its database on a regular basis and email you the results. This is easily done: ensure part of /etc/tripwire/twcfg.txt looks like this:
MAILMETHOD =SENDMAIL
MAILPROGRAM =/usr/sbin/sendmail -oi -t
|
!/bin/sh
HOST_NAME=`uname -n`
if [ ! -e /var/lib/tripwire/${HOST_NAME}.twd ] ; then
echo "** Error: Tripwire database for ${HOST_NAME} not found. **"
echo "** Run "/etc/tripwire/twinstall.sh" and/or "tripwire --init". **"
else
test -f /etc/tripwire/tw.cfg && /usr/sbin/tripwire --check
fi
|
HostSentry...Psionic (cf. LogSentry, PortSentry)...
From
AIDE (Advanced Intrusion Detection Environment) is a free replacement
for Tripwire. It does the same things as the semi-free Tripwire and more.
It creates a database from the regular expression rules that it finds from
the config file. Once this database is initialized it can be used to
verify the integrity of the files. It has several message digest algorithms
(md5, sha1, rmd160, tiger, haval, etc.) that are used to check the integrity
of the file. More algorithms can be added with relative ease. All of the
usual file attributes can also be checked for inconsistencies.
AIDE has been tested running on:
The Concurrent Versions System was designed to be used by software developers to organise source code. It can also be used as an intrusion detection tool with advavantages over and above Tripwire, the most commonly used tool.
Tripwire and similar tools tend to report a larger number of false positives; Tripwire reports only that a file has changed, not details of the change. This combination of features can mean a lot of work for system administrators. On the other hand CVS will report exactly how a text file has changed. CVS can also be used to compare the output of commands (e.g., ls -l my_dir) since these can be redirected to files. These advantages can save time and yield details about an intrusion which Tripwire does not. (On the other hand, CVS cannot handle binary files.)
For details of how CVS can be used (with a little Perl glue) see Veryifying Filesystem Integrity with CVS, Linux Journal, Feburary, 2002.
From the README:
chkrootkit is a tool to locally check for signs of a rootkit. It contains: * chkrootkit: a shell script that checks system binaries for rootkit modification. The following tests are made: aliens asp bindshell lkm rexedcs sniffer wted z2 amd basename biff chfn chsh cron date du dirname echo egrep env find fingerd gpm grep hdparm su ifconfig inetd inetdconf identd killall ldsopreload login ls lsof mail mingetty netstat named passwd pidof pop2 pop3 ps pstree rpcinfo rlogind rshd slogin sendmail sshd syslogd tar tcpd top telnetd timed traceroute write * ifpromisc.c: checks if the network interface is in promiscuous mode. * chklastlog.c: checks for lastlog deletions. * chkwtmp.c: checks for wtmp deletions. * check_wtmpx.c: checks for wtmpx deletions. (Solaris only) * chkproc.c: checks for signs of LKM trojans.
| ...previous | up (conts) | next... |