Terminal Server: Enough included w/MSDN?

[(Pete Cresswell)]

I'd like to dabble in Terminal Server enough to see if I can get some of my MS
Access apps to run through it.

I've got the MSDN subscription. Is there enough there for a real-world
implementation?
--
PeteCresswell

[david epsom dot com dot au]

Note: you can change the port. 1433 is just the default value.
1433 is fine if you WANT everybody to be able to assume the default
value.

(david)

"Trevor Best" <nospam@localho st> wrote in message
news:40******** **************@ auth.uk.news.ea synet.net...

PeteCresswell wrote:

Besides which, the last thing you want is port 1433 open to all and
sundry. If it's open on the net, it's not a matter of if, it *will* be
hacked.

I don't even know what port 1433 is.... but could it be open by
default on a PC that's running SQL Server/Developer? The PC that has
that on it seems to attract a steady stream of SQL Server Worm
Propogation attempts.

Port 1433 is what SQL server uses so yes. I trust your PC is firewalled?

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[David W. Fenton]

"(Pete Cresswell)" <x@y.z> wrote in
news:8j******** *************** *********@4ax.c om:

RE/

Your firewall doesn't block port 1433 at the network boundary?

Dunno if it blocks it or where, but it does appear to catch a lot
of what it calls W32_SQLEXP_Worm _Propogation.

Norton Personal Firewall.

The default state for any firewall should be 100% of incoming ports
closed. Then you may need to open up a few for specific tasks.

If you have a proper software firewall you can control who can
connect. For SQL Server, you could limit it to your local LAN's IP
address space, and then external machines wouldn't be able to
connect.

Of course, if the worm connection is coming from a machine on your
LAN, that won't get you anything.

Another thing to do is to use a non-standard port for SQL Server.
You'll have to specify it in your connection strings, but that
shouldn't be that big of a deal.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"Rick Brandt" <ri*********@ho tmail.com> wrote in
news:2m******** ****@uni-berlin.de:

"Tony Toews" <tt****@teluspl anet.net> wrote in message
news:cg******** *************** *********@4ax.c om...

Trevor Best <nospam@localho st> wrote:

>> And, yes, guys, I know that I could connect to my
>> SQL Server instance over port 1433 and don't need Terminal
>> Services but I am >> a poor Access developer and even worse Systems Admin.
>
>Besides which, the last thing you want is port 1433 open to all
>and sundry. If it's open on the net, it's not a matter of if, it
>*will* be hacked.

I've read this elsewhere as well. But if you have the latest
patches

installed, and

assuming there aren't unknown exploits out there, how can it
hurt?

Please be more

specific.

I've often wondered about this myself. The conventional wisdom
seems to be...

1) If you need real security use a database engine like SQL Server
instead of Jet.
2) Don't leave your SQL Server port exposed or you'll get hacked.

One of the above statements must be wrong, no?

Well, one of the problems is that, out of the box, the SA account
has no password (or maybe it's a password that everyone knows), so
anybody can connect as administator to any default installation.
Maybe recent SQL Server patches undo that. I don't know.

But I would do several things if I needed to run SQL Server on my
network:

1. set a strong password on the SA account.

2. run it on a non-standard port.

3. control who can connect to it.

The latter may be most easily done with a proxy server, or via VPN
connections. Either of those solutions would mean that the random
worm would not be able to connect.

Of course, you alsc can't really depend on a patched machine staying
in a "safe" condition. We all know perfectly well that repairing or
re-installation an application can revert you back to unpatched
versions of the software.

So, depending on the "security" of knowing that you've patched your
machine without doing something to prevent that "security" from
being tested is unwise.

Besides, there are probably plenty of vulnerabilities yet to be
found, and you'll still be vulnerable to those. Doing those 3 steps
will probably prevent any of them from getting you.

Probably.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Trevor Best]

david epsom dot com dot au wrote:

Note: you can change the port. 1433 is just the default value.
1433 is fine if you WANT everybody to be able to assume the default
value.

Not much defense against a port scanner, it'll find the open port.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Trevor Best]

Tony Toews wrote:

Trevor Best <nospam@localho st> wrote:

And, yes, guys, I know that I could connect to my
SQL Server instance over port 1433 and don't need Terminal Services but I am
a poor Access developer and even worse Systems Admin.

Besides which, the last thing you want is port 1433 open to all and
sundry. If it's open on the net, it's not a matter of if, it *will* be
hacked.

I've read this elsewhere as well. But if you have the latest patches installed, and
assuming there aren't unknown exploits out there, how can it hurt? Please be more
specific.

Erm... Hacked. As in some unauthorised person now has access to your
data, can read confidential information, blow your data away, etc. A
patch isn't going to stop that.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Trevor Best]

David W. Fenton wrote:

1) If you need real security use a database engine like SQL Server
instead of Jet.
2) Don't leave your SQL Server port exposed or you'll get hacked.

One of the above statements must be wrong, no?

Well, one of the problems is that, out of the box, the SA account
has no password (or maybe it's a password that everyone knows), so
anybody can connect as administator to any default installation.
Maybe recent SQL Server patches undo that. I don't know.

SP3 strongly recommends a password, but doesn't enforce it.
But I would do several things if I needed to run SQL Server on my
network:

1. set a strong password on the SA account.
Or disable it, SQL Server has two security holes^h^h^h^h^h methods,
Windows Authentication and Standard, you can disable standard so any
brute force attacks on the sa account will be futile. You cannot disable
the Windows integrated authentication but to get into SQL Server would
require someone to log onto your domain.
2. run it on a non-standard port.
This will only fool a casual cracker, if there is such a thing. A
determined one will use a port scanner, if you say put SQL Server on
port 80 (usually http) then the cracker will notice that no web service
is running on port 80 and may try something else.
3. control who can connect to it.
By far the best method.
Besides, there are probably plenty of vulnerabilities yet to be
found, and you'll still be vulnerable to those. Doing those 3 steps
will probably prevent any of them from getting you.

Probably.

Bit like any security, what did Qui-gon Jinn say in Ep1? There's always
a bigger fish.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Trevor Best]

Rick Brandt wrote:

I've often wondered about this myself. The conventional wisdom seems to
be...

1) If you need real security use a database engine like SQL Server instead
of Jet.
2) Don't leave your SQL Server port exposed or you'll get hacked.

One of the above statements must be wrong, no?

No. Do banks have their vault doors inside or outside the building?

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Rick Brandt]

"Trevor Best" <nospam@localho st> wrote in message
news:40******** *************** @auth.uk.news.e asynet.net...

Rick Brandt wrote:

I've often wondered about this myself. The conventional wisdom seems to be...

1) If you need real security use a database engine like SQL Server instead of Jet.
2) Don't leave your SQL Server port exposed or you'll get hacked.

One of the above statements must be wrong, no?

No. Do banks have their vault doors inside or outside the building?

Bad analogy. No bank is going to claim that the reason your money is safe
is because of the lock on the front door. Either the vault is secure or it
isn't.

If server-based engines provide "real" security then open ports should not
matter. If they matter then they don't provide real security either, just
security that is "somewhat better".

Following the argument that accessible ports are a security hazard then my
data is vulnerable to anyone who is allowed access to the LAN. Perhaps
that is the technical reality, but I just wonder if the people selling
these databases pitch it that way. "As long as you close ports to the
outside world only your employees will be able to break our security".
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[David W. Fenton]

Trevor Best <nospam@localho st> wrote in
news:40******** *************** @auth.uk.news.e asynet.net:

David W. Fenton wrote:

2. run it on a non-standard port.

This will only fool a casual cracker, if there is such a thing. A
determined one will use a port scanner, if you say put SQL Server
on port 80 (usually http) then the cracker will notice that no web
service is running on port 80 and may try something else.

Why would anyone be silly enough to put it on port 80??!

No, using a non-standard port won't help with exploits that scan all
ports, but *most worms don't do that* -- they scan a small number of
ports, so you're at least protecting yourself from the dumb worms,
and I think that's worth something.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"Rick Brandt" <ri*********@ho tmail.com> wrote in
news:2m******** ****@uni-berlin.de:

Following the argument that accessible ports are a security hazard
then my data is vulnerable to anyone who is allowed access to the
LAN. Perhaps that is the technical reality, but I just wonder if
the people selling these databases pitch it that way. "As long as
you close ports to the outside world only your employees will be
able to break our security".

That's pretty much a standard part of my Access database application
security pitch. I don't believe in undertaking superhuman efforts to
secure an Access application because the greatest danger is from the
people who are *supposed* to have full access to the application and
its data.

Most people think the danger is out there somewhere, in the wilds of
the Internet. I inform them that perimeter maintenance is important,
but the people who are most dangerous are the ones in whom you've
placed the most trust, not the other way around.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc