2

We occasionally get following email alerts.

DESCRIPTION: The login packet used to open the connection is structurally invalid; the connection has been closed. Please contact the vendor of the client library.

DESCRIPTION: Length specified in network packet payload did not match number of bytes read; the connection has been closed. Please contact the vendor of the client library.

I tried to search online. But I haven’t got any good direction about how exactly I should proceed to troubleshoot these alerts. Should I contact application team to check buggy code or security team to check any malicious activity in this case? Appreciate your guidance.

0

3 Answers 3

1

This could be due to ports scanning, contact your network team they must be performing port scanning during non peak hours. I experienced the same later network team confirm about this scanning.

1
  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Apr 21 at 10:12
5

Check the SQL Server error log and you will find a corresponding log message that includes the IP address of the originating system. This will be the most important clue to investigating what is causing this.

It is most likely that this is being caused by security software that is scanning/probing your server for vulnerabilities. If you find that is not the case, then it is either something that is accidentally or maliciously attempting to make a connection to whatever port SQL Server is listening on.

2
  • How do we exclude our vulnerability scanner IP from prompting these alerts?
    – Scott
    Commented Jul 8, 2019 at 18:50
  • @Scott The native SQL Server alerts don't have functionality to create exclusions. You might be able to create a rule in Outlook to delete them if that will suffice. Otherwise you'll need a third-party or custom solution instead of the built-in SQL Server alerts. I have not investigated this so I'm not confident that such a feature exists in any of the third party tools that are available. Another option would be to have the alert execute a job instead of sending an email. The job would then read the log messages and send email if necessary. Commented Jul 8, 2019 at 19:49
2

We were encountering this issue too and made some discoveries that we hope will help. If you want to avoid getting spammed with “Severity 20” alert email notifications, often due to vulnerability scans from applications like Nessus, there are a couple things you can do:

  1. In SSMS > SQL Server Agent > Alerts > find and right-click the “Severity 20” alert > Properties > Response, and instead of “Notify operators”, you can select “Execute job” and write a custom job leveraging the variables passed from the alert to the job using Tokens.

  2. Or you can forget all that business, and simply capture and squash the specific error notifications by implementing a New Alert for that specific error number without enabling “Notify operators” in that same Response section:

USE [msdb]
GO


EXEC msdb.dbo.sp_add_alert @name=N'Error Number 17836', 
        @message_id=17836, 
        @severity=0, 
        @enabled=1, 
        @delay_between_responses=0, 
        @include_event_description_in=0, 
        @category_name=N'[Uncategorized]', 
        @job_id=N'00000000-0000-0000-0000-000000000000'
GO

It seems the logic is that when an error occurs, the agent first looks for any alerts by the error number. If none, it will then look by severity. I haven’t researched the exact logic on this so please don’t quote me on it, but this seems to be how it behaves.

The error #’s that most often occur during these scans are 17810, 17832, and 17836. So you’d need make a separate New Alert for each one that you want to squash.

Although rare, please be warned that these errors can occur in the event that your server is actually under attack, so monitor your logs (they still get logged even though the alert is squashed) or maybe have it execute a job if it occurs “n” times in a short period. Simply put, use at your own discretion.

HTH

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.