[PATCH] ipfw logging through tcpdump ?

[Luigi Rizzo]

The following ipfw patch (which i wrote back in 2001/2002) makes
ipfw logging possible through tcpdump -- it works by passing to the
fake device 'ipfw0' all packets matching rules marked 'log' .
The use is very simple -- to test it just do

ipfw add 100 count log ip from any to any

and then

tcpdump -ni ipfw0

will show all matching traffic.

I think this is a quite convenient and flexible option, so if there
are no objections I plan to commit it to head.

cheers
luigi

Index: ../head/sys/netinet/ipfw/ip_fw2.c
===================================================================
--- ../head/sys/netinet/ipfw/ip_fw2.c (revision 200551)
+++ ../head/sys/netinet/ipfw/ip_fw2.c (working copy)
@@ -65,6 +65,8 @@
#include <sys/ucred.h>
#include <net/ethernet.h> /* for ETHERTYPE_IP */
#include <net/if.h>
+#include <net/if_types.h> /* for IFT_ETHER */
+#include <net/bpf.h> /* for BPF */
#include <net/radix.h>
#include <net/route.h>
#include <net/pf_mtag.h>
@@ -338,6 +340,15 @@
"Enable keepalives for dyn. rules");
#endif /* SYSCTL_NODE */

+#ifdef DEV_IPFW
+static struct ifnet *ifn; /* hook to attach to bpf */
+static int
+ipfw_ifnet_ioctl(struct ifnet *ifp, u_long cmd, caddr_t addr)
+{
+ return EINVAL;
+}
+#endif
+
/*
* L3HDR maps an ipv4 pointer into a layer3 header pointer of type T
* Other macros just cast void * into the appropriate type
@@ -3056,6 +3067,29 @@
if (V_fw_verbose)
ipfw_log(f, hlen, args, m,
oif, offset, tablearg, ip);
+#ifdef DEV_IPFW
+ else if (ifn && ifn->if_bpf != NULL) {
+ /* This kludge is OK; BPF treats
+ *the "mbuf" as read-only */
+ struct m_hdr mh;
+ mh.mh_next = m;
+ mh.mh_len = ETHER_HDR_LEN;
+ if (args->eh) /* layer2, complete */
+ mh.mh_data = (char *)args->eh;
+ else {
+ /* fake header and restore wire format*/
+ mh.mh_data = "DDDDDDSSSSSS\x08\x00";
+ ip->ip_off = ntohs(ip->ip_off);
+ ip->ip_len = ntohs(ip->ip_len);
+ }
+ BPF_MTAP(ifn, (struct mbuf *)&mh);
+ if (args->eh == NULL) {
+ /* restore IP format */
+ ip->ip_off = htons(ip->ip_off);
+ ip->ip_len = htons(ip->ip_len);
+ }
+ }
+#endif /* DEV_IPFW */
match = 1;
break;

@@ -4830,6 +4864,19 @@
printf("limited to %d packets/entry by default\n",
V_verbose_limit);

+#ifdef DEV_IPFW /** bpf code **/
+ ifn = if_alloc(IFT_ETHER);
+ if_initname(ifn, "ipfw", 0);
+ ifn->if_mtu = 65536;
+ ifn->if_flags = IFF_UP | IFF_SIMPLEX | IFF_MULTICAST;
+ ifn->if_ioctl = ipfw_ifnet_ioctl; /* getaddr */
+ ifn->if_addrlen = 6;
+ ifn->if_hdrlen = 14;
+ if_attach(ifn);
+ ifn->if_baudrate = IF_Mbps(10);
+ bpfattach(ifn, DLT_EN10MB, 14);
+#endif /** end bpf code **/
+
return (error);
}

@@ -4840,6 +4887,11 @@
ipfw_destroy(void)
{

+#ifdef DEV_IPFW
+ ether_ifdetach(ifn);
+ if_free(ifn);
+ ifn = NULL;
+#endif
uma_zdestroy(ipfw_dyn_rule_zone);
IPFW_DYN_LOCK_DESTROY();
printf("IP firewall unloaded\n");
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[David Horn]

Code works well for me with latest current r200562, although a bit of
extra fuzz factor was needed for the patch to apply cleanly.

My only comment is that I would prefer a tunable or sysctl to having
to recompile with CFLAGS+= -DDEV_IPFW added to the ipfw module
Makefile.

Very useful code.

---Dave Horn

[Bjoern A. Zeeb]

On Tue, 15 Dec 2009, Luigi Rizzo wrote:

Hi,

> The following ipfw patch (which i wrote back in 2001/2002) makes
> ipfw logging possible through tcpdump -- it works by passing to the
> fake device 'ipfw0' all packets matching rules marked 'log' .
> The use is very simple -- to test it just do
>
> ipfw add 100 count log ip from any to any
>
> and then
>
> tcpdump -ni ipfw0
>
> will show all matching traffic.
>
> I think this is a quite convenient and flexible option, so if there
> are no objections I plan to commit it to head.

pf(4) has pflog(4). Ideally calling it the same would be good though
I wonder if two of the the three of our firewalls grow that feature,
if we could have a common packet logging device rather than re-doing
it for each implementation.

Frankly, I haven't looked at the details of the implementation but I
found getting rul numbers with tcpdump -e etc. was pretty cool to
identify where things were blocked or permitted.

Also make sure that the per-VIMAGE interface will work correctly and
as expected.

/bz

--
Bjoern A. Zeeb It will not break if you know what you are doing.

[Luigi Rizzo]

On Tue, Dec 15, 2009 at 10:09:47AM +0000, Bjoern A. Zeeb wrote:
> On Tue, 15 Dec 2009, Luigi Rizzo wrote:
>
> Hi,
>
> >The following ipfw patch (which i wrote back in 2001/2002) makes
> >ipfw logging possible through tcpdump -- it works by passing to the
> >fake device 'ipfw0' all packets matching rules marked 'log' .
> >The use is very simple -- to test it just do
> >
> > ipfw add 100 count log ip from any to any
> >
> >and then
> >
> > tcpdump -ni ipfw0
> >
> >will show all matching traffic.
> >
> >I think this is a quite convenient and flexible option, so if there
> >are no objections I plan to commit it to head.
>
>
> pf(4) has pflog(4). Ideally calling it the same would be good though
> I wonder if two of the the three of our firewalls grow that feature,
> if we could have a common packet logging device rather than re-doing
> it for each implementation.
>
> Frankly, I haven't looked at the details of the implementation but I
> found getting rul numbers with tcpdump -e etc. was pretty cool to
> identify where things were blocked or permitted.

this is something trivial which i have planned already -- stuff
10-12 bytes in the MAC header with rule numbers and actions
is surely trivial.

Thanks for the pointer to pflog, i'll look at that.

> Also make sure that the per-VIMAGE interface will work correctly and
> as expected.

On this i would like more feedback -- is there anything special
that I am supposed to do to create per-vimage interfaces ?
Could you look at the code i sent ?
"ipfw0" uses the same attach/detach code used by if_tap.

cheers
luigi

[Julian Elischer]

I'm not sure we should do everything just because we can.
it gives us nothing that we can't already get. you can filter using
ipfw netgraph -> netgraph bpf -> ng_socket
you can efficiently capture packets with divert (or tee)
you can write to pcap files using phk's program.

[Luigi Rizzo]

On Tue, Dec 15, 2009 at 09:06:04AM -0800, Julian Elischer wrote:
> Luigi Rizzo wrote:
..

> >>>The following ipfw patch (which i wrote back in 2001/2002) makes
> >>>ipfw logging possible through tcpdump -- it works by passing to the
> >>>fake device 'ipfw0' all packets matching rules marked 'log' .
> >>>The use is very simple -- to test it just do
> >>>
> >>> ipfw add 100 count log ip from any to any
> >>>
> >>>and then
> >>>
> >>> tcpdump -ni ipfw0
> >>>
> >>>will show all matching traffic.
> >>>
> >>>I think this is a quite convenient and flexible option, so if there
> >>>are no objections I plan to commit it to head.

..

> I'm not sure we should do everything just because we can.
> it gives us nothing that we can't already get. you can filter using
> ipfw netgraph -> netgraph bpf -> ng_socket
> you can efficiently capture packets with divert (or tee)
> you can write to pcap files using phk's program.

it's not "because we can", it is "because it costs almost nothing
and gives new functionality".
The cost is just 30 lines of code (including comments) and one extra
compare on matching packets (those for which you already enabled
the 'log' option, so were prepared to pay the price of logging.

Most importantly, you don't need to change the existing ipfw configs.
That is, in my opinion, the main advantage.

cheers
luigi

[Luigi Rizzo]

On Tue, Dec 15, 2009 at 10:09:47AM +0000, Bjoern A. Zeeb wrote:

> On Tue, 15 Dec 2009, Luigi Rizzo wrote:
>
> Hi,
>
> >The following ipfw patch (which i wrote back in 2001/2002) makes
> >ipfw logging possible through tcpdump -- it works by passing to the
> >fake device 'ipfw0' all packets matching rules marked 'log' .
> >The use is very simple -- to test it just do

..

> pf(4) has pflog(4). Ideally calling it the same would be good though
> I wonder if two of the the three of our firewalls grow that feature,
> if we could have a common packet logging device rather than re-doing
> it for each implementation.
>
> Frankly, I haven't looked at the details of the implementation but I
> found getting rul numbers with tcpdump -e etc. was pretty cool to
> identify where things were blocked or permitted.

i checked pflog sources (contrib/pf/net/if_pflog.c) and it is almost
exactly the same thing i am doing, plus a handful of lines to prepend
a header with the metadata.
The main function, pflog_packet(), is so short and simple that
it would probably deserve going somewhere in if_ethersubr.c or
bpf<something>.c so we can use it more easily.

cheers
luigi

[Kevin Oberman]

> Date: Tue, 15 Dec 2009 09:06:04 -0800
> From: Julian Elischer <jul...@elischer.org>
> Sender: owner-free...@freebsd.org

While I agree with the sentiment, the proposal is so simple and elegant
and so easy to use that I think it would be crazy to not do it. It's
just much easier to use on an impromptu basis than doing the netgraph
stuff (except for those who do lots of netgraph).
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: obe...@es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751