1

We have a small network setup on a Windows Domain. We also have a company website that has the same domain name - but is actually not in any way on the domain - it's hosted elsewhere on a cheapo website hosting solution.

So our site for example would look like: www.test123.com

and our machines are all sat on the domain test123.com

We sell a product which uses SQL Server. So most of our machines have SQL Server Express installed, with the SQL Browser service activated.

Recently the company that hosts our website started blocking some of our networks. After talking to them they have stated that these networks were port scanning the website on port 1434 - SQL Server.

Now we're fully up to date with Windows updates, and Anti virus etc as yet nothings come up. One thought crossed our minds however. Could the SQL Server Browser service be looking for SQL Server instances on port 1434, and check the WWW address for the domain name?

1 Answer 1

0

1434 UDP is the SQL Browser port, so when scanning for instances, its looking on that. 1433 is the connection port. (typically, unless dynamic).

Not knowing how your connection string is setup, your client machines could be scanning the www address.Can you provide the connection string the clients are using?

This sounds like a DNS issue, not a SQL issue.

4
  • 1
    We don't. Sql server is only on the client machines - ports closed Mar 10, 2015 at 13:13
  • The website itself is a static dumb site with no Sql server database Mar 10, 2015 at 13:15
  • 1
    My guess would be one of 2 possibilities: 1) the product has code in it (maybe for testing) that reaches out to something on test123.com and is therefore hitting the default entry externally of test123.com which is pointing to the www host. OR 2) you have an internal entry for www A record in your DNS that points to the externally hosted site and your own network is doing a scan against that host.
    – TheCleaner
    Mar 10, 2015 at 13:27
  • The cleaner turned out to be correct - The product was incorrectly configured on a laptop that moved between our different sites. It was given a SQL Instance that didn't exist, and then for reasons known only to the developers went in search of that host in the method mentioned above. Once configured correctly the program stopped reaching out. This was eventually discovered by use of an application called TCPView - which actually also monitors UDP comms, and also tells you which process generated the messages. Mar 18, 2015 at 9:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .