various ports on seemingly random computers. SQL Profiler and Enterprise Man
ager do not show logins or processes that correspond to this activity. Howev
er Task Manager does show increased memory and CPU time for sqlservr.exe As
time goes on the number of netstat connections increases until I reboot the
server.
I have SP3 and also disable Port 1434.
I don't know if this is related but if I Stop and then Start MSSQLSERVER Ser
vice, then SQL doesn't seem to work until I reboot the Server.
Does anyone know what is causing these network connections? I plan to use IP
SEC to filter certain IPs and Ports to reduce this but I would like to under
stand the problem better before I try to solve it.Netstat should show you only valid IP addresses connected to 1433 on your
server.
You can use PortQuery or Port reporter to validate this as well.
832919 New features and functionality in PortQry version 2.0
http://support.microsoft.com/?id=832919
Is SQL Server behind a firewall?
Are you using Standard SQL Security ?
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Kevin,
Thanks for your response.
Downloaded Port Reporter. It stated that the server did not provide process
mapping. Downloaded TCPView.
At the time I ran TCPView, instead of the usual connections on port 1433, t
here were many (about 25) established connections on port 1025, some from IP
addresses on the server that should not be establishing connections. All of
these were associated with msdtc.exe. I killed a couple of these processes.
When I killed the 2nd all the remaining disappeared. What does this indicat
e?
When I have observed many connections on port 1433 the state is usually WAIT
_STATE or FIN_2 something.
The server is a leased server at an ISP (Interland) that I administer remote
ly via Terminal Services. There are 2 NICs: 1 to their LAN and 1 to the Inte
rnet.
For firewall I hoped to use IPSEC. I assume that 'Standard SQL Security' mea
ns the same to you as to me (passwords, limit user capabilities) and the ans
wer is Yes.
If the connection state is not "ESTABLISHED' does that mean that other devic
es are attempting to connect unsuccessfully? Could these be port scanner vir
uses or similar?
The msdtc.exe ESTABLISHED connections caused me more concern. Does that mean
my server and another device were 'handshaking' or exchanging data?
Mike
quote:|||Previous posting:
Originally posted by Kevin McDonnell [MSFT]
Netstat should show you only valid IP addresses connected to 1433 on your
server.
You can use PortQuery or Port reporter to validate this as well.
832919 New features and functionality in PortQry version 2.0
http://support.microsoft.com/?id=832919
Is SQL Server behind a firewall?
Are you using Standard SQL Security ?
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
At the time I ran TCPView, instead of the usual connections on port
1433, there were many (about 25) established connections on port 1025,
some from IP addresses on the server that should not be establishing
connections. All of these were associated with msdtc.exe. I killed a
couple of these processes. When I killed the 2nd all the remaining
disappeared. What does this indicate?
*** MSDTC is used for Distributed Transactions. If the IP address is not
from a machine
that you "Trust" , then this machine should be blocked.
When I have observed many connections on port 1433 the state is usually
WAIT_STATE or FIN_2 something.
*** TCP sessions have various states. FIN, TIME_WAIT are all valid states.
See:
137984 TCP Connection States and Netstat Output
http://support.microsoft.com/?id=137984
The server is a leased server at an ISP (Interland) that I administer
remotely via Terminal Services. There are 2 NICs: 1 to their LAN and 1
to the Internet.
*** Your provider should also have Firewall to prevent machines
from establishing connections. If they don't you should seriously consider
Publishing SQL from ISA Server.
For firewall I hoped to use IPSEC. I assume that 'Standard SQL
Security' means the same to you as to me (passwords, limit user
capabilities) and the answer is Yes.
*** If you only have certain valid clients that should be connecting to
your SQL Server
accross the internet, then IPSEc or a VPN could be used. Otherwise, since
your server
is open and using Standard Security, you'll be open to password guessing
attacks.
If the connection state is not "ESTABLISHED' does that mean that other
devices are attempting to connect unsuccessfully? Could these be port
scanner viruses or similar?
*** See TCP Connection States kb.
The msdtc.exe ESTABLISHED connections caused me more concern. Does that
mean my server and another device were 'handshaking' or exchanging
data?
*** If your SQL Server is not using Distributed Transactions, Stop the
MSDTC Server Service.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Kevin,
Thanks for your help.
Since I stopped the MSDTC Server Service the spurious connections on Port 14
33 and 1025 have not reoccurred. I still have some on Port 21 that look like
viruses trying to find an FTP connection. I'll use IPSEC to filter those.
Mikesql
