RE: FW: monitor ALL connections to ALL ports

From: Danny.Carroll@mail.ing.nl
Date: 10/16/02 

Date: Wed, 16 Oct 2002 10:48:01 +0200
From: <Danny.Carroll@mail.ing.nl>
To: <maildrop@qwest.net>

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.

-D

-----Original Message-----
From: Maildrop [mailto:maildrop@qwest.net]
Sent: 15 October 2002 19:58
To: Krzysztof Zaraska; Mike Hoskins; Maildrop
Cc: freebsd-security@freebsd.org
Subject: RE: FW: monitor ALL connections to ALL ports

Yep, this is exactly what I am looking for. All packets, is a bit heavy on
my hard drive :P This only works with tcp though, is there any thing to
watch udp packets (like the first packet from a host on a certain port?) I
know udp might be tougher, since it is stateless.

> -----Original Message-----
> From: Krzysztof Zaraska [mailto:kzaraska@student.uci.agh.edu.pl]
> Sent: Tuesday, October 15, 2002 10:57 AM
> To: Mike Hoskins; Maildrop
> Cc: freebsd-security@freebsd.org
> Subject: Re: FW: monitor ALL connections to ALL ports
>
>
> On Mon, 14 Oct 2002 14:58:50 -0700 (PDT)
> Mike Hoskins <mike@adept.org> wrote:
>
> > > I put these rule in:
> > > ipfw add count log all from any to any
> >
> > Is this rule before the other allow rules in your chain? Since the rule
> > chain is parsed on a first-match basis, you'll either need this rule
> > before all others or you'll need to add log entires to each of your
> > other rules.
>
> There's another problem I can see here: this setup will generate a log
> entry on EVERY packet, what is clearly an overkill. I think it would be
> more useful to log only opening of the connection; this can be
> accomplished using for example a 'setup' keyword, e.g.:
>
> # Allow access to our WWW
> ${fwcmd} add pass log tcp from any to ${oip} 80 setup
>
>
> --
> // Krzysztof Zaraska * kzaraska (at) student.uci.agh.edu.pl
> // Prelude IDS: http://www.prelude-ids.org/
> // A dream will always triumph over reality, once it is given the chance.
> // -- Stanislaw Lem
>
>
>

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
----------------------------------------------------------------- ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. -----------------------------------------------------------------

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)