Does anyone have any ideas for client / server firewall that is used to
provide security functions ?
Uh... why does your firewall solution have to be labelled "client/server?"Quote:>Does anyone have any ideas for client / server firewall that is used to
>provide security functions ?
If you're looking at a firewall, it's for a basic reason: you want to
provide some degree of connectivity from a private/secure/whatever
network to an untrusted/public/less-secure/whatever network. You'd like
your people to be able to use the resources of both networks, and the
"outside" people to only be able to use "outside" resources.
You need to determine what your needs are. Email? Usenet? ftp, telent, etc?
WWW? streaming audio/video? You need to know how much money you've got to
spend. You need to know what resources you have available. Based on that,
you can start making some intelligent decisions about the kind of solution
that's going to work best for you.
Any time someone bonehead throws you a phrase, of the buzz variety
or otherwise, while describing their product, ask yourself: "Of what
value is that feature?" You'll probably find lots of snake oil, smoke,
mirrors, and that sort of thing.
Security isn't about being client/server, object-oriented, fuzzy, visual,
real-time, multimedia, platform-independant, or any other buzzphrase you
can conjure. Security is about keeping the bad guys out of your
organization's private stuff. Don't be swayed by sales drones or
incompetant suits who insist that something that rates high on their
ding-dong scale must be a Good Thing(tm).
C Matthew Curtin [AT&T|Bell] Labs Internet Gateway Applications Group
I am in a situation which I imagine many people could be in and it seems
very disappointing to me. We have an application that uses OLE DB to
connect to SQL Server on a remote machine and we have been using TCP/IP to
do this so far. The idea is that users can use this application to connect
to the application running on a web server.
Now one of our clients want to know what ports to open in their firewall and
I thought it would just be 1433, however now I find that they would need to
open 1433 outgoing and a port range of 1024-65535 incoming! (and they where
worried about opening port 1433 because they have a local SQL Server).
The Microsoft article blames it on winsock - does anyone else think this is
missing the point? - they could have made it so you could use a fixed port
on the client, it doesn't matter what the winsock protocol says.
Anyway I suppose there is no point moaning now. Is there any way to get
around this dynamic IP range on the client?
Could we use named pipes over VPN - I am not sure what the performance
between a LAN and a web server will be over a 128 Kbs internet connection
will be like though...
If the client has to live with this situation with the firewall then can
anyone recommend the best practices for securing the firewall within these
requirements? I suppose most firewall would support only trusting
connections from the IP of the server running SQL Server, so the port range
would only need to be opened for this IP? What about IP spoofing is this
realistically a risk?
Most grateful for any advice