Stuff I'm Up To

Technical Ramblings

SRX SSH Ciphers, Algorithms & Key Exchange — July 31, 2017

SRX SSH Ciphers, Algorithms & Key Exchange

When doing a Nessus scan for the first time on the new SRX320 cluster it highlighted some weaknesses in the SSH protocol. This was due to arcfour, cbc and hmac being enabled by default.

So to remedy this we need to set the acceptable levels of ciphers etc.

Using the CLI a simple change to the config for the SSH service is required, under system services ssh.

# edit system services ssh
# set ciphers [ aes256-ctr "aes256-gcm@openssh.com" "chacha20-poly1305@openssh.com" ];
# set macs [ hmac-sha2-256 "hmac-sha2-256-etm@openssh.com" hmac-sha2-512 "hmac-sha2-512-etm@openssh.com" ];
# set key-exchange [ curve25519-sha256 ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 group-exchange-sha2 ]

Commit the changes and rescan and all is good.

Continue reading

Advertisements
Disaster Recovery Site and VRRP —

Disaster Recovery Site and VRRP

We’re currently working at putting in a new SIP based phone system that is externally hosted. As we already have a disaster recovery (DR) site with a network that routes out to it we figured we’d host the backup link for the phone system out there too.

The phone provider has installed 2 routers for us, one locally and the other at the DR site. They’ve then configured their routers to handle failovers using some active technology like BGP or VRRP. We don’t know the specifics and that really doesn’t matter to us. As long as we can route traffic out to them to their gateway address, then the rest is up to us to handle.

Continue reading

JunOS SRX too clever for it’s own good! — July 28, 2017

JunOS SRX too clever for it’s own good!

Today the planned migration from a Juniper ScreenOS SSG to a JunOS SRX didn’t quite go as smoothly as I’d have liked.

We spent many hours last night and this morning trying to figure out why numerous services that worked fine through the SSG firewall failed through the SRX. This despite me having triple checked the rule sets matched exactly from one system to the other.

We ended up making changes to connected systems to resolve the problems as workarounds but this was far from ideal. The eventual culprit turned out to be a default feature that is enabled on the SRX within the default application junos-dns-udp.

Continue reading

OpenSSL and Subject Alternative Names — July 27, 2017

OpenSSL and Subject Alternative Names

Now that Google chrome has started bitching about certificates not having Subject Alternative Names because the practice of using Common Names in certificates has changed.

So in order to get the SAN into a CSR you need to edit the OpenSSL config file you’re using for the request. You can spend time scripting something, but for the few times I do it I’ll just copy the base openssl.cnf file to one specific to the CSR I need to create. After all you’ll already have customised the req_distinguished_name section so you don’t have to put in the country and company name all the time. eg.

$ cp /etc/ssl/openssl.cnf ~/myserver.cnf

Then I just use that new cnf file as part of the command line to create the CSR.

$ openssl req -out myserver.csr -new -newkey rsa:2048 -nodes -keyout myserver.key -config ~/myserver.cnf

Continue reading

Squid Kerberos Nightmare — July 25, 2017

Squid Kerberos Nightmare

What a terrible sequence of events we suffered today. Took quite a bit of head scratching, log reading and plenty of Google fu to resolve.

We use Squid with an LDAP and authenticated lookup to establish if a user is a member of an AD group to allow them through the proxy. For some very strange reason the authentication and lookup began failing today.

Continue reading

Owncloud 10.0 Upgrade — July 24, 2017
Remmina/xfreerdp Certificate Name Mismatch — July 21, 2017

Remmina/xfreerdp Certificate Name Mismatch

When using Remmina to connect to some of our older Windows systems we’re seeing a certificate problem that prevents it from connecting. Remmina pretty much says you can’t connect, but you can see the error message if you run remmina from a terminal and try to connect.

connected to server:3389
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@           WARNING: CERTIFICATE NAME MISMATCH!           @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The hostname used for this connection (m3app) does not match any of the names given in the certificate:
Common Name (CN): no CN found in certificate
A valid certificate for the wrong name should NOT be trusted!
tls_connect: certificate not trusted, aborting.
Error: protocol security negotiation or connection failure

Continue reading

Squid3 changes for Debian Jessie —
Can’t ping using FQDN —

Can’t ping using FQDN

I’ve run across this a few times now. It seems every time I do a big Linux upgrade I lose the ability to connect to an internal server using its FQDN. I can ping the short name, I can do a DNS resolution of the FQDN, but I just can’t connect to it using RDP and can’t ping it using its FQDN.

This is something to do with the domain name being .local and conflicting with the MDNS service. Not sure exactly what but it’s an easy fix.

All you need do is adjust the order of the name service lookups in the /etc/nsswitch.conf file and make sure dns comes before the mdns entry.

$ sudo vi /etc/nsswtch.conf
...
hosts: files myhostname dns mdns4_minimal [NOTFOUND=return]

Initially I found the dns was last in the list so just move it in front of the mdns4_minimal entry and you’re set.

Fail2ban – Quick Reference — July 20, 2017
SSH – no matching key exchange method —

SSH – no matching key exchange method

Trying to logon to some older network switch management interfaces I came across a failure due to them using older SHA1 key exchanges and key types. Thankfully OpenSSH supports some legacy options to get around this, at least until we get the switches replaced or upgraded.

$ ssh admin@192.168.10.1
Unable to negotiate with 192.168.10.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

Add the option to use DH-G1-SHA1

$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 admin@192.168.10.1
Unable to negotiate with 192.168.10.1 port 22: no matching host key type found. Their offer: ssh-dss

So now add the ability to use the host key type ssh-dss:

$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss admin@192.168.10.1

Now we’re on!

 

References: https://www.openssh.com/legacy.html

VMware Horizon Client on Debian Stretch — July 17, 2017

VMware Horizon Client on Debian Stretch

In order to install the client on Debian 9 (stretch) I’ve had to get libpng12-0 installed from Jessie here:

https://packages.debian.org/en/jessie/amd64/libpng12-0/download

Then had to create symbolic link for libffi.so.5 to the newer version that’s installed.

$ sudo ln -s /usr/lib/x86_64-linux-gnu/libffi.so.5 /usr/lib/x86_64-linux-gnu/libffi.so.6

 

References: https://communities.vmware.com/thread/545364