Re: root access after failed fsck
On 20/02/2016 12:52 μμ, arrowscr...@mail.com wrote: Wow, that's new to me. Thanks. Anyway, I still think that this "password rescue" should not be allowed by default. I know operating systems can do very little to prevent physical problems like side-channel attacks, but this is not the case, and this does not mean that the OS should not make it harder the attacks even if someone have physical access. There's systems, from what I remember (HP servers, I think), that allow remote control based on firmware. One could use this escape "feature" to get your root, without physical access. Same for hosts services. Also, the page 14.21 from faq say "I forgot my passphrase! Sorry. This is real encryption, there's not a back door or magic unlocking tool." why exactly the root should be different? If one lost his passphrase, it's his fault. I thought the philosophy was "secure by default", even if this make the "computer difficult to manage properly". Moreover, this is also the case with most Linux distro's you've probably used in your life. You may have to enter a password on some distro's when in single-user mode, but grub is almost always passwordless, which means you can edit it to set /bin/bash as init, which basically bypasses all such "restrictions". Secure by default does not mean that everything is hardened, as this wouldn't be that practical either. One could argue that file system permissions on binary and library folders could be more strict, or that systrace should have been setup and configured by default, but I think that this by far exceeds what a "secure OS" would be and enforces probable restrictions on sysadmins that they may not want to adhere to. I don't think that the goal of a proactively secure OS like OpenBSD is to be configured to be hardened by default so as to be used by expert or non-expert admins to feel safer, because that would be more misleading than helpful, as Stuart suggested. The goal is to have a generically safe OS where program crashes don't result in privilege escalation that easily and whose code is designed and written with security in mind to reduce vulnerabilities. It's the sysadmins' responsibility to further "secure" their installations and chose which features they'd further add which would probably make OS maintenance more difficult. Having said that, to my understanding, securing physical access by asking the pass phrase in single-user mode in an OS would be more than a marketing thing rather than a security feature per-se. George.
Re: OpenBSD 5.8 ikev2 road warrior setup with various clients
Since, as it seems, this list is not the appropriate place for asking ikev2 related questions, could anybody please direct me as to where such a place would be (mailing list, irc, etc.)? Thanks again! On 17/02/2016 11:57 πμ, George Mamalakis wrote: On 16/02/2016 11:59 πμ, George Mamalakis wrote: Hi all! I'm trying to configure an ikev2 VPN gateway on my OpenBSD 5.8 box to allow remote access to my local network from various, road-warrior client "types" (MS Windows, Linux's, BSD's). My example local network is 10.0.0.0/24 and my public IP (egress) is 1.2.3.4. I've read various guides on the Internet regarding analogous setups, but all of them were discussing about MS Windows clients. I'm trying to test my setup with an OpenBSD 5.8 client but I fail, and next I'd like to test it with a FreeBSD and a Linux client to see if it works. My /etc/iked.conf looks like this: ikev2 passive esp \ from 10.0.0.0/24 to 10.10.10.0/24 local 1.2.3.4 peer any \ psk mypass \ config address 10.10.10.5 My client's /etc/iked.conf looks like this: ikev2 active esp \ from 10.10.10.0/24 to 10.0.0.0/24 peer 1.2.3.4 \ psk lala123 which is based on an old email of this list (at around 2012), and as I explained earlier, it doesn't work. What happens is that when I try to access 10.0.0.1 from my client, the specific traffic is not passing from enc0 but is rather passing directly from the egress interface to its default route. Now, as it seems, this is a routing/flows issue, but I am unsure as to how to address it. ipsecctl -sa on both machines looks good (or at least I think it does): server: # ipsecctl -sa FLOWS: flow esp in from 10.10.10.0/24 to 10.0.0.0/24 peer 5.6.7.8 srcid FQDN/1.2.3.4 dstid FQDN/5.6.7.8 type use flow esp out from 10.0.0.0/24 to 10.10.10.0/24 peer 5.6.7.8 srcid FQDN/1.2.3.4 dstid FQDN/5.6.7.8 type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x3ebcc647 auth hmac-sha2-256 enc aes-256 esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x736c382f auth hmac-sha2-256 enc aes-256 client: # ipsecctl -sa FLOWS: flow esp in from 10.0.0.0/24 to 10.10.10.0/24 peer 1.2.3.4 srcid FQDN/5.6.7.8 dstid FQDN/1.2.3.4 type use flow esp out from 10.10.10.0/24 to 10.0.0.0/24 peer 1.2.3.4 srcid FQDN/5.6.7.8 dstid FQDN/1.2.3.4 type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x3ebcc647 auth hmac-sha2-256 enc aes-256 esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x736c382f auth hmac-sha2-256 enc aes-256 As inferred, my client's public IP is 5.6.7.8, and on both machines ip forwarding is enabled (pf allows all traffic as well). Any help would be greatly appreciated, and directions towards an analogous, working, client setup for FreeBSD and Linux would be equally appreciated. Thanks all in advance, George. I've also tried a different setup (without an internal network) which works for about a minute or so, and then it stops. server: # cat /etc/iked.conf ikev2 passive esp \ from 10.0.0.0/24 to 0.0.0.0/0 local 1.2.3.4 peer any \ psk mypass # cat /etc/ipsec.conf flow esp out from 10.0.0.0/24 to 10.0.0.0/24 type bypass client: # cat /etc/iked.conf ikev2 active esp \ from 0.0.0.0/0 to 10.0.0.0/24 peer 1.2.3.4 \ psk mypass With this configuration, both client and server are able to access 10.0.0.0/24 (by adding the extra flow in server's /etc/ipsec.conf and loading it via ipsecctl -f /etc/ipsec.conf), but after a minute or so the setup stops working. Traffic is reaching the server's enc0 interface and replies are sent to the client via enc0, but the client's udp port which used to accept packets becomes unreachable (closes for some reason): 08:00:27:ee:e7:fd 08:00:27:59:7c:d4 0800 178: 1.2.3.4.52586 > 5.6.7.8.58353: udp 136 08:00:27:59:7c:d4 08:00:27:ee:e7:fd 0800 70: 5.6.7.8 > 1.2.3.4: icmp: 5.6.7.8 udp port 58353 unreachable I'm not sure that running: # iked -vvd & on both machines, reveals not additional information, except that the client checks both incoming and outgoing SA, whereas the server checks only the incoming: client: ikev2_init_ike_sa: "policy1" is already active ikev2_ike_sa_alive: outgoing CHILD SA spi 0x243b7395 last used 54 second(s) ago pfkey_sa_last_used: last_used 1455636797 ikev2_ike_sa_alive: incoming CHILD SA spi 0x2ee69c30 last used 54 second(s) ago ikev2_init_ike_sa: "policy1" is already active pfkey_sa_last_used: last_used 1455636860 ikev2_ike_sa_alive: outgoing CHILD SA spi 0x243b7395 last used 51 second(s) ago pfkey_sa_last_used: last_used 1455636860 ikev2_ike_sa_alive: incoming CHILD SA spi 0x2ee69c30 last used 51 second(s) ago server: pfkey_sa_last_used: last_used 1455636795 ikev2_ike_sa_alive: incoming CHILD SA spi 0x243b7395 last used 54 second(s) ago pfkey_sa_last_used: last_used 1455636858 ikev2_ike_sa_alive: incoming CHILD SA spi 0x243b7395 last used 51 second(s) ago Thanks all for your time and he
Re: root access after failed fsck
As in all BSD's I know of, edit /etc/ttys (as root) and change console to be insecure (it defaults to "secure"). This way you'll be asked for a password when in single user mode. This is no security issue, it is how single user mode "operates" and it's configurable. George. PS. Be sure you won't forget your root's password :). PS2. Physical access to a box (which is usually implied when running in single user mode) can almost certainly lead to a compromised machine. On 20/02/2016 10:59 πμ, arrowscr...@mail.com wrote: Some minutes ago I had a energy blackout here in my city. I was running OpenBSD. When I booted after energy came back, the system did the usual fsck. But this time something went wrong and he just escaped to root, without asking for any passphrase. The system did a question like "point the path to sh", and I just typed "/bin/sh" and he gained access to root. I think this is a serious security problem folks. I have softraid_crypto, so no problem for me, but one could (probably) induce this failure to access root when no FDE configured and he have physical access (or remove, who know with all these Intel AMT microcodes). The /var/log/ have none logs about it, all I can show is the dmesg (if you need more information, just ask): OpenBSD 5.9-beta (GENERIC.MP) #1864: Mon Jan 25 19:11:29 MST 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16481857536 (15718MB) avail mem = 15978151936 (15237MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe98e0 (94 entries) bios0: vendor American Megatrends Inc. version "1601" date 11/27/2013 bios0: ASUSTeK COMPUTER INC. P8H61-M LX2 R2.0 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG SSDT BGRT SSDT SSDT DMAR acpi0: wakeup devices P0P1(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PEGP(S4) PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) PXSX(S4) RP04(S4) PXSX(S4) RP03(S4) PS2K(S4) PS2M(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz, 3200.43 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz, 3200.03 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz, 3200.02 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz, 3200.02 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 2 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus 1 (PEG0) acpiprt5 at acpi0: bus -1 (PEG1) acpiprt6 at acpi0: bus -1 (PEG2) acpiprt7 at acpi0: bus -1 (PEG3) acpiprt8 at acpi0: bus 5 (RP04) acpiprt9 at acpi0: bus 3 (RP03) acpiprt10 at acpi0: bus 4 (PXSX) acpiec0 at acpi0: not present acpicpu0 at acpi0: C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpipwrres1 at acpi0: FN01, resource for FAN1 acpipwrres2 at
Re: OpenBSD 5.8 ikev2 road warrior setup with various clients
On 16/02/2016 11:59 πμ, George Mamalakis wrote: Hi all! I'm trying to configure an ikev2 VPN gateway on my OpenBSD 5.8 box to allow remote access to my local network from various, road-warrior client "types" (MS Windows, Linux's, BSD's). My example local network is 10.0.0.0/24 and my public IP (egress) is 1.2.3.4. I've read various guides on the Internet regarding analogous setups, but all of them were discussing about MS Windows clients. I'm trying to test my setup with an OpenBSD 5.8 client but I fail, and next I'd like to test it with a FreeBSD and a Linux client to see if it works. My /etc/iked.conf looks like this: ikev2 passive esp \ from 10.0.0.0/24 to 10.10.10.0/24 local 1.2.3.4 peer any \ psk mypass \ config address 10.10.10.5 My client's /etc/iked.conf looks like this: ikev2 active esp \ from 10.10.10.0/24 to 10.0.0.0/24 peer 1.2.3.4 \ psk lala123 which is based on an old email of this list (at around 2012), and as I explained earlier, it doesn't work. What happens is that when I try to access 10.0.0.1 from my client, the specific traffic is not passing from enc0 but is rather passing directly from the egress interface to its default route. Now, as it seems, this is a routing/flows issue, but I am unsure as to how to address it. ipsecctl -sa on both machines looks good (or at least I think it does): server: # ipsecctl -sa FLOWS: flow esp in from 10.10.10.0/24 to 10.0.0.0/24 peer 5.6.7.8 srcid FQDN/1.2.3.4 dstid FQDN/5.6.7.8 type use flow esp out from 10.0.0.0/24 to 10.10.10.0/24 peer 5.6.7.8 srcid FQDN/1.2.3.4 dstid FQDN/5.6.7.8 type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x3ebcc647 auth hmac-sha2-256 enc aes-256 esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x736c382f auth hmac-sha2-256 enc aes-256 client: # ipsecctl -sa FLOWS: flow esp in from 10.0.0.0/24 to 10.10.10.0/24 peer 1.2.3.4 srcid FQDN/5.6.7.8 dstid FQDN/1.2.3.4 type use flow esp out from 10.10.10.0/24 to 10.0.0.0/24 peer 1.2.3.4 srcid FQDN/5.6.7.8 dstid FQDN/1.2.3.4 type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x3ebcc647 auth hmac-sha2-256 enc aes-256 esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x736c382f auth hmac-sha2-256 enc aes-256 As inferred, my client's public IP is 5.6.7.8, and on both machines ip forwarding is enabled (pf allows all traffic as well). Any help would be greatly appreciated, and directions towards an analogous, working, client setup for FreeBSD and Linux would be equally appreciated. Thanks all in advance, George. I've also tried a different setup (without an internal network) which works for about a minute or so, and then it stops. server: # cat /etc/iked.conf ikev2 passive esp \ from 10.0.0.0/24 to 0.0.0.0/0 local 1.2.3.4 peer any \ psk mypass # cat /etc/ipsec.conf flow esp out from 10.0.0.0/24 to 10.0.0.0/24 type bypass client: # cat /etc/iked.conf ikev2 active esp \ from 0.0.0.0/0 to 10.0.0.0/24 peer 1.2.3.4 \ psk mypass With this configuration, both client and server are able to access 10.0.0.0/24 (by adding the extra flow in server's /etc/ipsec.conf and loading it via ipsecctl -f /etc/ipsec.conf), but after a minute or so the setup stops working. Traffic is reaching the server's enc0 interface and replies are sent to the client via enc0, but the client's udp port which used to accept packets becomes unreachable (closes for some reason): 08:00:27:ee:e7:fd 08:00:27:59:7c:d4 0800 178: 1.2.3.4.52586 > 5.6.7.8.58353: udp 136 08:00:27:59:7c:d4 08:00:27:ee:e7:fd 0800 70: 5.6.7.8 > 1.2.3.4: icmp: 5.6.7.8 udp port 58353 unreachable I'm not sure that running: # iked -vvd & on both machines, reveals not additional information, except that the client checks both incoming and outgoing SA, whereas the server checks only the incoming: client: ikev2_init_ike_sa: "policy1" is already active ikev2_ike_sa_alive: outgoing CHILD SA spi 0x243b7395 last used 54 second(s) ago pfkey_sa_last_used: last_used 1455636797 ikev2_ike_sa_alive: incoming CHILD SA spi 0x2ee69c30 last used 54 second(s) ago ikev2_init_ike_sa: "policy1" is already active pfkey_sa_last_used: last_used 1455636860 ikev2_ike_sa_alive: outgoing CHILD SA spi 0x243b7395 last used 51 second(s) ago pfkey_sa_last_used: last_used 1455636860 ikev2_ike_sa_alive: incoming CHILD SA spi 0x2ee69c30 last used 51 second(s) ago server: pfkey_sa_last_used: last_used 1455636795 ikev2_ike_sa_alive: incoming CHILD SA spi 0x243b7395 last used 54 second(s) ago pfkey_sa_last_used: last_used 1455636858 ikev2_ike_sa_alive: incoming CHILD SA spi 0x243b7395 last used 51 second(s) ago Thanks all for your time and help in advance, George. PS. I'm getting the same behaviour even without the additional flow of /etc/ipsec.conf, so I've ruled it out from a problem candidate.
OpenBSD 5.8 ikev2 road warrior setup with various clients
Hi all! I'm trying to configure an ikev2 VPN gateway on my OpenBSD 5.8 box to allow remote access to my local network from various, road-warrior client "types" (MS Windows, Linux's, BSD's). My example local network is 10.0.0.0/24 and my public IP (egress) is 1.2.3.4. I've read various guides on the Internet regarding analogous setups, but all of them were discussing about MS Windows clients. I'm trying to test my setup with an OpenBSD 5.8 client but I fail, and next I'd like to test it with a FreeBSD and a Linux client to see if it works. My /etc/iked.conf looks like this: ikev2 passive esp \ from 10.0.0.0/24 to 10.10.10.0/24 local 1.2.3.4 peer any \ psk mypass \ config address 10.10.10.5 My client's /etc/iked.conf looks like this: ikev2 active esp \ from 10.10.10.0/24 to 10.0.0.0/24 peer 1.2.3.4 \ psk lala123 which is based on an old email of this list (at around 2012), and as I explained earlier, it doesn't work. What happens is that when I try to access 10.0.0.1 from my client, the specific traffic is not passing from enc0 but is rather passing directly from the egress interface to its default route. Now, as it seems, this is a routing/flows issue, but I am unsure as to how to address it. ipsecctl -sa on both machines looks good (or at least I think it does): server: # ipsecctl -sa FLOWS: flow esp in from 10.10.10.0/24 to 10.0.0.0/24 peer 5.6.7.8 srcid FQDN/1.2.3.4 dstid FQDN/5.6.7.8 type use flow esp out from 10.0.0.0/24 to 10.10.10.0/24 peer 5.6.7.8 srcid FQDN/1.2.3.4 dstid FQDN/5.6.7.8 type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x3ebcc647 auth hmac-sha2-256 enc aes-256 esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x736c382f auth hmac-sha2-256 enc aes-256 client: # ipsecctl -sa FLOWS: flow esp in from 10.0.0.0/24 to 10.10.10.0/24 peer 1.2.3.4 srcid FQDN/5.6.7.8 dstid FQDN/1.2.3.4 type use flow esp out from 10.10.10.0/24 to 10.0.0.0/24 peer 1.2.3.4 srcid FQDN/5.6.7.8 dstid FQDN/1.2.3.4 type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x3ebcc647 auth hmac-sha2-256 enc aes-256 esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x736c382f auth hmac-sha2-256 enc aes-256 As inferred, my client's public IP is 5.6.7.8, and on both machines ip forwarding is enabled (pf allows all traffic as well). Any help would be greatly appreciated, and directions towards an analogous, working, client setup for FreeBSD and Linux would be equally appreciated. Thanks all in advance, George.
