Vlad, As in any App Server environment on the Web, the security vulnerabilities of the Orion App Server are on two fronts: Server-side: Orionserver Security Primer: http://www.jollem.com/~ernst/orion-security-primer/ Java Best Practices for Server-side Security: >From Sun: J2EE: The Tutorial: http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Security.html The Security Blueprint: http://java.sun.com/j2ee/blueprints/eis_tier/security/index.html Platform Spec for v.1.3 (go to the Security Bookmark in the .pdf) http://java.sun.com/j2ee/j2ee-1_3-pfd4-spec.pdf Additionally, there are potential vulnerabilities in the HTTP server, the plug-in architecture (especially when using CGI and PHP, Python, Perl or Jpython scripts/executables - allowed in Orion and rather easy to do, as well as being very fast). There was a general discussion about Java-based HTTP webservers at the WWW Mobile code forum (link:http://www.securityfocus.com/templates/archive.pike?end=2001-09-22&tid =196606&start=2001-09-16&list=107&threads=0&), but it didn't resolve anything. Bottom line: in general, currently both the HTTP and Java/J2EE functionality of the Orion Server is safe from all known exploits and vulnerabilities in the wild, with the possible exception of a DoS due to transparent proxying on the server (Cisco Routers and Xerox Printers, as well as most Cable and DSL modems are similarly vulnerable). Orion is no more vulnerable than Apache/Tomcat or IIS, and, as recent history has proven, is actually far less vulnerable than the Microsoft products for similar functionality (as well as being FAR faster and easier to develop for - Link: http://www.orionserver.com/benchmarks/benchmark.html , sadly, the BEAst will not allow Orion to continue to publlish stats, but you can read about that following the links:). The second major place that any J2EE AppServer is in the database. 'Nuff said, separate issue and separate practices. Use a secured (wrappered or tunneled with encruyption) HTTP or RMI connection to the database all JDBC connections. Secure the JDBC datastream and securew the database according to the best practices you may choose. The final place on the server-side that any J2EE or other App server is vulnerable is the environment. Nail down the ACLs for your specific environment and pay attention to the OS and the various other sevices and apps you are running on the box (including the security services - just had to repair a Symantec-installed hole left when they put their IDS tools on the production box!). Pay attention to domain and network issues, and keep the network clean and properly configured. Most Orion or Oracle penetrations I've seen/heard of were actually BIND exploits or port53 DNS issues. With the advent of NIMDA, we see another vector for attacks: the client program. With a few exceptions, Java AppServers are uniquely invulnerable to this new vector. Sun Client-side Security Note: http://java.sun.com/j2se/1.3.0/docs/guide/security/spec/security-specTOC.fm. html So, keep aware of general security threats, code to best practices, test developers' code for exploits before putting it into production (85% of all losses in the IT enterprise space are inside jobs) and be aware of normal security precautions. For Solaris tools see: http://www.solaris4you.dk/sunsolaris.html and, I'm testing the Astaro Security Linux implementation (and have installed it for 3 clients who use Orion or Oracle 9AS with OC4J) so far successfully. I include a few additional patches and configuration changes, but, in general it seems to work well. Link: http://www.astaro.com and http://www.astaro.org Comes with Enterprise VPN and AV support, too. Also having luck with Net Screen http://www.netscreen.com/products/index.html Hope all this was of assistance. Contact me offline if you have any more specific questions on Oracle, OAS or Orion Security. We also test Enterprise domain-level security and manage PKI infrastructures. Michael J. Cannon [EMAIL PROTECTED] PM/COO-hsqldb.org, Inc. http://hsqldb.org President, Ubiquicomm - Home of the Grupo Para Bellum Security Team http://www.ubiquicomm.com [EMAIL PROTECTED] ----- Original Message ----- From: "The elephantwalker" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Friday, September 21, 2001 11:52 AM Subject: RE: Questions about Orion > Vlad, > > see comments... > > regards, > > the elephantwalker > www.elephantwalker.com > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Vlad > Vinogradsky > Sent: Friday, September 21, 2001 7:08 AM > To: Orion-Interest > Subject: RE: Questions about Orion > > > Thanks for your response. Few follow-up questions. > > >By the way, Orion by itself can out do IIS by six to one!... > In what scenario? > <elephantwalker> > Orion serving up jsp pages compared to asp pages from IIS. > </elephantwalker> > > >... make sure you test the jdbc drivers with all necessary uses of sql > including > >things like LIMIT, CLOB, BLOB as well as 100's of open connections. > These are the key >database needs for a appserver servicing the web. > What about resource/connection pooling? > <elephantwalker> > Orion uses connection pooling for its ejbs, and you can specify connection > pooling for your jdbc connections in orion with a DataSource configuration. > </elephantwalker> > >Like anything, if you run it on Windows, it will be compromised. > I was asking more about known Orion vulnerabilities? > > <elephantwalker> > AFAIK, there are none if you take the following steps: > > 1. Run orion as a non administor user. > 2. Do not use any of the script based servlets, such as php. > 3. User jdbc drivers that support encrypted network traffic. Oracle does > this...I don't know about m$ sql server. > > > However, Windows is known to have many security issues, and if your > operating system security is compromised, the hackers will have access to > the orion, and any other resources you have. > > I would recommend staying away from any windows system for any internet > application because the windows record on security is so BAD. You should see > my internet logs the last few days ;(...filled with requests for silly > things on the c drive, something the frequently patched IIS is vulnerable > to, but which orion justs sends back a 404. > > In the past two years, I have seen no similar failure of Orion, nor any > complaints on the list. > </elephantwalker> > Thanks, > > Vlad > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of The > elephantwalker > Sent: Friday, September 21, 2001 1:08 AM > To: Orion-Interest > Subject: RE: Questions about Orion > > > Vlad, > > Here are the answers as I know them: > > 1. SQL Server 2000 database --> That's a tough one. I don't know any IT > managers recommending this beast. But if you got to live with it ... > make sure you test the jdbc drivers with all necessary uses of sql > including things like LIMIT, CLOB, BLOB as well as 100's of open > connections. These are the key database needs for a appserver servicing > the web. > > 2. Orion uses the Java 1.3 jvm from Sun, IBM or others. As they say, if > it runs on one, it runs on all. > > 3. We use IBM's jvm with absolutely no problems. > > 4. Scalability is determined by your clustering needs. Orion clusters > httpsessions in islands of two to four servers. Statefull Session Beans > are not clustered, but entity beans and slsb's are easily set up in a > clustered environment. Orion is easily the fastest jsp/servlet engine on > the planet, and along with some very good performance numbers on the ejb > side, you can out do other app servers by a factor of 3 to 1. By the > way, Orion by itself can out do IIS by six to one! Oracle thought so > much of the Orion performance, they licensed the software as the core of > their j2ee application server. > > > 5. j2ee security is used on Orion, you can implement your own user > security, or link up with ldap, or use the builtin usermanagers for > databases. SSL is also a feature of Orion, but I would recommend locking > down your web server with SSL, or use a hardward accelerator, and > proxying Orion outside the dmz. This is how most firms implement > appservers. > > 6. Like anything, if you run it on Windows, it will be compromised. We > have not had any security troubles with Linux RedHat 7.1 and orion. > > 7. Ironflare doesn't really provide the technical support that some > need. With Ironflare's encouragement, companies like Flowsheet > Technologies and others provide subscription based customer support for > Orion. Join our site, www.elephantwalker.com, its free, and sign up for > a subscription when you need some help. We also provide a course for > Orion in the San Francisco Bay Area. > > regards, > > the elephantwalker > www.elephantwalker.com > > > > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Vlad > Vinogradsky > Sent: Thursday, September 20, 2001 8:22 PM > To: Orion-Interest > Subject: Questions about Orion > > > I am evaluating the Orion server for use in a production web site which > would be hosted by a hosting services provider. It would run on a > Windows 2000 box alongside other web sites serviced by IIS and will > manage data in SQL Server 2000 database. I have a few questions I wasn't > able to find answers to and I wonder if you can help me with them. > > 1. I wonder if anybody had any negative experience using Orion server on > Windows 2000 or with SQL Server 2000? I-Net jdbc products are going to > be used. > > 2. Any comments on performance, scalability and availability of the > Orion server on Windows 2000? > > 3. What VM is best to use to run Orion server? > > 4. Does it have auto start and restart features? Do you have to have an > interactive logon session to start it? > > 5. What security context does it run in? > > 6. What is Orion server security track record? Has it ever been > compromised or taken out by DOS attacks? > > 7. Any comments on IronFlare's technical support? It looks like there is > no live tech support - just email. > > All input is welcome. > > Thanks, > > Vlad > > > > > >
