In my post about two years ago I showed how to monitor SSL certificates with Zabbix.
In the meantime the scripts/templates have been enhanced, with some small corrections/bugfixes.
One notable new feature is the possiblity to monitor SSL certificates which are delivered by SNI, which means you can have multiple SSL certificates available on the same IP/Port combination.
This is a critical feature, to better use the available IPv4 addresses.
The enhanced templates and scripts are now available via Github, which allows you to open issues if something is not working in your environment or contribute to new features as well.
I'm interested to hear about your use cases and feedbacks.
Tuesday, July 26, 2016
Thursday, March 31, 2016
Install Symantec Endpoint Protection on Debian Jessie
Syamntec endpoint protection is not only shipping for Windows systems, but also for OS-X and Linux systems.
Installing it on a debian jessie server does require some manual steps to have all features enabled.
The first step is to create a package in your SEP installation, simplest with a web downloadlink which you can later use to fetch the package via wget.
Installing it on a debian jessie server does require some manual steps to have all features enabled.
The first step is to create a package in your SEP installation, simplest with a web downloadlink which you can later use to fetch the package via wget.
- Install Java 8
- Download JCE from http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
- Install the cryptografic files into "/usr/lib/jvm/java-8-oracle/jre/lib/security"
- Ony 64-bit systems enable i386 packages and install glibc in 32bit edition
dpkg --add-architecture i386
apt-get update
apt-get install libc6:i386 - On 64-bit systems install the linux-headers to allow compilation of the realtime scan kernel modules
apt-get install linux-headers-amd64 - Download your SEP package from your server wget http://<your-sep-server>/EmailInstallPackages/xxxxxxxxxxxx/sep/SymantecEndpointProtection.zip
- Unzip zip package
- bash ./install.sh -i
Labels:
debian,
jessie,
sep,
symantec endpoint protection
Installing Java 8 on Debian Jessie
Installation Oracle Java 8 on Debian Jessie
Debian 8 alias Jessie ships with OpenJDK 7 which is fine in many cases. But sometimes you need a more recent version.
In that case you can use the ubuntu ppa archives as install source.
Just type these commands in the console of your Debian system and it should install just fine, also providing automatic security upgrades as they become available.
Debian 8 alias Jessie ships with OpenJDK 7 which is fine in many cases. But sometimes you need a more recent version.
In that case you can use the ubuntu ppa archives as install source.
Just type these commands in the console of your Debian system and it should install just fine, also providing automatic security upgrades as they become available.
echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" > /etc/apt/sources.list.d/webupd8team-java.list echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" >> /etc/apt/sources.list.d/webupd8team-java.list apt-key adv --keyserver keyserver.ubuntu.com --recv-keys EEA14886 apt-get update apt-get install oracle-java8-installer java -version
Thursday, January 28, 2016
Upgrading from Debian 6 Openswan to Debian 8 Strongswan
When upgrading from Debian 6 to Debian 8, then IPSEC softwarestack is changed from Openswan to Strongswan.
The switch itself is not a big thing, but when you still have other Openswan IPSEC partners, you will have to change your Strongswan config a little bit.
Otherwise the two IPSEC implementations won't be able to build the VPN tunnel.
On the Openswan end of the VPN you will see such messages in your auth.log file:
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #746: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #670 {using isakmp#4 msgid:6c3f1671 proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048}
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #669: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #669: starting keying attempt 5 of an unlimited number
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #747: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #669 {using isakmp#4 msgid:23eb99a9 proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048}
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: received and ignored informational message
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: received and ignored informational message
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
On the Strongswan side, you see this in the daemon.log:
Jan 28 12:16:52 vpn01 ipsec[13909]: 09[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSEN
Jan 28 12:16:52 vpn01 ipsec[13909]: 09[ENC] generating INFORMATIONAL_V1 request 2468276578 [ HASH N(NO_PROP) ]
This is dues to some IKE mismatch (The OpenSWAN IKEv2 implementation has does not respect all standards)
You can solve this issue by specifying IKEv1 for the connection in your ipsec.conf on the Strongswan side:
keyexchange=ikev1
This should solve the problem.
Sometimes (Depending the Openswan setttings) you also have to add this to your connection definition on the Strongswan side:
esp=aes128-sha1-modp2048!
The switch itself is not a big thing, but when you still have other Openswan IPSEC partners, you will have to change your Strongswan config a little bit.
Otherwise the two IPSEC implementations won't be able to build the VPN tunnel.
On the Openswan end of the VPN you will see such messages in your auth.log file:
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #746: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #670 {using isakmp#4 msgid:6c3f1671 proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048}
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #669: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #669: starting keying attempt 5 of an unlimited number
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #747: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #669 {using isakmp#4 msgid:23eb99a9 proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048}
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: received and ignored informational message
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: received and ignored informational message
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
On the Strongswan side, you see this in the daemon.log:
Jan 28 12:16:52 vpn01 ipsec[13909]: 09[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSEN
Jan 28 12:16:52 vpn01 ipsec[13909]: 09[ENC] generating INFORMATIONAL_V1 request 2468276578 [ HASH N(NO_PROP) ]
This is dues to some IKE mismatch (The OpenSWAN IKEv2 implementation has does not respect all standards)
You can solve this issue by specifying IKEv1 for the connection in your ipsec.conf on the Strongswan side:
keyexchange=ikev1
This should solve the problem.
Sometimes (Depending the Openswan setttings) you also have to add this to your connection definition on the Strongswan side:
esp=aes128-sha1-modp2048!
Subscribe to:
Posts (Atom)