Skip to main content
Database Administrators

Return to Answer

Specified ports in some sentences to be more specific to IP blocking by port and IP address public or private
Source Link
IT Thug Ninja
IT Thug Ninja
  • 2.3k
  • 16
  • 18

Block all IP addresses and only allowSo the private IP range which your DHCPIIS on this server givesis intended to be externally accessible from your internal machines (your development environment).

Ifdata network but the traffic is making it to SQL Server instance on this same server is not meant to allow for the failed authentication attempts, then a SQL profiler trace may show the IP fromexternal connections except for only through the failed authentication attempts I would think. Otherwiseweb interfaces of your applications, perhaps do a WireShark TCP/IP sniff and find the culprit or range brute forcing the SA.correct?

Block everything andIf so, then is not adding an explicit rule in the Windows Firewall on this server to allow only the entire internal private IP range which includes all possible possible IP addresses which could be assignedaddress ranges to your dev machine. Otherwise, setup DHCP with MAC reservationconnect via local network on SQL Server ports not acceptable? I assume you trust your dev machine to always get the same privateinternal IP addressaddresses on this port and just allow it.don't suspect those as the authentication attempts with malicious intent?

If this needs to be externally facing, only allow authentication throughAllow the web interface adding logic[localhost IP] IIS apps to not allow the brute-force type SAauthenticate to SQL (may need to check site bindings, etc. usernamesand/or setup internal DNS pointers too).

On your external side, you should only be allowing the port 80 or have a table with valid usernames and validate against that443 to port forward/NAT to the IIS server on those ports only and not all ports too it I would think -- stop at corporate firewall too I guess and only allow any that do not exist in that tablethe web app ports to even make itgo to SQL Server for authenticationthat server from the external interface with your firewall appliance proxies, etc.

Block all IP addresses and only allow the private IP range which your DHCP server gives to your internal machines (your development environment).

If the traffic is making it to SQL Server for the failed authentication attempts, then a SQL profiler trace may show the IP from the failed authentication attempts I would think. Otherwise, perhaps do a WireShark TCP/IP sniff and find the culprit or range brute forcing the SA.

Block everything and allow the entire internal private IP range which includes all possible possible IP addresses which could be assigned to your dev machine. Otherwise, setup DHCP with MAC reservation on your dev machine to always get the same private IP address and just allow it.

If this needs to be externally facing, only allow authentication through the web interface adding logic to not allow the brute-force type SA, etc. usernames, or have a table with valid usernames and validate against that and not allow any that do not exist in that table to even make it to SQL Server for authentication.

So the IIS on this server is intended to be externally accessible from your internal data network but the SQL Server instance on this same server is not meant to allow for external connections except for only through the web interfaces of your applications, correct?

If so, then is not adding an explicit rule in the Windows Firewall on this server to allow only the private IP address ranges to connect via local network on SQL Server ports not acceptable? I assume you trust your internal IP addresses on this port and don't suspect those as the authentication attempts with malicious intent?

Allow the [localhost IP] IIS apps to authenticate to SQL (may need to check site bindings, etc. and/or setup internal DNS pointers too).

On your external side, you should only be allowing the port 80 or 443 to port forward/NAT to the IIS server on those ports only and not all ports too it I would think -- stop at corporate firewall too I guess and only allow the web app ports to go to that server from the external interface with your firewall appliance proxies, etc.

Source Link
IT Thug Ninja
IT Thug Ninja
  • 2.3k
  • 16
  • 18

Block all IP addresses and only allow the private IP range which your DHCP server gives to your internal machines (your development environment).

If the traffic is making it to SQL Server for the failed authentication attempts, then a SQL profiler trace may show the IP from the failed authentication attempts I would think. Otherwise, perhaps do a WireShark TCP/IP sniff and find the culprit or range brute forcing the SA.

Block everything and allow the entire internal private IP range which includes all possible possible IP addresses which could be assigned to your dev machine. Otherwise, setup DHCP with MAC reservation on your dev machine to always get the same private IP address and just allow it.

If this needs to be externally facing, only allow authentication through the web interface adding logic to not allow the brute-force type SA, etc. usernames, or have a table with valid usernames and validate against that and not allow any that do not exist in that table to even make it to SQL Server for authentication.