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