DragonsKeep

Kill Systemd-Networking

Oct29

by Frank on October 29, 2019 at 07:45

Posted In: Professional / IT, Uncategorized

With fire. Seriously. Reason 1: anything that doesn’t honor kernel “sysctl” settings deserves to die.
Many thanks to “Yoon’s blog” and his post “https://www.naut.ca/blog/2018/12/12/disabling-systemd-networking/index.html”

Recap:
Install ifupdown to replace networkd:
apt-get install ifupdown

Now edit /etc/network/interfaces.

Disable networkd:
systemctl stop systemd-networkd.socket systemd-networkd networkd-dispatcher systemd-networkd-wait-online
systemctl disable systemd-networkd.socket systemd-networkd networkd-dispatcher systemd-networkd-wait-online

apt -y purge netplan.io

Disable resolved (might as well!):
systemctl disable systemd-resolved.service systemctl stop systemd-resolved

Create your own /etc/resolv.conf. Make sure to “rm /etc/resolv.conf” first – it’s a dang symlink into the ugly.

References as shown in the original blog post:
https://askubuntu.com/questions/1031709/ubuntu-18-04-switch-back-to-etc-network-interfaces
https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu

Comment

Strongswan GRE IPSec and OSPF (Bird)

Oct17

by Frank on October 17, 2017 at 07:17

Posted In: Misc, Professional / IT

OK, so I finally got Strongswan with a GRE over IPSec tunnel and OSPF (BIRD) running on Centos 6

Two remote sites are connected to the main site via Metro-Ethernet. In case of the Metro failing, the idea is to establish backup connectivity over the Internet via secure VPN tunnels. That poses a few problems: IPSec alone doesn’t play well with routing protocols (OSPF in my case), which is why we need GRE over IPSec. I chose “Strongswan” for IPSec on Centos 6 – the Centos 6 was already in place and I didn’t want to first update everything to Centos 7.

Note, Centos 6 uses iproute2, which does not support VTI interfaces 🙁

A “few” caveats that the usual how-to docs don’t quite seem to address:

make sure your ipsec.conf is in “transport” mode, not “tunnel”, or you’re in a world of pain nailing your GRE on it. Mind you, GRE will still come up if you do things wrong, but it won’t be encrypted! And of course the only way to see that is via packet capture on/past the switch port (yay switch port mirrors!)

The above will also help solve the issue of “left/rightsubnet” being “0.0.0.0/0” in both tunnels – you don’t need to specify left/rightsubnet in the conn section of ipsec.conf
(Two “tunnel” tunnels with left/rightsubnet 0.0.0.0/0 easily results in that you can only ping across the tunnel that came up last. And I couldn’t get the mark/key options of ‘tunnel’/’ipsec.conf’ to work right)

Once your tunnel is up and you can ping across it, OSPF might still not come up at all. I saw “OSPF HELLO” packets leave, but they never arrived at the other side. Wireshark to the rescue (via mirrored switch port) and lo and behold – the TTL is “1”, which is a tad small. Bring up your tunnel interface with “ip tunnel add… ttl=64“

While all this might be “obvious” to people who’ve “been there” before, it wasn’t obvious to me and my google-fu totally failed for quite a while. I hope this helps others (and future-me).

2 Comments

Cisco ASA “minimal” config

Oct06

by Frank on October 6, 2015 at 10:03

Posted In: Misc, Professional / IT

I’m currently trying to make friends with Cisco ASAs, and I keep forgetting things. Here’s a “minimal” config – create a key for future ssh access, a user/pass for any type of access, and enable http (and from where you accept https connections) for ASDM access

crypto key generate rsa modulus 1024 username password privilege 15 http server enable http (for instance: http 10.1.2.3 255.255.255.255 outside)
Once you’re in with ADSM, don’t forget
Config -> Device Management -> Users/AAA -> AAA Access
– Authentication Tab: check ‘Enable’ in the ‘Require auth to allow use’ at the top
– Authentication Tab: check ‘SSH’
– Authorization Tab: check ‘Enable Server Group…’

Configuration > Device Management > Management Access > ASDM/HTTPS/Telnet/SSH
– add “asdm/https” and “ssh” IP/netmask as needed

And don’t forget to hit “Apply” and then also “Save”

Comment

Sendmail TLS handshake errors (dh key too small)

Jul06

by Frank on July 6, 2015 at 07:42

Posted In: sendmail

Ooops – some recent openssl update seems to have “broken” things. Well, technically they’re just dismissing weak keys (Logjam), but still – annoying side effect.

TL;DR fix:
openssl dhparam -out /etc/pki/tls/certs/dhparams.pem 1024

Then edit your sendmail.mc by adding (if you have old versions – Fedora 10 or similar, comment out the two SSLOptions):
LOCAL_CONFIG O CipherList=HIGH:!ADH O DHParameters=/etc/pki/tls/certs/dhparams.pem O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3
run “make” or whatever to re-create your sendmail.cf, then restart sendmail.

Quick little test-command:
openssl s_client -starttls smtp -crlf -connect mail.example.com:smtp

For more info, see these links:
http://serverfault.com/questions/700655/sendmail-rejecting-some-connections-with-handshake-failure-ssl-alert-number-40
http://www.reddit.com/r/sysadmin/comments/3ay2ez/openssls_logjam_cve20154000_fixes_break_smtp/
https://weakdh.org/sysadmin.html

Comment