Re: Any 7 rumors?

2014-04-10 Thread Nico Kadel-Garcia
On Wed, Apr 9, 2014 at 2:11 PM, Stephen John Smoogen  wrote:
>
> On 9 April 2014 11:17, David Sommerseth 

>> Really!?  I've been involved in a few PCI-DSS certification rounds for a
>> company which provided online payment services back in the days.
>> Granted that's some years ago now (2005 to 2008-ish).  Even though our
>> scope was limited to only processing credit card information, we did not
>> see any requirements anywhere at that time for the shopping cart to be
>> PCI-DSS certified.

Don't forget the commonplace flat-out lying in PCI-DSS certification.
When a company says "we have a policy of secure password management",
and has a video about how passwords are never known by anyone other
than the password owner and are never sent in email, then *turns
around and orders you to do so as a matter of standard practice for
your entire department*, you know your PCI-DSS certification is not
meaningful.

This sort of thing is why I spend so much time trying to get Kerberos
based account authentication working well for SL based environments.
It puts the access control in an environment where a central IT staff,
or me, can set sane policies, set accounts safely, never store
unencrypted passwords on any server we control, and not rely on
someone else's implementation of written policies.


Re: Any 7 rumors?

2014-04-10 Thread Paul Robert Marino
Well the shopping cart isnt explicitly stated but it is implied and
there have been several cases where companies have gotten in trouble
for not properly securing the shoping cart data.

Keep in mind PCI compliance is a CYA exersize more than any thing else.

As far as providing a Gentoo based appliance to your customers in that
case you are taking the place of Red Hat in that case you are directly
responsible for ensureing the safty of your platform. if you have the
staff to do all the testing and integration of security patches.
further I actuallly like gentoo as an appliance platform because you
can very easilly build a custom stripped to the base minimum
appliance. the big trick is to build your own portage servers and
create binary packages so your appliancesdont have to compile every
update and if possible don't have a compiler installed at all.


On Wed, Apr 9, 2014 at 1:17 PM, David Sommerseth
 wrote:
> On 09/04/14 16:27, Paul Robert Marino wrote:
>> No it was always required because the shopping cart itself may in some
>> cases contain data which could possibly be used to gain access to
>> sensitive customer data. Also in a sense data about who purchases what
>> and where could also be used to mask credit card fraud by making the
>> fraudulent charges look like the normal shopping activities of the
>> card holder.
>
> Really!?  I've been involved in a few PCI-DSS certification rounds for a
> company which provided online payment services back in the days.
> Granted that's some years ago now (2005 to 2008-ish).  Even though our
> scope was limited to only processing credit card information, we did not
> see any requirements anywhere at that time for the shopping cart to be
> PCI-DSS certified.
>
> In fact one of our sales arguments at that time was that our customers
> could avoid certifications by implementing our online payment
> "terminal".  We even had some discussions with our auditor about this,
> who gave his blessings to our product.  The solution we provided in this
> case would take care of retrieving the credit card information from the
> customer, process the payment and just provide a status back to the
> merchant.  Merchants using a payment API for processing payments would
> in some cases need certification, based on the amount of transactions
> they had; this I believe has become much stricter since those days.
>
> And just to have mentioned it, the solutions we provided was based upon
> Gentoo(!) servers.  We even got very positive feedback for having
> absolutely minimum installs on our production servers, plus kudos for
> our maintenance routines.
>
> Of course, many of the requirements have most likely changed since then.
>  But I don't recognise the "always required" in regards to shopping carts.
>
>
> --
> kind regards,
>
> David Sommerseth
>
>
>>
>> On Wed, Apr 9, 2014 at 8:13 AM, James M. Pulver  wrote:
>>> We were recently informed PCI compliance also extends to the shopping cart
>>> software, this may be new this year...
>>>
>>>
>>>
>>> --
>>>
>>> James Pulver
>>>
>>> CLASSE Computer Group
>>>
>>> Cornell University
>>>
>>>
>>>
>>> From: owner-scientific-linux-us...@listserv.fnal.gov
>>> [mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Paul
>>> Robert Marino
>>> Sent: Tuesday, April 08, 2014 11:26 PM
>>> To: Nico Kadel-Garcia; ToddAndMargo
>>> Cc: Scientific Linux Users
>>> Subject: Re: Any 7 rumors?
>>>
>>>
>>>
>>> Well frankly if you need PCI-DSS compliance pay for RHEL. Its honestly not
>>> that expensive for the few systems that really require it. Only  the
>>> system's that handle credit cards supposedly require it and in most
>>> ecommerce companies that's probably 2 to 4 system's so what's the problem
>>> wit paying $750 a year each for those few systems to not have to deal with
>>> the problems and giving the stock investors a warm and fuzzy feeling. Your
>>> time spent on it costs them more money and ti reduces all the stress on
>>> every one if you buy compliance on the cheap.
>>>
>>>
>>> -- Sent from my HP Pre3
>>>
>>>
>>>
>>> 
>>>
>>> On Apr 8, 2014 22:55, Nico Kadel-Garcia  wrote:
>>>
>>> On Tue, Apr 8, 2014 at 10:14 PM, ToddAndMargo  wrote:
 Hi All,

 I have a customer who is going to have to upgrade a
 whole pail of stuff for PCI compliance (credit card
 security).

 Part of what he is going to have upgrade is his old
 CentOS 5.x server (it is too underpowered to handle
 his new software along with the addition drag
 caused by adding File Integrity Monitoring
 [FIM] Software).

 Any rumors as to when EL 7 will be out?

 Many thanks,
 -T
>>>
>>> Shortly after our favorite upstream vendor publishes it? I don't see
>>> the relevance though. If he needs to update CentOS 5, update it to SL
>>> 6 or CentOS 6. Why wait for RHE 7 to update? It's going to be major
>>> cluster futz with the the switch tu systemd from init scripts, with
>>> "/bin" being m

Re: Security ERRATA Important: openssl on SL6.x i386/x86_64

2014-04-10 Thread Dag Wieers

On Wed, 9 Apr 2014, David Sommerseth wrote:


On 09/04/14 16:42, Pat Riehecky wrote:


All applications linked against openssl must be restarted for this
update to take effect.


I installed lsof on my boxes and used

 [root@host: ~]# lsof | grep -E "libcrypto|libssl" | grep DEL

to identify processes/services which needs to be restarted.


This is incorrect, only libssl is relevant. Therefore sshd, snmpd, 
saslauthd or ntpd are not affected since they link only to libcrypto.so.


So this suffices:

# lsof | grep -P "\bDEL\b.+libssl.so.1.0.1e$"

and it will not catch any older processes still using the RHEL6.4 openssl 
libraries (in case your system was not rebooted after the upgrade to 
RHEL6.5).


--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, cont...@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]


heartbleed and openssl update

2014-04-10 Thread William Lutter
I see this link relative to openssl and heartbleed exploit...

https://www.openssl.org/news/secadv_20140407.txt

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server. Only 1.0.1 
and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. 1.0.2 
will be fixed in 1.0.2-beta2.

My SL 6.5 lists
openssl-1.0.1e-16.el6_5.7.x86_64
openssl098e-0.9.8e-17.el6_2.2.x86_64
openssl-devel-1.0.1e-16.el6_5.7.x86_64

so, it is a vulnerable version of openssl.

Question 1
I enabled fastbugs in sl-other.repo and well as usual enables in sl.repo, 
however, do not see an update for openssl.

Will there be one forthcoming from SL or have I missed the proper repository to 
get it? 
I have no server on this PC, so I am not worried yet.

Question 2
I surmise that older versions of openssl on older SLs are not impacted
such as
openssl-0.9.8e-26.el5_9.1.i686

Bill Lutter


Re: heartbleed and openssl update

2014-04-10 Thread Connie Sieh

On Thu, 10 Apr 2014, William Lutter wrote:


I see this link relative to openssl and heartbleed exploit...

https://www.openssl.org/news/secadv_20140407.txt

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server. Only 1.0.1 
and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. 1.0.2 
will be fixed in 1.0.2-beta2.

My SL 6.5 lists
openssl-1.0.1e-16.el6_5.7.x86_64
openssl098e-0.9.8e-17.el6_2.2.x86_64
openssl-devel-1.0.1e-16.el6_5.7.x86_64

so, it is a vulnerable version of openssl.


No,  that is the updated version.  TUV backports security errata.  They 
key is the .7 in el6_5.7 .




Question 1 I enabled fastbugs in sl-other.repo and well as usual enables 
in sl.repo, however, do not see an update for openssl.


Will there be one forthcoming from SL or have I missed the proper 
repository to get it? I have no server on this PC, so I am not worried 
yet.


It was released on Tuesday morning.



Question 2
I surmise that older versions of openssl on older SLs are not impacted
such as
openssl-0.9.8e-26.el5_9.1.i686


Not impacted.



Bill Lutter



-Connie Sieh