How to access the queue of incoming packets (Snort and libpcap)... - Networking

This is a discussion on How to access the queue of incoming packets (Snort and libpcap)... - Networking ; 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/f...me=snort-devel ). I ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: How to access the queue of incoming packets (Snort and libpcap)...

  1. How to access the queue of incoming packets (Snort and libpcap)...

    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/f...me=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

  2. Re: How to access the queue of incoming packets (Snort andlibpcap)...

    On May 27, 1:20*am, Alexander Mahone
    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

  3. Re: How to access the queue of incoming packets (Snort andlibpcap)...

    On May 27, 11:15 am, David Schwartz wrote:
    > On May 27, 1:20 am, Alexander Mahone
    > 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.

  4. Re: How to access the queue of incoming packets (Snort andlibpcap)...

    On May 27, 3:04*am, Alexander Mahone
    wrote:

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


    I think you have the wrong fix. The correct fix is to allow the timers
    to fire but do not issue the alerts until you've confirmed them. You
    need a queue of alerts and you need to check to see if a current
    packet "revokes" a queued alert. It's much easier to predict the past
    than the future.

    DS

  5. Re: How to access the queue of incoming packets (Snort andlibpcap)...

    On 27 Mag, 14:11, David Schwartz wrote:
    > On May 27, 3:04 am, Alexander Mahone
    > wrote:
    >
    > > 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.

    >
    > I think you have the wrong fix. The correct fix is to allow the timers
    > to fire but do not issue the alerts until you've confirmed them. You
    > need a queue of alerts and you need to check to see if a current
    > packet "revokes" a queued alert. It's much easier to predict the past
    > than the future.
    >
    > DS


    OK, that's an idea, but is it possible to do also as I said?
    Even with your solution, sooner of later the pending alerts are to be
    printed, that is, they have to be fired, if for example no traffic is
    present on the network, otherwise there would be false
    negatives...They can't wait indefinitely for some packet to unmark
    them, but this leads in turn to possible false positives, because
    there could be this scenario:
    - There is an alarm pending, a packet for its traffic pattern has
    arrived in time, but for some reason it takes too much time to get in
    front of the queue and be processed by the Snort's callback function,
    which in your opinion should invalidate the alarm...So the alarm fires
    (I repeat, even if I don't fire them as soon as their alarms tick,
    there must be a maximum time after which they are fired no matter
    what, otherwise missing traffic would never be reported, and we would
    have false negatives...)

  6. Re: How to access the queue of incoming packets (Snort andlibpcap)...

    On May 27, 5:46*am, Alexander Mahone
    wrote:

    > OK, that's an idea, but is it possible to do also as I said?


    No. That would require predicting the future. The system cannot
    process the packets before it processes them.

    > Even with your solution, sooner of later the pending alerts are to be
    > printed, that is, they have to be fired, if for example no traffic is
    > present on the network, otherwise there would be false
    > negatives...They can't wait indefinitely for some packet to unmark
    > them, but this leads in turn to possible false positives, because
    > there could be this scenario:
    > *- There is an alarm pending, a packet for its traffic pattern has
    > arrived in time, but for some reason it takes too much time to get in
    > front of the queue and be processed by the Snort's callback function,
    > which in your opinion should invalidate the alarm...So the alarm fires
    > (I repeat, even if I don't fire them as soon as their alarms tick,
    > there must be a maximum time after which they are fired no matter
    > what, otherwise missing traffic would never be reported, and we would
    > have false negatives...)


    There are many ways you could solve this. For example, you could send
    yourself a 'timestamp' packet. When you got that packet, you would
    know that any packet that arrived before you sent that packet had
    already been processed. That would mean you could safely flush all
    alarms that fired before that packet.

    You could also flush alarms only when the queue was empty. I'm not
    sure if you can get the information easily, but somewhere Snort knows
    that it's waiting for packets rather than processing them.

    DS

+ Reply to Thread