[Snort-users] yet another unix socket question...

Dr. Richard W. Tibbs ccamp at ...4532...
Mon Jan 14 10:40:09 EST 2002


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.
> 






More information about the Snort-users mailing list