You don't state explicitly where these clients are, but I'm
going to assume that they're out there on the 'net.
Considering the amount of work already done here, I'm
assuming your security needs are high, so here goes...
The solution looks fairly thought-through, but still there's
the matter of endpoint security. The communication between
the clients and the web server is "safe", as you probably
guessed yourself. But what about the people at the endpoints,
surfing around the web and reading mail? *shiver* :-)
You have a problem with the password mechanism; a trojan on
the user's machine could _easily_ sniff the keyboard when
the user types his/her password, and use it later on.
I'd recommend a public key certificate mechanism, involving
smart cards.
This is in no way fool proof, since a trojan could still
use the smart card as long as it is inserted, but once
it's out of the computer, you're safe. A trojan could
not pass smart card information along to a third party
to be used later on.
Ahwell.
If you want to go with your original solution, which
may very well be "safe enough", I'd still like to
point this out:
- Use server certificates. This makes sure noone
can impersonate your server and serve up
their on logon screen, asking users for uid/pwd.
- Distribute the server certificate by snail mail
(on a floppy) if you're going to be your own
Certificate Authority. Don't let people download
it off the 'net (or receive it by e-mail) before
the first use - this would allow an attacker to
give them a false certificate, and we'd have
the above situation again.
Also, you could look into one-time passwords generated by
a one-time pad that could be distributed to the users.
If you haven't seen them before, they mostly look like
pocket calculators. They're fairly cheap, and don't
require hardware meddling on the endpoints.
The one-time password mechanism would thwart password
stealing the same way a smart card would.
Of course, neither of the above would thwart a trojan
that uses your already-established connection, for
instance by keeping it open when you're done working,
and keep doing things in the background.
Security sucks, doesn't it? >:]
Just my $.02
Regards,
Mike
"WINCHESTER, STEVEN W." wrote:
>
> I'm another one of those who is new at network security and I happened on
> this list by chance. Since ya'll have more network experience than I do, I
> am seeking some comments/advice on a system configuration we will take
> over in the near future.
>
> We will be running a supply management application on an IBM AS/400
> mid-tier platform with the latest operating system (IBM OS/400, V4R3).
> Remote users (select few - not open to everyone) will have access to this
> supply management system via TCP/IP through a Web server, also running on
> the same AS/400 platform. Specific to the AS/400, access to both the Web
> Server and the application are controlled by ID/pass-phrase (up to 32
> characters) followed by ID/passwords (up to 8 characters) respectively. In
> other words, if the incoming user doesn't know both their Web server and
> application ID/passphrases for their pre-assigned account, they will not
> get in. Likewise, if they try three times at either the Web server or
> application level with a bogus ID/pass-phrase, their account will be locked
> out and must be reset by the administrator. To keep others from seeing
> ID/passphrase attempts, the remote users will connect to the Web server via
> HTTPs (port 443) encrypted.
>
> Further limitations to this AS/400 platform come in the form of a
> Sidewinder Firewall located at the only gateway to the local area network.
> The Sidewinder will limit all access to the AS/400 to specific
> predetermined protocols and IP addresses (However, some remote users are
> located behind an external proxy server so we are really talking about a
> predetermined range of IP addresses for some users).
>
> As I understand it, no outgoing traffic from the Web Server or supply chain
> application will be in the clear using HTTPs. As I see it, incoming
> protocol and IP address limitations through the firewall only provide
> low-level security (keeps out the casual Web surfer). More restrictive
> security comes in the form of the HTTPs only access followed by the
> ID/Passphrase combinations on the AS/400 platform. In your opinion, have
> we designed a secure system?
>
> Thanks in advance
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
