Snort - ARPSpoof preprocessor signal 11



  • I seem to have the same issue as some other people before me:
    https://forum.pfsense.org/index.php?topic=55868.0
    https://forum.pfsense.org/index.php?topic=56531.msg301993#msg301993

    However, a solution was never found.

    So, first things first, I wanted to enable ARP spoof detection in Snort, so I configured the following in "Advanced Configuration Pass-Through"

    # ARP spoof detection. 
    preprocessor arpspoof
    preprocessor arpspoof_detect_host: <ip> <mac></mac></ip>
    

    This triggers snort to include the following rules in the snort.rules file:

    alert ( msg: "ARPSPOOF_UNICAST_ARP_REQUEST"; sid: 1; gid: 112; rev: 1; metadata: rule-type preproc ; classtype:protocol-command-decode; )
    alert ( msg: "ARPSPOOF_ETHERFRAME_ARP_MISMATCH_SRC"; sid: 2; gid: 112; rev: 1; metadata: rule-type preproc ; classtype:bad-unknown; )
    alert ( msg: "ARPSPOOF_ETHERFRAME_ARP_MISMATCH_DST"; sid: 3; gid: 112; rev: 1; metadata: rule-type preproc ; classtype:bad-unknown; )
    alert ( msg: "ARPSPOOF_ARP_CACHE_OVERWRITE_ATTACK"; sid: 4; gid: 112; rev: 1; metadata: rule-type preproc ; classtype:bad-unknown; )
    

    Everything fine until here, then I try to trigger the rule, which also works fine, because I get the alert in my alert log:

    08/12/17-13:59:31.049272 ,112,2,1,"(spp_arpspoof) Ethernet/ARP Mismatch request for Source",,,,,,,Potentially Bad Traffic,2,
    
    

    However, right after that moment, Snort dies on that interface, with a signal 11 as mentioned in /var/log/system.log:

    Aug 12 13:59:28 pfSense kernel: arp: <localip> moved from <mac1> to <mac2> on igb1_vlan210
    Aug 12 13:59:31 pfSense kernel: arp: <localip> moved from <mac2> to <mac1> on igb1_vlan210
    Aug 12 13:59:31 pfSense kernel: pid 68199 (snort), uid 0: exited on signal 11</mac1></mac2></localip></mac2></mac1></localip>
    

    I tried to find the cause, but the only thing that is different from a preprocessor that is working (such as a portscan rule) is to be found in the alert log:

    08/12/17-13:59:22.937775 ,122,23,1,"(portscan) UDP Filtered Portsweep",,<localip>,,<localip>,,39881,Attempted Information Leak,2,
    08/12/17-13:59:31.049272 ,112,2,1,"(spp_arpspoof) Ethernet/ARP Mismatch request for Source",,,,,,,Potentially Bad Traffic,2,</localip></localip>
    

    If I match that with the alert_csv output, then it seems that the 'ID' is missing from the arp alert:
    output alert_csv: alert timestamp,sig_generator,sig_id,sig_rev,msg,proto,src,srcport,dst,dstport,id,classification,priority 500K

    I'm guessing that this 'ID' is mandatory, and that snort crashes if the id is null? This is just a wild guess. Any thoughts on how to solve this?



  • This is probably from some patches the pfSense version of the Snort binary has for the CSV log output function.  I thought I had all of the checks for null pointers in place, but maybe I missed some.  I am not the original author of that code, but I have been trying to maintain it for a few years.  I need to look and see if the patched code is blindly trying to use any pointer before checking it for NULL.  The pointers normally point to the text strings written to the log file.  Since that preprocessor has some empty strings (as evidenced by the commas), maybe NULL pointers are tripping it up.  They can definitely cause signal 11 faults.

    Bill



  • Update

    I am looking at the source code for the custom blocking plugin.  Haven't put my finger on it yet, but I will find the bug and fix it in an upcoming Snort update.  I think this bug may be responsible for a number of "Signal 11" errors reported by various Snort users.  Also, I don't think it is limited to just the ARP spoof preprocessor.

    The problem is definitely within the patched binary code and not an issue in the GUI package itself.

    Bill



  • Hi Bill,

    Thanks for looking into this. If I can be of any help, please give a shout!



  • @mkcharlie:

    Hi Bill,

    Thanks for looking into this. If I can be of any help, please give a shout!

    I think I found and fixed the problem.  I'm testing now in my virtual machine test setup.  The original code author's patch to the CSV output plugin was a little over-coded (IMHO) for the relatively simple task it needed to.  The code just needed to add the ability to specify and print two additional fields (CLASSIFICATION and PRIORITY) via the CSV output plugin.  I greatly simplified the patch and added extra checking for NULL pointers.  Originally the NULL pointer checks were non-existent for the two added fields.  Sometime back I had added some NULL pointer checking, but failed to check deep enough.  I needed to check a couple of layers deep in a structure and was not doing so.  I think that was the root of the issue.

    I am also going to fix a few bugs in the GUI package, so while I'm at it I will add the ability to configure the ARP preprocessor to the PREPROCESSORS tab in the GUI.  That will eliminate the need to use the Advanced Pass-Through stuff.

    Bill



  • Great work! Any idea when this will become available?



  • @mkcharlie:

    Great work! Any idea when this will become available?

    UPDATE – August 21

    The bug is apparently still there for the ARP Spoof preprocessor.  Got to dig a little more to find out what's happening.  I don't think it is in the logging code after I realized it is correctly logging the event.  Must be someplace else.

    I posted the pull request last night and it was merged this morning.  Nothing will show up in the Package Manager because I have not yet bumped the version for the GUI package the Package Manager keys off of.  I am working on some GUI updates first.

    However, if you are game, you can uninstall Snort and then reinstall it on your system that was giving the Signal 11.  You should see it show on the binary package on the Package Manger tab as 2.9.9.0_2.  It will be shown in small print as one of the dependencies along with Barnyard2.  I have not checked, but I think when Renato merged the update he put it in both the 2.4-DEVEL tree and the 2.3.4-RELEASE tree.  If you don't see the 2.9.9.0_2 binary listed, send me an IM and I can show you how to find it and manually install it.

    Bill



  • OK.  Finally found the root cause of this Signal 11 bug.  It was in the custom blocking module.  The Signal 11 was actually happening when the custom blocking module attempted to block based on the alert.  For these ARP spoof alerts the IP address information is frequently missing, and thus the blocking module got tripped up trying to insert a block for a NULL address.  The fix was to have the blocking module ignore packets with no IP address data, since it can't block them anyway.

    Details on the fix can be found in this pull request:  https://github.com/pfsense/FreeBSD-ports/pull/398.  As soon as the pfSense developer team can approve and merge the request, an updated binary package will be available with version 2.9.9.0_3 as the tag.  I tested this out on a virtual machine and was able to reliably produce the Signal 11 without the patch with ARP spoofing enabled.  With the patch, I got the ARP spoof alerts but no Signal 11.

    Bill



  • That makes sense.

    I'd be happy to try it out when the update becomes available.



  • @mkcharlie:

    That makes sense.

    I'd be happy to try it out when the update becomes available.

    I was sort of hoping it might become available today, but perhaps the developer team is busy with stuff from the release of 2.4.0-RC yesterday morning.  The binary fix and a GUI package update are both posted and just waiting on their approval and merging into package repository.

    Bill



  • @mkcharlie:

    I'd be happy to try it out when the update becomes available.

    The package update was posted today.  Please check it out and see if it corrects the Signal 11 issue.  Remember to remove Snort first, then reinstall the package.  This will make sure the binary is updated as well along with the GUIcode.  There have been some problems where GUI package updates run using the "UPDATE" command on the Package Manager failed to update the underlying binary.

    Bill



  • Hi Bill,

    Everything seems to work exactly the way it should be for the moment. Thanks for taking the time to do the changes.



  • @mkcharlie:

    Hi Bill,

    Everything seems to work exactly the way it should be for the moment. Thanks for taking the time to do the changes.

    Thanks for the feedback.  Glad to have found that particular bug and the related one in the logging code that caused Snort to die when logging a rule with no CLASSTYPE defined.

    Bill


Log in to reply