Re: FW: monitor ALL connections to ALL ports

From: Peter Pentchev (roam@ringlet.net)
Date: 10/16/02 

Date: Wed, 16 Oct 2002 12:37:15 +0300
From: Peter Pentchev <roam@ringlet.net>
To: Danny.Carroll@mail.ing.nl

On Wed, Oct 16, 2002 at 10:48:01AM +0200, Danny.Carroll@mail.ing.nl wrote:
> Something else you could do, if you want to put the effort into it is
> to write a program that accepts all packets from ipfw (via a divert
> rule) and then logs what you want before returning the untouched
> packed back to ipfw.
>
> Much like what natd does, except without the natting.
> I am sure the natd sources would be very useful in this case.

I am a bit surprised that nobody has mentioned ports/net/clog yet.
It is simple yet effective; it does not log UDP packets, but this
functionality may not be too hard to add.

G'luck,
Peter 

-- 
Peter Pentchev	roam@ringlet.net	roam@FreeBSD.org
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
This sentence every third, but it still comprehensible.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

Relevant Pages

  • Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility)
    ... For simple using, however, you don't need to bother all that details - just remember magic number and where to place it, and it is now simple for use with ipfw tags. ... Currently the only analyzing node in FreeBSD src tree is ng_bpf, but it merely splits incoming packets in two streams, matched and not. ... There are reasons to this, as netgraph needs to be modular, and each node does a small thing, but does it well. ... For long time ng_bpf was used for another purposes in the kernel, and now, as new ipfw features appeared, ng_tag came up for easy integration. ...
    (freebsd-current)
  • Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility)
    ... For simple using, however, you don't need to bother all that details - just remember magic number and where to place it, and it is now simple for use with ipfw tags. ... Currently the only analyzing node in FreeBSD src tree is ng_bpf, but it merely splits incoming packets in two streams, matched and not. ... There are reasons to this, as netgraph needs to be modular, and each node does a small thing, but does it well. ... For long time ng_bpf was used for another purposes in the kernel, and now, as new ipfw features appeared, ng_tag came up for easy integration. ...
    (freebsd-isp)
  • Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility)
    ... For simple using, however, you don't need to bother all that details - just remember magic number and where to place it, and it is now simple for use with ipfw tags. ... Currently the only analyzing node in FreeBSD src tree is ng_bpf, but it merely splits incoming packets in two streams, matched and not. ... There are reasons to this, as netgraph needs to be modular, and each node does a small thing, but does it well. ... For long time ng_bpf was used for another purposes in the kernel, and now, as new ipfw features appeared, ng_tag came up for easy integration. ...
    (freebsd-net)
  • FreeBSD Security Advisory: FreeBSD-SA-01:08.ipfw [REVISED]
    ... included in FreeBSD 4.0 and above. ... based on an old version of ipfw and does not contain as many features. ... Due to overloading of the TCP reserved flags field, ... incorrectly treat all TCP packets with the ECE flag set as being part ...
    (FreeBSD-Security)
  • Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility)
    ... The problem with pf is that pf compiles all the rules at the time, so exact tags representation can change each time (for this reason ipfw tags were made incompatible with pf), and you must that values to supply them to. ... Also, as it seems non-trivial on current ipfw dynamic rules implementation, I don't know if shaping will work at all. ... But you can try to test such ruleset (it supposes that dynamic rules are checked twice, on incoming packets and on outgoing also, as with all other rules as ipfw manpage says): ...
    (freebsd-current)