Re: yet another unix socket question...

["Dr. Richard W. Tibbs" <ccamp () oakcitysolutions com>]

Yes, on further inspection, the libpcap header has the time values... 
Thanks for pointing that out, Fyodor!
alert.pkth.ts.tv_sec  & tv_usec are valid.
So that settles the time problem.

Now, one or two more if you can stand it:    ;-)

The Alertpkt structure contains the dlhdr, nethdr, and transhdr fields, 
and as I read
spo_alert_unixsock.h
these fields are called "offsets". This raises a question of interpretation.
For an ICMP packet, which uses "application over IP", the transhdr offset
includes the ip and dl packet headers, so (see data below) the actual 
payload starts at byte 46, right?

Now, the val field is 0 for my ping test. Literal interpretation of the 
comments in the Alertpkt struct definition would say that "no fields are 
valid" (?).  This is clearly not the case --- How do you interpret the 
val field?

Finally, it would appear that one more item only found in the pcap 
header is the total length "off the wire" which is
alert.pkth.len  = 98   in the case of my ping test.
So payload size is 98 -46 = 52 bytes, right?  But ping always says 
PING  ya.dd.aa.1 (ya.dd.aa.1): 56 data bytes
64 bytes from ya.dd.aa.1: icmp.....blah blah
64 bytes from ya.dd.aa.1: icmp.....blah blah
... etc.

I am currently a little unsure how to resolve these numbers -- can 
anyone help?


( assume no fragmentation here ... in which case caplen = len)

THanks >>>> RWT

Fyodor wrote:

> from libpcap header? :-) I will look into this later :-)
>
> On Mon, Jan 14, 2002 at 01:40:32PM -0500, Dr. Richard W. Tibbs wrote:
>
> > Ah, yes. If I assign cnt=recvfrom(..) I get pretty consistent byte counts.
> > Now, two more problems:
> > All of the timestamp values are 0. -- and the dlhdr length is always 0
> > I know there is a default to *not* pass on the dlhdr data, so I think I 
> > can turn it on ...
> > The timestamp, however is more mysterious.    I have run snort 'from the 
> > package' , i.e. snort -v, and I get good time values .. How come not 
> > with unixsock?
> > Running a ping, I can observe
> > the Alertpkt structure, which I can observe in the kdb debugger running 
> > my "server" program, shows good data in
> > alert.dlhdr = 0
> > alert.nethdr = 14
> > alert.transhdr = 34
> > alert.data = 46
> >
> > but,
> >
> > alert.event.ref_time.tv_sec    = 0
> > alert.event.ref_time.tv_usec = 0
> >
> > When I printf these values useing %lu format, they are also 0.
> >
> > Any idea how to get good timestamps in unixsock mode?
> >
> >
> > Fyodor wrote:
> >
> > > On Sun, Jan 13, 2002 at 07:48:40PM -0500, Dr. Richard W. Tibbs wrote:
> > >
> > > > Thanks, Fyodor.  Your code sample really helped. Things are "working", 
> > > > that is I succeed in getting the alerts via the socket. But.... some 
> > > > wierd results, all the alerts appear to be length 2 bytes.  I describe 
> > > > my approach below.
> > >
> > >
> > > len is not the length of bytes received. len is the size of struct
> > > sockaddr structure, which recvfrom filled in. if you want to see the
> > > length of bytes received, change the code like:
> > >
> > >
> > >   while ((recv = recvfrom (sockfd, (void *) &alert, sizeof (alert),
> > >                    0, (struct sockaddr *) &bogus, &len)) > 0)
> > >     {
> > >  
> > > .. 
> > > recv will have the size of Alertpkt structure. I think you may also need
> > > to do neccesary data validation after (which I omitted in my code)
> > > comparing the data from libpcap pktheader with actual datasize. Current
> > > situation is that if the packet is bigger than maximum  snaplen, then it
> > > will be truncated. (same goes with message, if it is too long, it would
> > > be truncated accordingly).
> > >
> > > > Several questions at this point:
> > > > 1) For testing the socket alert, I would like to set up snort to alert 
> > > > only pings.  (I will ping from same machine as snort is running, and 
> > > > make sure I get all the packets, etc.)
> > > > I think there must be many ways of doing this, but after reading the 
> > > > snort manual, the simplest one I come up with is:
> > > >
> > > > snort -A unsock -c snort.conf
> > > >
> > > > < where somewhere in snort.conf ...>
> > > > #################################
> > > > # Step #3 Configure output plugins...
> > > > #  (blah blah)
> > > > output alert_unixsock
> > > > alert icmp any any -> any any
> > > > <rest of snort.conf ... but all other rule files commented out >
> > > maybe also (msg:"pings"); ;-)
> > >
> > > > 2) I notice in the code sample you sent, that the variables snortaddr & 
> > > > bogus are declared sockaddr_un, but then cast to sockaddr in the bind 
> > > > and recvfrom calls. Why is this? Shouldn't it be cast to sockaddr_un? 
> > >
> > >
> > > Because bind() and recvfrom() require the cast due to their declarations.
> > >
> > >        int  bind(int  sockfd, struct sockaddr *my_addr, socklen_t
> > >        addrlen);
> > >
> > >        int  recvfrom(int  s,  void  *buf,  size_t len, int flags,
> > >        struct sockaddr *from, socklen_t *fromlen);
> > >
> > >   
> > >
> > >
> > > > (Either way, I get 2 bytes for each ping .)
> > > >
> > > > 3) Finally: Where are the various
> > > > sys/types.h
> > > > sys/socket.h ...
> > > > located in a Suse linux distrib?
> > >
> > >
> > > /usr/include/ ? ;-)
> > >
> > > > Your question 2 emails ago "..how is myaddr declared.." is a good one;
> > > > from the socket how-tos I found on google, I thought everything could 
> > > > just be "sockaddr".
> > >
> > >
> > > no, sockaddr is generic structure. General definition is that most of
> > > the socket relevant syscalls take this structure as parameter. Then they
> > > operate it according to what your socket type is. AF_INET would make
> > > sockaddr considered to be sockaddr_in, AF_UNIX, sockaddr_un, etc. That's
> > > why you still have to cast the sockaddr_* structs, so the same
> > > function/interface would be used to operate with different socket types.
> > >
> > > hope it helps.
> >
> >
> > _______________________________________________
> > Snort-users mailing list
> > Snort-users () lists sourceforge net
> > Go to this URL to change user options or unsubscribe:
> > https://lists.sourceforge.net/lists/listinfo/snort-users
> > Snort-users list archive:
> > http://www.geocrawler.com/redir-sf.php3?list=snort-users



_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users