Securing HP SWS Apache to DoD DISA STIG (1194 Views)
Reply
Trusted Contributor
Cass Witkowski
Posts: 344
Registered: ‎01-12-2004
Message 1 of 14 (1,194 Views)

Securing HP SWS Apache to DoD DISA STIG

I'm looking for anyone who has had to secure HP's SWS running on OpenVMS Itanium to satisfy the DoD DISA STIG.

I would like to not have to reinvent the wheel if someone else has done this.

Thanks,

Cass
Respected Contributor
Rick Retterer
Posts: 156
Registered: ‎04-30-2003
Message 2 of 14 (1,194 Views)

Re: Securing HP SWS Apache to DoD DISA STIG

Cass,

Rick Retterer here. Can you drop me an email on this please?

We received an inquiry from the Engineering Management staff on this yesterday...

Cheers,
Rick
- Rick Retterer



Honored Contributor
Hoff
Posts: 4,958
Registered: ‎01-29-2006
Message 3 of 14 (1,194 Views)

Re: Securing HP SWS Apache to DoD DISA STIG

This is going to be an interesting review project.

To save you the digging...

CSWS/SWS/Apache is built from 2.0.52
Apache 2.2.17 and 2.0.64 are current

csws_php is built from 5.2.13
php 5.3.5 and 5.2.17 are current
(support for php prior to 5.3 has ended)

csws_perl is built from 5.8-6
perl is at 5.12.13

Trusted Contributor
Cass Witkowski
Posts: 344
Registered: ‎01-12-2004
Message 4 of 14 (1,194 Views)

Re: Securing HP SWS Apache to DoD DISA STIG

Hoff, Why did you say that this would be an interesting review project? Have you done this before?
Honored Contributor
Hoff
Posts: 4,958
Registered: ‎01-29-2006
Message 5 of 14 (1,194 Views)

Re: Securing HP SWS Apache to DoD DISA STIG

This project will be "interesting" because these software versions are old, and there are known issues with various of them.

Have a look at http://labs.hoffmanlabs.com/node/43 for some links and pointers, including to NIST's SP800-44v2, to the VMS SRR, and AS-816.

Trusted Contributor
Cass Witkowski
Posts: 344
Registered: ‎01-12-2004
Message 6 of 14 (1,194 Views)

Re: Securing HP SWS Apache to DoD DISA STIG

True the age of the software affects some of the issues with securing but most of what needs to be addressed is applicable to all version.

Regular Advisor
Peter Barkas
Posts: 157
Registered: ‎03-14-2005
Message 7 of 14 (1,194 Views)

Re: Securing HP SWS Apache to DoD DISA STIG

Indeed it will be an interesting review particularly if HP actually updates any of the aforementioned software or indeed releases a version of CSWS that is compatible with SSL V1.4.
Trusted Contributor
Cass Witkowski
Posts: 344
Registered: ‎01-12-2004
Message 8 of 14 (1,194 Views)

Re: Securing HP SWS Apache to DoD DISA STIG

From what I hear look in early Q3 for a new version of OpenSSL
Trusted Contributor
Cass Witkowski
Posts: 344
Registered: ‎01-12-2004
Message 9 of 14 (1,194 Views)

Re: Securing HP SWS Apache to DoD DISA STIG

Alot of the DISA STIG findings are related to who owns the files in the Apache directory tree versus who is running the webservices.

For example the current setup for Apache on OpenVMS is to have the APACHE$WWW user be the owner of the processes that run the web services executables and the APACHE$WWW user also owns the HTTPD.CONF and other configuration files.

The fear is if someone can cause the webservice process to change the HTTPD.CONF file then they would control your web server.

Is this a valid concern?

If not please explain why.
Regular Advisor
Peter Barkas
Posts: 157
Registered: ‎03-14-2005
Message 10 of 14 (1,194 Views)

Re: Securing HP SWS Apache to DoD DISA STIG

My understanding is that OpenVMS APACHE (CSWS) has access to nothing unless it is granted access.

So for example, the http.conf file will have an identifier that allows APACHE to READ it.
Regular Advisor
Peter Barkas
Posts: 157
Registered: ‎03-14-2005
Message 11 of 14 (1,190 Views)

Re: Securing HP SWS Apache to DoD DISA STIG

Just reread the question. That depends on the privileges that the webservice is granted.

If the webservice has the privilege to modify system files then yes it is a concern.

So the answer is not to grant that kind of privilege to a webservice, and indeed why would one?
Honored Contributor
Hoff
Posts: 4,958
Registered: ‎01-29-2006
Message 12 of 14 (1,190 Views)

Re: Securing HP SWS Apache to DoD DISA STIG

Most security audits will fail the versions of Apache and php packages available for OpenVMS, among other common tools. (I've worked with auditors that have flagged and failed far newer versions than what are available with VMS.)

The web server should not own and should have extremely limited write access to any device and directory and file resources. The default should be no write access, and no control access, and often a top-level ACL on everything else blocking access. Some web-facing systems do require writeable directories (for client file uploads, usually), and those can be, well, hazardous.

It can be easier to deploy a locked down web server (often in a DMZ) than to try to lock down an existing and active server, too.

Web server attacks now tend to target the injection of php code or of SQL, depending on what services are active and what the site is serving up. Proper file protections are a reasonable backstop for some of that, but are far from a panacea. Other attacks can include gifar uploads (into directories that are writeable) and the recent spate of "fun" that has been Firesheep.

Trusted Contributor
Cass Witkowski
Posts: 344
Registered: ‎01-12-2004
Message 13 of 14 (1,190 Views)

Re: Securing HP SWS Apache to DoD DISA STIG

Here is the security of HTTPD for HP SWS on OpenVMS.

HTTPD.CONF;15
[AP_HTTPD,APACHE$WWW] (RWED,RWED,,) (IDENTIFIER=APACHE$READ,ACCESS=READ)

So APACHE$WWW owns the file. It has owner access of RWED and the APACHE$READ identifer.

So it looks like the Webservice process that runs as the APACHE$WWW user has write access to the HTTPD.CONF file, unless I'm missing something.

Regular Advisor
Peter Barkas
Posts: 157
Registered: ‎03-14-2005
Message 14 of 14 (1,190 Views)

Re: Securing HP SWS Apache to DoD DISA STIG

It seems that O:RWED is the standard setting.

I think that the owner should have no access by protection setting.

Interested to know the HP response.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.