dilyan.be

Blog

  • Add routing to L2TP VPN in Mac OS X

    L2TP over IPSec is available in MAC OS X, and is very stable in Ventura with OpenBSD server. However, if your network is in the same subnet as the remote network you’re reaching with the VPN is tricky. Let me try to explain:

    me (with home network 192.168.1.0/24) —- L2TP VPN with IP 10.0.0.2 —– Internet —— Office L2TP VPN with 10.0.0.1 gateway —- Office network 192.168.1.0/24 {some machines you want to reach 192.168.1.9 and 192.168.1.124 for example}

    Now, when you establish the VPN, you can ping 10.0.0.1 from your laptop at home, but you can not ping 192.168.1.9 on the other side of the VPN (my office network).

    The easiest way is to add these routes in the point-to-point config in Mac OS.

    1. Open a shell and go to /etc/ppp directory
    # cd /etc/ppp
    2. Create a file called ip-up with:
    # sudo nano ip-up
    3. Put inside these additional routings you want to pop-up when you establish the VPN:
    #!/bin/sh
    /sbin/route add 192.168.1.116/32 -interface ppp0
    /sbin/route add 192.168.1.117/32 -interface ppp0
    /sbin/route add 192.168.1.124/32 -interface ppp0
    4. Exit and save.

    Now, when a VPN is setup, these 3 routes 192.168.1.116, .117, .124 will be available thru the VPN interface ppp0 (the default in Mac Os X).

    How easy it is to make an OpenBSD L2TP VPN server? Very easy, just need to touch three files 🙂

    Let’s first enable IPSEC and ISAKMPD on the OpenBSD box:
    # rcctl enable ipsec
    # rcctl enable isakmpd
    # rcctl set isakmpd flags -K

    In OpenBSD 7.2, all you need to do is:

    1. In /etc/npppd folder open the npppd-users file and add:
    dilyan:\
    :password=123456:
    This will add user “dilyan” with password “123456”

    2. In the same directory, you need to to touch the npppd.conf file to configure DNS, IP addresses and listening ports, etc:

    authentication LOCAL type local {
    users-file “/etc/npppd/npppd-users”
    }

    tunnel L2TP protocol l2tp {
    listen on 0.0.0.0
    listen on ::
    }

    ipcp IPCP {
    pool-address 10.0.0.2-10.0.0.254
    dns-servers 192.168.1.9 8.8.8.8
    }

    interface pppx0 address 10.0.0.1 ipcp IPCP
    bind tunnel from L2TP authenticated by LOCAL to pppx0
    —
    with this basically we’re saying – listen on the host for IPv4 and v6, have a gateway address of 10.0.0.1, assign to the coming connections addresses from 10.0.0.2 till 254, and use DNSs 192.168.1.9 and 8.8.8.8.

    3. The last is to touch /etc/ipsec.conf with adding the following text:
    ike passive esp tunnel from X.Y.Z.Q to any \
    main group “modp1024” \
    quick group “modp1024” \
    psk “0987654”

    where X.Y.Z.Q is the public IP address of the VPN server, and 0987654 is the password for the tunnel (the shared secret).

    In Mac OS X, the L2TP over IPSec is in the default VPN configurations (System Setting -> VPN -> Add VPN Configuration), add the server address (the X.Y.Z.Q from the step above), user authorization is “Password” and put the 123456 from the npppd configuration, the Machine Authentication shall be chose as “Shared Secret” and is the 0987654 one you put in ipsec.conf. Voila.

    More details in the OpenBSD FAQ: https://www.openbsd.org/faq/faq17.html

  • WordPress installation on FreeBSD 13.1 particularities

    There’s a little specific when installing WordPress from package under FreeBSD 13 and its Apache.

    Now, the Apache server coming with the distro is v. 2.4.54 and it is expecting PHP 8.0 (otherwise loading some modules is not working like msqli).
    If you install WordPress from packages it will come with v.6.1 and it has dependencies on PHP 8.1, and then a little drama is starting as Apache can not loading all the needed modules and the error log is full of issues.
    It becomes a nightmare, so the easiest way I have found is to do it by hand (no from packages):

    1. De-install WordPress from the FreeBSD repository and PHP 8.1
    2. Install PHP 8.0 from packages and add php80-zlib + php80-filter, then enable the service:
    # pkg install mod_php80 php80-zlib php80-filter
    # cp /usr/local/etc/php.ini-production /usr/local/etc/php.ini
    # service php-fpm enable
    # service php-fpm start
    3. You need to add the following either in the httpd.conf, or create a new modules file, or example – /usr/local/etc/apache24/modules.d/001_mod-php.conf. Then add the following text:

    DirectoryIndex index.php index.html

    SetHandler application/x-httpd-php


    SetHandler application/x-httpd-php-source


    4. Touch the Apache config file, which in FreeBSD 13.1 is located at /usr/local/etc/apache24/httpd.conf
    a) make sure the following like is uncommented and is there: LoadModule rewrite_module libexec/apache24/mod_rewrite.so
    b) point the document root to the right directory of the WordPress, in my case it is under: /usr/local/www/wordpress. So, httpd.conf is having:
    DocumentRoot “/usr/local/www/wordpress”

    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted

    5. Download the latest WordPress version (as of writing this is 6.2) and unzip it in the directory /usr/local/www/wordpress:
    # wget https://wordpress.org/latest.tar.gz
    # tar -xzvf latest.tar.gz
    6. Restart all the services and open the IP address of the configured Apache:
    # service apache24 restart

  • For few msec less – local Unbound DNS

    It is always the DNS!

    I have several jails and virtual machines on my Dell T5600 home lab. It is much easier to operate when each machine is having a FQDM, so I decided to play with Unbound DNS which is a kind of default for OpenBSD and FreeBSD.
    Here is the setup – the host OS is FreeBSD 13.1 (in the example below with IP 192.168.1.115), OpenBSD 7.2 (IP 192.168.1.9) is a virtual machine with bhyve on top of the host OS.

    I have configured all my hosts with a domain name under *.dilyan.be + the reverse record. Below you’ll see in the example postgres.dilyan.be, openbsd.dilyan.be, wp.dilyan.be, etc with their addresses configured.

    In OpenBSD you just have to enable it:

    # rcctl enable unbound
    # rcctl start unbound
    unbound(ok)

    the config files are under /var/unbound/etc

    here’s my config:


    [root@openbsd etc]$ cat unbound.conf
    # $OpenBSD: unbound.conf,v 1.21 2020/10/28 11:35:58 sthen Exp $
    server:
    interface: 127.0.0.1
    interface: 192.168.1.9
    interface: ::1
    port: 53
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: ::0/0 refuse
    access-control: ::1 allow
    access-control: 10.0.0.0/8 allow
    access-control: 127.0.0.0/8 allow
    access-control: 192.168.0.0/16 allow
    root-hints: "/var/unbound/db/root.hints"
    hide-identity: yes
    hide-version: yes
    auto-trust-anchor-file: "/var/unbound/db/root.key"
    val-log-level: 2
    aggressive-nsec: yes
    verbosity: 1
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: yes
    do-ip4: yes
    do-ip6: yes
    do-udp: yes
    do-tcp: yes
    cache-min-ttl: 3600
    cache-max-ttl: 86400
    prefetch: yes
    num-threads: 2
    msg-cache-slabs: 8
    rrset-cache-slabs: 8
    infra-cache-slabs: 8
    key-cache-slabs: 8
    rrset-cache-size: 512m
    msg-cache-size: 256m
    so-rcvbuf: 2m
    private-address: 172.16.0.0/12
    private-domain: "dilyan.be"
    unwanted-reply-threshold: 10000
    val-clean-additional: yes
    statistics-cumulative: yes
    extended-statistics: yes
    use-syslog: yes
    local-zone: "dilyan.be" static
    local-data: "dilyan.be IN A 52.208.215.96"
    local-data: "www.dilyan.be IN A 52.208.215.96"
    local-data: "vpn.dilyan.be IN A 212.5.153.206"
    local-data: "django.dilyan.be IN A 192.168.1.119"
    local-data: "mongodb.dilyan.be IN A 192.168.1.118"
    local-data: "test.dilyan.be IN A 192.168.1.120"
    local-data: "wp.dilyan.be IN A 192.168.1.116"
    local-data: "postgres.dilyan.be IN A 192.168.1.117"
    local-data: "neo4j.dilyan.be IN A 192.168.1.121"
    local-data: "rpi.dilyan.be IN A 192.168.0.115"
    local-data: "wiki.dilyan.be IN A 192.168.1.124"
    local-data: "openbsd.dilyan.be IN A 192.168.1.9"
    local-data: "freebsd.dilyan.be IN A 192.168.1.115"
    local-data: "obsd.dilyan.be IN A 192.168.1.223"
    local-data-ptr: "192.168.1.119 django.dilyan.be"
    local-data-ptr: "192.168.1.118 mongodb.dilyan.be"
    local-data-ptr: "192.168.1.120 test.dilyan.be"
    local-data-ptr: "192.168.1.116 wp.dilyan.be"
    local-data-ptr: "192.168.1.117 postgres.dilyan.be"
    local-data-ptr: "192.168.1.121 neo4j.dilyan.be"
    local-data-ptr: "192.168.0.115 rpi.dilyan.be"
    local-data-ptr: "192.168.1.124 wiki.dilyan.be"
    local-data-ptr: "192.168.1.9 openbsd.dilyan.be"
    local-data-ptr: "192.168.1.115 freebsd.dilyan.be"
    local-data-ptr: "192.168.1.223 obsd.dilyan.be"
    forward-zone:
    name: .
    forward-addr: 8.8.8.8 #Google-1
    forward-addr: 1.1.1.1 #Cloudflare-1
    forward-addr: 9.9.9.9 #Quad9.net
    forward-addr: 1.0.0.1 #Cloudflare-2
    forward-addr: 8.8.4.4 #Google-2
    forward-addr: 149.112.112.112 #Quad9-2
    forward-addr: 208.67.222.222 #OpenDNS-1
    forward-addr: 208.67.220.220 #OpenDNS-2
    remote-control:
    control-enable: yes
    control-interface: /var/run/unbound.sock

    After completing the config, restart the service with

    # rcctl restart unbound
    unbound(ok)

    So, what do I gain, apart from having the local machines with DNS? Well, a couple of milliseconds :).
    Here’re are some tests from the local machine compared to Google, Cloudflare, Quad. When asking for the IP address of bbc.co.uk, Cloudflare replied in 5 msec, Google in 31 msec, the local OpenBSD in 2 ms.

    [root@openbsd etc]$ drill bbc.co.uk @1.1.1.1

    ;; HEADER;- opcode: QUERY, rcode: NOERROR, id: 33177
    ;; flags: qr rd ra ; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
    ;; QUESTION SECTION:
    ;; bbc.co.uk. IN A
    ;; ANSWER SECTION:
    bbc.co.uk. 261 IN A 151.101.64.81
    bbc.co.uk. 261 IN A 151.101.128.81
    bbc.co.uk. 261 IN A 151.101.192.81
    bbc.co.uk. 261 IN A 151.101.0.81
    ;; AUTHORITY SECTION:
    ;; ADDITIONAL SECTION:
    ;; Query time: 5 msec
    ;; SERVER: 1.1.1.1
    ;; WHEN: Fri Mar 31 11:53:16 2023
    ;; MSG SIZE rcvd: 91
    ———
    [root@openbsd etc]$ drill bbc.co.uk @8.8.8.8
    ;; HEADER;- opcode: QUERY, rcode: NOERROR, id: 30222
    ;; flags: qr rd ra
    ; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
    ;; QUESTION SECTION:
    ;; bbc.co.uk. IN A
    ;; ANSWER SECTION:
    bbc.co.uk. 21 IN A 151.101.0.81
    bbc.co.uk. 21 IN A 151.101.64.81
    bbc.co.uk. 21 IN A 151.101.128.81
    bbc.co.uk. 21 IN A 151.101.192.81
    ;; AUTHORITY SECTION:
    ;; ADDITIONAL SECTION:
    ;; Query time: 31 msec
    ;; SERVER: 8.8.8.8
;; WHEN: Fri Mar 31 11:53:23 2023
    ;; MSG SIZE rcvd: 91
    ——–
    [root@openbsd etc]$ drill bbc.co.uk @192.168.1.9
    ;; HEADER;- opcode: QUERY, rcode: NOERROR, id: 55555
    ;; flags: qr rd ra
    ; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
    ;; QUESTION SECTION:
    ;; bbc.co.uk. IN A
    ;; ANSWER SECTION:
    bbc.co.uk. 3580 IN A 151.101.128.81
    bbc.co.uk. 3580 IN A 151.101.192.81
    bbc.co.uk. 3580 IN A 151.101.0.81
    bbc.co.uk. 3580 IN A 151.101.64.81
    ;; AUTHORITY SECTION:
    ;; ADDITIONAL SECTION:
    ;; Query time: 2 msec
    ;; SERVER: 192.168.1.9
    ;; WHEN: Fri Mar 31 11:53:27 2023
    ;; MSG SIZE rcvd: 91

    Now, in FreeBSD is a little bit confusing, as they have local_unbound and “normal” unbound. The configs are under /var/unbound, but the structure is a little different than in OpenBSD. For example, there’re different files for forwarders, blocked sites, etc. that are included in the main unbound.conf at the end:


    include: /var/unbound/forward.conf
    include: /var/unbound/lan-zones.conf
    include: /var/unbound/control.conf
    include: /var/unbound/conf.d/*.conf
    include: /var/unbound/blocked_servers

    Then the example from the OpenBSD is identical, just the forwarders (Google, Cloudflare, Quad9 DNS addresses are in the file forward.conf). I also noticed that some of the parameters in the OpenBSD are giving errors, so I had to remove the following lines from the above config to make it work:


    # auto-trust-anchor-file: "/var/unbound/root.key"
    # num-threads: 2
    # rrset-cache-size: 512m
    # msg-cache-size: 256m
    # so-rcvbuf: 2m

    I did not have the time to play and make the FreeBSD options work, just commented them. The rest is identical with the OpenBSD config. Restart the service with:

    #service local_unbound restart

    N.B. local_unbound is different than unbound in FreeBSD!

    Now the test of the drill, from the FreeBSD shell, this time with cnn.com:

    [root@fbsd /var/unbound]# drill cnn.com @1.1.1.1

    ;; HEADER opcode: QUERY, rcode: NOERROR, id: 11433
    ;; flags: qr rd ra ; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
    ;; QUESTION SECTION:
    ;; cnn.com. IN A
    ;; ANSWER SECTION:
    cnn.com. 58 IN A 151.101.195.5
    cnn.com. 58 IN A 151.101.131.5
    cnn.com. 58 IN A 151.101.3.5
    cnn.com. 58 IN A 151.101.67.5
    ;; AUTHORITY SECTION:
    ;; ADDITIONAL SECTION:
    ;; Query time: 2 msec
    ;; SERVER: 1.1.1.1
    ;; WHEN: Fri Mar 31 12:08:20 2023
    ;; MSG SIZE rcvd: 89
    ——–
    [root@fbsd /var/unbound]# drill cnn.com @8.8.8.8
    ;; HEADER opcode: QUERY, rcode: NOERROR, id: 29708
    ;; flags: qr rd ra
    ; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
    ;; QUESTION SECTION:
    ;; cnn.com. IN A
    ;; ANSWER SECTION:
    cnn.com. 18 IN A 151.101.195.5
    cnn.com. 18 IN A 151.101.3.5
    cnn.com. 18 IN A 151.101.131.5
    cnn.com. 18 IN A 151.101.67.5
    ;; AUTHORITY SECTION:
    ;; ADDITIONAL SECTION:
    ;; Query time: 28 msec
    ;; SERVER: 8.8.8.8
    ;; WHEN: Fri Mar 31 12:08:25 2023
    ;; MSG SIZE rcvd: 89
    ——–
    [root@fbsd /var/unbound]# drill cnn.com @192.168.1.115
    ;; HEADER opcode: QUERY, rcode: NOERROR, id: 62215
    ;; flags: qr rd ra
    ; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
    ;; QUESTION SECTION:
    ;; cnn.com. IN A
    ;; ANSWER SECTION:
    cnn.com. 3595 IN A 151.101.131.5
    cnn.com. 3595 IN A 151.101.195.5
    cnn.com. 3595 IN A 151.101.3.5
    cnn.com. 3595 IN A 151.101.67.5
    ;; AUTHORITY SECTION:
    ;; ADDITIONAL SECTION:
    ;; Query time: 0 msec
    ;; SERVER: 192.168.1.115
    ;; WHEN: Fri Mar 31 12:08:37 2023
;; MSG SIZE rcvd: 89

    Cloudflare replied in 2 ms, Google in 28 msec, the FreeBSD in 0 msec .. obviously it was cached 🙂

    To be honest, the FreeBSD is _very_ fast if the DNS is in the cache and has been requested recently. If it is the first time request, it can go to 100 ms, as it asks the forwarders (Google, Cloudflare, Quad9, OpenDNS that I’ve configured). It is normal to see 0 msec for hours after the DNS was cached, something that I’ve never seen in OpenBSD, so looks like the caching mechanisms are different.

    A great how-to with more explanations is https://calomel.org/unbound_dns.html

  • Firewall rules on OpenBSD security bastion

    The setup is like that:

    Internet (public IP) — ISP router — FreeBSD 13.1 host — OpenBSD 7.2 virtual machine

    the OpenBSD is running a) ssh server with Yubikey authorization, b) Wireguard VPN server, c) L2TP VPN as a back-up on the Wireguard. The ISP router is forwarding ports tcp 22 (ssh), tcp 443 (Wireguard), udp 400 and 4500 for the L2TP VPN to the OpenBSD address directly.

    The pf.conf rules to make this setup work:

    [root@openbsd dilyan]$ cat /etc/pf.conf
    set block-policy return
    set limit table-entries 400000 #due to pfbadhost
    set skip on lo
    ext_if = “vio0”
    vpn_if = “pppx”
    vpn_net = “10.0.0.0/24”
    home_net = “192.168.0.0/24” #home network thru VPN
    office_net = “192.168.1.0/24” # office network
    table <bruteforce> persist #table for ssh-attackers
    table <pfbadhost> persist file “/etc/pf-badhost.txt”

    antispoof for { $ext_if, $vpn_if }
    match in all scrub (no-df random-id )

    block return # block stateless traffic
    block quick from <bruteforce> #block the ssh-attackers
    block in quick on egress from <pfbadhost>
    block out quick on egress to <pfbadhost>

    # By default, do not permit remote connections to X11
    block return in on ! lo0 proto tcp to port 6000:6010
    # Port build user does not need network
    block return out log proto {tcp udp} user _pbuild
    block all

    pass # establish keep-state
    pass inet proto icmp synproxy state #allow ICMP protocol – all
    pass proto { tcp, udp } from { wg0:network, $home_net, $vpn_net, $office_net } to port { ssh, domain }
    pass proto { tcp, udp } to port { ssh, 500, 4500 } keep state (max-src-conn 5, max-src-conn-rate 3/60, overload <bruteforce> flush global)
    pass proto udp from {$ext_if, $office_net} to port { 123 } #allow network time protocol (NTP) port

    # Rule for WireGuard VPN to NAT traffic to public net#
    match out on $ext_if from wg0:network to any nat-to $ext_if

    # Rules for L2TP VPN to work and NAT traffic #
    pass on $ext_if proto esp # allow ESP protocol on public interface
    pass on $ext_if proto udp to port { isakmp, ipsec-nat-t } # allow isakmpd UDP traffic through the public interface on ports 500 and 4500
    pass on enc0 keep state (if-bound) # filter all IPSec traffic on the enc interface
    pass on $vpn_if from { $vpn_net, $home_net } # allow all trafic in on and out to the VPN network
    pass on $vpn_if to { $vpn_net, $home_net }
    match out on $ext_if from $vpn_net to any nat-to $ext_if # nat VPN traffic going out on the public interface with the public IP

    These rules will _not_ work on FreeBSD, as their implementation requires grouping the rules in particular order – Macros, Tables, Options, Normalization, NAT/Redirections and then Filtering (i.e. you need to rearrange the rules).

    Once you open port 22 for ssh service on a public IP address, attackers will start attempts like ~17-20k tries per day. This is why I implemented the table, so an IP that tries to guess a username/password more than 3 times per 60 minutes to be blocked for a day. This reduced the attacks to less than 12k per day. Then I followed this how-to https://geoghegan.ca/pfbadhost.html to block malicious IPs thru the table and the attempts dropped below 9k per day.

  • Few specifics in running PostgreSQL, MongoDB, Neo4j and ELK in FreeBSD 13.1 jails

    As a note to myself and to save the time in troubleshooting and chasing issues, few specifics to make the below services run in jail environment under FreeBSD 13.1.

    First, the generic options:
    # cat /etc/jail.conf
    allow.raw_sockets = 1;
    allow.set_hostname = 1;
    allow.sysvipc = 1;
    mount.devfs; # Mount devfs inside the jail
    exec.start = "/bin/sh /etc/rc"; # Start command
    exec.stop = "/bin/sh /etc/rc.shutdown"; # Stop command

    1. PostgreSQL: few parameters need to be set in the jail.conf – sysvshm, sysvsem, sysvmsg
    postgres {
    host.hostname = postgres.dilyan.be; # Hostname
    ip4.addr = 192.168.3.117; # IP address of the jail
    path = "/zroot/jails/postgres"; # Path to the jail
    sysvshm = new;
    sysvsem = new;
    sysvmsg = new;
    }

    2. MongoDB: all it needs is allow.mlock in the jail definition
    mongodb {
    host.hostname = mongodb.dilyan.be; # Hostname
    ip4.addr = 192.168.3.118; # IP address of the jail
    path = "/zroot/jails/mongodb"; # Path to the jail
    allow.mlock;
    }

    3. Neo4j: due to the java you need to specify how to mount the local fstab
    neo4j {
    host.hostname = neo4j.dilyan.be; # Hostname
    ip4.addr = 192.168.3.121; # IP address of the jail
    path = "/zroot/jails/neo4j"; # Path to the jail
    mount.fstab="/zroot/jails/neo4j/etc/fstab.neo4j"; # mount local fstab for the java
    }

    the content of the fstab in the jail is:

    fdesc /dev/fd fdescfs rw 0 0
    proc /proc procfs rw 0 0

    4. Elastic Search and Kibana (ELK stack): same as for the Neo4j – you need to specify how to mount the local fstab


    elk {
    host.hostname = elk.dilyan.be; # Hostname
    ip4.addr = 192.168.3.122; # IP address of the jail
    path = "/zroot/jails/elk"; # Path to the jail
    mount.fstab="/zroot/jails/elk/etc/fstab.java"; # mount local fstab for the java
    }

    cat /zroot/jails/elk/etc/fstab.java
    fdesc /dev/fd fdescfs rw 0 0
    proc /proc procfs rw 0 0

    The rest of the service I ran in jails have no particularities in the defitionions – Apache, wikimedia, Django, OpenVPN

  • Yubikey for ssh authentication with FIDO2

    Yubikey is my preferred solution for securing social account (Twitter, Facebook, Google), WordPress admin accounts, Git, Apple ID (since the iOS 16.3, and you need two keys) and OpenSSH (since v 8.2p1).

    The Yubico how-to is great, I will just add couple of specifics on configuring the server and the clients.

    I chose the “discoverable” config and followed the steps in the how-to. For MacOS Ventura 13.1, the latest is OpenSSH_9.1p1, OpenSSL 1.1.1s, so you can generate the key with ecdsa-sk.

    The second specific that is not well covered in the Yubico how-to is the server config.

    – For Debian 11.6 (with OpenSSH_8.4p1 Debian-5+deb11u1, OpenSSL 1.1.1n) add the following in your /etc/ssh/sshd_config

    #Yubikey FIDO authentification
    PubkeyAuthentication yes
    PubkeyAuthOptions verify-required
    PubkeyAcceptedKeyTypes ssh-ed25519,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com

    you also need to disable PAM in the config with:
    UsePAM no

    – for OpenBSD 7.2 (with OpenSSH_9.1, LibreSSL 3.6.0) is the same, but it works even if you comment the PAM option:

    #Yubikey FIDO authentification
    PubkeyAuthentication yes
    PubkeyAuthOptions verify-required
    PubkeyAcceptedKeyTypes ssh-ed25519,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com
    #UsePAM no

    I have added the options ssh-ed25519,sk-ssh-ed25519 to PubkeyAcceptedKeyTypes because I have several Yubikeys with different firmware versions, and several generated keys types. For Yubikey with NFC support and firmware 5.4.3 I just need sk-ecdsa-sha2-nistp256.

    Limitations:
    – you need the Yubikey all the time (obviously). BUT if you need to login to a bastion A for example, and from the bastion A to another host B, you can not do it with this setup. You can do the config on your local client and your bastion A with the above setup, but you can not do it on host B thru a bastion. Because when you login in bastion A, you lose the Yubico verification (PIN and touch) as the ssh can not “see” your Yubikey plugged on your local client.
    – you better have two Yubikeys in case you lose your primary one.

  • The most advanced fiber sense solutions

    There’re plenty of applications for using fiber optics sensors in the industry.

    In the DWDM world, installing fiber sense system on a working optical cable may give you the needed information when there’s civil works on-going near your cable, maintenance in a shaft/volt, and tell you where exactly this is happening.

    The three most advanced solutions (in my short research) are:
    1. https://fibersense.com/
    2. https://www.apsensing.com/
    3. https://senstar.com/

    These companies cover utilities monitoring, submarine applications, oil & gas, railways, seismic monitoring, etc.

  • Apple TimeMachine config on Debian and FreeBSD

    This is my current working configuration for MacOS Ventura 13.1 for TimeMachine hosted on a RaspberryPi home NAS and FreeBSD server.

    Tested with Samba version 4.13.13-Debian on the RaspberryPi (Conmpute module 4 with IO board), and 4.16.8 on the FreeBSD 13.1.

    The following is added to the smb.conf (in Debian is /etc/samba/smb.conf, in FreeBSD is /usr/local/etc/smb4.conf)

    [TimeMachine]
    path = /nas/backup
    public = yes
    browseable = Yes
    guest ok = yes
    vfs objects = fruit streams_xattr
    read only = No
    inherit acls = Yes
    fruit:time machine = yes
    writeable = yes
    create mask = 0600
    directory mask = 0700
    spotlight = yes
    fruit:nfs_aces = No
    netbios name = freenas
    fruit:aapl = yes
    vfs objects = catia fruit streams_xattr
    fruit:resource = file
    fruit:metadata = stream
    fruit:locking = none
    fruit:encoding = native
    mdns name = mdns
    ea support = yes
    fruit:posix_rename = yes
    fruit:veto_appledouble = no
    fruit:wipe_intentionally_left_blank_rfork = yes
    fruit:delete_empty_adfiles = yes
    fruit:aapl = yes

  • Dell Precision T5600 as home server

    Recently I managed to find a decent dual-processor Dell Precision T5600 on ebay for ~90 euro. With 2x Xeon E5-2630 2.3GHz | 6 core each, 8 DIMM slots for ECC RAM, and Intel 82759 network.

    It came with just 8 GB RAM, but second hand options for 1333 or 1600 DDR3 RDIMM ECC
 memory were plenty on the local market, so I managed to find additional 56 GB for 60 euro (for the 8 DIMM slots the options are 1 GB, 2 GB, 4 GB, 8 GB, and 16 GB
).

    The latest BIOS rev is A19, but in order to upgrade the BIOS you need to disable the Intel virtualization options in the BIOS first …. it took me two days to figure it out, because the processes finishes without any error or warning, but you end up with the old version. If you do not upgrade the BIOS to the latest release, you will not get the disk controller enabled to configure any RAID arrays.

    I installed FreeBSD 13.1 with zfs and made software 1+1 RAID with 2 disk. Everything is supported and works like a charm. The dual-processor setup is a little bit power and cooling hungry, but it is bearable.

    The official manual:
    https://dl.dell.com/manuals/all-products/esuprt_desktop/esuprt_dell_precision_workstation/precision-t5600_owner’s%20manual_en-us.pdf

  • Safari не сработва със системата за сигурно електронно връчване и НАП

    Safari не сработва със системата за сигурно електронно връчване и НАП

    Системата за сигурно електронно връчване https://edelivery.egov.bg/ е доста удобна за административна работа и спестява доста разкарване по институции (физически). Аз я ползвам предимно с електроннен поспис (КЕП), но Safari 16.2 под Mac OS Ventura 13.1 не се разбират с автентификацията. Рекуеста се насочва към https://qes-login.eauth.egov.bg и излиза грешка ” …. Safari can’t establish a secure connection to the server ….”. Интересното е обаче, че под Firefox 102.6 esr работи, само иска да се разреши cross-site cookies. Има валиден SSL сертификат, но вероятно Java скрипта от path: /api/idp/qes не се сработва със Safari. С Chrome 108 също работи.

    В сайта на НАП https://portal.nra.bg/ пък проблемите са други – там се влиза с КЕП без проблем. Но по услугите настава нечетливо по менюта и бутони (предполахам се чупи някой темплейт). Например на приоверка на здравен статус от https://portal.nra.bg/my-health-status изглежда така: