FreeTDS Development Group

["Craig A. Berry" <craigberry AT mac.com>]

On Oct 29, 2012, at 2:03 PM, James K. Lowden <jklowden AT freetds.org> wrote:

> Why not fix the network/whitelist/firewall?  A rational organization
> avoids work instead of creating it.  *

Bzzt.  You used "rational" and "organization" in the same sentence :-).  And 
you also assumed it's a single organization that designs the architecture of 
the network and the architecture of the services and applications.

> I see no reason to have a firewall between a TDS server and client,
> even if that client is a webserver.  I see still less reason to block
> legitimate packets from known interfaces.  Not only is extra admin work
> created, but the efficiency of the network is reduced.  

I get the feeling that internal firewalls are on the rise, especially the 
ones that do "deep packet inspection."  In other words, they do the 
equivalent of wireshark on your connection attempt in order to see if it's 
worthy of being allowed.  If it doesn't match the profile for something 
explicitly allowed by rule, the connection isn't made, even if it's on an 
allowed port.  Telnet to port 1433 tells you nothing about whether your SQL 
Server is running.  

And a successful connection from your workstation tells you nothing about why 
the user you are supporting can't connect because you are in a different zone 
from the user, and the various servers involved are in one or more different 
zones from both of you and possibly from each other.

> If the reason is "security" then the answer should explain the specific
> threat, and why ordinary routing rules are insufficient.  

I suspect there are piles of whitepapers that attempt to do just that but 
it's not something I've ever looked into. 



________________________________________
Craig A. Berry
mailto:craigberry AT mac.com

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser