On May 27, 11:15 am, David Schwartz <dav...@webmaster.com> wrote:
> On May 27, 1:20 am, Alexander Mahone <salvodanilogiuffr...@gmail.com>
> wrote:
>
> > Hello, I'm writing a Snort preprocessor, that needs to access the
> > queue of packets who have arrived up until a certain moment of time
> > (you can find some posts about it in the snort-devel mailing list -http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel).
> > I tried to find some function to do this in the libpcap library, but I
> > haven't found anything. Is there any way to do this at the OS (Linux)
> > level?
> > Thanks a lot
>
> I think what you're attempting to do is impossible in principle. The
> system cannot know what's going to happen when it goes to process
> packet X until it goes to process packet X. It can't provide you some
> sort of prognostication of what the future state is going to be like.
>
> For example, suppose the network card has packets X, Y, and Z in its
> receive queue. Assume further that some processing entity ahead of you
> is going to see packet Y (at processing time) and, on the basis of Y
> adjust its internal state, such that when it sees Z, it will modify it
> before you see it, turning it into Z'. How can the system know what
> packet Z' is going to look like until after packet Y is processed?
>
> Until it finishes processing packet Y, it has no idea what packet Z is
> going to look like by the time it gets to your module. So now, before
> X has been processed, it has no way to show you Z'.
>
> In other words, the system has no way to know what your view of a
> packet when it processes it should be until it processes it. If you
> were permitted to "peek into the future" (and every other module were
> too), chaos would result and there would be no guarantee the system
> could ever settle on what packets to present.
>
> For example, suppose there are two packets in the queue, X and Y.
> Suppose two modules each "peek at Y" while processing X. What happens
> if one module, seeing Y, wants to turn X into X', but the other
> module, seeing X', wants to drop Y?!
>
> You are asking for the ability to go back in time, after seeing packet
> Y, you want to change packet X. Well, what if you shoot your
> grandfather?
>
> What are you really trying to do? What's your outer problem?
>
> DS
Hello,
what I want to do is this: I create one or more timers (with the
function timer_create()), that every x seconds (x is configured, and
can be different for every timer, I won't explain how I initialize
every timer differently, I don't think it's important) print a message
saying that "In the last x seconds no packet from x.y.z.k ti a.b.c.d
has passed on the network", where also the addresses are different for
each timer (that is, each timer alerts of the absence of a different
pattern of traffic). This, unless a packet from x.y.z.k to a.b.c.d
doesn't actually travel on the network al least every x seconds, in
that case the timer is resetted to rearm in the next x seconds, no
message is printed on the console, and so on (every time a packet
arrives, the corresponding timer which is controlling that pattern of
traffic is resetted to tick after the next x seconds. You can
understand that if there's a continuous stream of packets for a
certain pattern the timer will never ticks, because it will always be
rearmed in time before expiration).
The problem I have is that sometimes, expecially when the timer must
'tick' every 1 second (but I guess it depends on the hardware's speed,
and on the fact that I'm running inside a virtualized Ubuntu guest
with Sun xVM VirtualBox), false positives are printed on the screen,
that is, for example the timer is going to tick in 0.1 seconds, a
packet for its pattern arrives, but by the time it arrives, and the
function that should reset its timer (a callback function that Snort
calls every time a packet is read by libpcap, no matter what is its
source or destination; inside it, a read the source and destination
address, and look in a linked list, but I plan to switch to a perfect
hashed hash table, if there's a timer which is checking the absence of
this pattern of traffic) is able to do this, the timer has already
ticked.
What I plan to do to fix this is shifting the logic of suppressing the
alerts from the callback function to the timers, by making them check,
before printing the alert message, if in the incoming packets queue
there's a packet that refers to its traffic pattern, and in this case
make it don't print the message, because it means that a packet has
arrived before the timer ticked (I'd check also the timestamp of
course, just to be more sure).
The whole idea of this preprocessor is to add to Snort the
functionality to not only look for malicious traffic, but also for the
absence of 'required' traffic, that is, traffic that if not present on
the network might be a sign of a DOS, or even simply of an hardware/
software malfunctioning.
Similar Threads
Linear Mode
