Well, the trick is to separate your Apache as an access point in the DMZ and
put network-level restricitons (Layer 3, i.e. TCP/IP) on the traffic between
apache and ofbiz in this case.
That will suffice PCI requirements.

For your other question: A two-layer layout is IMHP strongly imposed by
section 1 of the PCI requirements document v1.2. If you do not have that,
check
https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

I am sure you will agree that a standalone instance with your cardholder
data in the DMZ (or a single zone exposed to internet traffic) will not
suffice these requirements.

Are you already in the audit process? Or just preparing?

Regards


Carsten

2009/9/3 rajesh ramkumar <[email protected]>

>
> 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
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/PCI-compliance-issue---week-ciphers-are-enabled-by-default-tp25273745p25275109.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>
>


-- 

Best

Carsten Schinzer

Waisenhausstr. 53a
80637 München
Germany

Reply via email to