[vox-tech] network blinken lights experiment

Mike Simons vox-tech@lists.lugod.org
Thu, 22 May 2003 15:37:59 -0400


--cDtQGJ/EJIRf/Cpq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 19, 2003 at 11:08:02AM -0700, dylan wrote:
> Here is my question - is it possible for a shell script / perl script to
> monitor a filtered data stream from 'tcpdump' -- looking for key pieces of
> text. when there is a match on say "FTP"  or "WWW" or "SSH", the shell
> script or perl script would output a single byte of data to the serial po=
rt:

  Yes.

  I have used perl and tcpdump before to monitor and reconstruct
application flows from a third party machine on the network (in a remote
logging sort of mode).

  This is a neat little project... could be used for a blinking
intrusion detection system that sits on your monitor for example.


> $ tcpdump | grep -v stuff_to_filter | some_perl_or_shell_script > /dev/tt=
yS0
>=20
> so for every packet with a header that matches
>=20
> SSH   --> output a '1'
> WWW   --> output a '2'
> FTP   --> output a '3'   .... and so on.

  As Nicole mentioned, unless you get practically no traffic you should
do this a different way... a high speed ssh file transfer would completely
flood a slow serial channel with '1's ...=20

  I would recommend you have your script print a byte every on some sort
of timer... the byte would indicate which types of packets have happened
in the last interval of time... you can check which bits are present on
the basic stamp and light the correct button.

  0x1 - means SSH
  0x2 - means http
  0x4 - means ftp

  I'm not going to paste perl code that does this right now... since
I don't have code samples of this any handy.

> is it possible to search streams of data like this, and would such a sear=
ch
> actually provide reliable information?
>=20
> any ideas?

On Mon, May 19, 2003 at 03:00:57PM -0700, wenk@praxis.homedns.org wrote:
> On Mon, 19 May 2003, dylan wrote:
> I wonder if using tcpdump would be the best way of doing this...=20
>=20
> And yes, you could do the whole thing via perl using perl regular=20
> expressions.  Either do a open INBUF, "tail -f <file> |"; or maybe=20
> there is a way to do it completely in perl.

  You have the right idea going,  just open the tcpdump from inside of
perl... if you log the data to a file and read the file you will
eventually fill up the hard drive.  there is probably no reason to store
the output... ;)

=3D=3D=3D
open INPUT, "tcpdump -nl |";
open OUTPUT, "> /dev/ttyS0";
=3D=3D=3D

  You can also get tcpdump to do most of the filtering for you:
=3D=3D=3D
tcpdump -nl port 22 or port 80 or port 20 or port 21
tcpdump -nl port 22 or port 80 or port 20 or port 21 and dst host HOSTNAME
=3D=3D=3D


On Wed, May 21, 2003 at 08:46:40PM -0700, dylan wrote:
> ngrep -q -D | awk -f netled.awk > /dev/ttyS0

> seems to work.. however, ngrep doesn't always report the packets as soon =
as
> they occur....need to figure out how to make it more responsive..

  There are three possible reasons... you could be sending too much data
to the device... so it falls behind, as I mentioned above.

  When tcpdump is run on the screen the output is line buffered so you
don't notice... but when directed to a file block buffering happens.
you can add the -l option to tcpdump to get it to line buffering
to files.

  If you don't use the -n option tcpdump resolves host names and port
numbers... depending on your configuration the DNS lookups can take a=20
long time and can even cause tcpdump to miss packets.

--=20
GPG key: http://simons-clan.com/~msimons/gpg/msimons.asc
Fingerprint: 524D A726 77CB 62C9 4D56  8109 E10C 249F B7FA ACBE

--cDtQGJ/EJIRf/Cpq
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+zScX4Qwkn7f6rL4RAnReAJ9gsnWlfp8UYNBHTIAx6h00vo49gQCfYGZa
qFe1hRjbENyVmEoK2gRwQ3Y=
=D7n9
-----END PGP SIGNATURE-----

--cDtQGJ/EJIRf/Cpq--