The Basics:

Who: Responder was written by Fred Cohen with
assistance from Don Cohen. It uses a modified version of the raw socket
package for CLISP, CLISP, C, and Linux - which means that it rests on
the shoulders of giants. It is intended to be used by those who would
defend their networks through active defensive measures. In order to
use Responder at the level of setting up simple responses for simple
cases, the operator is expected to have basic network knowledge,
including details of IP addresses, gateways, and something of an
understan ding of packets and how and why they operate. Responder can
also be programmed at increasing levels of sophistication by
increasingly sophisticated operators - without any top end in sight. It
helps to know Lisp and a great deal about the details of packets and
protocols, and it also helps to know your enemy and their tools.

What: Responder listens to packets on
interfaces, manipulates them, stores information about them if desired,
and sends, possibly altered or augmented, packets back out. It has a
number of built-in manipulation functions designed to selectively create
cognitive clarity or dissonance based on what comes in and the
operator-provided specification of how to deal with it. For example,
the operator may specify that certain computers are bad, based on IP
addresses, and indicate that they should be 'dazzled', 'mirrored',
'forged', 'ignored', 'slowed', 'attacked', and so forth, in select ways.
Similarly, 'good' computers might have some of their packets
'posed' as packets for another network.

Where: Responder was developed in my living
room in Hudson, Ohio then in my garage in Livermore, CA, and now in the
distributed and ever-expanding network of small shops and boutiques that
form the global network of my associates. Responder can be situated at
different points in your network depending on its purpose. Since it has
multiple interface capabilities, it can be situated at control points
between LANs or anywhere else a router or gateway computer might be
placed. In this sort of location it can act as a sort of firewall,
router, address translator, and general purpose security and
communication facilitation device. You can also place Responder on one
or more LANs and have it act to defend those LANs against illicit use on
the same LAN segment. The more you know about networks and how they
work, the more clever things you will likely find to do with Responder.
I even know people that use it so they don't have to worry about setting
up gateway addresses or other such things on their internal networks.

Why: Responder exists because the stoic
defenses of old were designed to take abuse, but not to inhibit further
abuse. They did not make things more difficult for the attacker than it
absolutely had to be in order for the defense to operate. Responder is
a mechanism intended to increase the difficulty to the attacker by
making their tools and techniques less effective than they would
otherwise be. It also provides the same sorts of stoic defense
capabilities as previous defenses, but it enhances them with the ability
to confuse attackers while having no noticeable negative side effect on
the normal user.

When: Responder was developed starting in late
1995 and its initial development continued into 1996. Deception ToolKit
was in its line of ascension and one of the side effects of its
seemingly eternal development was a series of experiments and papers on
deception written in 2001. It undergoes development even as I write and
will likely continue its development for the foreseeable future. As long
as attackers continue to develop, defenders will continue to find ways
to respond to them. Responder can be used at any time when power and
networks are available, but it is most enjoyable to use it when you have
the chance to watch the attackers as they writhe in frustration.

How: The computer that Responder runs on is
typically dedicated to this purpose and does not appear to exist from a
standpoint of network traffic, except of course that it makes the
network appear to operate quite differently than it otherwise would. It
does not need or want an IP address - please don't feed it one. It
observes packets using the 'Promiscuous' mode of Ethernet cards and
makes those Ethernet packets available to a program written in C and
Lisp. This program examines and manipulates packets based on the
operator's specification. The program is extensible in the sense that
the advanced operator may add to or alter the program to do precisely
what they desire, and of course this is how we develop custom response
mechanisms for customers who want a little bit more or different here or
there than what you can purchase over the counter. Responder also has
several operator 'languages', special purpose specifications, designed
to allow some of the more common things to be done with a minimum of
knowledge.

Getting Started:

Responder exists in both hardware and software incantations.

Step 1:

Hardware: Plug it in, turn it on.

Software: Boot from the Responder CD-ROM in the
PC you are dedicating to this task. You may have to change the BIOS to
boot from a CDROM instead of your hard drive or floppy. Check with your
equipment manufacturer for details.

Step 2: Software Only: Get CD-ROM to work

Software Only: Identify which interface card is
associate with which device names in your computer. Device names are
shown during the bootup process - typically as 'eth0', 'eth1', and so
forth. As each interface comes up , it should light its LEDs at the
interface point (assuming each interface is connected to a network).
Note which is first, second, third, etc. and label the interfaces on
your computer. The first one to turn on is 'eth0', the second one is
'eth1' and so forth. Some of your interfaces may not work with the
Responder CD. Most do, but there is no guarantee. Our hardware version
is designed to eliminate these problems...

NOTE: During this process, as with most
Responder processes, turning your computer off - even by pulling the
plug from the wall - or resetting it - will NOT have a serious negative
effect. When booting from the Responder CD-ROM, unless you do something
to make it alter other things on your computer, it will not do so. If
you use your hard disk to store information from Responder, the disk may
become corrupt across such reboots and it may take a long time to
reboot. Another good reason to use our hardware version.

Step 3: Configure it (and save the configuration files)

The easy way to run whatever configuration came with responder:

At the login prompt, type:

root

At the next prompt type:

cp -af /usr/Responder /tmp; cd /tmp
router-run responses

A GUI for responder is under development. Programming
Responder is described throughout the rest of this manual.

Step 4: Operate it

The simplest way to operate it, once configured, is to
just leave it alone. It pretty much takes care of itself.

Step 5: Maintain it

If you change things in your network that you were
asked about in installation, you might have to change the installation.
To do that, do step 3 again.

If Responder is configured to produce audit trails,
you need to periodically examine them - or they won't be of any use.
Older audit trails may be automatically deleted to save disk space (if
it starts running low), so track your system and figure out how often
you will need to check log files.

Step 6: Enhance it

Now the fun begins. For details, read all about it
below...

At factory install

At factory install, Responder ignores all traffic, has
no IP address, and no external services. This is a good thing, because
it makes the system practically invincible from network attack and
assures that it has no negative impacts on your network, but it is also a
bad thing because it does nothing at all to protect your network.

In order to get Responder to start to protect your
network, you need to configure it to do something. Before you do that,
here's a little note.

NOTE: Responder does not need or want an IP
address - please don't feed it one.

I hope this is clear. Responder operates under the
Linux operating system. Linux, like other operating systems, can do
many things. Some of those things are safe, while others are less safe.
In order to operate Responder, you do not need to have any IP address
assigned to the computer Responder runs on. Not having an IP address
makes Responder far safer from network attack than it might otherwise be
because there is no way to explicitly direct packets toward it and there
are no external 'services' that it provides which might be exploited to
the attacker's benefit. Responder's internal operation is such that no
external packets will likely overflow buffers or otherwise induce
misoperation UNLESS YOU CHANGE THE WAY IT WORKS. So don't.

Operating modes

Responder is general purpose in that it can do any
transform on packets or packet sequences that you can get a computer
implement. That means that it could - literally - replace a whole
computer network - or act as if it were the whole Internet... if it had
enough storage and was fast enough. But it's doesn't and it's not. So,
since replacing the whole Internet is not a likely option, let's focus
on some of the things it was built to do. These are the current standard
operating modes:

Router: Router mode provides a router-like
interface the runs as a 'production system'. It uses a series of rules
that are interpreted in sequence. Each rule has a condition (also
called a trigger) and an action (which is said to fire). If the
condition is true, the action is taken (i.e., if the trigger is pulled,
the rule fires). Unless a rule explicitly acts to prevent it, once a
rule that matches is found, no other rules will be examined and no other
actions taken. The final rule is permanently built-in to ignore the
packet, so unless the rules tell Responder what to do, it will do
nothing but check against the list of rules - which takes time... More
rules - more time.

Programmed: Programmed mode is pretty
painful to use unless you are an expert. In programmed mode, you write
fragments of lisp programs that call our built-in routines, and your
programs are run to respond to packets. You get full access to make a
mess of things both for your program and the networks you are operating
on.

Responder implements modes by translating all other
modes into Programmed mode programs which are compiled and run in the
Responder. Because other modes compile their specifications into
Programmed mode, you can start with a program in any other mode,
translate it into Programmed mode, and modify it from there. This is a
very convenient way to get started.

Router mode

The format for router mode is similar to the format of
many routers. If you are clever (or if you are clever enough to hire us
to do it) you (or we) can program Responder to use the identical syntax
to one of your routers. the normal syntax for Router mode goes like this:

Rule := Trigger Fire ; comment
| ( rest-of-lisp-expression
| [ lisp-expression
| ! lisp-expression
| : lisp-expression
| ? lisp-expression
| + lisp-expression
| [Hh] hashname IP-address [IP-address]*
| [Pp] pashname portnumber [portnumber]*
| [Mm] mashname MACaddress [MACaddress]*
| ; comment line
where: Trigger := Interface PackTypes Source Dest Options
Fire := Actions
comment is anything you like - ignored by the interpreter
; begins a comment line - it is ignored for processing rules but increments the rule count and prints on parsing
( followed by content are lisp expressions executed before listening starts
[ followed by content are lisp expressions executed after a packet arrives but before the first conditional
! followed by a lisp expression evaluates the lisp expression before testing the next rule
? followed by a lisp expression evaluates the lisp expression as part of the triggering 'AND'
: followed by a lisp expression evaluates the lisp expression after triggerring but before acting on the next rule
+ followed by a lisp expression evaluates the lisp expression just before the restore associated with a 'continue' option
h hash-set IP-address ... adds the IP(s) to the hash set - creates hash set if needed
p hash-set port ... adds the port(s) to the hash set - creates hash set if needed
m hash-set MACaddress ... adds the MAC(s) to the hash set - creates hash set if needed
NOTE: One Rule Per Line!

The basic function of responder in router mode is
to run a loop that lookes at the next packet, goes through a set of
production rules, and fires the first applicable one (or more if
continuation is set in rules). It does this by translating rule
sequences into a lisp function that is compiled and run when you invoke
the router. The function looks something like this:

The expressions indicated by and of 'MmHhPp(' are
evaluated before entering the loop and are thus able to set parameters
or configure content. They will only be evaluated once.

Expressions starting with ! are interpreted between
previous and subsequent rules (assuming the production system gets that
far. They are very handy for things like changing the TTL policy,
generating intrusion detection information, and providing special output
or state changes. Expressions starting with ? are interpreted as part
of the conditional. Expressions starting with : are interpreted only
within the next rule and only if that rule is triggered. Expressions
starting with + are evaluated after other evaluations are done but
before the original packet is restored if continuation is used. Lisp
statement lines do not have comments removed and should NOT include
comments. Please place these comments on a separate line.

If desired, a rule can be composed completely of
user-designed content (other than the interface name) by using a
combination of lisp rule components and a rule like this:

;; lisp content elements go here
eth0 * *.*.*.* *.*.*.* - I

The details of this will become clear as you read on.
Also note that by setting dosend to NIL prior to the action, you can do
all of the packet operations without actually sending the packet, and
then use the '+' expression to do additional rework and send the packet
after the final rework is completed. The dosend variable is set to NIL
if the TTL field reaches 0 in the process of evaluating the packet.
This allows simulation of realistic TTL operations

Interface := [* | eth0 | eth1 | ...]

The Ethernet interface of the incoming packet for this rule. An asterix
(*) indicates any interface.

PackTypes := [*ATUIO]+

One or more of
A (arp), T (tcp), U (udp), I(icmp), or O (other IP). An asterix (*)
indicates any packet type.

Source := Dest := *|[[IP][Ports][MAC]]

A source or destination Specifier which includes
optional specifications for IP address, port, and MAC address separated
by minus signs. A single asterix (*) indicates any IP address. At
least one specifier must be present.

Options := [- | [Ss | Aa | Ff | Pp | Uu | Rr | Cc | Vv | Dd |Mm]+]

Options are formed by a minus sign (for no
checking of options) or a set of indicators. Indicators may be flags
requiring (must have: upper case) or inhibiting (can't have: lower case)
TCP flags (Syn, Ack, Fin, Push, Urgent, and Reset) and/or Continue to
force further rules to be considered even if this one fires. Option 'C'
saves packet contens before performing the action and restores after the
action, while 'c' neither saves nor restores packet content. C is
slower but always 'safe' while 'c' is faster but if the packet is
altered during triggering future rules may work on parts or all of the
new packet values. Options v (verbose) and V (very verbose) along with
d (details) and D (more details) provide verbose output on the packets
associated with the rule and details and more details of the rule being
triggered. The M option fixes the destination MAC address by using the
one gleaned from previous incoming packets with the same destination IP
address on the outbound interface. If no cached value exists, it leaves
the MAC address unchanged. The m option fixes the source MAC address by
using the one gleaned from previous outgoing packets with the same
source address on the outbound interface. This is used to create
packets that appear to come from the same IP and MAC address as those on
a third interface that forwards packets to the same output interface.

Deny: In this mode packets are responded to
with type specifying TCP FIN (F) or RST (R) flags or ICMP NoHost (H),
NoNet (N), or NoRoute (T) deny packets. F is the default. The
dazzlement type indicates R or G for random or generated ARP addresses.
R is the default.

daZzle: In this mode packets are responded
to in such a manner as to appear to operate while returning meaningless
byte sequences. The dazzlement type indicates R or G for random or
generated ARP addresses. R is the default.

Mirror: In this mode inbound traffic has
its MAC, IP, and port numbers reversed and is sent out. The effect is
as if the attacker was attacking themselves.

Garble: In this mode, mirroring is
operational but content of packets is injected with noise so that it has
the general appearance of legitimacy while being corrupted. The value
of metric is used to determine the likelihood with which content is
garbled, in percent out of 100. Modes of garbling include (T)ickle
(select alterations of occasional bits), (I)tch (larger scale
alterations of more bits later in the packets), (P)oke (pretty obvious
corruption of things), and (S)tab (pretty much screw up everything that
can be screwed up). Stab, the default is the only mode currently
operating.

Forge: In this mode, responses are foged to
apear as if they were coming from specific system and service types.
Systype is the name of a system type defined in an external
configuration file.

Ignore: In this mode the packet is ignored.

Weird: In this mode, depending on the
source and destination IP addresses, ports, and MAC addresses, a
selection of other actions (i.e., dazzle ignore mirror garble deny) is
taken. These results will tend to be be consistent for any given
attacker from any given location, but will be inconsistent for different
people from different places. This is intended to create difficulties
in fingerprinting systems, particularly when applied to large numbers of
'low' ports (i.e., 1-1024) or select ports (e.g., 21, 22, 23, 25, 79,
80, 443, etc.) that are in legitimate use in some systems in the
protected IP space. If additional access controls - such as authorized
access locations for services - are used, they can be culled off in an
earlier rule, and this action will cause unauthorized users to tend to
misassociated 'real' systems from 'fictitious' systems.

Slow: In this mode, responses are mirrored
and dropped with a probability in percentage out of 100 set by the
Metric. The effect is a slowing of progress.

Attack: In this mode user-provided attack
code is executed in response.

Pose: In this mode, IP addresses, ports,
and MAC addresses are posed as different than they were and the packet
is forwarded to another interface. It provides for a form of network
address translation as well as providing selective forwarding without
transformation.

IP := ByteSpec.ByteSpec.ByteSpec.ByteSpec
|@hashname

An IP address specification consists of a series
of 4 byte specifiers, one for each of the 4 parts of an IP address,
separated by periods. Alternatively, for triggering rules, an @
followed by a previously defined hash set name matches any of the IP
addresses in the hash set.

Ports := :IntSpec
|@hashname

A port specification consists of a colon followed
by an integer specifier. Alternatively, for triggering rules, an @
followed by a previously defined hash set name matches any of the port
numbers in the hash set.

A MAC addres specification consists of a colon
followed by a series of 6 byte specifiers, one for each of the 6 parts
of a MAC address, separated by colons. Alternatively, for triggering
rules, an @ followed by a previously defined hash set name matches any
of the MAC addresses in the hash set.

ByteSpec := [ByteValue | ByteValue-ByteValue | *]

A byte specification consists of either an integer byte
value in the range of 0 to 255, a pair of byte values separated by a
minun sign, or an asterics. The byte value pair indicates all values
that are both greater than or equal to the first byte value and less
than or equal to the second byte value. The asterics indicates that any
value will be accepted.

IntSpec := [IntValue | IntValue-IntValue | *]

An IntValue consists of either an integer value in the
range of 0 to 65535, a pair of integer values separated by a minun sign,
or an asterics. The integer value pair indicates all values that are
both greater than or equal to the first integer value and less than or
equal to the second integer value. The asterics indicates that any
value will be accepted.

AttackSpec := User-defined with [SI, DI, SP, DP, SM, DM]

An attack specification is a user defined call to
an external program which may include as arguments a list of S (source)
or D (destination) followed by I (IP address), P (port), or M (MAC
address) to indicate that Responder should insert values for those
entries from the triggering packet as arguments to the external program.
NOTE that this program is run till completion before Responder
continues its operation - make it quick or lose lots of packets

SourceChange := DestChange := [DIP][DPorts][DMAC]]

A source (destination) change specification
consists of an IP delta, a Ports delta, and a MAC delta.

DIP := [DByte.DByte.DByte.DByte]

A sequence of 4 byte change specifications
separated by periods.

DPorts := [:DInt]

A colon followed by an integer chance specification.

DMAC := [:DByte:DByte:DByte:DByte:DByte:DByte]

A colon followed by a sequence of 6 byte change
specifications separated by colons.

DByte := [Byte-Value | +Byte-Value | -Byte-Value | R | G | + | - | =]

Either a byte value to be assigned to this byte, a
byte value to be added to this byte mod 256, a byte value to be
subtracted from this byte value mod 256, a random byte value, or a
generated byte value that is a function of the IP address and the byte
position in the packet. A + or - without a value is treated as +0 or
-0. An '=' produces no code for that field and is thus more efficient
than +0.

DInt := [Int-Value | +Int-Value | -Int-Value | R | G]

Either an integer value to be assigned to this
port, an integer value to be added to this port mod 65535, an integer
value to be subtracted from this port value mod mod 65535, a random
integer value, or a generated integer value that is a function of the IP
address and the byte position in the packet. A + or - without a
bytevalue is treated as +0 or -0, so that - is an unaltered port.

Note that a valid rule file ends in a line with only a
'.' (period) on it. All lines thereafter are ignored, which can be
convenient for more extensive documentation associated with the rule
file. If the end of file is reached before such a line, the rule set is
assumed to be completed at the end of the file. Once you have prepared
a valid rule file, you can run the following command to translate it
into a lisp expression and detect any errors in your specification:

/usr/local/Responder/router-parse valid-rule-file

Once this result looks right, you can load, compile,
and run the rules by typing:

/usr/local/Responder/router-run valid-rule-file

Invalid rule files are treated rather poorly and the
diagnostics are obscure at best, but on the other hand, the rules should
not be that hard to get right since each has the same fields. All
fields must be properly capitalized and only spaces may be used to
separate fields. Debugging messages in the form of each line read are
printed out, so if there is a syntax error, it will apply to the line
just printed and include a line number. Syntax errors will also cause
the rule to be replaced by a "SYNTAX ERROR" printout that will replace
the rule so that any time the rule is missed the error message will be
printed. In addit6ion, a generic syntax error will be printed at the
start of every packet reception.

Here are a few examples of rules file I have used.
The IP addresses and ports have been changed to protect the users:

The net effect is to slow down many Internet worms.
When they try to come to these addreses, which have no legitimate
services on port 80, their inbound packets are accepted, and they are
provided with consistent forged ARPs and ICMP responses, but no
responses are made after the TCP 'connection' is made. This tends to
run the attacking computers out of resources because they only have so
many available outbound ports and to get them stuck on these IP
addresses because of the retry mechanisms in TCP that continue trying to
complete the uncompletable connection.

You can view the lisp code produced by a rule set by
using:

/usr/local/Responder/router-parse valid-rule-file

Here is the result of applying a version of
router-parse to the rule set above:

The output begins by describing what was loaded to
start compilation. It then indicates that the RAWSOCK package is being
used to interact with the interface card. It lists the lines of the
router file and the shows the program generated by these rules. It
starts by setting the packet number PNUM to 0 and then creates a loop
that eternally gets a packet, increments PNUM, and executes a
conditional COND. Lisp has big numbers so that the PNUM count can never
get so large as to cause an overflow (actually - it is limited to the
largest number that can be represented in the memory of your computer
using 8 bits per byte and as many bytes as your RAM can hold).
(FACEMATCH '(101 116 104 48) (SLOT FROM 'SA_DATA)) matches the string
'eth0' to the ethernet data arriving on the interface that got the last
packet. (EQUAL (ARPTYPE) :ARP) checks if it is an ARP packet. (LISTCMP
(ARPDST) '(10 2 3 (4 5)) checks the ARP destination address against the
IP address 10.2.3.4-5. (PROGN (FORWARD '(101 116 104 49)) T)) forwards
the result to ethernet 1. The other conditions are handled in a similar
manner and finally, 1099 is the length of the source code for the
function.

The difference here is that all TCP is Itched. The
effect is quite extrordinary. In effect, Garbling in 'Itch' mode means
that packets are mirrored with the initial parts of packet content left
untouched, while the latter part is garbled. Remote worm code entering
this site starts by connecting to port 80, which is basically mirrored
untouched. Then, as the work tries to insert its code into the
defending systems, the mirror sends the same code back to the attacker,
but the garbling effect causes the latter part of the attack code to
become randomized. This means that, while the initial part of the
break-in code that lets the worm in runs on the attacking computer, the
coherent code of the worm that tends to reside near the end of the
packet is no longer coherent when it is executed on the attacker's
machine. The majority of incoherent byte sequences executed by
processors causes programs to fail. The net effect is that the worm
enters the attackers computer and crashes it.

NOTE: This may bring legal liability to
those who use it. I only apply this in cases where I feel that 'self
defense' justifies it. Examples where I might think it is justified
include cases where an infrastructure that I depend on for something
vital is near collapse, or cases where a remote attacker is trying to
cause harm over an extended period and other attempts to stop them,
including contacting them through authorized contact channels, has
failed.

Note the importance of using the hash sets in terms of
rule (and thus time) savings. Without the hashsets, this would have
taken about 2,000 rules - with hash sets it takes only 11 rules. Please
feel free to parse it yourself. The resulting function is 7793 bytes long.

Performance Enhancement

Performance of Responder is quite good. We have run
traffic at near saturation levels on several 100Mbps Ethernets using a
350Mhz processor with an inexpensive interface card without packet loss.
Performance is, however, largely effected by the rules you choose ond
the amount of logging used.

The first thing to note is that when using the D and V
modes for verbose output and detailing, response times can become quite
long. In ping flood experiments we were able to get ping performance to
more than a second of delay with all logging turned on and output going
to an X11 display. We we3re also running TCPdump on all three
Ethernets. When we removed D and V from the options field except on
rules were particularly interested in, response time stayed below a
milisecond.

Another critical performance enhancer is keeping the
number of rules small. With the use of hash functions we have turned
rules sets with thousands of rules in to sets with a few rules. The net
effect was dramatic performance enhancement similar to the results of
logging (but not as stark). We have done quite complex response
mechanisms with only 10-20 rules, including gateway routing for select
systems, bad computer differentiation and deception, select logging, and
translations between three networks.

The third thing to do for enhanced performance is to
order rules so that the things that are encountered most often are
triggered first. Rule ordering is a complex issue because you are
deinfing a finite state machine by the order of your rules. It is the
source of many mistakes by less experienced folks and there are some
subtle things that can happen with rule reordering. Still, if you can
find an ordering that uses earlier rules more often performance will be
faster. Also note that by trying to exercise different rules an
attacker might be able to tell something about the rule ordering. It is
an interesting covert channel that can be largely avoided at the cost of
performance - but that discussion must go elsewhere.

The last thing to do is be careful about your lisp
code. We have been pretty careful about our parser and as a result, you
will see that in many (perhaps most) cases, when a check does not have
to be done it is not done. For example, when you use '*' or '=' for a
field, in many cases, no check is done for that field at all. If you
don't include ports or MAC addresses, no check is generated for them.
This makes the program smaller, faster, and more efficient at runtime.
You can do the same thing in your lisp code. Avoid inefficient
constructs, don't make unnecessary loops, and don't do recursive
functions. It sounds almost blasphemous to say that to lisp
programmers, but performance is improved when less memory allocaiton is
done, and recursion uses lots of memory allocation.

Intrusion Detection

It turns out that in router mode, Responder makes a
real nice intrusion detector. By selectively using d, D, v, and V
options, you can configure your system so that all non-permitted packets
generate output for review. As a first cut - in a relatively quiet
network environment, this is a winner. If you are doing deceptions,
then any attempt by attackers to use deceptions can be handled by a rule
with logging as well. By using comments in a reasonable way, you can
even provide hints about what happened to other analysis programs. For
example, use WARNING and DANGER in comments an your output listing will
provide lots of useful information about intrusion attempts.

But Responder can do a lot better than that through
the use of embedded lisp. For example, suppose I wanted to keep counts
of every packet from each IP address that triggered select rules, and
when a threshold was reached, change the behavior for that IP address.
The plan would be to create a hashset for 'questionable' addresses with
a value equal to the number of times that IP address triggered an event.
When the threshold is reached on an IP address, add it to the 'bad'
address list which is treated differently, log the event, and continue
on. For lisp programmers, this is a fairly simple matter. It takes
perhaps 3-4 lines of lisp code. Here is a simple example:

Handy Selections for Implementations

This section is full of handy things from previous
implementations. We will start with an ARP cache and restoration
mechanism that is very useful for cases where you want to remember the
ARP source addresses from incoming traffic and apply them to outbound
traffic later. For example, if you have a gateway and traffic going to
one of two interfaces depending on its source address, you need to store
the ARP addresses of the destinations on interfaces and restore the
proper ARPs in each direction or packets will get lost.

H gateway 1.2.3.4
:(setarphash (SLOT FROM 'SA_DATA) (src) (arpsrc))
; the source ARP address from the ARP packet's request
* A * * C I ; store ARPs in ARP cache for all ARP packets and go on
:(setarphash (SLOT FROM 'SA_DATA) (src) (tomac))
; the destination MAC from the TCP packet resulting from prior ARP replies from eth1
* TUIO * * C I ; store ARPs in ARP cache for all other IP packets and go on
;; OK - a note here - something like this is required if you want to set ARP cache values
;; this particular setup assumes that source ARPs are valid and ignores destination ARPs,
;; but it's a matter of personal choice - and situation - to determine when to trust what.
;..... other stuff not using ARP caches goes here
; all ARPs are sent from the gateway to both sides - this primes the ARP caches for the other interfaces.
eth0 A * * C F eth1 ;send eth0 ARP packets to eth1 unaltered
eth0 A * * - F eth2 ;also send eth0 ARP packets to eth2 unaltered
; note this generates ARP returns which are collected by the above rules for all Ethernets.
; ARPs are forwarded from eth1 to eth0 - priming the pump and asnwering requests.
eth1 A * * - F eth0 ;send eth1 ARP packets to eth0 with destination MAC for gateway
; ARPs from eth2 are dazzled so that responses are ignored and requests appear to have addresses
eth2 A * * - Z G ;Dazzle ARPS on eth2 - G so addresses seem to have unique ARP addresses
; Other packets from eth1 pass through to eth0 unaltered.
eth1 * * * - F eth0 ;send eth1 other returns to eth0
; Other packets from eth2 are given the MAC address of the gateway on eth0
eth2 * * * Mm F eth0 ;send eth2 other packets to eth0 with destination MAC for gateway and src MAC from eth1
;; Why from eth1? Because it is the only one that returned ARP information to the gateway - which then uses it's ARP on inbound
;; packets as the destination ARP...
; Finally, we decide which way things go on eth0 and associate ARPs from eth2 if they go that way.
eth0 * 1.2.3.4 * - F eth1 ; things from this source go to eth1 and are left alone
eth0 * * * M F eth1 ; everywhere else go to eth2 fixing the destination ARP per previous ARP responses (for example)

Programmed mode

In programmed mode you can write your own programs to
cause Responder to function as you wish. You will need to know LISP,
since Responder is a LISP program. Specifically, the following data
structures and functions are provided for your use.

This example demonstrated how the 'mirror' function is
implemented. It swaps the header information and sends the packet back
out on the same interface it arrived on. Nothing to it. Note that you
would have to call ipcsum just before sendt and, as apropriate, udpcsum,
tcpcsum, or icmpcsum before that, except that these particular
transforms do not alter the checksum for a packet.

To run your program (called yourprogram in
/u/yourdir), do the following from the Unix shell: