Intrusion Detection
&
Network Forensics
Marcus J. Ranum
1
An ounce of
prevention is worth a
pound of detection
2
Why Talk about IDS?
• Emerging new technology
– Very interesting
...but...
– About to be over-hyped
• Being informed is the best weapon in
the security analyst’s arsenal
– It also helps keep vendors honest!
3
What is an Intrusion?!
• Difficult to define
– Not everyone agrees
– This is a big problem
• How about someone telnetting your system?
– And trying to log in as “root”?
• What about a ping sweep?
• What about them running an ISS scan?
• What about them trying phf on your webserver?
– What about succeeding with phf and logging in?
4
What is IDS?
• The ideal Intrusion Detection System
will notify the system/network manager
of a successful attack in progress:
– With 100% accuracy
– Promptly (in under a minute)
– With complete diagnosis of the attack
– With recommendations on how to block it
…Too bad it doesn’t exist!!
5
Objectives: 100% Accuracy
and 0% False Positives
• A False Positive is when a system
raises an incorrect alert
– “The boy who cried ‘wolf!’” syndrome
• 0% false positives is the goal
– It’s easy to achieve this: simply detect
nothing
• 0% false negatives is another goal:
don’t let an attack pass undetected
6
Objectives: Prompt
Notification
• To be as accurate as possible the
system may need to “sit on” information
for a while until all the details come in
– e.g.: Slow-scan attacks may not be
detected for hours
– This has important implications for how
“real-time” IDS can be!
– IDS should notify user as to detection lag
7
Objectives: Prompt
Notification
(cont)
• Notification channel must be protected
– What if attacker is able to sever/block
notification mechanism?
– An IDS that uses E-mail to notify you is
going to have problems notifying you that
your E-mail server is under a denial of
service attack!
8
Objectives: Diagnosis
• Ideally, an IDS will categorize/identify
the attack
– Few network managers have the time to
know intimately how many network attacks
are performed
• This is a difficult thing to do
– Especially with things that “look weird” and
don’t match well-known attacks
9
Objectives: Recommendation
• The ultimate IDS would not only identify
an attack, it would:
– Assess the target’s vulnerability
– If the target is vulnerable it would notify the
administrator
– If the vulnerability has a known “fix” it
would include directions for applying the fix
• This requires huge, detailed knowledge
10
IDS: Pros
• A reasonably effective IDS can identify
– Internal hacking
– External hacking attempts
• Allows the system administrator to
quantify the level of attack the site is
under
• May act as a backstop if a firewall or
other security measures fail
11
IDS: Cons
• IDS’ don’t typically act to prevent or
block attacks
– They don’t replace firewalls, routers, etc.
• If the IDS detects trouble on your
interior network what are you going to
do?
– By definition it is already too late
12
Privacy: a Problem
• Some governments/states mandate
levels of privacy protection for
employees or students
– This may make it impossible to adequately
gather data for the IDS
– This may make it impossible to gather
forensic data for analysis or prosecution
13
Privacy: a Problem
(cont)
• Is it prying if it’s done by a computer?
– What if a human never sees it?
– What if the information is never acted
upon?
• At what point is privacy violated?
– Looking at packet headers?
– Looking at packet contents?
– Looking at /var/mail/user?
14
Paradigms for Deploying IDS
• Attack Detection
• Intrusion Detection
15
Attack Detection
DMZ
Network
Desktop
WWW
Server
Internet
Router
w/some
screening
Internal
Network
Firewall
IDS detects (and counts) attacks against
the Web Server and firewall
IDS
16
Attack Detection
• Placing an IDS outside of the security
perimeter records attack level
– Presumably if the perimeter is well
designed the attacks should not affect it!
– Still useful information for management
(“we have been attacked 3,201 times this
month…)
– Prediction: AD Will generate a lot of noise
and be ignored quickly
17
Intrusion Detection
DMZ
Network
Desktop
WWW
Server
Internet
Router
w/some
screening
Internal
Network
Firewall
IDS detects hacking activity WITHIN
the protected network, incoming or outgoing
IDS
18
Intrusion Detection
• Placing an IDS within the perimeter will
detect instances of clearly improper
behavior
– Hacks via backdoors
– Hacks from staff against other sites
– Hacks that got through the firewall
• When the IDS alarm goes off, it’s a red
alert
19
Attack vs Intrusion Detection
• Ideally do both
• Realistically, do ID first then AD
– Or, deploy AD to justify security effort to
management, then deploy ID (more of a
political problem than a technical one)
• The real question here is one of staffing
costs to deal with alerts generated by
AD systems
20
Paradigms for Data
Correlation
•
•
•
•
IDES
Audit
Inline
Hybrid (a mix of both)
21
IDES
• Dorothy Denning (1986) publishes “An
Intrusion Detection Model” which
defines much IDS thinking
– Defines components of an IDS in terms of:
• Subjects - initiators of activity
• Objects - targets of activity
• Profiles - characterization of how subjects
operate on objects (may be statistical models
or pattern matching)
22
IDES
(cont)
• Audit Records - trace information about the
occurrence of events in time
• Anomaly Records - trace information about the
occurrence of unusual events in time, often
generated by the IDS or applications
• Alarms - information that the system brings to
the security administrator’s attention
– Systems evolved from IDES: DIDs, Stalker,
Emerald
23
Block Diagram: Generic IDS
Pre-Processing
Host
System
or
Network
Sniffer
Response
manager
Statistical
analysis
Signature
matching
Alert manager
Knowledge
base
Long term
storage
GUI
24
Audit Based IDS
• Audit based IDS post-process audit trail
(and other) information
– Activity is first logged then post-processed
– Batch oriented approach allows for virtually
infinite correlation if enough data is present
Kernel
and
applications
IDS
Correlation
Audit
Database
reports
alerts
25
Audit Data
• Determining what is a good audit probe
point (where to record something) is a
difficult problem
– Orange book includes 23 probe points
within UNIX kernel and applications
•
•
•
•
open read/write
creation of IPC
bad login
add/remove user/group
process fork
create/remove file
password change
etc...
26
Networked Auditable Events
•
•
•
•
•
•
Users logging in at unusual hours*
Unexplained reboots
Unexplained time changes
Unusual error messages
Failed login attempts
Users logging in from unfamiliar sites*
* (implies that per-user “history” is kept)
27
CIDF
• ARPA sponsored effort to achieve
Common Intrusion Detection
Framework
– Architectural conventions for IDS modules
– Messaging specification for audit data and
its transmission
– Information on CIDF on the web:
http://www.seclab.ucdavis.edu/cidf/spec/cidf.txt
28
CIDF
(cont)
• Conceptual components are modules
– Event generators - collect or generate data
– Analysis engines - processing and
correlation
– Storage mechanisms - archival and short
term storage including of logs and audit
records
– Response components - outputs
29
CIDF
(cont)
• Will CIDF work?
– Pro: It’s a generalization of most IDS; all
the pieces are there
– Con: Will IDS vendors see any value in an
interoperable, modular solution?
30
Inline IDS
• Inline IDS process audit data as it is
generated
– Typically discard audit data that it does not
recognize as significant
– Amount of correlation tends to be limited
Kernel
and
applications
IDS
Correlation
Bit bucket
reports
alerts
Incident
database
31
Audit vs Inline
• Inline is faster but only provides a “local”
view unless a lot of data is forwarded in
realtime to a central location
• Audit is deeper but requires keeping lots
of data
• Hybrid systems exploit both: inline
detection of significant events to an
audit station
32
IDS Data Source Paradigms
• Host Based
• Network Based
33
Host Based IDS
• Collect data usually from within the
operating system
– C2 audit logs
– System logs
– Application logs
• Data collected in very compact form
– But application / system specific
34
Host Based: Pro
• Quality of information is very high
– Software can “tune” what information it
needs (e.g.: C2 logs are configurable)
– Kernel logs “know” who user is
• Density of information is very high
– Often logs contain pre-processed
information (e.g.: “badsu” in syslog)
35
Host Based: Con
• Capture is often highly system specific
– Usually only 1, 2 or 3 platforms are
supported (“you can detect intrusions on
any platform you like as long as it’s Solaris
or NT!”)
• Performance is a wild-card
– To unload computation from host logs are
usually sent to an external processor
system
36
Host Based: Con
(cont)
• Hosts are often the target of attack
– If they are compromised their logs may be
subverted
– Data sent to the IDS may be corrupted
– If the IDS runs on the host itself it may be
subverted
37
Network Based IDS
• Collect data from the network or a hub /
switch
– Reassemble packets
– Look at headers
• Try to determine what is happening from
the contents of the network traffic
– User identities, etc inferred from actions
38
Network Based: Pro
•
•
•
•
•
No performance impact
More tamper resistant
No management impact on platforms
Works across O/S’
Can derive information that host based
logs might not provide (packet
fragmenting, port scanning, etc.)
39
Network Based: Con
• May lose packets on flooded networks
• May mis-reassemble packets
• May not understand O/S specific
application protocols (e.g.: SMB)
• May not understand obsolete network
protocols (e.g.: anything non-IP)
• Does not handle encrypted data
40
IDS Paradigms
•
•
•
•
•
Anomaly Detection - the AI approach
Misuse Detection - simple and easy
Burglar Alarms - policy based detection
Honey Pots - lure the hackers in
Hybrids - a bit of this and that
41
Anomaly Detection
• Goals:
– Analyse the network or system and infer
what is normal
– Apply statistical or heuristic measures to
subsequent events and determine if they
match the model/statistic of “normal”
– If events are outside of a probability
window of “normal” generate an alert
(tuneable control of false positives)
42
Anomaly Detection
(cont)
• Typical anomaly detection approaches:
– Neural networks - probability-based pattern
recognition
– Statistical analysis - modelling behavior of
users and looking for deviations from the
norm
– State change analysis - modelling system’s
state and looking for deviations from the
norm
43
Anomaly Detection: Pro
• If it works it could conceivably catch any
possible attack
• If it works it could conceivably catch
attacks that we haven’t seen before
– Or close variants to previously-known
attacks
• Best of all it won’t require constantly
keeping up on hacking technique
44
Anomaly Detection: Con
• Current implementations don’t work
very well
– Too many false positives/negatives
• Cannot categorize attacks very well
– “Something looks abnormal”
– Requires expertise to figure out what
triggered the alert
– Ex: Neural nets can’t say why they trigger
45
Anomaly Detection: Examples
• Most of the research is in anomaly
detection
– Because it’s a harder problem
– Because it’s a more interesting problem
• There are many examples, these are
just a few
– Most are at the proof of concept stage
46
Anomaly Detection
(cont)
• IDES/NIDES
– Real-time IDS using statistical anomaly
detection combined with rule-based misuse
detection
– Relies on system’s audit records for input
– Rulebase is limited
ftp://ftp.csl.sri.com/pub/nides/index1.html
47
Anomaly Detection
(cont)
• GrIDS
– Graph-based intrusion detection system
– Models network activity based on analysis
of graph matching
– Includes a policy language for translating
organizational policies into analysis
rulesets
http://seclab.cs.ucdavis.edu
48
Anomaly Detection
(cont)
• Emerald
– Multiple layered model IDS
• Service specific analysis - service monitors
deployed within network gather tailorable
information
• Domain-wide analysis - correlation of service
analysis
• Enterprise-wide analysis - correlation of events
across domains
49
Emerald
(cont)
• Information propagated upward gets
sparser but is more dense
– Data is abstracted into a common format
from packet traces, application logs, and
kernel logs
– Profiler engine - looks for statistical
anomalies
– Signature engine - looks for attack
signatures
50
Misuse Detection
• Goals:
– Know what constitutes an attack
– Detect it
51
Misuse Detection
(cont)
• Typical misuse detection approaches:
– “Network grep” - look for strings in network
connections which might indicate an attack
in progress
– Pattern matching - encode series of states
that are passed through during the course
of an attack
• e.g.: “change ownership of /etc/passwd” ->
“open /etc/passwd for write” -> alert
52
Misuse Detection: Pro
•
•
•
•
•
•
Easy to implement
Easy to deploy
Easy to update
Easy to understand
Low false positives
Fast
53
Misuse Detection: Con
• Cannot detect something previously
unknown
• Constantly needs to be updated with
new rules
• Easier to fool
54
Misuse Detection
(cont)
• A number of commercial misuse
detection products are on the market
– ISS RealSecure
– Cisco NetRanger
– NAI CyberCop
– NFR Network Flight Recorder
• Deployment model is to feed rulesets to
customer as subscription service
55
Misuse Detection
(cont)
• Things misuse detection looks for:*
– IP Frag attack
Ping flooding
– Source routing
Ping of death
– ISS Scan check SATAN scan check
– Rwhod check
Rlogin decode
– Rlogin -froot
TFTP get passwd check
– IMAP buffer smash
– SMTP WIZ check … etc.
* (From ISS RealSecure)
56
Misuse Detection
(cont)
• Misuse detection systems are similar to
virus scanning systems:
– Both rely on meta-rules of vulnerabilities
– Both need frequent rules updates
– Both are easily fooled by slight mutations
in virus/attack signature
– Both are fairly low in generating false
positives
57
Burglar Alarms
• A burglar alarm is a misuse detection
system that is carefully targeted
– You may not care about people portscanning your firewall from the outside
– You may care profoundly about people
port-scanning your mainframe from the
inside
– Set up a misuse detector to watch for
misuses violating site policy
58
Burglar Alarms
(cont)
• Goals:
– Based on site policy alert administrator to
policy violations
– Detect events that may not be “security”
events which may indicate a policy
violation
• New routers
• New subnets
• New web servers
59
Burglar Alarms
(cont)
• Trivial burglar alarms can be built with
tcpdump and perl
• Netlog and NFR are useful event
recorders which may be used to trigger
alarms
http://www.nswc.navy.mil/ISSEC/Docs/loggingproject.html
ftp://coast.cs.purdue.edu/pub/tools/unix/netlog/
http://www.nfr.net/download
60
Burglar Alarms
(cont)
• The ideal burglar alarm will be situated
so that it fires when an attacker
performs an action that they normally
would try once they have successfully
broken in
– Adding a userid
– Zapping a log file
– Making a program setuid root
61
Burglar Alarms
(cont)
• Burglar alarms are a big win for the
network manager:
– Leverage local knowledge of the local
network layout
– Leverage knowledge of commonly used
hacker tricks
62
Burglar Alarms: Pro
•
•
•
•
•
•
Reliable
Predictable
Easy to implement
Easy to understand
Generate next to no false positives
Can (sometimes) detect previously
unknown attacks
63
Burglar Alarms: Con
• Policy-directed
– Requires knowledge about your network
– Requires a certain amount of stability
within your network
• Requires care not to trigger them
yourself
64
Honey Pots
• A honey pot is a system that is
deliberately named and configured so
as to invite attack
– swift-terminal.bigbank.com
– www-transact.site.com
– source-r-us.company.com
– admincenter.noc.company.net
65
Honey Pots
(cont)
• Goals:
– Make it look inviting
– Make it look weak and easy to crack
– Instrument every piece of the system
– Monitor all traffic going in or out
– Alert administrator whenever someone
accesses the system
66
Honey Pots
(cont)
• Trivial honey pots can be built using
tools like:
– tcpwrapper
– Burglar alarm tools (see “burglar alarms”)
– restricted/logging shells (sudo, adminshell)
– C2 security features (ugh!)
• See Cheswick’s paper “An evening with
Berferd” for examples
67
Honey Pots: Pro
•
•
•
•
Easy to implement
Easy to understand
Reliable
No performance cost
68
Honey Pots: Con
• Assumes hackers are really stupid
– They aren’t
69
Hybrid IDS
• The current crop of commercial IDS are
mostly hybrids
– Misuse detection (signatures or simple
patterns)
– Expert logic (network-based inference of
common attacks)
– Statistical anomaly detection (values that
are out of bounds)
70
Hybrid IDS
(cont)
• At present, the hybrids’ main strength
appears to be the misuse detection
capability
– Statistical anomaly detection is useful more
as backfill information in the case of
something going wrong
– Too many false positives - many sites turn
anomaly detection off
71
Hybrid IDS
(cont)
• The ultimate hybrid IDS would
incorporate logic from vulnerability
scanners*
– Build maps of existing vulnerabilities into
its logic of where to watch for attacks
• Backfeed statistical information into
misuse detection via a user interface
* Presumably, a clueful network
72
admin would just fix the vulnerabilty
Fooling IDS
• The quality of information available to
an IDS is directly proportional to how
closely it is collected to its origin
– Log messages from an application are
most valuable
– Log messages from kernel logs may allow
IDS to infer application states
– Network traffic from sniffer may allow
inferring O/S or application state
73
Fooling IDS
(cont)
• The more closely the data has to be
gathered the harder it is to collect
– Application logs require modified software
– Kernel logs require kernel specific
configuration (may also cause performance
problems)
– Network-oriented data collection is nonintrusive and invisible
74
Fooling IDS
(cont)
• The farther away the IDS is from the
source of the data the more vulnerable
it is to spoofing
– Network-oriented IDS will have trouble
making sense of:
$ stty erase R
$ rxRoxRoxRotkit
$ stty erase ^?
– A logging shell would not be fooled
75
Fooling IDS
(cont)
• Flooding networks with data may also
be used to mask an attack against an
IDS
– Of course, this is a dead giveaway!
– Few systems are capable of doing packet
capture at speeds greater than 20Mb/s
• If all else fails, the attacker can try to
crash the IDS itself (another dead giveaway!)
76
Fooling IDS
(cont)
• Not all network based IDS do full TCP
reassembly; they are vulnerable to
attempts to manipulate TCP stream
– Such attempts should be detected as
unusual/noteworthy events in their own
right
– (Usually networks do not fragment large
packets into 40-byte fragements, etc)
77
Fooling IDS
(cont)
• Summary: The IDS designer must
establish a judicious balance between:
– Recording too much and being too
obtrusive and slow
versus
– Quickly gathering secondhand data and
possibly being fooled or missing something
78
IDS and the WWW
• IDS are a logical candidate for
protecting web sites
– Unfortunately, they are not very good
against SSL-encrypted streams
– Use host-based IDS for web servers
– Use network-based IDS to profile scans
and sweeps against web servers
79
IDS and the WWW
(cont)
• For critical / paranoid web sites
consider:
– Build burglar alarms using host security on
the server itself
– Install O/S security (e.g.: SeOS, or C2 with
alerts) to notify administrator of httpd
attempting anything other than running cgibin and opening files in http area
80
Simple Burglar Alarm
HTTP and SSL
permitted
Desktop
WWW
Server
Internet
Router
w/some
screening
Internal
Network
Firewall
Nothing else
permitted
DMZ
Network
In-kernel screening
on WWW server with
inverse of router rules
81
Simple Burglar Alarm
(cont)
• In-kernel screening can be used to
generate alerts easily
• Example is based on ip_filt screening
language
– Ip_filt can log packet bodies or events
– Logs can be post-processed/watched with
a simple perl script
– Remember: this should never happen
82
Simple Burglar Alarm
(cont)
# sample: block all packets by default
block all
# drop “localhost” packets coming in from network
block in on le0 log body from localhost to any
# drop “inside” packets coming in from “outside”
block in on le1 log body from mynet to any
# drop source routed packets
block in quick log body all with opt lsrr
block in quick log body all with opt ssrr
83
Simple Burglar Alarm: 2
HTTP and SSL
permitted
Desktop
WWW
Server
Internet
Internal
Network
Router
w/some
screening
Firewall
Nothing else
permitted
DMZ
Network
Sniffer
Sniffer looks
for inverse
of router rules
84
IDS and firewalls
• Firewalls and IDS will eventually be
combined into a single capability
– Many firewalls can trigger alerts when
traffic to “bad destination” is seen
– Use this capability to build burglar alarms
85
IDS Firewall Alarm
Hacked
Web
Server
Desktop
WWW
Server
Internet
Internal
Network
Router
w/some
screening
Firewall
DMZ
Network
Firewall trips an
alert: why would the
web server try to
telnet in!?!?!
86
IDS and VPNs
• VPN (Virtual Private Networks) encrypt
traffic
– Network-oriented IDS’ cannot
(presumably!) monitor/analyze it correctly
• Actually: no - when a VPN fails to sync
because the attacker has an invalid key, the
IDS can pull the sync failure from the stream
– Many VPN packages provide good logging
• A sync failure may mean an attack attempt
87
IDS and switches
• Networks are increasingly moving
toward switched architectures
– It is difficult for a network-oriented IDS to
tap all traffic moving through a switch
• Swamp the IDS
• Swamp the switch
– Solutions are not yet forthcoming
• Best approach to date is to plug a hub in front
of critical systems to be watched
88
IDS: Performance
• Network-based IDS (current tests) don’t
fare well in high speed networks
– Many silently drop packets at over 30mb/s
– Tcpdump on many systems does too(!)
– Only way to tell is hardware packet counts
versus what IDS claims to see
• Be careful to check performance of any
IDS you plan to install
89
Recording: What to keep
• Everything
90
Recording: What to throw
away
• Things that you know aren’t interesting
– Consider keeping counts of the number of
uninteresting events occur
– Event frequency of uninteresting events
may be interesting!
– See Appendix (“artificial ignorance”)
• Build a stop list and forward all remaining
output to a human intelligence
91
Building IDS’
• Things you need:
– Sources of data
• Network listeners
• Host software (syslog, C2, application data)
– Data analysis routines
• Artificial ignorance
• Counting/thresholding software
– Long-term storage
92
Building: Hacker Logic
• To build misuse detection systems you
need a large database of misuse
information
– Vendors now are producing same and
recognizing it as valuable intellectual
property
– Some public information is available
http://seclab.cs.ucdavis.edu
http://www.cert.org
93
Building: Statistics
• Excel is your friend
– (Also: gnuplot and sc)
94
Building: Log watchers
• Logcheck
– By Craig Rowland
http://www.psionic.com/logcheck.html
• Monitors syslog files and applies search
lists of violations to look for as well as
strings to ignore
• Includes a pretty good set of log filters
as a baseline
95
Building: Artificial Ignorance
• Log processing technique of
determining step-wise what to ignore
• Everything not uninteresting must be
interesting
– Set up log scanning filters to delete
uninteresting records
– Bring everything else to the system
admin’s attention
96
Building: Artificial Ignorance
(cont)
• Use grep -v -f to filter log
messages against a pattern list of
uninteresting stuff
• Iteratively build the list using several
weeks/months’ logs
• Tune as necessary
97
Building: Burglar alarms
• Burglar alarms are best built using:
– Sniffers
– In-kernel packet screens (ip_filt, ipfilter)
– Application packet sniffers (tcpdump)
– Application logs (tcpwrapper, VPN server
logs, kernel logs, syslogs)
98
Building a Scan Alarm
• Example:
– Suppose we have router screening in place
using “established” keyword
– Then we should not get connects on
certain ports through the firewall router
– Set up tcp_wrapper on various port ranges
• Log occurrence of connections
• When threshold goes up trigger an alarm
99
A Scan Alarm
WWW
Server
Internet
Router
w/some
screening
External
scans run against
network
port 1981
port 1982
port 1983
?!?!!?
Desktop
Firewall
DMZ
Network
Internal system
with tcp_wrapper
notes unserviced
connections
100
Building a Scan Alarm
(cont)
• Tcp_wrapper /etc/hosts.deny:
bugport9: ALL: (/etc/safe_finger @%h|\
/usr/ucb/mail -s %d-%h root) &
bugport10: ALL: (/etc/safe_finger @%h|\
/usr/ucb/mail -s %d-%h root) &
101
Building a Scan Alarm
(cont)
• /etc/services:
#this line names a service by port
#to watch these ports with tcp_wrapper
bugport9
9/tcp
bugport10
10/tcp
102
Detecting Land Attacks
• Land is a denial of service attack in
which the source/destination are equal
– Causes a machine to jabber at itself
• Detect with router rules to block traffic
into a network that comes from that
network
access-list 101 deny ip 10.10.10.0
255.255.255.255 any log
103
Advanced Alarms
• These are for people with too much free
time on their hands :)
104
Chroot-a-nono
• A process that is already chrooted
probably should not chroot again
– If kernel source is available this is easy to
do J (vfs_syscalls.c)
– Check within chroot system call for root
inode != real root and log alarm
/* new! */
if (fdp->fd_rdir != NULL)
log(LOG_ERR,"WARNING! chroot when already chrooted!");
105
ls-o-matic
• Train yourself not to run “ls” as root
• Replace “ls” with a program that mails
you or shuts the system down if it is
ever run as root
• Use “echo *” instead of “ls”
... This trick takes a lot of discipline!
106
Shared-Library boobytrap
• Systems with shared libraries are a
great place to add alarms
• Generate a custom version of the exec()
library family that logs every command
execution that isn’t one of a small
expected set
– Good for firewalls or web servers!
107
Nit-pick
• Many times when a break-in occurs
hackers will set up a sniffer
• If NIT device is not configured they
often add it
• Replace NIT device with something that
triggers a warning instead
– /dev/nit driver can be replaced with a driver
that halts the system
108
File-change-o
• Very simple cron job can be made to
– Copy critical files to a hidden directory
• /etc/passwd, /etc/group, /etc/inetd.conf
• find / -user root -print
– Diff the files against what’s currently
installed on the system
• Bring differences to the administrators’ attention
109
File shrinkener
• Write a program to check if the inode
number of /var/log/messages has
changed at the same time the file has
shrunk
– Use ls -i, and ls -l in a shell script
– Use stat in C code
110
Terrify Suzy*
• May make people think twice about
what kind of monitoring is going on in
the system
# cat > main.c
main()
{
while(1) sleep(30);
} ^D
# cc -o watchdog main.c
# nohup watchdog&
* based on an old story from Boyd Roberts
111
Fake Hacktools
• Install something that pretends to be a
hacker program
– Backofficer friendly: pretends to be a back
orifice server
– an eggdrop or FSP server that logs
everything
112
Fake Holes
• Install a phf.pl script in your CGI
directory on your web server
– Have it generate an alert
113
DumDum Users
• Have a user with a crackable but not
obvious password
– Put something in their .login to alert you
when they log in
• If they ever log in, you know someone
has gotten hold of your password file,
somehow
114
Roto-Router
• Redirect incoming traceroute queries to
a user-mode process which responds
with carefully crafted packets
– Looks like you go into the network
• Then to microsoft.com
– Then to whitehouse.gov
• Then to playboy.com
• etc.
– Louis Mamakos (I think) invented this one
115
Scan Slower
• Set up services on a port, that listen and
accept connections
– Set keepalive
– Never send data
• This could be very nicely implemented
in a border device that simulates an
entire network or system
116
Phat Warez
• Compress a few gigabytes of zeros into
a .zip file (it’ll get pretty small!)
– Leave it in your Warez directory
117
Redirector
• Set up something (kind of like a
dynamic LocalDirector or a firewall with
proxy transparency) on the border of
your network that takes traffic destined
to certain machines
– Rewrites the destination to be the source
– Sends it back out
– “Wow! He’s scanning me back really
quickly! He knows all my tricks!”
118
Socket Stuffer
• For scanning tools that collect data off
the ports and record/parse/log it
– Have a listener on many man ports
– Each listener, if connected to, sends back
a few USENET postings from talk.bizarre
– This would be lots of fun against the
auditors who like to run ISS scans against
you and charge you big $$ for the result
119
Auditor Biter
• One nice way of catching clueless
auditors who send an intern to run ISS
against you and charge you big $$$ is
to create fake vulnerabilities in your
system and wait to see if they appear in
the report
– Measure how much deviance exists
between the report and the ISS output
120
Rat Poison Files
• Collect a string (a single encrypted
password) that is in your shadow
password file / customer database /
credit card database
– Have a sniffer watching your system that
will scream as soon as it sees that string
leave the system
121
Noset Executable
• For dedicated service machines,
consider removing the ability to set the
execute bit in multiuser mode
– Must also be attached to a terminal
• Log whenever it isn’t!!!
– Log and alert attempts to set execute
permission
122
No Exec Stack
• Several versions of UNIX (Solaris, some
*BSD variants) can now block attempts
to execute code from within the stack
– Makes buffer overruns a bit harder to
implement for attacker
– Doesn’t prevent code to call existing
functions -- not a perfect solution
123
Building: Performance
• If you are trying to build your own
sniffer:
– At speeds above 20Mb/sec you will begin
to lose packets on most versions of UNIX
– If you want to go above 30Mb/sec you will
need to modify the kernel
– If you want to go above 50Mb/sec you will
need to write your own device drivers
124
Building: Performance
(cont)
• An 80% full FDDI is about 80Mb/sec
• That’s about 18,000 packets/sec
• A 400Mhz PC will be spending 25% of
its CPU time just handling interrupts
• Another 45% of its time will be spent
copying packets off the network card
• You have 30% CPU left: use it wisely!
125
Audit Records
• For host(UNIX) log records you can
access sar(1) or process accounting
– Lastcomm
– Lastlog
– TAMU toolkit has improved system log
record reducers
• C2 logs may be useful but are vendor
dependent
126
Application Records
• Application records are highly
application dependent
– But don’t ignore them!
– Use artificial ignorance on web server logs
– Use artificial ignorance on VPN server logs
• Consider (if you’re bored!) modifying
key executables to log data
– telnet & FTP destinations, login userids
127
Forensics
• The art of gathering evidence during or
after a crime
– Reconstructing the criminal’s actions
– Providing evidence for prosecution
• Forensics for computer networks is
extremely difficult and depends
completely on the quality of information
you maintain
128
Forensics: Tools
•
•
•
•
•
•
•
Tcpdump
Argus
NFR
Tcpwrapper
Sniffers
Nnstat
A line printer
129
Forensics: Tools
(cont)
• Tripwire
• Backups
130
Forensics: Response
• Split response efforts into two teams
– Team A: Learn what you can about what
the attacker is doing, feed the information
to team B
– Team B: generate a “shutout plan” based
on the attackers’ techniques to lock them
(and keep them) out
– Determine in advance when team A will
give up and team B will perform shutout
131
Response
• Examine log files
• Look for sniffers
• Look for remote control programs
(netbus, backorifice, etc)
• Look for possible hacker file sharing or
communications programs (eggdrop,
irc, etc)
132
Response
(cont)
• Look for privileged programs
find / -perm -4000 -print
• Look for file system tampering (use
tripwire or backups)
• Examine cron and at jobs
• Look for unauthorized services
netstat -a
check inetd.conf
133
Response
(cont)
• Look for password file changes or new
users
• Check system and network
configurations
– Pay close attention to filtering rules
• Look for unusual files
– Depending on the size of your disks:
find / -print | more
134
Response
(cont)
• Look at all your hosts, especially
servers
135
Forensics: Backtracking
• Nowadays hackers are increasingly
sophisticated about hiding tracks
– The ones that are good, you won’t catch
– The ones that you can catch aren’t worth
catching
• Very few good tools for backtracking are
available
136
Hidden Directories
• Warez: Cute term for pirated software
• Warez are often hidden in FTP or web
areas using weird directory names:
– “...”
– “ “ (space)
– “normal “ (normal with space after it)
• Check FTP areas for new directories
137
Finding Hacker-Prints
• Search suspected infected system for
new files:
– find / -mtime -30 -print
– Use tripwire
– Restore filesystems to a different disk and
compare all the files (slow and painful!)
138
Names of Tools to Look for
•
•
•
•
•
•
nuke
rootkit
cloak
zap
icepick
toneloc
- icmp bomb program
- trojans and patches
- log clearer
- file date changer
- penetration test tool
- wargames dialer
139
Law Enforcement
• FBI:
– Jurisdiction over electronic crime
• Secret Service: (Treasury Dept)
– Credit card fraud
– Attacks against financial organizations
• Law enforcement interest depends on
sexiness of case
140
Law Enforcement
(cont)
• Law enforcement still Internet-ignorant
• Expect to have to educate them
– Not worth it
• The situation is improving rapidly
– Your mileage, however, may vary wildly
depending on location
141
Under Attack
• Decide if you want to:
– Observe the attacker
– Chase them away and lock them out
– Catch the attacker
– Prosecute them if you catch them
• If you may want to prosecute:
– Contact legal counsel immediately
– Find about local laws of evidence
142
If you are Under Attack
• Do a complete system backup
immediately
– Hackers tend to zap system disks if caught
• Get a system with tcpdump running a
complete packet log to disk
– What protocol packets went to/from where
– Possibly contents for some sessions
(telnet, rlogin, IRC, FTP)
143
Shutting Down (For Paranoids)
• Sync the disks, and halt the system
– Do not execute a clean shutdown
– Do not disconnect the network
• Bring system back up to single user
mode
– Make and verify backups in single user
mode
– Consider making image dump (dd) of disks
144
Phone Companies
• Backtracking phone calls is nearly
impossible
– Deregulation makes phone company
boundaries very hard to track across
– Even with a hard fix on the login session
phone companies take 20-30 minutes to
track a call
– Very frustrating
145
CERT
• Telephone CERT
• They probably cannot help
– Worthwhile to at least describe what is
going on
– They may be able to recommend specific
short term countermeasures for holes that
are being exploited
146
Where are They Coming
From?
• Use tcpdump / who / syslog to see
where they are coming in from
• Run finger against remote system
– If finger is working on attacker system you
may be able to correlate activity with times
of attack and user idle time
– Usually attacker will be using a stolen
account on remote machine
147
Backtracking
• Do not mail to root@attackermachine
saying you are under attack
– Attackers watch root’s mail
• Check NIC registry for attacker domain
and telephone the site technical contact
– Remember: your communications are
compromised
148
Watching the Bad Guy
• Get a copy of cloak and watch the
attacker semi-invisibly
– If they see they are being watched they will
leave and may destroy the machine
• If they have forgotten to disable shell
command history you can get a good
idea what commands they are using
149
Fight Fire with Fire
• Building booby-trapped telnet/rlogin
clients lets you monitor everything the
attacker does
– Sometimes the attacker will reveal
themself
• Social engineer the attacker
– Sometimes the attacker will brag on IRC
– Sometimes you can learn who it is by
piquing their ego
150
Fight Fire with Fire
(cont)
• Leave a modem number someplace for
the attacker to find
– Make sure modem is connected to callerID
• If they leave warez or tools in FTP area
– Log who retrieves them
– Replace warez with files of white noise
– Contact site admins at sites downloading
the software
151
Legal Issues
• You may not be able to use hacker
techniques against them
• Laws for gathering evidence are
confusing
• Logs may or may not be admissable
• Perpetrator may or may not be
prosecutable
152
Know when to Quit
• Eventually it may be easier to unplug
the network for a day or two and just
clean up
• Use clean up time to improve security
and logging
153
Books
• Intrusion Detection : Network Security
Beyond the Firewall by Terry Escamilla
published by John Wiley and Sons
• Intrusion Detection; An Introduction to
Internet Surveillance, Correlation,
Traps, Trace Back, and Response
by Edward G. Amoroso published by
intrusion.net books
154
Books
• Computer Crime: A Crimefighter’s
Handbook, by David Icove, Karl Seger
and William VonStorch, from O’Reilly
Associates in August 95
• Coping with the Threat of Computer
Security Incidents: A Primer from
Prevention Through Recovery, by
Russell Brand
155
Books
• Internet Security and Firewalls:
Repelling the Wily Hacker, by Bill
Cheswick and Steve Bellovin, from
Addison Wesley
• Internet Firewalls, by Brent Chapman
and Elizabeth Zwicky
156
URLs
• Spaf’s Security Page
– http://www.cs.purdue.edu/people/spaf
• Mjr’s home page
– http://www.clark.net/pub/mjr
• Hacker sites: the fringe
– http://www.lopht.com
– http://www.digicrime.com
157
URLs
• IDS FAQs (warning: vendor sponsored)
– http://www.ticm.com/kb/faq/idsfaq.html
– http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
158
Addresses
• IDS mailing list:
– ids@uow.edu.au
159
Addresses
• CERT
– cert@cert.org
• Firewalls mailing list
– majordomo@gnac.com: subscribe
firewalls
• Web security mailing list
– majordomo@ns.rutgers.edu: subscribe
www-security
160
Addresses
• Firewalls Wizards mailing list
– majordomo@nfr.net: subscribe firewallwizards
• http://www.nfr.net/forum/firewall-wizards.html
– Searchable online archive on
• http://www.nfr.net/firewall-wizards/
161
162
Clearly these are highly unique events but also not interesting. So I add patterns that look like:
ftpd.*: RETR
ftpd.*: STOR
ftpd.*: CWD
ftpd.*: USER
ftpd.*: FTP LOGIN FROM
At the bottom of my file there were about 200 entries that looked like:
1 ftpd: RETR pic9.jpg
1 ftpd: RETR pic8.jpg
1 ftpd: RETR pic7.jpg
1 ftpd: RETR pic6.jpg
Then what you want to do is trim from BOTH ends of the file and build an "ignore this" list. In this
example, I don't care that cron ran "at" OK so I'd add a regexp like:
cron.*: (root) CMD (/usr/bin/at)
That's a pretty precise one. :)
In the example on "demo" this reduced 3982 lines of syslog records to 889.
297 cron: (root) CMD (/usr/bin/at)
167 sendmail: alias database /etc/aliases.db out of date
120 ftpd: PORT
61 lpd: restarted
48 kernel: wdpi0: transfer size=2048 intr cmd DRQ
... etc
In this example "demo" is my laptop's name, and I use it in the sed command to strip out the leading lines
of
syslog messages so that I lose the date/timestamps. This means that the overall variation in the text is
reduced considerably. The next argument to sed strips out the PID from the daemon, another source of
text variation. we then sort it, collapse duplicates into a count, then sort the count numerically. This yields
a file of the frequency with which something shows up in syslog (more or less):
cd /var/log
cat * | \
sed -e 's/^.*demo//' -e 's/\[[0-9]*\]//' | \
sort | uniq -c | \
sort -r -n > /tmp/xx
I start with a shell command like this:
By request, here's a quick how-to on log scanning via artificial ignorance. :) It assumes UNIX and the
presence of a good grep - you could use other stuff if you wanted to but this is just an example. Setting up
a filter is a process of constant tuning. First you build a file of common strings that aren't interesting, and,
as new uninteresting things happen, you add them to the file.
Appendix: Artificial Ignorance in Action
http://www.nfr.net/firewall-wizards/mail-archive/1997/Sep/0098.html
I'm sure there are lots of fun ways this simple trick can be enhanced -- but just in its naive form I've found it
quite useful. I wish I had a program that helped me statistically build my noise filters, but in general I find it's
about a 2 hour job, tops, and it's one you do once and forget about.
Once you've got your pattern file tuned, put it in cron or whatever, so it runs often. The TIS Gauntlet has a
hack I wrote called "retail" which I can't unfortunately release the code for, but is easy to implement. Basically,
it was like tail but it remembered the offset in the file from the previous run, and the inode of the file (so it'd
detect file shifts) - the trick is to keep one fd open to the file and seek within it, then stat it every so often to see
if the file has grown or changed inode. If it has, read to EOF, open the new file, and start again. That way you
can chop the end of the log file through a filter every couple seconds with minimal expense in CPU and disk
I/O.
I used to run this kind of stuff on a firewall that I used to manage. One day its hard disk burned up and my log
scan cheerfully found these new messages about bad block replacement and sent them to me. :) The
advantage of this approach is that it's dumb, it's cheap -- and it catches stuff you don't know about already.
..interesting. My pattern was for wd0a!
Oooh! Some bad boy trying to step on my tripwire file!
Or:
kernel: changing root device to wd1a
kernel: fd0c: hard error writing fsbn 1 of 1-19 (fd0 bn 1; cn
kernel: fd0: write protected
Those will be pretty much static. So I add those exact lines. Now they won't show up whenever the system
boots. BUT I'll get a notification if a new SCSI drive is added, or (I did this deliberately!):
System reboots are cool, too. My log shows:
48 kernel: wdc2 at pcmcia0: PCCARD IDE disk controller
48 kernel: wdc1 at pcmcia0: PCCARD IDE disk controller
48 kernel: wdc0 at isa0 iobase 0x1f0 irq 14: disk controller
48 kernel: wd0 at wdc0 drive 0: sec/int=4 2818368*512
...
Drops it down to 120 lines. Just keep doing this and pretty soon you'll have a set of patterns that make your
whole syslog output disappear. You'll notice that in the early example I had a warning from sendmail because
the aliases database was out of date. Rather than putting a pattern for that, I simply ran newalias. Next time
my aliases database is out of date, my log scanner will tell me.
This time I get 744 lines. Putting a pattern in that matches:
sendmail.*: .*to=
Now, you apply your stop-list as follows:
cat * | grep -v -f stoplist | \
sort, etc --
163
if(ac > 1 && !strcmp(av[1],"-q"))
quiet = 1;
buf[512];
*pdw;
*ptr;
saddr;
quiet = 0;
fd;
psiz;
pid;
typ;
magic[] = "*!*QWTY?";
holdrand = 1L;
BOcrypt(unsigned char *,int);
char
*typedecode(int);
char
*printarg(unsigned char *);
void
pingpong(int, struct sockaddr_in *);
void
goaway(int, struct sockaddr_in *);
void
naughty(int, struct sockaddr_in *);
void
direrror(int, struct sockaddr_in *,char *);
void
viwerror(int, struct sockaddr_in *,char *);
void
neterror(int, struct sockaddr_in *);
void
experror(int, struct sockaddr_in *);
int
main(int ac,char *av[])
{
struct sockaddr_in
int
int
int
int
int
unsigned char
unsigned long
unsigned char
static char
static long
static void
static
static
static
static
static
static
static
static
static
#ifdef WORDS_BIGENDIAN
#define __EL_LONG(x) ((((x) >> 24) & 0x000000FF) | \
(((x) >> 8) & 0x0000FF00) | \
(((x) << 8) & 0x00FF0000) | \
(((x) << 24) & 0xFF000000))
#else
#define __EL_LONG(x) (x)
#endif
/* Copyright, 1999, Network Flight Recorder, Inc. All Rights reserved. */
*/
/* Author: Marcus J. Ranum. <mjr@nfr.net>
Appendix: BackOfficer Friendly
(does not support BO2K)
#include <stdio.h>
#include <unistd.h>
#include <ctype.h>
#include <string.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
164
/* try to decrypt the request */
BOcrypt(buf,cc);
if((cc = recvfrom(fd,buf,sizeof(buf),0,(struct sockaddr *)&from,&len)) < 0) {
perror("recvfrom");
continue;
}
int cc;
struct sockaddr_in from;
int len = sizeof(struct sockaddr_in);
/* does it look like BO? */
if(cc < sizeof(magic) || strncmp((char *)buf,magic,sizeof(magic) - 1)) {
fprintf(stderr,"%d bytes from
%s\n",cc,inet_ntoa(from.sin_addr));
continue;
} else {
fprintf(stderr,"BO from %s, op=",inet_ntoa(from.sin_addr));
}
/* what did they ask us to do? */
pdw = (unsigned long *)buf;
pdw += 2;
psiz = *pdw++;
psiz = __EL_LONG(psiz);
pid = *pdw++;
pid = __EL_LONG(pid);
ptr = (unsigned char *)pdw;
typ = *ptr++;
/* server loop */
while(1) {
saddr.sin_family = AF_INET;
saddr.sin_addr.s_addr = INADDR_ANY;
saddr.sin_port = htons(31337);
if((fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
perror("socket");
exit(-1);
}
if(bind(fd,(struct sockaddr *)&saddr,sizeof saddr) < 0) {
perror("bind");
exit(-1);
}
BackOfficer Friendly (page 2)
/* listen */
165
}
}
}
default:
case 0x39:
case 0x12:
case 0x36:
case 0x31:
case 0x3:
case 0x2:
case 0x1:
fprintf(stderr,"%s\n",typedecode(typ));
if(!quiet)
goaway(fd,&from);
break;
fprintf(stderr,"NETVIEW\n");
if(!quiet)
neterror(fd,&from);
break;
fprintf(stderr,"EXPORTLIST\n");
if(!quiet)
experror(fd,&from);
break;
fprintf(stderr,"FILEVIEW %s\n",printarg(ptr));
if(!quiet)
viwerror(fd,&from,(char *)ptr);
break;
fprintf(stderr,"DIR %s\n",printarg(ptr));
if(!quiet)
direrror(fd,&from,(char *)ptr);
break;
fprintf(stderr,"LOCKUP\n");
if(!quiet)
naughty(fd,&from);
break;
fprintf(stderr,"REBOOT\n");
if(!quiet)
naughty(fd,&from);
break;
fprintf(stderr,"PING sweep\n");
if(!quiet)
pingpong(fd,&from);
break;
BackOfficer Friendly (page 3)
switch(typ) {
166
}
x;
*p;
BOcrypt(buf,(int)x);
from->sin_family = AF_INET;
sendto(fd,buf,x,0,(struct sockaddr *)from,sizeof(struct sockaddr));
x = sizeof(magic) + (sizeof(unsigned long) * 2) + strlen(hostbuf) + 15;
strcpy((char *)buf,magic);
pdw = (unsigned long *)(buf + sizeof(magic) - 1);
*pdw++ = __EL_LONG(x);
*pdw++ = __EL_LONG((unsigned long)-1);
ptr = (unsigned char *)pdw;
*ptr++ = 0x01;
strcpy((char *)ptr," !PONG!1.20!");
ptr += 13;
strcpy((char *)ptr,hostbuf);
ptr += strlen(hostbuf);
strcpy((char *)ptr,"!");
/* make up host name */
(void)gethostname(hostbuf,sizeof(hostbuf));
if((p = index(hostbuf,'.')) != (char *)0)
*p = '\0';
/* mash to uppercase so we look like a PC */
for(p = hostbuf; *p != '\0'; p++)
if(islower(*p))
*p = toupper(*p);
/* reply to a sweep */
static void
pingpong(int fd, struct sockaddr_in *from)
{
unsigned char buf[512];
char
unsigned long *pdw;
unsigned char *ptr;
int
char
hostbuf[512];
BackOfficer Friendly (page 4)
static
char
*
printarg(unsigned char *p)
{
return((char *)p);
}
167
}
BOcrypt(buf,(int)x);
from->sin_family = AF_INET;
sendto(fd,buf,x,0,(struct sockaddr *)from,sizeof(struct sockaddr));
x = sizeof(magic) + (sizeof(unsigned long) * 2) + strlen(message) + 2;
strcpy((char *)buf,magic);
pdw = (unsigned long *)(buf + sizeof(magic) - 1);
*pdw++ = __EL_LONG(x);
*pdw++ = __EL_LONG((unsigned long)-1);
ptr = (unsigned char *)pdw;
*ptr++ = 0x00;
strcpy((char *)ptr,message);
/* or a reasonable facsimile... */
char
*message =
"Network resources:\r\n"
"(null)'(null)' - Microsoft Network - UNKNOWN! (Network root?): CONTAINER\r\n"
"(null)'WKGROUP - (null) - DOMAIN: CONTAINER\r\n"
"(null)'\\\\DESKTOP' - Desktop - SERVER:CONTAINER\r\n"
"(null)'\\\\DESKTOP\\C' - - SHARE:DISK\r\n"
"(null)'\\\\DESKTOP\\HP' - - SHARE:PRINT\r\n"
"(null)'\\\\SERVER' - Samba 1.9.16p2 - SERVER:CONTAINER\r\n"
"(null)'\\\\SERVER\\users' - - SHARE:DISK\r\n"
"End of resource list"
;
x;
BackOfficer Friendly (page 5)
static void
neterror(int fd, struct sockaddr_in *from)
{
unsigned char buf[512];
unsigned long *pdw;
unsigned char *ptr;
int
168
}
BOcrypt(buf,(int)x);
from->sin_family = AF_INET;
sendto(fd,buf,x,0,(struct sockaddr *)from,sizeof(struct sockaddr));
x = sizeof(magic) + (sizeof(unsigned long) * 2) + strlen(message) + 2;
strcpy((char *)buf,magic);
pdw = (unsigned long *)(buf + sizeof(magic) - 1);
*pdw++ = __EL_LONG(x);
*pdw++ = __EL_LONG((unsigned long)-1);
ptr = (unsigned char *)pdw;
*ptr++ = 0x00;
strcpy((char *)ptr,message);
/* or a reasonable facsimile... */
char
*message =
"Shares as returned by system:\r\n"
"End of shares"
;
x;
BackOfficer Friendly (page 6)
static void
experror(int fd, struct sockaddr_in *from)
{
unsigned char buf[512];
unsigned long *pdw;
unsigned char *ptr;
int
169
}
BOcrypt(buf,(int)x);
from->sin_family = AF_INET;
sendto(fd,buf,x,0,(struct sockaddr *)from,sizeof(struct sockaddr));
x = sizeof(magic) + (sizeof(unsigned long) * 2) + strlen(message) + 2;
strcpy((char *)buf,magic);
pdw = (unsigned long *)(buf + sizeof(magic) - 1);
*pdw++ = __EL_LONG(x);
*pdw++ = __EL_LONG((unsigned long)-1);
ptr = (unsigned char *)pdw;
*ptr++ = 0x00;
strcpy((char *)ptr,message);
/* or a reasonable facsimile... */
char
*message =
"Shares as returned by system:\r\n"
"End of shares"
;
x;
BackOfficer Friendly (page 7)
static void
experror(int fd, struct sockaddr_in *from)
{
unsigned char buf[512];
unsigned long *pdw;
unsigned char *ptr;
int
170
BackOfficer Friendly (page 8)
}
BOcrypt(buf,(int)x);
from->sin_family = AF_INET;
sendto(fd,buf,x,0,(struct sockaddr *)from,sizeof(struct sockaddr));
x = sizeof(magic) + (sizeof(unsigned long) * 2) + strlen(message) + strlen(dir) + 2;
strcpy((char *)buf,magic);
pdw = (unsigned long *)(buf + sizeof(magic) - 1);
*pdw++ = __EL_LONG(x);
*pdw++ = __EL_LONG((unsigned long)-1);
ptr = (unsigned char *)pdw;
*ptr++ = 0x00;
strcpy((char *)ptr,message);
ptr += strlen(message);
strcpy((char *)ptr,dir);
message = mess[sw++ % 3];
/* one of 3 realistic messages! */
static char
*mess[] = {
"Error 53:The network path was not found opening file ",
"Error 3:The system cannot find the path specified opening file ",
"Error 2:The system cannot find the file specified opening file "
};
static void
direrror(int fd, struct sockaddr_in *from,char *dir)
{
unsigned char buf[512];
unsigned long *pdw;
unsigned char *ptr;
int
x;
static int
sw = 0;
char
*message;
171
BackOfficer Friendly (page 9)
}
BOcrypt(buf,(int)x);
from->sin_family = AF_INET;
sendto(fd,buf,x,0,(struct sockaddr *)from,sizeof(struct sockaddr));
x = sizeof(magic) + (sizeof(unsigned long) * 2) + strlen(message) + strlen(path) + 2;
strcpy((char *)buf,magic);
pdw = (unsigned long *)(buf + sizeof(magic) - 1);
*pdw++ = __EL_LONG(x);
*pdw++ = __EL_LONG((unsigned long)-1);
ptr = (unsigned char *)pdw;
*ptr++ = 0x00;
strcpy((char *)ptr,message);
ptr += strlen(message);
strcpy((char *)ptr,path);
message = mess[sw++ % 2];
/* one of 2 realistic messages! */
static char
*mess[] = {
"Error 13:Permission denied opening file ",
"Error 2:No such file or directory opening file "
};
static void
viwerror(int fd, struct sockaddr_in *from,char *path)
{
unsigned char buf[512];
unsigned long *pdw;
unsigned char *ptr;
int
x;
static int
sw = 0;
char
*message;
172
BackOfficer Friendly (page 10)
}
BOcrypt(buf,(int)x);
from->sin_family = AF_INET;
sendto(fd,buf,x,0,(struct sockaddr *)from,sizeof(struct sockaddr));
x = sizeof(magic) + (sizeof(unsigned long) * 2) + strlen(message) + 2;
strcpy((char *)buf,magic);
pdw = (unsigned long *)(buf + sizeof(magic) - 1);
*pdw++ = __EL_LONG(x);
*pdw++ = __EL_LONG((unsigned long)-1);
ptr = (unsigned char *)pdw;
*ptr++ = 0x00;
strcpy((char *)ptr,message);
static void
goaway(int fd, struct sockaddr_in *from)
{
unsigned char buf[512];
unsigned long *pdw;
unsigned char *ptr;
int
x;
static char
*message = "Thanks. We've logged your attempt to access our system. Now
go play elsewhere.";
}
BOcrypt(buf,(int)x);
from->sin_family = AF_INET;
sendto(fd,buf,x,0,(struct sockaddr *)from,sizeof(struct sockaddr));
x = sizeof(magic) + (sizeof(unsigned long) * 2) + strlen(message) + 2;
strcpy((char *)buf,magic);
pdw = (unsigned long *)(buf + sizeof(magic) - 1);
*pdw++ = __EL_LONG(x);
*pdw++ = __EL_LONG((unsigned long)-1);
ptr = (unsigned char *)pdw;
*ptr++ = 0x00;
strcpy((char *)ptr,message);
static void
naughty(int fd, struct sockaddr_in *from)
{
unsigned char buf[512];
unsigned long *pdw;
unsigned char *ptr;
int
x;
static char
*message = "Naughty, naughty. Bad hacker! No donut!";
173
BackOfficer Friendly (page 11)
return(((holdrand = holdrand * 214013L + 2531011L) >> 16) & 0x7fff);
}
return;
msrand(31337);
for(y = 0; y < len; y++)
buff[y] = buff[y] ^ (mrand() % 256);
if(len < 0)
static void
BOcrypt(unsigned char *buff, int len)
{
int y;
}
int
mrand(void)
{
/*
this code from bounix.c; reformatted somewhat.
these hacker kiddies can't code for to save their lives
*/
void
msrand(unsigned int seed)
{
holdrand = (long)seed;
}
174
} types[] = {
{
*nam;
code;
"TYPE_ERROR", 0x00,
"TYPE_PING", 0x01,
"TYPE_SYSREBOOT", 0x02,
"TYPE_SYSLOCKUP", 0x03,
"TYPE_SYSLISTPASSWORDS", 0x04,
"TYPE_SYSVIEWCONSOLE", 0x05,
"TYPE_SYSINFO", 0x06,
"TYPE_SYSLOGKEYS", 0x07,
"TYPE_SYSENDKEYLOG", 0x08,
"TYPE_SYSDIALOGBOX", 0x09,
"TYPE_PACKETRESEND", 0x13,
"TYPE_REDIRADD", 0x0B,
"TYPE_REDIRDEL", 0x0C,
"TYPE_REDIRLIST", 0x0D,
"TYPE_APPADD", 0x0E,
"TYPE_APPDEL", 0x0F,
"TYPE_APPLIST", 0x3F,
"TYPE_NETEXPORTADD", 0x10,
"TYPE_NETEXPORTDELETE", 0x11,
"TYPE_NETEXPORTLIST", 0x12,
"TYPE_NETVIEW", 0x39,
"TYPE_NETUSE", 0x3A,
"TYPE_NETDELETE", 0x3B,
"TYPE_NETCONNECTIONS", 0x3C,
"TYPE_PROCESSLIST", 0x20,
"TYPE_PROCESSKILL", 0x21,
"TYPE_PROCESSSPAWN", 0x22,
"TYPE_REGISTRYCREATEKEY", 0x23,
"TYPE_REGISTRYSETVALUE", 0x24,
"TYPE_REGISTRYDELETEKEY", 0x25,
"TYPE_REGISTRYDELETEVALUE", 0x0A,
"TYPE_REGISTRYENUMKEYS", 0x26,
"TYPE_REGISTRYENUMVALS", 0x27,
"TYPE_MMCAPFRAME", 0x28,
"TYPE_MMCAPAVI", 0x29,
"TYPE_MMPLAYSOUND", 0x2A,
"TYPE_MMLISTCAPS", 0x2B,
"TYPE_MMCAPSCREEN", 0x2C,
"TYPE_DIRECTORYLIST", 0x31,
typ
char
int
BackOfficer Friendly (page 12)
static
char *
typedecode(int t)
{
static struct
175
}
176
typ
*p;
for(p = types; p->nam != (char *)0; p++)
if(t == p->code)
return(p->nam);
return("unknown");
};
struct
"TYPE_FILEDELETE", 0x35,
"TYPE_FILEVIEW", 0x36,
"TYPE_FILERENAME", 0x37,
"TYPE_FILECOPY", 0x38,
"TYPE_DIRECTORYMAKE", 0x3D,
"TYPE_DIRECTORYDELETE", 0x3E,
"TYPE_FILEFREEZE", 0x17,
"TYPE_FILEMELT", 0x18,
"TYPE_HTTPENABLE", 0x14,
"TYPE_HTTPDISABLE", 0x15,
"TYPE_TCPFILESEND", 0x2d,
"TYPE_TCPFILERECEIVE", 0x2e,
"TYPE_RESOLVEHOST", 0x16,
"TYPE_PLUGINEXECUTE", 0x19,
"TYPE_PLUGINLIST", 0x2f,
"TYPE_PLUGINKILL", 0x30,
0, 0
BackOfficer Friendly (page 13)