There are many excellent suggestions on how to deal with invalid/unauthorised
access attempts via ssh. I'd used sshguard for around 8 months but recently
changed to bruteblock, both are in the ports/security. sshguard was very easy
to configure, via rc.conf arguments. Bruteblock handled the
Do the changes to libc imply that community members that install and build
their system using gcc 4.2.2+ will remain vulnerable?
If so, should the /usr/src/UPDATING reflect this ongoing exposure?
(I note that 8.2S uses gcc version 4.2.2 20070831 prerelease [FreeBSD]
9.0S has gcc 4.2.1)
Kind rega
> And as a flip side to the argument, is there a reason not to
> raise the default to 4096? Certainly the same advances in
> processors makes this size key quite usable. I've seen no
> noticeable slowness with 4096 bit RSA or 521 bit ECDSA.
Robert, A good question and it's good to check under
Michael,
I think you'll find that the cipher selection is based on negotiation
between the client & server. Perhaps if you examine the config files, or
ascertain the defaults of the applications being used, you'll be able to
pin-point the reason for the selection.
Regards, Dewayne.
Paul,
This is akin to dd if=/dev/ada0s1b of=/tmp/File
Where ada01b is the swap partition and then reading through the output. Its
really nothing to be concerned about, and not worth
zeroing the page for :)
Regards, Dewayne.
___
freebsd-security@freeb
An excellent example of where swap shouldn't be used. It isn't the use of the
swap file that is the issue, it is how the output of
using swap is used. PHK was right in his advice to not use swap.
Good catch, nanobsd.sh should be changed.
___
freebsd-
> -Original Message-
> From: owner-freebsd-secur...@freebsd.org
> [mailto:owner-freebsd-secur...@freebsd.org] On Behalf Of
> pr...@cc.ttu.ee
> Sent: Tuesday, 11 June 2013 1:10 AM
> To: freebsd-security@freebsd.org
> Subject: libarchive and MAC labels
>
> I've created a patch for libarchi
> -Original Message-
> From: owner-freebsd-secur...@freebsd.org
> [mailto:owner-freebsd-secur...@freebsd.org] On Behalf Of Xin Li
> Sent: Friday, 23 August 2013 5:15 AM
> To: freebsd-security@freebsd.org
> Cc: freebsd...@freebsd.org; k...@freebsd.org
> Subject: Allowing tmpfs to be mounted
John,Ollivier,
I've found the openssl speed tests to be an unreliable measure of comparison.
I think you might be better served by comparing the
performance of encrypting/decrypting content, such as
dd if=/dev/zero bs=1M count=100 | openssl aes-128-cbc -e -pass pass:secretpwd |
\
openssl aes
On 13/04/2014 6:09 PM, Christian Kratzer wrote:
> Hi,
>
> apparentyly openbsd has more or less silently fixed an older openssl
> issue that has been stuck in the openssl bug tracker:
>
> The openbsd patch:
>
> http://www.openbsd.org/errata55.html#004_openssl
>
>
> http://ftp.openbsd.org/pub
Thank-you for engaging us John-Mark. If you're referring to:
geli:
In our case, there are no-local users, and we provide customers with
jailed environments where the disks are stratified, so only those
elements that need encryption get it, and the algorithm is chosen
depending on the criticality
I agree with Dan's comments as I don't really see the value in divesting
blanket "trust" to another party. But I appreciate the heads-up from
Xin Li, so I have the opportunity of moving my certs/CA/keys to a
different location.
___
freebsd-security@freeb
On 10/10/2014 1:44 AM, Hans Petter Selasky wrote:
> On 10/09/14 15:59, Oliver Pinter wrote:
>> On 10/9/14, Hans Petter Selasky wrote:
>>> Hi Julian,
>>>
>>> On 10/09/14 01:46, Julian H. Stacey wrote:
Hi Hans etc
"Julian H. Stacey" wrote:
> Hans Petter Selasky wrote:
>> Hi,
>
On 21/11/2014 8:35 AM, John-Mark Gurney wrote:
> As I'm about to commit my AES-GCM work, I've been trying to do
> some testing to make sure I didn't break IPsec.
>
> The first major issue I ran across was transport mode... ae@ has been
> nice enough to get ICMP working in transport mode for IPv4
Slawa,
Heimdal is (and has been for some time) undergoing constant development.
For reasons unknown, they do not perform releases. I am aware of updates
from heimdal that are being applied to the samba project (in fact some of
the samba developers are also feeding into heimdal). The latest discus
Begs the question-what impact to FreeBSD distribution or use will US export
control laws have, if FreeBSD migrated to MIT Kerberos?
--
*Disclaimer:*
*As implied by email protocols, the information in this message is not
confidential. Any intermediary or recipient may inspect, modify (add),
cop
On 14 March 2017 at 09:06, Steven Chamberlain wrote:
> From this document (TOP SECRET//SI//NOFORN):
> https://wikileaks.org/ciav7p1/cms/files/NOD%20Cryptographic%
> 20Requirements%20v1.1%20TOP%20SECRET.pdf
>
> version 1.0 said:
>
> | 8. (S//NF) [...] If RC4 is used, at least the first 1024
> | by
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
I was about to send to @freebsd-stable until I realised that there are
security implications for folks that may be using this, thinking that
their confidential material is protected, which may not be entirely correct.
---
Would appreciate others testing/confirming TCP over ESP as it seems to
have
On 6/12/2017 8:13 AM, Yuri wrote:
> On 12/05/17 13:04, Eugene Grosbein wrote:
>> It is illusion that https is more secure than unencrypted http in a
>> sense of MITM
>> just because of encryption, it is not.
>
>
> It *is* more secure. In order to break it, you have to have
> compromized https autho
On 26/07/2018 9:45 PM, PRAKASH RAI (prakrai) via freebsd-security wrote:
> Hi All,
>
> I was going through the https://wiki.freebsd.org/OpenSSL and found that
> openssl 1.1.1 support is planned for freeBSD 12.
> As TLSv1.3 is based on openssl 1.1.1, does it mean that freeBSD 11.X would
> not be
I want to have a secure platform, but would not like to degrade performance
(amd64 based systems)
If everything that a user touches is in a jail (sendmail, dovecot, squid,
httpd, ...), and each jail is running at secure level 3 AND there are no
/dev/mem nor /dev/kmem devices accessible within the
I'm on a similar ride. We run applications in both i386 and amd64 jails
with FreeBSD's ASLR enabled (sendmail, squid, apache, ...) and all good.
On the build server, the i386 jail with aslr enabled wasn't able to
build gcc9; so this was disabled kern.elf32.*.
ntp was the only real application th
020 at 04:19, Dewayne Geraghty
> wrote:
>>
>> I'm on a similar ride. We run applications in both i386 and amd64 jails
>> with FreeBSD's ASLR enabled (sendmail, squid, apache, ...) and all good.
>
> Great!
>
>> On the build server, the i386 jail with a
It would be palatable to have a "secure.mk" under /usr/ports/Mk/Uses
that enables pie, relro, now, noexecstack and elfctl features. Then
port users can enable/disable their (elfctl) default features as they wish.
I look forward to removing long lists of category/ports from my
make.conf that make
Thank-you Ed. Though I have two questions:
1. We've recompiled all the ports I use with either -fPIC or -fPIE and
the linker flag -pie. Is there something required for ports to utilise
these changes, or are the changes only in the mk files affecting the
base system build?
2. I've also taken adva
I'm unsure of how to proceed regarding the vulnerability notifications
at http://www.cnnvd.org.cn/ which affects all lua and luajit versions on
FreeBSD. Normally I'd wait for the US CERT notification. However lua is
part of the base FreeBSD and per /usr/src/contrib/lua/README we're using
lua 5.3.5
The prevailing paradigm is that a package install requires an affirming
action in rc.conf. Neither of "man pkg-add" nor "pkg-install" explicitly
states that an installed package will do other than perform installation
and updating steps. At best, it is implied that installation scripts
are run by
Thank-you Ed, for providing a window for discussion.
As much as I strongly agree with Dave Cottlehuber , there is sadly a
pragmatic dimension. So, off by default goes some way to improve the
world, but folk do appear to need to be able to connect to "antique"
equipment that they have no mechanism
29 matches
Mail list logo
