[819] in Intrusion Detection Systems
ANNOUNCE: RealSecure 1.0 Available
daemon@ATHENA.MIT.EDU (Christopher Klaus)
Fri Dec 27 01:33:25 1996
From: Christopher Klaus <cklaus@iss.net>
To: ids@uow.edu.au
Date: Tue, 17 Dec 1996 15:20:32 -0500 (EST)
Reply-To: ids@uow.edu.au
"Advance Intrusion Detection Systems [like RealSecure] are a necessity,
along with firewalls and auditing software, for any company connecting
to the Internet that values their data."
- Aleph One
Moderator of BugTraq Security Mailing List
(Some additional stories on ISS this week have been:
The SAFEsuite Network Scanner Bundle for NT Available
http://www.pcweek.com/reviews/1216/16safe.html
Next generation of Security Tools
http://www.pcweek.com/news/1216/16sea.html
)
Announcement: RealSecure (tm) 1.0 Has Arrived.
RealSecure (RS) is a real-time monitoring, attack recognition, and
response system. This system allows for great flexibility in your
network traffic policy and identifying people attacking your networks.
Feel free to grab an evaluation copy at our web site http://www.iss.net .
RealSecure v1.0
---------------
Please email rs-support@iss.net with any problems or suggestions.
The technical support area of the ISS web page (http://www.iss.net) also
allows you to report any problems or suggestions that you have.
This directory contains the following programs:
rs - the monitoring engine
rsgui - the GUI to run the rs engine
playback - a utility to play back raw logged data
sssd - the master daemon which controls the engine ("rs")
Also, there are the following config files:
filter.cfg - a sample filter configuration
features.cfg - a sample attack patterns configuration
services - a mapping of ports to service names
ethcodes - a mapping of ethernet addresses to vendor names
Instructions (READ ALL OF THESE FIRST):
README - this file
README.install - installation notes
license.txt - license agreement for RealSecure
Features
--------
* Versions are available for SunOS 4.1.X, Solaris 2.3 and up, and Linux (kernel
versions 1.3.X and up). The NT version will be available in the
first half of the 1997 year.
* TCP/UDP Connection Triggering
* By IP source/destination address and mask
* By protocol
* By source/destination port
* Attack Pattern Triggering
* Host not responding to connection attempts
* Duplicate IPs
* Ping flooding
* TCP Half-Open scan
* Unknown IP protocol
* Source routed connections
* Identd returning bad replies (newlines, overflows)
* Rlogin and Rsh user/password/command, -froot check
* Rexec: user, passwd
* Sendmail: to user, from user, subject, vrfy, expn
* pipe attempts
* decode attempts
* WIZ attempts
* DEBUG attempts
* FTP: user/passwd, filename for get or put
* site exec attempts
* cwd ~root attempts
* POPmail: user/passwd
* HTTP: web traffic logging
* PHF attempts
* RPC Services
* Portmapper
* Rusers
* Rwall
* Statd
* Bootparam
* Admind
* Rexd
* NFS
* NIS
* Responses (activated by a TCP/UDP Connection or Attack Patterns)
* Ignore this event
* Display this connection's data in a terminal window
* Kill this connection (TCP only)
* Log the connection's raw data to a file (TCP/UDP/ICMP)
* Log the connection's textual data to a file (TCP/UDP/ICMP)
* Decode the event and pass the data to:
* a file
* an administrator via email
* standard input of a custom user program
* Reporting
* Play back logged data in a terminal window (Raw Logs only)
Usage
-----
RealSecure is very versatile, and thus has many different functions it can
perform. Some possible uses include:
* Auditting network utilization (How many hits do each of our web servers
get? Who is transferring files from our FTP site?)
* Auditting and blocking network intrusion attempts (How many attacks do
we get from non-US sites? How many rlogin attempts do we get and from
where?)
* Providing a second tier of security behind a firewall (We should never
see telnet sessions coming into our internal network, so kill and log
any such attempts)
* Detecting network state and possible problems (Did Sales just put a new
machine on our network? Who is using it? Did they accidentally use an
IP of an existing machine?)
* Obtaining profiles of a detected intruder and assessing damage (Ok, we
now know that the intruder is using our web server to attack other sites.
We will log all of his session data throughout the night and play it
back later.)
Sample configuration files are included in the distribution and show some
entries which should guide the administrator with producing a custom setup for
the target network.
To obtain maximum benefits from RealSecure, it should be installed on a
dedicated machine at the entry point to the network. Good places include
the Ethernet interface just inside the firewall or between the Internet
router and the internal machines. For security and performance, it is
strongly recommended that RealSecure be run on its own dedicated machine.
The machine should ideally have as many of its own services as possible
turned off. Also, the only users should be the administrator(s).
RealSecure collects a lot of data from the network, so the more power
and disk space the machine has, the better.
There are two components of RealSecure: the engine and the user
interface. The engine is called "rs" and the user interface is called
"rsgui". The user interface (GUI) is a way to configure engines and
see a summary of the latest network information. However, all the
real intelligence is located in the engine. Since it is possible to
run engines on a different host than the GUI, the engines must be able
to continue processing information and protecting your network even if
the link between the GUI and themselves is severed.
On all hosts running the engine ("rs"), you must run the ISS manager
daemon, sssd. It provides a secure means of transferring files, upgrading
RealSecure automatically, and running remote engines.
For the first time using it, get a feel for what your network
traffic is like. You can use the default filter.cfg to monitor the
traffic on your network, or you can setup a simple filter configuration
that looks like:
tcp 0.0.0.0/0 0.0.0.0/0 0 0 All-TCP 3 D
udp 0.0.0.0/0 0.0.0.0/0 0 0 All-UDP 3 D
Log into any hosts that will be running the engine and start up "sssd".
Then, log into the management (GUI) host and start up "rsgui". Both must
be run as root. The diagram below shows what a typical network might look
like:
------------ (network) ---------------
| GUI Host | ______------| Engine host |
| |-------------< | "sssd" |
| "rsgui" | -----_____ --------------- ---------------
------------ ---------------------| Engine host |
| "sssd" |
---------------
Of course, if a machine is going to be running an engine and the
GUI, both rsgui and sssd must be run on that machine.
When you start up rsgui, you will see a short intro screen and then the
engine management window will appear. No monitoring can be done until you
select the engines to run. Type in the name or IP of each machine that
will be running the engine. Then hit ENTER or click on "Start Engine"
to begin. Note that as you start up each engine, its name will appear
in the list of active engines. If any of them dies or is unreachable,
the GUI will show it in this list. If all is well, each engine should
say "Alive".
By now, the engines will be reporting all TCP and UDP connections
in the main window. As you can see, it can get very crowded, quickly.
Select "Quit" from the toolbar to exit RealSecure.
Now, review what your network policy is. Do you allow rlogin from
anywhere?
>From just internal hosts? Examining the firewall's configuration can
help here. The entries in the filter.cfg file are matched one at a
time, in order. A match means the action specified at the end of the
line is taken, and further matches are discarded. For this reason,
wildcard entries (like the ones above) should be saved for the end.
The configuration can also be editted from "rsgui" under the
Configuration" screen by selecting the "Filter" button. It is an
easier-to-use way of editting a filter configuration. For further
examples on how to use RealSecure, it is strongly recommended that you
read filter.cfg and features.cfg before running this on your network.
Dangers
-------
Because RealSecure watches and responds to network events, it has some
associated risks. First, it can log all data in a connection including
keystrokes and email. Discretion should be exercised when using this
feature. Once logs are created, they should be kept on a secure host
as they may contain passwords or other sensitive data. This is another
reason to run RealSecure on a dedicated machine. Intruders will see
the monitoring machine as a prime target, both to steal its saved data
and to erase evidence of their actions.
Second, RealSecure responds to events. In particular, the 'kill'
option, if misused, can block traffic over an entire network. Be careful
to ensure that any connections being killed are the ones that are supposed
to be blocked. A wildcard rule with a 'kill' action will block all
connections, including web, telnet, ftp.
The rule of thumb to use is "think twice, configure once".
Requirements
------------
* SunOS 4.1.X, Solaris 2.3 and up, or Linux (kernel versions 1.3.X
and up)
* An Ethernet interface connected to the target network
* 486-class performance or better (note that if the machine is not
dedicated to running RealSecure, more resources will be
necessary)
* At least 25 mb of free disk space To use the GUI:
* The X-Window system, version 11 or higher
* Motif Installation (Solaris 2.3 and 2.4 only)
License
-------
Please check the web site (http://www.iss.net) or send
mail to rs-support@iss.net for information about using this release.
See the file "license.txt" for a description of license conditions.
Legality
--------
In most cases, the US government has upheld the right of individuals to
monitor their networks. The general consensus is that all users
should be notified of the monitoring. We recommend that you consult
with a lawyer if you have any questions as to the legality of this
product's use. Below is a CERT advisory explaining the legal issues.
*****************************************************************************
CA-92:19 CERT Advisory
December 7, 1992
Keystroke Logging Banner
-----------------------------------------------------------------------------
The CERT Coordination Center has received information from the United
States Department of Justice, General Litigation and Legal Advice
Section, Criminal Division, regarding keystroke monitoring by computer
systems administrators, as a method of protecting computer systems from
unauthorized access. The information that follows is based on the Justice
Department's advice to all federal agencies. CERT strongly suggests
adding a notice banner such as the one included below to all systems.
Sites not covered by U.S. law should consult their legal counsel.
-----------------------------------------------------------------------------
The legality of such monitoring is governed by 18 U.S.C. section
2510 et seq. That statute was last amended in 1986, years before
the words "virus" and "worm" became part of our everyday vocabulary.
Therefore, not surprisingly, the statute does not directly address
the propriety of keystroke monitoring by system administrators.
Attorneys for the Department have engaged in a review of the statute
and its legislative history. We believe that such keystroke
monitoring of intruders may be defensible under the statute.
However, the statute does not expressly authorize such monitoring.
Moreover, no court has yet had an opportunity to rule on this issue.
If the courts were to decide that such monitoring is improper, it
would potentially give rise to both criminal and civil liability
for system administrators. Therefore, absent clear guidance from
the courts, we believe it is advisable for system administrators
who will be engaged in such monitoring to give notice to those who
would be subject to monitoring that, by using the system, they are
expressly consenting to such monitoring. Since it is important that
unauthorized intruders be given notice, some form of banner notice at
the time of signing on to the system is required. Simply providing
written notice in advance to only authorized users will not be
sufficient to place outside hackers on notice. An agency's banner
should give clear and unequivocal notice to intruders that by signing
onto the system they are expressly consenting to such monitoring.
The banner should also indicate to authorized users that they may be
monitored during the effort to monitor the intruder (e.g., if a hacker
is downloading a user's file, keystroke monitoring will intercept
both the hacker's download command and the authorized user's file).
We also understand that system administrators may in some cases
monitor authorized users in the course of routine system maintenance.
If this is the case, the banner should indicate this fact. An example
of an appropriate banner might be as follows:
This system is for the use of authorized users only. Individuals
using this computer system without authority, or in excess of
their authority, are subject to having all of their activities
on this system monitored and recorded by system personnel.
In the course of monitoring individuals improperly using this
system, or in the course of system maintenance, the activities
of authorized users may also be monitored. Anyone using this
system expressly consents to such monitoring and is advised that
if such monitoring reveals possible evidence of criminal activity,
system personnel may provide the evidence of such monitoring to
law enforcement officials.
-----------------------------------------------------------------------------
Each site using this suggested banner should tailor
it to their precise needs. Any questions should
be directed to your organization's legal counsel.
-----------------------------------------------------------------------------
The CERT Coordination Center wishes to thank Robert S. Mueller,
III, Scott Charney and Marty Stansell-Gamm from the United States
Department of Justice for their help in preparing this Advisory.
*****************************************************************************
