Date: Tue, 3 Sep 2013 18:58:00 -0700 From: Kurt Buff <kurt.buff@gmail.com> To: freebsd-net@freebsd.org Subject: Re: Question regarding security run output Message-ID: <CADy1Ce4EnnrfU9DjneHTf1J=%2BFPD7ihQKbP3Tbf3zB3PuMHQnQ@mail.gmail.com> In-Reply-To: <20130904000959.GG19904@verio.net> References: <CADy1Ce5b-fHNK3FELMnZtzYnQw6jwYgczVF5DUE1CPnE4EfZCg@mail.gmail.com> <20130904000959.GG19904@verio.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 3, 2013 at 5:09 PM, David DeSimone <fox@verio.net> wrote: > Kurt Buff <kurt.buff@gmail.com> wrote: >> >> Over the three-day US weekend, I was working on some stuff, and found an >> interesting set of entries in the daily security run emails all three days. >> >> The output looks as follows: >> >> ntop.example.com kernel log messages: >> >> +++ /tmp/security.IUGsscCR 2013-08-26 03:02:24.000000000 -0700 >> >> +arp: unknown hardware address format (0x4500) (from 00:05:b7:de:cd:79 to >> 72:6e:61:6c:2c:70) >> >> +arp: unknown hardware address format (0x0100) (from 00:05:b7:de:cd:79 to >> 6c:3d:31:37:2c:6e) >> >> +arp: unknown hardware address format (0x4500) (from 00:05:b7:de:cd:a3 to >> 77:72:69:74:74:65) >> >> +arp: unknown hardware address format (0x0000) (from 00:05:b7:de:cd:71 to >> 2d:0d:0a:62:6f:64) > > These are all interesting because the destination MAC address is > composed entirely of valid ASCII characters. > > 72:6e:61:6c:2c:70 = "rnal,p" > > 6c:3d:31:37:2c:6e = "l=17,n" > > 77:72:69:74:74:65 = "writte" > > 2d:0d:0a:62:6f:64 = "-\r\nbod" That is indeed interesting. >> This box is monitoring a mirror port on a procurve switch, using an >> unnumbered interface. >> >> My investigation led me to the engineering lab, and I'm querying them >> regarding the equipment, but I don't know what the above entries signal. >> Does anyone have a clue they can throw me on this? >> >> I also find it interesting that the MAC addresses are either unknown, or >> belong to Arbor Networks. We don't have any Arbor Networks equipment, >> though I suppose they could vend them to an OEM. I'm going to see if I can >> trace them down and get some idea of what's running around in that lab. > > > Is there some hardware NIC fault causing DMA from random places in > memory on these devices, or some other data leak propogating through the > stack on them? It is probably worth capturing the odd packets and > analyzing them further to see why they look the way they do. Unknown, but the units in that lab are a system/product under development, and after talking with them this afternoon, they did mention they were having some problems. I shall pass your tidbits on to them, and see if it rings a bell for them. Many thanks for the help. Kurt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADy1Ce4EnnrfU9DjneHTf1J=%2BFPD7ihQKbP3Tbf3zB3PuMHQnQ>