Re: [CentOS] Low random entropy

2017-05-28 Thread Robert Moskowitz 



On 05/28/2017 06:57 PM, Rob Kampen wrote:

On 28/05/17 23:56, Leon Fauster wrote:

Am 28.05.2017 um 12:16 schrieb Robert Moskowitz :



On 05/28/2017 04:24 AM, Tony Mountifield wrote:

In article <792718e8-f403-1dea-367d-977b157af...@htt-consult.com>,
Robert Moskowitz  wrote:

On 05/26/2017 08:35 PM, Leon Fauster wrote:
drops back to 30! for a few minutes.  Sigh.

http://issihosts.com/haveged/

EPEL: yum install haveged

WOW!!!

installed, enabled, and started.

Entropy jumped from ~130 bits to ~2000 bits

thanks

Note to anyone running a web server, or creating certs. You need
entropy.  Without it your keys are weak and attackable. Probably even
known already.
Interesting. I just did a quick check of the various servers I 
support,

and have noticed that all the CentOS 5 and 6 systems report entropy in
the low hundreds of bits, but all the CentOS 4 systems and the one old
FC3 system all report over 3000 bits.

Since they were all pretty much stock installs, what difference 
between

the versions might explain what I observed?
This is partly why so many certs found in the U of Mich study are 
weak and factorable.  So many systems have inadequate entropy for 
the generation of key pairs to use in TLS certs. Worst are certs 
created in firstboot process where at times there is no entropy, but 
the firstboot still creates its certs.


/var/lib/random-seed and $HOME/.rnd are approaches to mitigate this 
scenario.


--
LF
so there are mitigations - the question really is: why hasn't redhat 
made these mitigations the default for their enterprise products - 
maybe other influences we are unaware of - seems like a huge big hole. 
With the advent of SSL/TLS being mandated by google et al, every 
device needs access to entropy.


The challenge is this is so system dependent.  Some are just fine with 
stock install.  Others need rng-tools.  Still others need haveged.  If 
Redhat were to do anything, it would be to stop making the default cert 
during firstboot.  Rather spin off a one-time process that would wait 
until there was enough entropy and then create the default cert.  Thing 
is I can come up with situations were that can go wrong.


There are a lot of best practices with certificates and crypto that are 
not apparent to most admins.  I know some things for the crypto work I 
do (I am the author of the HIP protocol in the IETF).  There is just not 
one size fits all here, and people need to collect clues along with 
random entropy




___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Low random entropy

2017-05-28 Thread Leon Fauster 
> Am 29.05.2017 um 00:57 schrieb Rob Kampen :
> 
> On 28/05/17 23:56, Leon Fauster wrote:
>>> Am 28.05.2017 um 12:16 schrieb Robert Moskowitz :
>>> 
>>> 
>>> 
>>> On 05/28/2017 04:24 AM, Tony Mountifield wrote:
 In article <792718e8-f403-1dea-367d-977b157af...@htt-consult.com>,
 Robert Moskowitz  wrote:
 Interesting. I just did a quick check of the various servers I support,
 and have noticed that all the CentOS 5 and 6 systems report entropy in
 the low hundreds of bits, but all the CentOS 4 systems and the one old
 FC3 system all report over 3000 bits.
 
 Since they were all pretty much stock installs, what difference between
 the versions might explain what I observed?
>>> This is partly why so many certs found in the U of Mich study are weak and 
>>> factorable.  So many systems have inadequate entropy for the generation of 
>>> key pairs to use in TLS certs.  Worst are certs created in firstboot 
>>> process where at times there is no entropy, but the firstboot still creates 
>>> its certs.
>> 
>> /var/lib/random-seed and $HOME/.rnd are approaches to mitigate this scenario.
>> 
> 
> so there are mitigations - the question really is: why hasn't redhat made 
> these mitigations the default for
> their enterprise products - maybe other influences we are unaware of - seems 
> like a huge big hole. With the
> advent of SSL/TLS being mandated by google et al, every device needs access 
> to entropy.


Who said upstream hasn't done something? :-) The mentioned artifacts are the 
evidence that they are "in place/in use" 
by default. BTW, any crypto-sensitive task needs beside entropy also others 
prerequisites. So, i recommend checking 
the own systems to understand, what upstream respectively the crypto 
functions/libraries etc. actually does/do.

--
LF


  





___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Low random entropy

2017-05-28 Thread Rob Kampen 

On 28/05/17 23:56, Leon Fauster wrote:

Am 28.05.2017 um 12:16 schrieb Robert Moskowitz :



On 05/28/2017 04:24 AM, Tony Mountifield wrote:

In article <792718e8-f403-1dea-367d-977b157af...@htt-consult.com>,
Robert Moskowitz  wrote:

On 05/26/2017 08:35 PM, Leon Fauster wrote:
drops back to 30! for a few minutes.  Sigh.

http://issihosts.com/haveged/

EPEL: yum install haveged

WOW!!!

installed, enabled, and started.

Entropy jumped from ~130 bits to ~2000 bits

thanks

Note to anyone running a web server, or creating certs.  You need
entropy.  Without it your keys are weak and attackable.  Probably even
known already.

Interesting. I just did a quick check of the various servers I support,
and have noticed that all the CentOS 5 and 6 systems report entropy in
the low hundreds of bits, but all the CentOS 4 systems and the one old
FC3 system all report over 3000 bits.

Since they were all pretty much stock installs, what difference between
the versions might explain what I observed?

This is partly why so many certs found in the U of Mich study are weak and 
factorable.  So many systems have inadequate entropy for the generation of key 
pairs to use in TLS certs.  Worst are certs created in firstboot process where 
at times there is no entropy, but the firstboot still creates its certs.


/var/lib/random-seed and $HOME/.rnd are approaches to mitigate this scenario.

--
LF
so there are mitigations - the question really is: why hasn't redhat 
made these mitigations the default for their enterprise products - maybe 
other influences we are unaware of - seems like a huge big hole. With 
the advent of SSL/TLS being mandated by google et al, every device needs 
access to entropy.






___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] test builds on private server updates (drivers, mesa, kernel)

2017-05-28 Thread Andreas Benzler 
Forgotten so say I tested the opensource against the one from AMD.

Both drivers works for me. The AMD Version can be used without my repo.

I look forward to rework wine 2.8 on centos from the spec file of
fedora 25.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] test builds on private server updates (drivers, mesa, kernel)

2017-05-28 Thread Andreas Benzler 
Hello Guys,

while im testing a AMD Radeon RX 480 i was up on my centos 7.

To get the card realy work, I upgrade my repros:

Drivers:

[cms4all-drivers]
name=cms4all-drivers
baseurl=http://centos.cms4all.org/repo/7/drivers/
gpgcheck=0
enabled=1

libdrm -> 2.4.81
libav -> 1.8.2
libav-utils -> 1.8.2

xorg-x11-drv-intel-2.99.917-21.20170418
xorg-x11-drv-nouveau-1.0.15-1
xorg-x11-drv-ati-7.9.0
xorg-x11-drv-amdgpu-1.3.0

ATI and AMDGPU works here, intel stays out here for test.

Mesa:

[cms4all-mesa]
name=cms4all-mesa
baseurl=http://centos.cms4all.org/repo/7/mesa/
#baseurl=file:///srv/repo/centos/7/mesa
gpgcheck=0
enabled=1

Mesa3D, needs drivers because of libdrm 2.4.81

Mesa 17.1.1

Add downgrade patch zlib 2.8 -> 2.7
Add mesa-vaapi as separate package, still problmes with video out on
centos, remove gstreamer1-vaapi to get my videos working. No problem on
other distro (not Fedora). There is a hughe difference gstreamer 1.8
Gnome 3.24.

Kernel:
[cms4all-kernel]
name=cms4all-kernel
baseurl=http://centos.cms4all.org/repo/7/kernel/
gpgcheck=0
enabled=1

kernel 4.11.3

Same as elrpo, but add functions to amdgpu and radeon.

Sincerely

Andy
PS: Still unsigned private builds, take the source if your unshure.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] can't access remote urls from Nautilus...

2017-05-28 Thread Kay Schenk 

ooops! Forgot some details...

Gnome/Nautlus 2.28 on CentOS 6.9--32 bit

On 05/28/2017 10:39 AM, Kay Schenk wrote:

...and this includes the "Help". What am I missing?

Thanks.


--
--
MzK

"Every new beginning comes from some other
 beginning's end."
 -- "Closing Time"
 Semisonic
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] can't access remote urls from Nautilus...

2017-05-28 Thread Kay Schenk 

...and this includes the "Help". What am I missing?

Thanks.
--
--
MzK

"Every new beginning comes from some other
 beginning's end."
 -- "Closing Time"
 Semisonic
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Low random entropy

2017-05-28 Thread Leon Fauster 
> Am 28.05.2017 um 12:16 schrieb Robert Moskowitz :
> 
> 
> 
> On 05/28/2017 04:24 AM, Tony Mountifield wrote:
>> In article <792718e8-f403-1dea-367d-977b157af...@htt-consult.com>,
>> Robert Moskowitz  wrote:
>>> 
>>> On 05/26/2017 08:35 PM, Leon Fauster wrote:
>>> drops back to 30! for a few minutes.  Sigh.
 http://issihosts.com/haveged/
 
 EPEL: yum install haveged
>>> WOW!!!
>>> 
>>> installed, enabled, and started.
>>> 
>>> Entropy jumped from ~130 bits to ~2000 bits
>>> 
>>> thanks
>>> 
>>> Note to anyone running a web server, or creating certs.  You need
>>> entropy.  Without it your keys are weak and attackable.  Probably even
>>> known already.
>> Interesting. I just did a quick check of the various servers I support,
>> and have noticed that all the CentOS 5 and 6 systems report entropy in
>> the low hundreds of bits, but all the CentOS 4 systems and the one old
>> FC3 system all report over 3000 bits.
>> 
>> Since they were all pretty much stock installs, what difference between
>> the versions might explain what I observed?
> 
> This is partly why so many certs found in the U of Mich study are weak and 
> factorable.  So many systems have inadequate entropy for the generation of 
> key pairs to use in TLS certs.  Worst are certs created in firstboot process 
> where at times there is no entropy, but the firstboot still creates its certs.


/var/lib/random-seed and $HOME/.rnd are approaches to mitigate this scenario.

--
LF






___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Low random entropy

2017-05-28 Thread Robert Moskowitz 



On 05/28/2017 04:24 AM, Tony Mountifield wrote:

In article <792718e8-f403-1dea-367d-977b157af...@htt-consult.com>,
Robert Moskowitz  wrote:


On 05/26/2017 08:35 PM, Leon Fauster wrote:

Am 27.05.2017 um 01:09 schrieb Robert Moskowitz :

I am use to low random entropy on my arm boards, not an intel.

On my Lenovo x120e,

cat /proc/sys/kernel/random/entropy_avail

reports 3190 bits of entropy.

On my armv7 with Centos7 I would get 130 unless I installed rng-tools and then 
I get ~1300.  SSH into one and it

drops back to 30! for a few minutes.  Sigh.

Anyway on my new Zotac nano ad12 with an AMD E-1800 duo core, I am seeing 180.

I installed rng-tools and no change.  Does anyone here know how to improve the 
random entropy?

http://issihosts.com/haveged/

EPEL: yum install haveged

WOW!!!

installed, enabled, and started.

Entropy jumped from ~130 bits to ~2000 bits

thanks

Note to anyone running a web server, or creating certs.  You need
entropy.  Without it your keys are weak and attackable.  Probably even
known already.

Interesting. I just did a quick check of the various servers I support,
and have noticed that all the CentOS 5 and 6 systems report entropy in
the low hundreds of bits, but all the CentOS 4 systems and the one old
FC3 system all report over 3000 bits.

Since they were all pretty much stock installs, what difference between
the versions might explain what I observed?


This is partly why so many certs found in the U of Mich study are weak 
and factorable.  So many systems have inadequate entropy for the 
generation of key pairs to use in TLS certs.  Worst are certs created in 
firstboot process where at times there is no entropy, but the firstboot 
still creates its certs.



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Ovirt Hosted-Engine VM iptables

2017-05-28 Thread Gianluca Cecchi 
On Sun, May 28, 2017 at 8:17 AM, Andrew Dent  wrote:

> Hi
>
> I would like to add rules into the iptables of the Hosted Engine VM in
> Ovirt.
>
> the version is oVirt Engine Version: 4.1.1.8-1.el7.centos
> I have tried using the normal process for iptables (iptables-save etc),
> but it seems that the file
> /etc/sysconfig/iptables
> this is ignored in the Ovirt Engine VM.
> How can I add permanent rules into the Engine VM?
>
> Kind regards
>
>
>
> Andrew
>


Hi, probably the oVirt users mailing list would be better than the general
CentOS list; here archives and registration information:
https://lists.ovirt.org/mailman/listinfo/users


That said, the hosted engine setup workflow should give you the option to
configure the firewall too. Didn't you choose that option?
Did you use the provided appliance or did you manage yourself the os
installation and run of engine-setup inside the hosted engine vm?

I suppose you have iptables and not firewalld installed, so that the command

systemctl status firewalld

returns service not found, correct? Otherwise yo uhave to disable firewalld
and enable iptables

For my hosted engine 4.1.1 test setup I have in place firewalld on CentOS
7.3, that is the default using the appliance, and these are the rules if I
run

iptables -S > /tmp/itables-dump.txt

so you can convert them to /etc/sysconfig/iptables rules
Note that the needed rules could change also depending on the oVirt related
services you enable on the engine (eg ovirt-imageio-proxy that needs 54323
port open below, websocket proxy, ecc..)

[root@ractorshe ~]# cat /tmp/iptables-dump.txt
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N FORWARD_IN_ZONES
-N FORWARD_IN_ZONES_SOURCE
-N FORWARD_OUT_ZONES
-N FORWARD_OUT_ZONES_SOURCE
-N FORWARD_direct
-N FWDI_public
-N FWDI_public_allow
-N FWDI_public_deny
-N FWDI_public_log
-N FWDO_public
-N FWDO_public_allow
-N FWDO_public_deny
-N FWDO_public_log
-N INPUT_ZONES
-N INPUT_ZONES_SOURCE
-N INPUT_direct
-N IN_public
-N IN_public_allow
-N IN_public_deny
-N IN_public_log
-N OUTPUT_direct
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j INPUT_direct
-A INPUT -j INPUT_ZONES_SOURCE
-A INPUT -j INPUT_ZONES
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -j FORWARD_direct
-A FORWARD -j FORWARD_IN_ZONES_SOURCE
-A FORWARD -j FORWARD_IN_ZONES
-A FORWARD -j FORWARD_OUT_ZONES_SOURCE
-A FORWARD -j FORWARD_OUT_ZONES
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -j OUTPUT_direct
-A FORWARD_IN_ZONES -i eth0 -g FWDI_public
-A FORWARD_IN_ZONES -g FWDI_public
-A FORWARD_OUT_ZONES -o eth0 -g FWDO_public
-A FORWARD_OUT_ZONES -g FWDO_public
-A FWDI_public -j FWDI_public_log
-A FWDI_public -j FWDI_public_deny
-A FWDI_public -j FWDI_public_allow
-A FWDI_public -p icmp -j ACCEPT
-A FWDO_public -j FWDO_public_log
-A FWDO_public -j FWDO_public_deny
-A FWDO_public -j FWDO_public_allow
-A INPUT_ZONES -i eth0 -g IN_public
-A INPUT_ZONES -g IN_public
-A IN_public -j IN_public_log
-A IN_public -j IN_public_deny
-A IN_public -j IN_public_allow
-A IN_public -p icmp -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 6641 -m conntrack --ctstate NEW -j
ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 6642 -m conntrack --ctstate NEW -j
ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 6100 -m conntrack --ctstate NEW -j
ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 9696 -m conntrack --ctstate NEW -j
ACCEPT
-A IN_public_allow -p tcp -m tcp --dport  -m conntrack --ctstate NEW -j
ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW -j
ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW -j
ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j
ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 54323 -m conntrack --ctstate NEW
-j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 5432 -m conntrack --ctstate NEW -j
ACCEPT
-A IN_public_allow -p udp -m udp --dport 7410 -m conntrack --ctstate NEW -j
ACCEPT

NOTE: 6641 and 6642 are for OVN setup (
http://www.ovirt.org/develop/release-management/features/ovirt-ovn-provider/)
and probably you don't need them

If I run the dump from command "ip6tables -S" and then run a diff with the
former file, you get an hint on how to create also your
/etc/sysconfig/ip6tables file if you are using ipv6

[root@ractorshe ~]# diff /tmp/ip6tables-dump.txt /tmp/iptables-dump.txt
31c31
< -A INPUT -j REJECT --reject-with icmp6-adm-prohibited
---
> -A INPUT -j REJECT --reject-with icmp-host-prohibited
40c40
< -A FORWARD -j REJECT --reject-with icmp6-adm-prohibited
---
> -A FORWARD -j REJECT --reject-with icmp-host-prohibited
49c49
< -A FWDI_public -p ipv6-icmp -j ACCEPT
---
> -A FWDI_public -p icmp -j ACCEPT
58c58,60
< -A

Re: [CentOS] Low random entropy

2017-05-28 Thread Tony Mountifield 
In article <792718e8-f403-1dea-367d-977b157af...@htt-consult.com>,
Robert Moskowitz  wrote:
> 
> 
> On 05/26/2017 08:35 PM, Leon Fauster wrote:
> >> Am 27.05.2017 um 01:09 schrieb Robert Moskowitz :
> >>
> >> I am use to low random entropy on my arm boards, not an intel.
> >>
> >> On my Lenovo x120e,
> >>
> >> cat /proc/sys/kernel/random/entropy_avail
> >>
> >> reports 3190 bits of entropy.
> >>
> >> On my armv7 with Centos7 I would get 130 unless I installed rng-tools and 
> >> then I get ~1300.  SSH into one and it
> drops back to 30! for a few minutes.  Sigh.
> >>
> >> Anyway on my new Zotac nano ad12 with an AMD E-1800 duo core, I am seeing 
> >> 180.
> >>
> >> I installed rng-tools and no change.  Does anyone here know how to improve 
> >> the random entropy?
> >
> > http://issihosts.com/haveged/
> >
> > EPEL: yum install haveged
> 
> WOW!!!
> 
> installed, enabled, and started.
> 
> Entropy jumped from ~130 bits to ~2000 bits
> 
> thanks
> 
> Note to anyone running a web server, or creating certs.  You need 
> entropy.  Without it your keys are weak and attackable.  Probably even 
> known already.

Interesting. I just did a quick check of the various servers I support,
and have noticed that all the CentOS 5 and 6 systems report entropy in
the low hundreds of bits, but all the CentOS 4 systems and the one old
FC3 system all report over 3000 bits.

Since they were all pretty much stock installs, what difference between
the versions might explain what I observed?

Cheers
Tony
-- 
Tony Mountifield
Work: t...@softins.co.uk - http://www.softins.co.uk
Play: t...@mountifield.org - http://tony.mountifield.org
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Ovirt Hosted-Engine VM iptables

2017-05-28 Thread Andrew Dent 

Hi

I would like to add rules into the iptables of the Hosted Engine VM in 
Ovirt.


the version is oVirt Engine Version: 4.1.1.8-1.el7.centos
I have tried using the normal process for iptables (iptables-save etc), 
but it seems that the file

/etc/sysconfig/iptables
this is ignored in the Ovirt Engine VM.
How can I add permanent rules into the Engine VM?

Kind regards



Andrew
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos