Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

Stealth mode and 'connection opened' in NSA 3600 event logs

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
Reply

Answers

  • TKWITSTKWITS Community Legend ✭✭✭✭✭

    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.

  • SaravananSaravanan Moderator

    Hi @DALEWEST,

    Thank you for visiting SonicWall Community.

    Your understanding with Stealth Mode is right. Let me try to understand your firewall config.

    • Which direction traffic are we talking about here? LAN to WAN or vice versa?
    • Do you have appropriate access rules defined on the SonicWall to deny the traffic?
    • Could you please check the Connections Monitor page on the SonicWall and filter the page with corresponding IP address(es) and see if there is actually a connection opened by SonicWall?
    • We may need to perform a packet capture on the SonicWall based on the IP address or port number in question and see the packet status on the SonicWall.

    Let me know how it goes.

    Regards

    Saravanan V

    Technical Support Advisor - Premier Services

    Professional Services

  • DaleWestDaleWest Newbie ✭

    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.

  • DaleWestDaleWest Newbie ✭

    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.

  • SaravananSaravanan Moderator

    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

  • DaleWestDaleWest Newbie ✭

    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?

  • SaravananSaravanan Moderator

    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

  • DaleWestDaleWest Newbie ✭

    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?

  • SaravananSaravanan Moderator

    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

  • CheesemanCheeseman Newbie ✭

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

Sign In or Register to comment.