similar to: easy way to stop old ssl's

On 11.10.19 22:40, Warren Young wrote: > On Oct 11, 2019, at 12:12 PM, Jerry Geis <jerry.geis at gmail.com> wrote: >> >> is there a script that is available that can be ran to bring >> a box up to current "accepted" levels ? > > I don?t know why you?d use a script for this at all. Just ship a new HTTPS configuration to each server. Apache loads all

On Oct 12, 2019, at 4:06 AM, Markus Falb <markus.falb at fasel.at> wrote: > > On 11.10.19 22:40, Warren Young wrote: >> Just ship a new HTTPS configuration to each server. > > Instead of configuring every application separataly it would be nice if > "accepted levels of security" could be set system wide. ?which implies that there is some authority that

On 12.10.19 19:33, Warren Young wrote: > On Oct 12, 2019, at 4:06 AM, Markus Falb <markus.falb at fasel.at> wrote: >> >> On 11.10.19 22:40, Warren Young wrote: >>> Just ship a new HTTPS configuration to each server. >> >> Instead of configuring every application separataly it would be nice if >> "accepted levels of security" could be set

On Oct 11, 2019, at 12:12 PM, Jerry Geis <jerry.geis at gmail.com> wrote: > > is there a script that is available that can be ran to bring > a box up to current "accepted" levels ? I don?t know why you?d use a script for this at all. Just ship a new HTTPS configuration to each server. Apache loads all *.conf files in its configuration directory, so you might be able to

Hi, I am running the below servers on Red Hat Enterprise Linux release 8.7 (Ootpa). The details are as follows. # rpm -qa | grep openssh openssh-8.0p1-16.el8.x86_64 openssh-askpass-8.0p1-16.el8.x86_64 openssh-server-8.0p1-16.el8.x86_64 openssh-clients-8.0p1-16.el8.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 8.7 (Ootpa) # How do I enable strong KexAlgorithms, Ciphers and

On 25.01.24 14:09, Kaushal Shriyan wrote: > I am running the below servers on Red Hat Enterprise Linux release 8.7 > How do I enable strong KexAlgorithms, Ciphers and MACs On RHEL 8, you need to be aware that there are "crypto policies" modifying sshd's behaviour, and it would likely be the *preferred* method to inject your intended config changes *there* (unless they

On Oct 11, 2019, at 2:52 PM, isdtor <isdtor at gmail.com> wrote: > >> Yes, breaking changes. Doing this *will* cut off support for older browsers. On purpose. > > Old browsers aren't really the problem. Even ff 45 (?) from CentOS5 will happily access a TLSv1.2-only server. IE 10 and older won?t, though: https://caniuse.com/#feat=tls1-2 > The problem is user that

> Yes, breaking changes. Doing this *will* cut off support for older browsers. On purpose. Old browsers aren't really the problem. Even ff 45 (?) from CentOS5 will happily access a TLSv1.2-only server. The problem is user that have old versions of software installed with no TLSv1.2 support. SVN, python 2.7 scripts, etc.

Without context it's impossible to make firm statements but, having gone through this a while back (and discovering that less than 1 percent of an examined list of connections couldn't support current ssl - mainly Apple hardware), who do you want to protect? Is it the minority who won't/can't upgrade or the majority who have? And, do you have to protect yourself from liability

I've been making my own custom RHEL / CentOS boot CDs for years, and all of the instructions for such work call out to take a distro's CD, and copy key files from it. Among those files are those that I think are associated with the the SYSLINUX/ISOLINUX project; e.g.: http://mirror.centos.org/centos/6/os/x86_64/images/ http://mirror.centos.org/centos/6/os/x86_64/isolinux/ Two

On 10/13/2015 01:40 PM, Brian Reichert wrote: > On Tue, Oct 13, 2015 at 12:51:07PM -0400, Brian Reichert wrote: >> On Tue, Oct 13, 2015 at 11:42:08AM -0500, Johnny Hughes wrote: >>> The info you are looking at there is for CentOS-7 .. the syslinux for >>> CentOS-6 is here: >>> >>>

On Tue, Oct 13, 2015 at 11:42:08AM -0500, Johnny Hughes wrote: > The info you are looking at there is for CentOS-7 .. the syslinux for > CentOS-6 is here: > > http://vault.centos.org/6.7/os/Source/SPackages/syslinux-4.04-3.el6.src.rpm > > The CentOS team did not modify that source code, we just built it as is. > > That source code produces the syslinux binary used by

On Tue, Oct 13, 2015 at 12:03:00PM -0400, Jonathan Billings wrote: > On Tue, Oct 13, 2015 at 11:38:06AM -0400, Brian Reichert wrote: > > Does anyone have any insight on these topics, or, at the very least, > > a better forum to pursue them? > > The patches used to build the latest syslinux package for CentOS7 are > here: > >

First off, I have to admit that I'm uncertain if this is the appropriate forum; I'd be happy for suggestions about where else to look. I'm doing this work on a stock install of CentOS-7-x86_64-Minimal-1810.iso, with no updates. I'm trying to create an RPM database from a custom set of RPMs. One RPM ('openldap-ltb' from the LDAP Tool Box project (ltb-project.org) has a

Everyone, I have been working on a new installation of CentOS 5.0 on a x86_64 machine. The installation has gone well except for httpd. When I start httpd with LogLevel turned to debug all I get is an immediate failure with the following errors the logs: /var/log/httpd/error_log: [Sun Jul 22 13:00:31 2007] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) /var/log/ssl_error.log:

On Tue, Oct 13, 2015 at 03:18:16PM -0500, Johnny Hughes wrote: > On 10/13/2015 01:40 PM, Brian Reichert wrote: > > On Tue, Oct 13, 2015 at 12:51:07PM -0400, Brian Reichert wrote: > >> On Tue, Oct 13, 2015 at 11:42:08AM -0500, Johnny Hughes wrote: > >>> The info you are looking at there is for CentOS-7 .. the syslinux for > >>> CentOS-6 is here: >

http://bugs.freedesktop.org/show_bug.cgi?id=23495 Summary: nouveau KMS produces no output on a Dell 3008WFP monitor Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at

I have asked this before in -questions but due to a odd security requirement, I need the option to auto lock a normal user's account (root and those in the wheel group must be excluded) after let say, 3, login failures. I know this can cause a DoS issue but I HAVE to have the option of doing it in FreeBSD. Any info is appreciated Thanks. Mike C carlson39@llnl.gov

Hello. I once read somewhere that it's possible to limit SSH pubkeys to 'tunnel-only'. I can't seem to find any information about this in any of the usual places. I'm going to be deploying a few servers in a couple of days and I'd like them to log to a central server over an SSH tunnel (using syslog-ng) however I'd like to prevent actual logins (hence

I'm forwarding this to security@, as I'm getting no replies on ipfw@. Hope it's relevant enough for you :( ---Original Message----- From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd-ipfw@freebsd.org] On Behalf Of Erik Paulsen Skålerud Sent: Wednesday, May 28, 2003 1:02 AM To: ipfw@freebsd.org Subject: Question about logging. Sorry for asking this, It's probably been