Unlock Keepass database with Gnome session unlock

In order to unlock your KeepassXC database when you unlock your session, do the following :

prerequisites :
install the packet libsecret-tools

1. put the password in the Gnome keyring
secret-tool store --label="KeePass" database <database_name>

2. create the script like this :
#!/bin/bash
secret-tool lookup database <database_name> | /usr/bin/keepassxc --pw-stdin <database_location> --keyfile <database_key_location>


3. Add a launcher at ~/.config/autostart/Keepass.desktop:
[Desktop Entry]
Name=Keepass Unlock
GenericName=KeepassUnlock
Comment=Unlocks the keepass DB at session unlock
Exec=<absolute_path_of_script>
Terminal=false
Type=Application
X-GNOME-Autostart-enabled=true

EDIT : added the use of a keyfile

Strongswan routed FQDN IPSec Ikev2 with certificates auth with a Fortigate

EDIT : I've updated with this tutorial from Google, with the updown script on strongswan:

https://cloud.google.com/community/tutorials/using-cloud-vpn-with-strongswan

The VPN is between :
- localsite.domain.com
    debian buster with strongswan 5.7.2-1
- remotesite.domain.com
    Fortigate 6.2.3

Important :

This will not work if the Kernel does not have the CONFIG_NET_IPVTI module enabled.
On OVH you have to upgrade to debian Buster that has a Kernel 4.19 (as of today)

create a PKI :

CA.crt
local.crt
local.pem
remote.crt

Configure IPSEC :

ipsec.conf

 config setup
        #charondebug="ike 3, net 2, esp 2, chd 2, pts 3, cfg 0, asn 0"
        uniqueids=yes
        strictcrlpolicy=no

conn %default
        # keyexchange=ikev2 # now ikev2 is default
        forceencaps=yes
        ike=aes256-sha256-modp2048!
        ikelifetime=24h
        # lifetime=43200s # default is 1h
        esp=aes256-sha256-modp2048,aes256gcm128-sha256
        leftauth=pubkey
        rightauth=pubkey
        closeaction=restart

conn homesite
        #here
        left=localsite.domain.com  
        # left|rightcert in /etc/ipsec.d/certs
        leftcert=local.crt
        # left|rightca in /etc/ipsec.d/cacerts
        leftca=CA.crt

leftsubnet=0.0.0.0/0

#remote
right=remote.domain.com
rightid="<remote site certificate DN>" # TODO check if it can be taken from cert

rightcert=remote.crt
rightca=%same
rightsubnet=0.0.0.0/0

auto=route
mark = 42

/etc/ipsec.secrets 

# cert has to be in /etc/ipsec.d/private/
: RSA local.pem

trust the CA

 cp CA.crt /etc/ipsec.d/cacerts/CA.crt

check that the certificates are recognized with 'ipsec listcerts'.

The flag 'has private key' needs to be present for the certificates with a private key provided.

modify apparmor charon to install DNS provided by tunnel

 I had an issue with apparmor that was not able to accept the dns settings, as the resolv.conf could not be modified in the charon apparmor module, so add at the bottom of the list, before the } in /etc/apparmor.d/usr.lib.ipsec.charon :

/etc/resolv.conf          rwk,

modify the /etc/hosts to resolve to your external IP

1.2.3.4    cloud.domain.com

Configure Route-based VPN :

In my case the local has a static IP. Otherwise, you have to use a script.

/etc/network/interfaces.d/ipsec0.conf

auto ipsec0
iface ipsec0 inet manual
        pre-up ip tunnel add ipsec0 local <ip of the localsite> remote 0.0.0.0 mode vti key 42
        up ip link set ipsec0 up
        up ip address add 10.2.0.2/24 dev ipsec0
        up ip route add 192.168.1.0/24 dev ipsec0 via 10.2.0.1
        up sysctl -w "net.ipv4.conf.ipsec0.disable_policy=1"

        down ip route del 192.168.0.0./24 dev ipsec0
        down ip address del 10.2.0.2/24 dev ipsec0
        post-down ip tunnel del ipsec0

/etc/strongswan.d/charon.conf :

install_routes = no
install_virtual_ip = no

Fortigate config 

Key exchange :

config vpn ipsec phase1-interface
    edit "VPNikev2"
        set type ddns
        set interface "wan1"
        set ike-version 2
        set authmethod signature
        set net-device disable
        set proposal aes256-sha256
        set remotegw-ddns "localsite.domain.com"
        set certificate "remote.crt"
        set peer "remote_side"
    next
end

ChildSA :

config vpn ipsec phase2-interface
    edit "VPNikev2p2"
        set phase1name "VPNikev2"
        set proposal aes256-sha256 aes256gcm
        set keylifeseconds 3600
    next
end

User config:

config user peer
    edit "remote_side"
        set ca "Root_CA"
        set subject "<DN to match localsite cert>"
    next
end

static route for RPF check:

config router static
     edit 0
         set dst 10.2.0.0 255.255.255.0
         set device "VPNikev2"
     next
end

change the container runtime in Kubernetes after upgrade to 1.21

 from https://v1-21.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/

 

find the cgroupDriver on the master node, then in /var/lib/kubelet/config.yaml in workers

 

 

Use docker for flashing an opensource Zigbee Router

 Following this procedure to increase my Zigbee network range (works amazing !), I've ended up with another method of using cc-tools :

https://www.zigbee2mqtt.io/how_tos/how_to_create_a_cc2530_router.html

At the end of step2., this is given to perform https://www.zigbee2mqtt.io/how_tos/how_to_create_a_cc2530_router.html procedure, which is very similar.

Using cc-tools was a burden for me as I use a hybrid testing/stable debian, I could not get all the dependencies solved.

I've found some docker images : https://hub.docker.com/search?q=cc-tool&type=image

So I've used joonas' one

Here is the command :

- perform 'lsusb' to get the device bus ID of the Texas Instrument flashing device.

- download the firmware image in /dest/ and bind mount it in /srv

- joonas/cc-tool:latest does not exist, so it is mandatory to use the correct image tag

docker run -it --device /dev/bus/usb/001/021 -v /dest/CC2530_CC2591_router_2020_09_29:/srv joonas/cc-tool:20210112_1334_98a05cdf cc-tool -e -w /srv/router-cc2530-cc2591-std.hex

Secure Fortigate Virtual Server

 By default, the settings for a Fortigate virtual server are not considered secure on this website : https://internet.nl/site/ or https://www.ssllabs.com/ssltest/analyze.html

 

Current FortiOS version is 6.4.4 so custom ciphers should not be used, as the traffic is not processed afterwards (bug ?)

 

The list :

 

TLS 1.1 phased out

cyphers phased out :

• ECDHE-ECDSA-DES-CBC3-SHA [1.0]
• ECDHE-RSA-DES-CBC3-SHA [1.0]
• DHE-RSA-DES-CBC3-SHA [1.0]
• AES256-GCM-SHA384 [1.2]
• AES128-GCM-SHA256 [1.2]
• AES256-SHA256 [1.2]
• AES256-SHA [1.0]
• AES128-SHA256 [1.2]
• AES128-SHA [1.0]
• DES-CBC3-SHA [1.0]

DH-2048 Key exchange phased out

Client-initiated renegotiation

Here are the settings to avoid it :

conf firewall vip

edit <vip_name>

        set ssl-dh-bits 3072
        set ssl-algorithm custom
        config ssl-cipher-suites
            edit 1
                set cipher TLS-AES-256-GCM-SHA384
                set versions tls-1.2 tls-1.3
            next
            edit 2
                set cipher TLS-CHACHA20-POLY1305-SHA256
                set versions tls-1.2 tls-1.3
            next
            edit 3
                set cipher TLS-AES-128-GCM-SHA256
                set versions tls-1.2 tls-1.3
            next
            edit 4
                set cipher TLS-AES-256-GCM-SHA384
                set versions tls-1.2 tls-1.3
            next
            edit 5
                set cipher TLS-CHACHA20-POLY1305-SHA256
                set versions tls-1.2 tls-1.3
            next
            edit 6
                set cipher TLS-AES-128-GCM-SHA256
                set versions tls-1.2 tls-1.3
            next
        end
        set ssl-min-version tls-1.2
        set ssl-client-renegotiation deny

end

end

restrict SFTP to a user and specific directory

 create a SSH Subsystem :

#Subsystem      sftp    /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp
  Match group sftpusers
  ChrootDirectory %h
  ForceCommand internal-sftp

restart ssh server

create a user member of sftpusers:

sudo useradd -g sftpusers -s /sbin/nologin -m -d /directory/to/share username

Apply permissions for Chroot


As ChrootDirectory needs to belong to root and have 755 permissions :

chown root: /directory

chown root: /directory/to

chown root: /directory/to/share

and also apply 755 permissions to these

apply the wanted permissions for the shared directory

chown -R user1:sftpusers /directory/to/share/*

Calico does not insert iptables rules

on kubernetes pod had  a DNS issue, it could not reach the outside. The Fortigate firewall was not receiving the packet.

Only one node was affected, and this node was an updated Debian Buster image from Stretch.

The difference is that Buster uses now nftables instead of iptables.

so there is the iptables command and the iptables-legacy.

I could see that the iptables -L command was not being populated with calico inputs, and instead these rules were added in iptables-legacy.

This is due to the fact that calico still uses the old iptables.

In order to make everything work, I use only the iptables-legacy :

update-alternatives --set iptables /usr/sbin/iptables-legacy

this is a known Calico issue #2322 : https://github.com/projectcalico/calico/issues/2322

External email with OVH mail on proxmox

configure the /etc/postfix/main.cf like the below

# See /usr/share/postfix/main.cf.dist for a commented, more complete version

#CHANGEME
myhostname=proxmox1.gatom.net

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
#mydestination = $myhostname, localhost.$mydomain, localhost
#relayhost =
mynetworks = 127.0.0.0/8
inet_interfaces = loopback-only
recipient_delimiter = +

compatibility_level = 2

# OVH SMTP/TLS
relayhost = [ssl0.ovh.net]:465
smtp_use_tls=yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_sasl_security_options = noanonymous

smtp_tls_wrappermode = yes
smtp_tls_security_level = encrypt

the two last are required for SMTPS or error message is :

(TCP port 465) requires setting "smtp_tls_wrappermode = yes", and "smtp_tls_security_level = encrypt" (or stronger)

add credentials to /etc/postfix/sasl_passwd

 [ssl0.ovh.net]:465     login:password

set permissions

chmod 600 /etc/postfix/sasl_passwd

create the password db

postmap /etc/postfix/sasl_passwd

of the db is not correct with the given credentials, error is

(SASL authentication failed; server ssl0.ovh.net[193.70.18.144] said: 535 5.7.1 Authentication failed)

install the package for sasl

apt-get install libsasl2-modules

otherwise error is

(SASL authentication failed; cannot authenticate to server ssl0.ovh.net[193.70.18.144]: no mechanism available)

restart postfix

systemctl restart postfix

test

echo "test ok" | mail -s "Test" dest-email@domain.com

 

change Ceph permissions

ceph auth list

...
client.cloud
    key: AQB6hPddq....HcQpUMPSNunT2w==
    caps: [mds] allow rw path=/nas/path/1, allow rw path=/nas/path/2
    caps: [mon] allow r
    caps: [osd] allow rw pool=cephfs_data
...

change with :

ceph auth caps client.cloud \
     mon 'allow r' \
     osd 'allow rw pool=cephfs_data' \
     mds 'allow rw path=/nas/path/1, allow rw path=/nas/path/3'

then check with ceph auth list

...
client.cloud
    key: AQB6hPddq....HcQpUMPSNunT2w==
    caps: [mds] allow rw path=/nas/path/1, allow rw path=/nas/path/3
    caps: [mon] allow r
    caps: [osd] allow rw pool=cephfs_data
...

LoadBalance Service for Bare metal / VM Kubernetes : Metallb

I use Metallb for the LoadBalance service of my kubernetes cluster.

helm install metallb --namespace=metallb stable/metallb

apply the configmap that is the default for the chart.

remember that for the Helm chart the configmap name has to be metallb-config, which is different from the metallb documentation.

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb
  name: metallb-config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
        - 10.0.14.100-10.0.14.200

I prefer the BGP implementation :

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb
  name: metallb-config
data:
  config: |
    peers:
    - peer-address: 10.0.14.1
      peer-asn: 64501
      my-asn: 64500
    address-pools:
    - name: default
      protocol: bgp
      addresses:
      - 10.0.12.128/25

I peer the BGP peers with the Fortigate firewall which is 10.0.14.1 :

config router bgp
    set as 64501
    set router-id 0.0.0.1
    config neighbor
        edit "10.0.14.11"
            set remote-as 64500
        next
        edit "10.0.14.12"
            set remote-as 64500
        next

        ... (and the remaining nodes)

        next
    end
    config redistribute "connected"
    end
    config redistribute "rip"
    end
    config redistribute "ospf"
    end
    config redistribute "static"
    end
    config redistribute "isis"
    end
    config redistribute6 "connected"
    end
    config redistribute6 "rip"
    end
    config redistribute6 "ospf"
    end
    config redistribute6 "static"
    end
    config redistribute6 "isis"
    end
end

do not forget to open the firewall rules then.

reference for the Helm chart :

https://hub.helm.sh/charts/stable/metallb