Suricata not generating alerts for PPPOE interface



  • Why does my suricata not generate any events? It appears to be running... currently running in inline mode.

    pfsense 2.4.4
    Suricata 4.0.13_8

    igb0@pci0:1:0:0:	class=0x020000 card=0x10a78086 chip=0x10a78086 rev=0x02 hdr=0x00
        vendor     = 'Intel Corporation'
        device     = '82575EB Gigabit Network Connection'
        class      = network
        subclass   = ethernet
    igb1@pci0:1:0:1:	class=0x020000 card=0x10a78086 chip=0x10a78086 rev=0x02 hdr=0x00
        vendor     = 'Intel Corporation'
        device     = '82575EB Gigabit Network Connection'
        class      = network
        subclass   = ethernet
    re0@pci0:3:0:0:	class=0x020000 card=0x81681849 chip=0x816810ec rev=0x11 hdr=0x00
        vendor     = 'Realtek Semiconductor Co., Ltd.'
        device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
        class      = network
        subclass   = ethernet
    

    Rules enabled

    emerging-info,emerging-scan,emerging-drop,emerging-current_events,emerging-compromised,emerging-dshield,emerging-smtp
    

    ps aux

    root    44701   0.6  4.3 547420 173840  -  Ss   08:19     17:44.40 /usr/local/bin/suricata --netmap -D -c /usr/local/etc/suricata/suricata_20749_pppoe0/suricata.yaml --pidfile /var/run/suricata_pppoe020749.pid
    

    Sid_changes.log

    ********************************************************
    Starting auto SID management for WANIF
    Start Time: 2018-09-26 12:30:26
    Processing drop_sid list: dropsid.conf
        Parsed 3826 potential SIDs to match from the provided list of tokens.
        Found 3826 matching SIDs in the active rules.
        Changed action for 3826 SIDs to 'drop'.
    End Time: 2018-09-26 12:30:26
    ********************************************************
    

    Suricata.log

    26/9/2018 -- 12:30:38 - <Info> -- 2 rule files processed. 3356 rules successfully loaded, 9742 rules failed
    26/9/2018 -- 12:30:38 - <Info> -- Threshold config parsed: 0 rule(s) found
    26/9/2018 -- 12:30:38 - <Info> -- 3356 signatures processed. 54 are IP-only rules, 622 are inspecting packet payload, 2755 inspect application layer, 103 are decoder event only
    26/9/2018 -- 12:30:39 - <Info> -- cleaning up signature grouping structure... complete
    26/9/2018 -- 12:30:39 - <Notice> -- rule reload complete
    

    alerts.log is empty

    Got a whole bunch of these in dmesg every time i restart suricata, not sure if it's just warnings:

    960.438645 [ 760] generic_netmap_dtor       Restored native NA 0
    981.857122 [ 254] generic_find_num_desc     called, in tx 1024 rx 1024
    981.857134 [ 262] generic_find_num_queues   called, in txq 0 rxq 0
    981.857143 [ 760] generic_netmap_dtor       Restored native NA 0
    981.861795 [ 254] generic_find_num_desc     called, in tx 1024 rx 1024
    981.861808 [ 262] generic_find_num_queues   called, in txq 0 rxq 0
    981.861817 [ 760] generic_netmap_dtor       Restored native NA 0
    981.861846 [ 254] generic_find_num_desc     called, in tx 1024 rx 1024
    981.861854 [ 262] generic_find_num_queues   called, in txq 0 rxq 0
    


  • @logboss
    What kind of network interface card is in your box? It very well could be that your NIC hardware driver does not properly support Netmap. Many NIC drivers do not. Netmap support is required for Inline IPS Mode to operate correctly.

    If you switch to Legacy Mode blocking and restart Suricata do you get alerts then? I see you have emerging-scan enabled, so if you scan your firewall with a tool such as Kali-Linux or some of the available online web-based scanning tools, you should see some alerts then.

    You can also examine any Pass Lists you have defined. Make sure you are not whitelisting the whole world. If you use the default settings, that should not happen. With Inline IPS Mode, you should not use a Pass List at all.



  • Is there an accurate way to get the model remotely?

    I dont have any pass list.



  • @logboss
    Not sure what you mean by "model". Kali-Linux is a specialized cybersecurity Linux distro that comes with a ton of hacking tools and scanners, so if you have Suricata on your LAN interface you can simply scan the firewall's IP and generate Suricata alerts. You can easily install a Kali virtual machine in VMware or any of the other hypervisors out there.

    If you are running Suricata on the WAN (which I generally don't recommend for most users), you can use one of several web-based scanning tools to scan your firewall for open ports. That scan should trigger some Suricata alerts from the emerging-scan rules. Gibson Research is one such tool here.

    EDIT: Oh, I think I just realized what you meant with "model", you mean the model of NIC, correct? If you can establish a shell session, you can use the utilities that scan the PCI bus and report on what's there such as lspci.



  • @bmeeks Just read the netmap man page, both re and igb are supported, currently it's configured to run on my igb pppoe interface.

    igb0@pci0:1:0:0:	class=0x020000 card=0x10a78086 chip=0x10a78086 rev=0x02 hdr=0x00
        vendor     = 'Intel Corporation'
        device     = '82575EB Gigabit Network Connection'
        class      = network
        subclass   = ethernet
    igb1@pci0:1:0:1:	class=0x020000 card=0x10a78086 chip=0x10a78086 rev=0x02 hdr=0x00
        vendor     = 'Intel Corporation'
        device     = '82575EB Gigabit Network Connection'
        class      = network
        subclass   = ethernet
    


  • Have you tried a scan like I suggested? Also, convert over to Legacy Mode (on the INTERFACE SETTINGS tab for the interface) and see if you get alerts then.

    I see you are also running PPPoE (on your WAN, I presume). That is a different type of virtual interface and I'm not sure how well or if it works with Netmap. I didn't write any of the Netmap code in Suricata or FreeBSD, so I can't tell you if a PPPoE connection works or not. Everyone I know about has Inline IPS Mode running on conventional interfaces such as a DHCP setup. I do know that way back in the early days of Suricata PPPoE was not supported at all within the binary. That was eventually fixed, but I'm not sure if the fix applies to Netmap, too.



  • @bmeeks Legacy works. But according to the man page, my NIC is supported, is there a way for me to use inline?



  • @logboss
    Upon further reflection, I don't think it's your NIC driver that is the problem. Instead it is the fact you have to use PPPoE for your connectivity. That is another layer of software on top of the network connection. My suspicion is that PPPoE is not compatible with Netmap. As I mentioned, every user I know of that has success with Inline IPS Mode is using either DHCP for the interface IP or has a static IP assigned.

    I do recall that early versions of Suricata on FreeBSD did not work with PPPoE connections, not even in Legacy Mode. That did get fixed, though. The difference is Legacy Mode uses libpcap whereas Inline IPS Mode uses Netmap. Those two are quite different.

    I just found this thread on the Suricata Redmine bug reporting site: https://redmine.openinfosecfoundation.org/issues/1925

    That bug report was closed by the Suricata team because the original poster never responded. It very well could be the bug still exists in FreeBSD. That bug report was opened originally by one of the developers for OpnSense, which is a fork of the older version of pfSense. Since they never responded to the Suricata team's request for further info, I don't know if the OpnSense crew solved it internally or if it fell through the cracks.



  • I've done a bit more research into this and it seems to be the case that PPPoE and FreeBSD and Suricata never have really been a great combo. PCAP operation was fixed back in version 2.1, but Netmap operation has never been fixed for PPPoE interfaces. So if you have a PPPoE connection on the interface where you run Suricata in Inline IPS Mode (which uses Netmap), then you won't get any alerts. So essentially that means Suricata is not inspecting and alerting on traffic transiting a PPPoE interface when using Inline IPS Mode.

    Fixing this will be a challenge because not very many folks have PPPoE connections, and even fewer software developers have such connections available for testing. I certainly do not have any way to test and debug with a PPPoE connection. The issue appears to be specific to Netmap and FreeBSD.

    So users experiencing this issue have two potential solutions. First, move your Suricata monitoring to an interface that does not use PPPoE such as your LAN. Avoid the WAN if that connection uses PPPoE. The second solution is to switch to Legacy Mode operation. That will use PCAP which has been patched to work with PPPoE on FreeBSD. Of course Legacy Mode is not a true Inline IPS.


  • Rebel Alliance Developer Netgate

    @bmeeks said in Suricata not generating alerts:

    Fixing this will be a challenge because not very many folks have PPPoE connections, and even fewer software developers have such connections available for testing. I certainly do not have any way to test and debug with a PPPoE connection. The issue appears to be specific to Netmap and FreeBSD.

    pfSense has a PPPoE server, and you can connect a pfSense PPPoE client WAN to that if it's running on a separate box. So if you can setup a test lab to use that, it can work. That's how we test most PPPoE issues here.

    Client pfSense w/PPPoE WAN -> PPPoE Server on another pfSense Instance -> WAN/external net/etc.

    Just requires an extra VM/test box in between or to be setup on the edge of your lab. I can provide more detail for you if it would help.



  • @jimp
    Thanks Jim! I guess I could configure a pair of virtual machines in VMware Workstation to handle that, but my next stumbling block is going to be my somewhat limited FreeBSD kernel programming experience. I am not familiar with how Netmap is implemented in FreeBSD other than it is a kernel compile-time option that can be enabled. Beyond that I don't know the details of how it is plumbed up.

    If you follow my link up above to the Suricata Redmine site you will see a pair of links to two OpnSense forum discussion threads on the issue. They don't have a fix over there either. Their suggested workaround is to move Suricata to a non-PPPoE interface, too.

    If the Netgate/pfSense team has some contacts with the FreeBSD folks responsible for Netmap, maybe those developers would have some theories ???

    I may try setting up a pair of virtual machines just to see about getting PPPoE itself working. After that I can play around with debugging a bit.



  • Is there anyway i can get around this? I need netmap. I've got a spare ethernet port, can i use 1 interface for PPPOE, DMZ an interface and put everything behind that?

    Something else?



  • @logboss said in Suricata not generating alerts for PPPOE interface:

    Is there anyway i can get around this? I need netmap. I've got a spare ethernet port, can i use 1 interface for PPPOE, DMZ an interface and put everything behind that?

    Something else?

    I suggest running Suricata on your LAN interface and not on the WAN interface (which I assume is the one using PPPoE). In the vast majority of situations, running the IDS/IPS on the LAN is actually better because that way all the IP addresses you see in alerts have already been NAT translated back to their actual LAN IP address space. This is useful when you are using NAT, which most folks do. The only time running Suricata on the WAN might be useful is if you have several open ports on the Internet-facing side. Again, most folks do not have open ports on their WAN. So running Suricata on the WAN provides no meaningful extra security.

    So in your case I recommend moving your Suricata instance over to your LAN interface and any other local interface like a DMZ and abandon running it on the WAN.