Blocking TCP Port 1433?
-
What I know about TCP/IP could be slotted in between the gaps within a piece of neutron matter so please bear with me if I am asking stupid questions.
For security reasons our network admins want to change the default port from 1433 to something else. I know that port 21 is typically for FTP, 80 is for HTTP, 443 is for HTTPS
Are there any recommendations for which ports to use for SQL Server?
Would I be correct in thinking that it shouldn't be any in this following list?
What exactly is a UDP port and how does it differ from a TCP/IP port?
Are there any rules that apply to this?
-
Use a high number port, above 1024. Stay away from the common ports, like the list you've included. When we assign ports for apps, we break out dice. Yup, Dungeons and Dragons type ten-siders and roll so that the results are completely random.
TCP = Transmission Control Protocol. This is a stateful, session-oriented protocol. Communications with SQL Server occur over TCP. There is a handshake to begin communications, etc. Think of this like a telephone conversation. SQL Server listens by default on TCP port 1433.
UDP = User Datagram Protocol. This is a stateless, non session-oriented protocol. Basically "fire and forget." Clients use this to talk to the SQL Server listener service (UDP port 1434) to get back information on named instances and the ports they are listening on. Think of this like a postcard. No guarantee of a return communications. No assurance that the message actually got through.
TCP and UDP are both protocols within the larger TCP/IP suite.
K. Brian Kelley
@kbriankelley -
Changing the default SQL Server port (1433) will require that all applications that access the server have their connection properties changed to <Server name or instance name or IP address>,<custom port number>.
Andy
-
This KB article lists the well known port numbers you should avoid:
http://support.microsoft.com/default.aspx?scid=kb;en-us;174904
You'll probably want to verify the port number you choose with your data security department since there is a range that is frequently used by trojans. I don't recall what they are. You might consider using named instances with a different static port per server varying the last two digits from 1 to 99. Have your developers specify the the hostname.domain.com,portnumber i.e. myserver.mydomain.com,XXXX this way you can block the locator service running on port 1434 (the same port SQL Slammer attacked in 2003). This does complicate firewalls rules a little. Keep in mind not all 3rd party products support named instances. Sometimes you can get around this limitation by setting up a SQL client alias (run cliconfg).
-
Why not ask your firewall admins what port they would prefer you to use for the TCP connection? That will keep you on their good side as you are including them in the decision. Plus, you won't be 'grabbing' a port that is being used for something else.
-SQLBill
-
Aw, come on SQLBill, that makes too much sense!
K. Brian Kelley
@kbriankelley -
The firewall admins asked me what I would recommend.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply