Re: IP spoofing -- assessment
Paul Ferguson (paul@hawksbill.sprintmrn.com)
Wed, 25 Jan 1995 10:02:11 -0500 (EST)
ziese@chaos.csap.af.mil writes -
>
> Were am I going? First, the tools taken from Tsutomu will most likely not be
> seen for a while because unlike the gimme program, there were code snippets
> not functional shell scripts AND they can be easily attributed to him. Two,
> ip spoofing is bad, but the ankle biters are worse because our systems (yours
> and mine) are vulnerable to the most elementary attacks and as long as that
> stands, the exotic ones should be counted but not obsessed over.
>
I'm not so concerned about the attacks themselves, per se, as I am
about the detection methodology (which is why I subscribed to this
list in the first place) to determine the usage of the tools themselves.
I received this interesting e-mail yesterday concerning TAP. Apologies
to those on the list who have already read it on the firewalls list.
forwarded message:
TAP could be a program that was posted in 1992 by Simon Ney in alt.sources.
There is another varient called advise that does the same thing.
If it is a streams based program like tap ... provided that pstat hasn't
been compromised, the following will show a tap:
here an example output from ,pstat -S'' while one tapmon is running:
LOC WRQ VNODE DEVICE PGRP SIGIO FLAGS
f05461e f05583c f0cdb94 59, 0 0 0 R
Write side:
NAME COUNT FLG MINPS MAXPS HIWAT LOWAT
strwhead 0 0 0 0 0
tapc 0 R 0 INF 0 0
Read side:
tapc 0 R 0 INF 0 0
strrhead 0 R 0 INF 5120 1024
LOC WRQ VNODE DEVICE PGRP SIGIO FLAGS
f0543e0 f0550ec f0cc9f4 12, 1 905 0
Write side:
NAME COUNT FLG MINPS MAXPS HIWAT LOWAT
strwhead 0 0 0 0 0
tap 0 R 0 INF 0 0
ttcompat 0 R 0 INF 300 200
ldterm 0 R 0 INF 1 0
zs 0 R 0 INF 2048 128
Read side:
zs 0 R 0 INF 2048 128
ldterm 0 R 0 128 500 200
ttcompat 0 R 0 INF 2048 128
tap 0 R 0 INF 0 0
strrhead 0 0 INF 300 200
Here is what TAP says:
DESCRIPTION:
- the device is a monitor/manipulator for other STREAMS-devices
such as standard UNIX control-terminals.
- this driver is a kernel-loadable-module. (==>no reboot required)
- it is a combination of a STREAMS-module and a STREAMS-driver.
tap - is the name of the pushable/poppable STREAMS-modules.
tapc* - are the names of the STREAMS-driver nodes (special
files)..
- the tap-modules must first manually pushed/popped on each stream
to be monitored or manipulated, independ if the tapc-driver is
open or not. see also ioctl(fd,I_PUSH|I_POP,"tap").
- the first module pushed become the id 0, the second 1, and so on...
if any of these modules are popped the next pushed will become
the old id of the previous popped module. the module ids are
always unique, and are assigned first fit.
the maximal number of tap-modules pushed is NTAP (see tap.h).
- a pushed-tap-module act as NULL-streams-MODULE (pass data from below
to above and data from above to below) unless it is connected with
the tapc-driver.
- now if a minor device of the tapc-driver is opened the minor
device-number is used to check if such tap-module is pushed
(minor number = tap-id). if no such module id is present a
ENETUNREACH (Network is unreachable) error is returned by open().
if the module id (minor device number) can be found, a connection
to the pushed-tap-module is established.
- all minor-device-nodes can only open by one user at a time,
the second open() on the same minor device returns a EBUSY (Device
busy) error.
- if the open() has the O_NDELAY flag set a TAP_REVERSE flag
is internal set in the driver. the TAP_REVERSE flag can only
set by the super-user, a non-superuser open() returns a EACCES
(Permission denied) error.
- now data can be received/send from/to the pushed-tap-module
with read() and write().
- if the TAP_REVERSE flag is not set, data received by the tap-module
from the above modules/streamshead (upper-stream) is duplicated
and send to the read-side of the tapc-driver, and can be read by
the user process that opened the tapc-driver.
data written with write() by the process that opened the tapc-driver
are send to modules/streamshead above the tap-module (upper-stream).
- if the TAP_REVERSE flag is set, data received by the tap-module
from the module/driver below the tap-module (lower-stream) is
duplicated and send to the read-side of the tapc-driver, and can
be read by the user process that opened the tapc-driver.
data written with write() by the process that opened the tapc-driver
are send to the modules/driver below the tap-module (lower-stream).
- if the tapc-driver is closed the messages are not dupclicated as
long as the tapc-driver is re-open. (the tap-modules remains
pushed)
- if data is written by the tapc-driver and the connected module
was popped a ENETCONNRESET (Connection reset by peer) error is
return to the write().
- if the stream that has the tap-module pushed is closed, all modules
on this stream are popped by the system. but there is a configuration
option in sunos to autopush any modules on open() (that's different
in a SYSV environment).
---------------
FIGURES:
(USER PROCESS) (BIG BROTHER)
(csh,vi) (tapmon) (tapmon -r) (tip/cu/uucico)
/dev/ttya /dev/tapc0 /dev/tapc1 /dev/cua1
--------------------------------------------------------------------------------
|ttya HEAD | |tapc HEAD| |tapc HEAD| |cua1 HEAD |
+----------+ +---------+ +---------+ +----------+
| ^ | ^ | ^ | ^
| | | | | | | |
| | ........... ........... | |
| | . MORE . . MORE . | |
| | . MODULES . . MODULES . | |
| | ........... ........... | |
| | | | | | | |
v | v | v | | |
............ +---------+ +---------+ ............
. MORE (2). |TAPC 0 | |TAPC 1 | . MORE (2) .
. MODULES . |DRIVER | |DRIVER(1)| . MODULES .
............ +---------+ +---------+ ............
(3)| ^(4) | ^ | ^ | | UPPER
v | | | | | v | STREAMS
+----------+ | | | | +----------+
| \ \ | | | | | | TAP 1 |
| \ \--|<---------/ | | \--------|\ MODULE |
| TAP 0\---|------------/ \--------->| \ PUSHED|
| MODULE | |\ \REVERSE|
| PUSHED | | \ \ OPEN |
| | <--- NORMAL REVERSE---> | \ \ |
+----------+ +----------+
| ^ (4)| ^(3) LOWER
v | v | STREAMS
............ ............
. MORE (2). . MORE .
. MODULES . . MODULES .
............ ............
| ^ | ^
v | v |
+----------+ +----------+
| zs DRIVER| | zs DRIVER|
--------------------------------------------------------------------------------
physical STREAMS device physical STREAMS device
(terminal) (modem)
(intruder) (other systems)
----------
(1) - opened by O_NDELAY from root
(2) - e.g. ttcompat,ldterm,kb,ms,
slip,ax25,pf,nbuf
(3) - duplicated streams
(4) - multiplexed streams
NOTE: the ,,physical STREAMS device'' above shown can be any streams device
e.g.: /dev/{tty*,console,nit,tcp,loop,mux,mti,kbd,mouse,*CLONE*}
(nit and tcp is a clone device !)
slip cant monitored because itself pops all modules pushed.
the only way is to modify sliplogin.c to push the tap module below
the slip module.
- ---
_______________________________________________________________________________
Paul Ferguson
US Sprint tel: 703.689.6828
Managed Network Engineering internet: paul@hawk.sprintmrn.com
Reston, Virginia USA http://www.sprintmrn.com