DComTalk.com

In article <3v8dokF14i2f8U2@individual.net>, usenet-2005
@planetcobalt.net says...

Leythos wrote:
In article <3v81h3F14hncrU1@individual.net>, usenet-2005@planetcobalt.net says...
Do you read only every other word or something? The exposure is AT
MOST the same.

At Most - so then at some point it is the same - so, if at some point
it could be the same, then it will be the same (for one reason or
another) and that follows what I said.

I'll take that for a 'yes'.

*plonk*

Do you plonk everyone that doesn't see things your way?

I happen to have a point that is different than yours, works for all of
our clients, has not been compromised, and is easy to manage at the same
time. Just because I don't agree with you doesn't mean we can't discuss
it like men, and I think it's childish of you to plonk anyone.

--

spam999free@rrohio.com
remove 999 in order to email me

Leythos wrote:

In article <3v81h3F14hncrU1@individual.net>, usenet-2005@planetcobalt.net says...
Do you read only every other word or something? The exposure is AT
MOST the same.

At Most - so then at some point it is the same - so, if at some point
it could be the same, then it will be the same (for one reason or
another) and that follows what I said.

I'll take that for a 'yes'.

*plonk*

cu
59cobalt
--
"Another option [for defragmentation] is to back up your important files,
erase the hard disk, then reinstall Mac OS X and your backed up files."
--http://docs.info.apple.com/article.html?artnum=25668

You don't want *any* host in the DMZ to be able to establish
connections
into your private network, since that would break the DMZ. Put the
backend servers into the DMZ (or a separate second DMZ). Replicate
(push!) the relevant data from your backend servers to servers in the
DMZ. But *never* *ever* allow connections from the DMZ to the
internal network

Back to some definitions and basics.
A LAN can be many things, none of which are accessible by public IP
address assignments.

A DMZ is a set of components isolated from the Internet and the backend
processors by firewalls on both sides
Public -- FW(#1) --- DMZ systems -- FW(#2) --- backend processing(BEP)

Best practices says the corporate LAN should not be accessible from the
DMZ or the public Internet.

The WWW.* systems have components in the DMZ which may be compromised
from time to time (which is why we need backups, pagers and have jobs).
By segmenting the networks and using non-default ports in the backend
processing, access from the Public net to the BEP can only be achieved
by software in the DMZ properly configured (ie no scripting kiddy is
crossing two firewalls which have no natural routes into the BEP).
Now you can run a DBMS in the BEP subnet and again, the kiddies can't
run injections scripts and smash your data.

Yea, there's much more to configure, and you need to bind the
applications externally rather than default address and ports, but it's
also safe, secure, and scalable when expansion is needed.

--
---
Jeff B (remove the No-Spam to reply)