Yes this sounds like the better choice indeed
Jacques
From: "Raj Saini" <[email protected]>
Hi Rajesh,
If you use Apache web server to front OFBiz, you can restrict the OFBiz connector (AJP/1.3) to bind only to the loopback interface
(127.0.0.1). I generally disable http and ssl connector and just keep the AJP/1.3. This way you OFBiz will not be accessible form
outside world and only Apache web server running on the same host will communicate with OFBiz.
Thanks,
Raj
rajesh ramkumar wrote:
Hi carsten,
Thanks for the reply.
As stated by yourself, we are on single layer OFBiz architecture and I have
not come across any restrictions for getting PCI compliance based on this
architecture. Can you please forward me links/website that mentions this
restriction.
Even if you introduce a web & application layer, i.e front your ofbiz
server(server on which you run ofbiz) with apache using mod jk connector/ajp
protocol, how are you restricting the access on http(80 or any) and
https(443 or any) ports on the ofbiz server(internal tomcat).
If you are running apache on a different server then, I would assume that
you need to get both your servers audited for PCI compliance? If you are
running both apache & ofbiz on the same server then you might have
configured the http & https ports on internal tomcat to be different to 80 &
443, but even then the new ports can be hit from outside, so how did you
deal with that.
Any reply/help is greatly appreciated.
regards
Rajesh
Carsten Schinzer wrote:
Hi Rajesh,
with a single MEDIUM criticality issue you are at compliance level 3, i.e.
you will not put your PCI compliance at risk.
However, you are right: We solve these issues at Apache level.
I wonder how the auditors did approve your single layer OFBiz architecture
(which I assume you will have since you are asking this audience for help
in
a Web Layer configuration issue)?
If there is a solution in OFBiz configuration itself, I would like to know
as well. However, I thought you would need to
* introduce a Web Layer and
* introduce a App Layer
and PCI will require you to not allow un-authorized access from Web to App
Layer. So how did you solve this architectural demand?
Regards
Carsten
2009/9/3 rajesh ramkumar <[email protected]>
We are trying to get PCI Compliance to be able to do credit card
processing.
We have resolved all the issues but for the "Weak Supported SSL Ciphers
Suites on https(443/tcp)".
In a typical environment this is normally set at tomcat
configuration/apache
configuration level and in ofbiz these setting are in
ofbiz-container.xml(root/frameworks/base/config). Any help to fine tune
to
configuration to solve this risk is greatly appreciated
Our current setting:
server - linux, centOS5
ssl certificate - supports upto 256-bit encryption
security protocol used - TLSv1 (ofbiz_container.xml)
cipher suite - "HIGH:MEDIUM:!SSLv2:!ADH:!aNULL:!eNULL:!NULL:!LOW"
(Basically
allows only high and medium ciphers of either SSLv3 or
TLSv1)(ofbiz_container.xml)
PCI rejection error:
Risk factor : Medium / CVSS Base Score : 5.0
(CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) Plugin output : Here is the list
of weak SSL ciphers supported by the remote server : Low Strength
Ciphers (< 56-bit key) SSLv3 EXP-EDH-RSA-DES-CBC-SHA
Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export
EXP-DES-CBC-SHA Kx=RSA(512) Au=RSA Enc=DES(40)
Mac=SHA1 export EXP-RC4-MD5 Kx=RSA(512)
Au=RSA Enc=RC4(40) Mac=MD5 export TLSv1
EXP-EDH-RSA-DES-CBC-SHA Kx=DH(512) Au=RSA Enc=DES(40)
Mac=SHA1 export EXP-DES-CBC-SHA Kx=RSA(512)
Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC4-MD5
Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5
export The fields above are : {OpenSSL ciphername} Kx={key
exchange} Au={authentication} Enc={symmetric encryption method}
Mac={message authentication code} {export flag}
--
View this message in context:
http://www.nabble.com/PCI-compliance-issue---week-ciphers-are-enabled-by-default-tp25273745p25273745.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
--
Best
Carsten Schinzer
Waisenhausstr. 53a
80637 München
Germany
