Re: ops$/w2k/"secure" connections question

"Boivin, Patrice J" wrote:
>
> I was asking myself the same question as I was reading through the Oracle9i
> Security features on the Oracle web site, single-sign on is in there. They
> also mention OS authentication as a great thing. That puzzled me for a bit.
>
> I may have figured it out, though, let me know if this makes sense.
>
> I guess they assume that if you are concerned about Oracle, you are going to
> use encrypted networking and passwords. You know that without the Trusted
> Oracle or Secure Networking options, or some other 3rd party network
> security setup, Oracle passwords are transmitted in clear text over the
> network... right?
>
> So if you have Oracle logons, anyone with a packet can grab the Oracle
> passwords. A packet monitor is one shipped for free with the NT distribution
> disks although it only monitors the NT server's own NIC. But you can grab
> some at hundreds of Web sites on the 'net, it would take just a few minutes
> to find one, download it, and start using it.
>
> i.e. all your networking techies know what the Oracle passwords, or they can
> easily find out if they are so inclined.
> i.e. your power users also are quite capable of finding out what the Oracle
> passwords are.
>

Patrice,

At a company that has a terms of use clearly defined, using a sniffer or simply putting a NIC (network interface card) into promiscuous mode could be grounds for immediate dismissal.

Ask Larry Wall.

Its a good idea to get written permission prior to using a password cracker (as a Network Admin) to test for weak passwords for the NT domain accounts, as this type of action could also grounds for termination.

Simply installing ARCServeIT Backup software, with the TNG Unicenter program is enough to put a NIC into promiscuous mode. I was at a client site whereby a part time net admin installed a scanner product (7 PM on a friday night) and the whole stack lit up - solid. They were ready to shut down the network - for 500 users - with backups running - to try to isolate where the source of the traffic was coming from.

I worked at a company in the past - where if you so much connected a modem to a computer (and thereby circumvented the firewall) you were gone. But the company distributed a mailing, held a meeting convering it - and had everyone sign a terms of use agreement. As long as its clearly stated and understood - this seems to be fair to me. Development shops tend to be much more loose than that.

Floating the term "grounds for immediate dismissal" should tend to keep the sniffers off the network.

Paul

> HTH
> Patrice Boivin
> Systems Analyst (Oracle Certified DBA)
>
> Systems Admin ? Operations | Admin. et Exploit. des systèmes
> Technology Services | Services technologiques
> Informatics Branch | Direction de l'informatique
> Maritimes Region, DFO | Région des Maritimes, MPO
>
> E-Mail: boivinp_at_mar.dfo-mpo.gc.ca ?mailto:boivinp_at_mar.dfo-mpo.gc.ca?
>
> -----Original Message-----
> From: Koivu, Lisa [SMTP:lisa.koivu_at_efairfield.com]
> Sent: Friday, August 17, 2001 4:38 PM
> To: Multiple recipients of list ORACLE-L
> Subject: ops$/w2k/"secure" connections question
>
> After much fiddling, I got ops$ (os authenticated) logons to work in
> my w2k db. However, I'm confused. I had to set REMOTE_OS_AUTHENT = TRUE in
> order for this to work. See snippet from doco below.
>
> I'm doing this all locally. When I set REMOTE_OS_AUTHENT=FALSE it
> does not work. My question is, why is a local connection seen as
> non-secure? I can connect via sqlplus with the listener down, so I'm not
> running into the restriction with Net8.
>
> Thanks in advance for any comments you may have.
>
> ?-- from doco
> By default, Oracle only allows operating system authenticated logins
> over secure connections. Therefore, if you want the operating system to
> authenticate a user, by default that user cannot connect to the database
> over Net8. This means the user cannot connect using a multi-threaded server,
> since this connection uses Net8. This default restriction prevents a remote
> user from impersonating another operating system user over a network
> connection.
>
> If you are not concerned about remote users impersonating another
> operating system user over a network connection, and you want to use
> operating system user authentication with network clients, set the parameter
> REMOTE_OS_AUTHENT (default is FALSE) to TRUE in the database's
> initialization parameter file. Setting the initialization parameter
> REMOTE_OS_AUTHENT to TRUE allows the RDBMS to accept the client operating
> system username received over a non-secure connection and use it for account
> access.
>
> --?
>
> Lisa Koivu
> Oracle Database Administrator
> Fairfield Resorts, Inc.
> 954-935-4117
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Boivin, Patrice J
> INET: BoivinP_at_mar.dfo-mpo.gc.ca
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Paul Drake
  INET: paled_at_home.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).