Device Reboot, Not a Kernel Panic

[beachbum2021]

Is there a more detailed report for sudden unscheduled reboots on a SG-3100? I had a random reboot occur and am not getting much detail from the SysLog. I am wondering if there is a DDos attack? I am flooded with these suricata alerts. The Ip traces back to a African ISP.

[kiokoman]

Source: whois.arin.net
IP Address: 154.21.21.141
Name: COGENT-154-21-16
Handle: NET-154-21-0-0-1
Registration Date: 05/02/92
Range: 154.21.0.0-154.21.255.255
Org: PSINet, Inc.Org Handle: PSI-2Address: 2450 N Street NW
City: Washington
State/Province: DC
Postal Code: 20037
Country: United States

not from Africa at least, port 0, it's probably some misconfiguration on his side
I saw it once from an IP trying to connect to my NTP server with port 0, it stopped after a few days
anyway I don't think this is the reason for your reboot

[beachbum2021]

@kiokoman roger that, thanks for clarifying the source for me. It has finally ended. Sifting through the logs now. If I have anymore random reboots I'll check my M.2 Drive for issues.

[Gertjan]

@beachbum2021 : suricata was analysing traffic on LAN or is it reporting traffic from WAN ?

[beachbum2021]

@Gertjan thanks for responding, suricata only run on LAN/OPT1 which are both internal. It is also not actively blocking at this time as I fine tune the rules.

[bmeeks]

@beachbum2021 said in Device Reboot, Not a Kernel Panic:

@Gertjan thanks for responding, suricata only run on LAN/OPT1 which are both internal. It is also not actively blocking at this time as I fine tune the rules.

How is that 154.21.21.141 IP address being seen on your LAN interface? With most accepted WAN configurations, it should have never gotten through the WAN to show up on the LAN. In other words, most folks have a "deny all" inbound rule on the WAN. So that means nothing from the WAN gets through to any internal interface unless an internal host initiated the conversation and established a stateful connection with an external host.

So if Suricata actually saw that traffic on your LAN, then I would be very worried unless you purposefully have a rule on your WAN allowing that traffic inbound.

[Gertjan]

@bmeeks : +1

[beachbum2021]

@bmeeks this is a good point, I will review my rules again to make sure I haven't inadvertently opened a security vulnerability. I haven't had any random reboots since the posting or suricata alerts other than spam internal traffic

[johnpoz]

Also there is a port 0 block, high up in the rules.. That you wouldn't be able to remove without considerable effort..

block drop quick inet proto tcp from any port = 0 to any label "Block traffic from port 0"
block drop quick inet proto udp from any port = 0 to any label "Block traffic from port 0"
block drop quick inet proto tcp from any to any port = 0 label "Block traffic to port 0"
block drop quick inet proto udp from any to any port = 0 label "Block traffic to port 0"
block drop quick inet6 proto tcp from any port = 0 to any label "Block traffic from port 0"
block drop quick inet6 proto udp from any port = 0 to any label "Block traffic from port 0"
block drop quick inet6 proto tcp from any to any port = 0 label "Block traffic to port 0"
block drop quick inet6 proto udp from any to any port = 0 label "Block traffic to port 0"

[beachbum2021]

@johnpoz current rules

[johnpoz]

Those are the rules pfsense shows you, there are quite a few hidden rules.

If you want to see the full rule set

pfctl -sr
https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html

[beachbum2021]

@johnpoz i wasnt aware of this, i will open a shell and verify. TYVM

[johnpoz]

I love the comment when you look at
/tmp/rules.debug

Above those rules ;)

# We use the mighty pf, we cannot be fooled.

[beachbum2021]

@johnpoz unable to post in text as the site is saying it's spam but i believe these were the rules you were refering to.

[bmeeks]

I am beginning to suspect that maybe Suricata is actually on your WAN interface and not your LAN (or else it is on both). Suricata lives between the NIC and the kernel network stack, so when on the WAN it will see traffic before firewall rules have been applied.

However, seeing WAN traffic with a destination of one of your internal RFC1918 IP addresses is weird.

Do you, or did you, by chance have a misconfigured device on your LAN? That would explain this traffic. Because if that device had the 154.21.21.141 IP, it would have sent its traffic to the gateway (pfSense) in order to reach your internal 192.168.1.103 host. Again, on the LAN Suricata would see the traffic before the firewall rules would (for inbound traffic on that interface).

[beachbum2021]

i cant speak for what may have been misconfigured at the time of posting but it's possible I had accidently enabled it at that time but at this moment it's only enabled on the LAN and OPT1 which are both internal. Is it possible that the firewall had crashed before the reboot and logged some free flowing traffic?

[bmeeks]

@beachbum2021 said in Device Reboot, Not a Kernel Panic:

i cant speak for what may have been misconfigured at the time of posting but it's possible I had accidently enabled it at that time but at this moment it's only enabled on the LAN and OPT1 which are both internal. Is it possible that the firewall had crashed before the reboot and logged some free flowing traffic?

It's just really weird for the traffic to have that 192.168.1.103 address as the destination if the capture was directly off the NIC (which is the way Suricata would have gotten it on the WAN interface by way of libpcap). Traffic on the WAN should normally have the public IP of your firewall as the destination (for most users with NAT).

[beachbum2021]

@bmeeks im with you, i think the IP spam and the reboot are not related and there may have been a temporary misconfiguration. The M.2 drive I installed two weeks ago could have faulted and it's just a coincidences both of these anomalies occurred at the same time. I'm not sure there's much that can be done at this point unless the issue returns in the same facet.