Stealth mode and 'connection opened' in NSA 3600 event logs
DaleWest
Newbie ✭
Greetings-
I have stealth mode turned on by default, such that any connection attempt to a port that is not explicitly allowed is dropped, with no response sent to the initiating system. I've tested this via various means.
Problem is, when looking at my event logs, these connection attempts are logged as 'Connection Opened', which suggests that the system actually did allow the connection.
This makes accurate analysis of what my firewall is and is not allowing through exceedingly difficult.
Any thoughts/suggestions?
Category: Mid Range Firewalls
0
Answers
IME 'connection opened' simply indicates a connection was attempted, not that it was allowed. 'connection established' would be a completed connection handshake, thus indicating it was allowed. I do not know if that is how the log reports it though, maybe @shiprasahu93 or @Saravanan can clarify.
Hi @DALEWEST,
Thank you for visiting SonicWall Community.
Your understanding with Stealth Mode is right. Let me try to understand your firewall config.
Let me know how it goes.
Regards
Saravanan V
Technical Support Advisor - Premier Services
Professional Services
Hi @Saravanan... thanks for getting back.
So, to be clear, the issue I'm having is with the _logging_, in that the logs seem to indicate that a connection was allowed ("Connection opened") when in _fact_ I know that it was dropped. In this case I'm only talking about inbound connections (WAN to LAN). In addition to Stealth Mode, I also have a 'drop' rule with some specific IP addresses that I use for testing. As above, the connections from those IP addresses were indeed dropped (not denied), but they were logged as "Connection opened". Here's an obfuscated sample:
id=FirewallName sn=123456789101 time="2021-07-06 08:20:15" fw=n.n.n.n pri=1 c=262144 gcat=6 m=98 msg="Connection Opened" src= x.x.x.x:55829:X1 dst=n.n.n.n:1047:X1 proto=tcp/1047 sent=46 n=769272991 fw_action="NA" dpi=0
This is important because analyzing the logs is the only feasible way I have to determine if traffic was allowed into my network. But the logs make it look like pretty much everything is getting in.
So, @Saravanan... any further thoughts or input from your colleagues? This issue is really keeping me from knowing just what is and is not getting into my network.
Hi @DALEWEST,
I see what you are telling. Could you please check the Connections Monitor section on the SonicWall GUI and see if the IP addresses are listed there with some Tx and Rx bytes?
Regards
Saravanan V
Technical Support Advisor - Premier Services
Professional Services
Hi @Saravanan; thanks for getting back to me.
So, the plot thickens somewhat. First, a quick background: one of my SIEM tools parses out my Sonicwall logs and corelates the connecting IP addresses with known malicious IPs, and produces a "top 10" report of inbound connections from those malicious IPs, based on the number of connections. This tool is how I ran across this weird logging issue.
On a weekly basis, I take the 'top 10' list of IPs from the tool and aggregate them into a growing text list of malicious IP addresses (26 so far). This list is then automatically FTP'd into a DEAG group on my Sonicwall via the Dynamic External Objects feature. This group is listed in an Access Rule that is configured to drop packets.
Now, back to the thickened plot: I parsed out the IPs in the Connection Logs as you suggested, and used Excel to see if there were any matches between the source IPs in the Connection Logs and the IPs in my DEAG group... and found a match for one of the IPs.
I found that this particular IP address connects to one of my FTP servers over port 22, but only three packets are exchanged.
So, here's the plot: my Drop access rule has a higher priority (19) than the one that allows inbound connections to that FTP server (25). That connection should be dropped, and not allowed.
So... what now?
Hi @DALEWEST,
I think we'll have to go through the report produced by the tool and how it works what info SonicWall provides to the tool. It would be better to get this verified over a remote session. I would recommend you to approach our support team for further assistance on this.
Regards
Saravanan V
Technical Support Advisor - Premier Services
Professional Services
Hi @Saravanan; thanks again for your attention.
However, while I'm not against getting Support involved, I think I may have muddied the waters when talking about my SIEM tool. I only mentioned it because it is what enabled me to discover the problem with how my Sonicwall is logging events.
So, in summary, I have two issues: 1) the device logging dropped connections as "Connection Opened", and now 2) the device allowing a connection despite the connecting IP being listed in a Drop rule that has higher priority than the one allowing connections to a service.
Can we still work on these here, or do I need to open separate Support tickets?
Yes @DALEWEST. I agree to your points. What I feel is, we have to troubleshoot on the SonicWall appliance to cross verify and fix these two scenarios reported by you. So, a remote session is required to identify the root cause. Hence I request you to contact our support team and take assistance on this.
Hope this clarifies.
Regards
Saravanan V
Technical Support Advisor - Premier Services
Professional Services
@DaleWest What was the result of the support session? Were the connections dropped on 'Connection Opened' or were they making it through?
I've posted a similar question.
https://community.sonicwall.com/technology-and-support/discussion/2805/false-positive-or-not-nsa2650-and-rapid7-siem
Greetings... I wish I had an update, but I haven't been able to circle back to this issue yet (as frustrating as it is). I'm pretty sure they're not making it through, because my Symantec clients aren't logging them.