Re: Usage of global tables and anchors in PF
On 20 Jun 2017 at 14:17, Alen Mistric wrote:
> Howdy!
>
> I have a global table defined in pf.conf that I would like to use in
> both the main rule set and inside an anchor. However, I keep getting
> a namespace collision when I reload the configuration file. I can't
> quite figure out from reading the man pages if you're not supposed
> to use a global table inside an anchor or if I'm just doing it the
> wrong way. Any ideas?
Unfortunately, this is a known limitation in current PF -- you can use global
tables
in an anchor strictly in read-only mode. Any attempt to modify a table within
an
anchor results in the creation of an anchor-local table with identical name
which
also prevents any subsequent access to the global table.
>
> table persist
> block quick from
>
> pass in proto tcp to port ssh modulate state \
> (max-src-conn-rate 5/3, overload flush global)
>
> anchor "ftp" {
> pass in proto tcp to port ftp modulate state \
> (max-src-conn 2, overload flush global )
> pass in proto tcp to port { 4:5 }
> pass out proto tcp to port ftp
> }
>
Re: Usage of global tables and anchors in PF
Based on a conversation with Henning at BSDCon2017, the limitation is known as
well as the
reasons for its existence, but at this time there is no developer for whom the
pain of the limitation
has exceeded the expected pain of diving into this particular section of the
code.
On 21 Jun 2017 at 23:06, Alen Mistric wrote:
> Ouch, that´s a bummer. Has there been any attempts to try and
> resolve this matter?
>
>
> > 21. jun. 2017 kl. 04.40 skrev Jacob Leifman :
> >
> > On 20 Jun 2017 at 14:17, Alen Mistric wrote:
> >
> >> Howdy!
> >>
> >> I have a global table defined in pf.conf that I would like to use
> in
> >> both the main rule set and inside an anchor. However, I keep
> getting
> >> a namespace collision when I reload the configuration file. I
> can't
> >> quite figure out from reading the man pages if you're not
> supposed
> >> to use a global table inside an anchor or if I'm just doing it
> the
> >> wrong way. Any ideas?
> >
> > Unfortunately, this is a known limitation in current PF -- you can
> use global tables
> > in an anchor strictly in read-only mode. Any attempt to modify a
> table within an
> > anchor results in the creation of an anchor-local table with
> identical name which
> > also prevents any subsequent access to the global table.
> >
> >>
> >> table persist
> >> block quick from
> >>
> >> pass in proto tcp to port ssh modulate state \
> >> (max-src-conn-rate 5/3, overload flush global)
> >>
> >> anchor "ftp" {
> >> pass in proto tcp to port ftp modulate state \
> >>(max-src-conn 2, overload flush global )
> >> pass in proto tcp to port { 4:5 }
> >> pass out proto tcp to port ftp
> >> }
> >>
> >
> >
>
>
Re: Fail2ban alternative for OpenBSD
You might also want to check out http://openports.se/security/sshguard which integrates directly with PF. I find it quite effective. On 29 Oct 2017 at 6:30, x9p wrote: > On 2017-10-29 04:35, Rupert Gallagher wrote: > > Note that PF cannot discriminate between legitimate and abusive > > multiple connections from same cidr. If you whitelist the cidr of a > > mobile network, to avoid banning yourself on port 993, you also > > whitelist bruteforce attacks from the same cidr. > > > > Sent from ProtonMail Mobile > > > > On Sun, Oct 29, 2017 at 5:26 AM, Tom Rosso wrote: > > > >> On 2017-10-28 21:20, x9p wrote: > Hi, > > Coming from the Linux world, > >> I wonder if there is a better alternative > to fail2ban, already being > >> used in OpenBSD servers by the majority. > > cheers. > > x9p The pf > >> firewall provides the capability to block brute force attacks. See > >> max-src-conn-rate. > >> https://www.openbsd.org/faq/pf/filter.html#stateopts > > was suggested http://openports.se/sysutils/sec , which seems the most > proper. > > thanks all for the inputs.. > > cheers. > > x9p > >
Is there an option switch to lower minimum DH strength in SSH client?
I was finally able to bring our OpenBSD based Network Management System up to the current OS release (it was a couple of years out of date) but this process broke access to a large number of older HP switches on our network. Thorough analysis of the problem and study of the source code lead me to believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14: increase the minimum modulus that we will send or accept in diffie-hellman-group-exchange to 2048 bits; Within the file it further explains that this is mitigation for DH precomputation attacks. I understand and appreciate strengthening server code. But this breaks the use of SSH client leaving little recourse other than perhaps telnet with NO encryption instead of somewhat weak encryption, as the "server" is outside of our control. (I already checked that we have the latest firmware, less than one year old.) Curiously, diffie-hellman-group1-sha1, which is the only one supported by the switches, is an accepted KexAlgorithm value in OpenSSH 7.6 (OBSD 6.2); I was hoping that I could use it to explicitly request smaller DH but ultimately it still dies with "Invalid key length" error. Is this an oversight or is there a particular logic to intentionally breaking compatibility with a not-insignificant base of installed equipment? Thank you, Jacob Leifman Educational Technology Weymouth Public Schools -- CONFIDENTIALITY NOTICE: This e-mail message and any attachment to it is intended only for the individual or entity to which it is addressed and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient but do not wish to receive communication through this medium, please advise the sender immediately. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the Weymouth Public Schools. www.weymouthschools.org/
Re: Is there an option switch to lower minimum DH strength in SSH client?
On Fri, Nov 3, 2017 at 9:17 AM, Solène Rapenne wrote: > Je 2017-11-03 05:06, Jacob Leifman skribis: > > I was finally able to bring our OpenBSD based Network Management System up >> to the current OS release (it was a couple of years out of date) but this >> process broke access to a large number of older HP switches on our >> network. >> Thorough analysis of the problem and study of the source code lead me to >> believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14: >> >> increase the minimum modulus that we will send or accept in >> diffie-hellman-group-exchange to 2048 bits; >> >> Within the file it further explains that this is mitigation for DH >> precomputation attacks. I understand and appreciate strengthening server >> code. But this breaks the use of SSH client leaving little recourse other >> than perhaps telnet with NO encryption instead of somewhat weak >> encryption, >> as the "server" is outside of our control. (I already checked that we have >> the latest firmware, less than one year old.) >> >> Curiously, diffie-hellman-group1-sha1, which is the only one supported by >> the switches, is an accepted KexAlgorithm value in OpenSSH 7.6 (OBSD 6.2); >> I was hoping that I could use it to explicitly request smaller DH but >> ultimately it still dies with "Invalid key length" error. >> >> Is this an oversight or is there a particular logic to intentionally >> breaking compatibility with a not-insignificant base of installed >> equipment? >> >> Thank you, >> >> Jacob Leifman >> Educational Technology >> >> Weymouth Public Schools >> > > Hello, > > I'm not sure if it's what you ask but I had a problem with old ssh clients > not able to connect to a recent ssh server after a system upgrade. I had to > add this to my sshd config (on the server) to allow them to connect : > > > KexAlgorithms +diffie-hellman-group1-sha1 > Ciphers +aes128-cbc > > Regards > Hi, Not quite, I have the converse problem -- using the modern ssh client and being unable to connect to an older embedded ssh server. But your solution indicates that in the ssh server implementation the explicit compatibility mode actually works. I find the incongruity between server and client approaches to backwards compatibility rather odd, since it is generally much easier to upgrade or replace a client application (end-user software) than the server application, especially embedded server as in my case. -Jacob. -- CONFIDENTIALITY NOTICE: This e-mail message and any attachment to it is intended only for the individual or entity to which it is addressed and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient but do not wish to receive communication through this medium, please advise the sender immediately. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the Weymouth Public Schools. www.weymouthschools.org/
Re: Is there an option switch to lower minimum DH strength in SSH client?
On Fri, Nov 3, 2017 at 8:37 AM, Janne Johansson wrote: > 2017-11-03 5:06 GMT+01:00 Jacob Leifman >: > >> I was finally able to bring our OpenBSD based Network Management System up >> to the current OS release (it was a couple of years out of date) but this >> process broke access to a large number of older HP switches on our >> network. >> > > >> But this breaks the use of SSH client leaving little recourse other >> than perhaps telnet with NO encryption instead of somewhat weak >> encryption, >> as the "server" is outside of our control. (I already checked that we have >> the latest firmware, less than one year old.) >> >> Is this an oversight or is there a particular logic to intentionally >> breaking compatibility with a not-insignificant base of installed >> equipment? >> >> > If your vendor, even with a <1y firmware still only can handle old and > deprecated > keysizes, you should not ask for everyone elses sshs to become worse, but > rather > push the vendor to get up to speed, and since that will not work, you will > have to > resort to building older ssh and use that instead of the safer one that > comes with > the modern OS you upgraded to. > > Same goes for browsers and https, the bad parts of SSL/TLS gets weeded out > in browsers > so that the majority of users are safe, not kept to cater to the lowest > common denominator > of the laziest vendor still alive. > > You should be asking HP how come they can't keep the free sshd code > updated, > if security is your prime concern, not ask openbsd to lower everyone elses > security. > I am not asking to lower anyone else's security or for SSH to "become worse", I appreciate the default behavior being what it is. I am asking about a way to have an explicit compatibility mode -- even if we are successful at lobbying a behemoth like HP for an update, it will take time, probably a lot of time. Nor is a chronically underfunded public school district in the position to outright replace >$500K worth of switches that do their primary duties without fail. Not having some kind of compatibility mode, leaves me with choice of bad and worse. Typical K-12 management neither understands tech nor can afford to divert funds to "frivolous" upgrades. Their inevitable response is either "don't upgrade" or "choose another product", a product that will not have even the basic security level OpenBSD had say three years ago. > > -- > May the most significant bit of your life be positive. > -- CONFIDENTIALITY NOTICE: This e-mail message and any attachment to it is intended only for the individual or entity to which it is addressed and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient but do not wish to receive communication through this medium, please advise the sender immediately. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the Weymouth Public Schools. www.weymouthschools.org/
Re: Meltdown workaround enabled?
On 13 Mar 2018 at 16:57, Mike Larkin wrote: > On Tue, Mar 13, 2018 at 06:20:16PM -0500, Brian Camp wrote: > > On Tue, Mar 13, 2018 at 4:41 PM, Mike Larkin wrote: > > > On Tue, Mar 13, 2018 at 02:23:29PM -0700, Mike Larkin wrote: > > >> On Tue, Mar 13, 2018 at 08:27:49AM -0500, Brian Camp wrote: > > >> > On Tue, Mar 13, 2018 at 2:29 AM, Mike Larkin > > >> > wrote: > > >> > > On Sun, Mar 11, 2018 at 04:33:49PM -0500, Brian Camp wrote: > > >> > >> I have two systems running 6.2-stable with the meltdown syspatch > > >> > >> installed. I noticed that while one of them lists "MELTDOWN" in the > > >> > >> CPU flags, the other does not. The one that does not has a Celeron > > >> > >> J3455, which Intel lists as affected by meltdown. > > >> > >> > > >> > >> Does the absence of the MELTDOWN flag mean that the workaround isn't > > >> > >> functioning on this machine? Dmesg below. > > >> > >> > > >> > >> > > >> > >> Thanks > > >> > >> > > >> > >> -Brian > > >> > >> > > >> > > > > >> > > Odd. Two of us have looked at the detection code again and we can't > > >> > > see any > > >> > > issues. Can you please do the following to help diagnose? > > >> > > > > >> > > 1. install the "cpuid" port package? > > >> > > > > >> > > pkg_add cpuid > > >> > > > > >> > > 2. send the output of: > > >> > > > > >> > > cpuid 0x0 > > >> > > cpuid 0x7 > > >> > > > > >> > > On each of the two machines? (Make sure to say which is the working > > >> > > one > > >> > > and which is the one where meltdown isn't properly being detected). > > >> > > > > >> > > Thanks. > > >> > > > > >> > > -ml > > >> > > > >> > Sure thing. > > >> > > > >> > Working (i5-4690) - > > >> > > > >> > bcamp@z97x-sli:~ (OpenBSD 6.2) > > >> > $ cpuid 0x0 > > >> > eax = 0x000d13"" > > >> > ebx = 0x756e65471970169159"Genu" > > >> > ecx = 0x6c65746e1818588270"ntel" > > >> > edx = 0x49656e691231384169"ineI" > > >> > bcamp@z97x-sli:~ (OpenBSD 6.2) > > >> > $ cpuid 0x7 > > >> > eax = 0x 0"" > > >> > ebx = 0x27ab 10155"?'??" > > >> > ecx = 0x 0"" > > >> > edx = 0x 0"" > > >> > bcamp@z97x-sli:~ (OpenBSD 6.2) > > >> > $ > > >> > > > >> > Non-working (Celeron J3455) - > > >> > > > >> > bcamp@nuc6cayh:~ (OpenBSD 6.2) > > >> > $ cpuid 0x0 > > >> > eax = 0x001521"" > > >> > ebx = 0x756e65471970169159"Genu" > > >> > ecx = 0x6c65746e1818588270"ntel" > > >> > edx = 0x49656e691231384169"ineI" > > >> > bcamp@nuc6cayh:~ (OpenBSD 6.2) > > >> > $ cpuid 0x7 > > >> > eax = 0x 0"" > > >> > ebx = 0x2294e283 580182659"???"" > > >> > ecx = 0x 0"" > > >> > edx = 0x2c00 738197504"???," > > >> > bcamp@nuc6cayh:~ (OpenBSD 6.2) > > >> > $ > > >> > > > >> > > > >> > -Brian > > >> > > > >> > > >> As naddy@ pointed out in the earlier reply, this behaviour indicates > > >> that for > > >> some reason your CPU is saying it's not vulnerable. The 0x2c in edx for > > >> cpuid > > >> 0x7 in the J3455 case in your mail indicates the firmware (bios) says > > >> that > > >> the IA32_ARCH_CAPABILITIES MSR is available. We read that and if bit 1 > > >> is set, > > > > > > Meant "bit 0" there. > > > > > > -ml > > > > > >> it means the CPU is not susceptible to "RDCL" (RDCL_NO = not susceptible > > >> to > > >> "Rogue Data Cache Load" ala Meltdown). > > >> > > >> Can you apply this diff and boot the J3455 machine and send the boot > > >> dmesg > > >> after applying it (apply to -current, please). This caches what answer > > >> we saw > > >> during boot and will tell us if the CPU is reporting garbage there. > > > > Patch applied to -current and the resulting dmesg attached. > > > > >> > > >> PS - you might also try looking for a newer BIOS, although this machine > > >> BIOS is > > >> listed as 08 Jan 2018, it's possible that was applied during that short > > >> period where Intel was releasing broken firmware updates. I'd appreciate > > >> it > > >> however if you booted with the diff below, first, before trying that. > > >> > > > > Thats actually the latest version. Even though this board is made by > > Intel itself, they have yet to release a BIOS update with the patched > > microcode that other OEMs are shipping. > > > > Thanks > > > > -Brian > > > > > > OpenBSD 6.3-beta (GENERIC.MP) #0: Tue Mar 13 18:01:15 CDT 2018 > > > > bc...@nuc6cayh.int.thecamps.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 8411357184 (8021MB) > > avail mem = 8149372928 (7771MB) > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x79aa1000 (51 entries) > > bios0: vendor Intel Corp. version "AYAPLCEL.86A.0047.2018.0108.1419" > > date 01/08/2018 > > bios0: Intel Corporation NUC6CAYH > > acpi0 at bios0: rev 2 > > acpi0: sleep states S0 S3 S4 S5 > > acpi0: tables DSDT FACP FPDT
