Category Archives: Security

Let's Encrypt Certificate for SMTP with STARTTLS

Let's Encrypt provides an easy way to get free certificates not only for web servers, but also for email servers like Postfix.

The way Let's Encrypt usually works requires you to setup a web server. Let's Encrypt sends you a challenge, and you have to prove ownership of the domain by providing a response to that challenge. You do this by placing the response in a certain URL on your web server:
http://www.yourserver.com/.well-known/acme-challenge/FgedPYS65N3HfwmM7IWY2...

That way you prove that you are the owner of the domain "yourserver.com". But there is another even easier way to prove ownership of a domain: DNS. You place the response in a specific TXT record of your domain: _acme-challenge.www.yourserver.com

  • You can use your domain hosting service (GoDaddy, Whois, etc.) to create a new TXT record.
  • The "certbot" command line client does all the rest in just one call.
  • Under Debian 9 and 10, "certbot" is part of the official package repository.
  • You can run certbot on any Linux client. You don't have to run it on the email server.

Example

In this example the public hostname of your mail server is mx.yourserver.com. Therefore you have to create a TXT record called _acme-challenge.mx.yourserver.com . The value of the TXT record is in the output of certbot.

# certbot certonly --manual --preferred-challenges dns -d mx.yourserver.com
 
Saving debug log to /var/log/letsencrypt/letsencrypt.log 
Plugins selected: Authenticator manual, Installer None 
Obtaining a new certificate 
Performing the following challenges: 
dns-01 challenge for mx.yourserver.com 
 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
NOTE: The IP of this machine will be publicly logged as having requested this 
certificate. If you're running certbot in manual mode on a machine that is not 
your server, please ensure you're okay with that. 
 
Are you OK with your IP being logged? 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
(Y)es/(N)o: Y 
 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Please deploy a DNS TXT record under the name 
_acme-challenge.mx.yourserver.com with the following value: 
 
1A4RACHEISTBLUTWURST_egTVadkeiieikeieisfkfk
 
Before continuing, verify the record is deployed. 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Press Enter to Continue 
Waiting for verification... 
Cleaning up challenges 
 
IMPORTANT NOTES: 
 - Congratulations! Your certificate and chain have been saved at: 
   /etc/letsencrypt/live/mx.yourdomain.com/fullchain.pem 
   Your key file has been saved at: 
   /etc/letsencrypt/live/mx.yourdomain.com/privkey.pem 
   Your cert will expire on 2020-02-15. To obtain a new or tweaked 
   version of this certificate in the future, simply run certbot 
   again. To non-interactively renew *all* of your certificates, run 
   "certbot renew" 
 - If you like Certbot, please consider supporting our work by: 
 
   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate 
   Donating to EFF:                    https://eff.org/donate-le
Share

World's most famous and secure public VPN service is leaking sensitive information

Probably one of the world's most famous public VPN providers is leaking your traffic. The weirdest thing about it is, nobody noticed the traffic before.

Lessons learned: Always check no matter how good the reputation might be.

https://www.niem.es/2019/03/f5d599a39d02caef1984e95fdc606f838893ffc5-xyz.html

Update (2019-10)
Nobody is perfect. Half a year later, there seems to be another problem with our famous VPN service. Not so much information about it out there, so here is a link in case you want to check yourself.

Lessons learned: Double check for safety's sake.

https://www.theregister.co.uk/2019/10/05/security_roundup_october_4/

Update (2019-10)
Oh noooo, now our famous VPN provider got hacked really bad. Private keys for OpenVPN have been revealed, but they already expired in 2018. Nevertheless, it could be that those keys were hacked in 2018 when they were still valid. All I can say: "Told ya!"

Lessons learned: Triple check for safety's sake.

https://share.dmca.gripe/hZYMaB8oF96FvArZ.txt

Share

Security Alert: Migrate to Post-Quantum Cryptography Right Now!

Current cryptographic algorithms will be broken within the next couple of years. The time to migrate to post-quantum cryptography is right now. Ah yes ... and while you're at it, don't forget about crypto currency.

https://www.zdnet.com/article/ibm-warns-of-instant-breaking-of-encryption-by-quantum-computers-move-your-data-today/

Migration steps towards post-quantum cryptography:

  1. Identify possible technologies
  2. Choose algorithms for standardization
  3. Standardization (RFCs)
  4. Implementation
  5. Integration into operating systems

Right now, we are at step 1 and 2.

Update (20.04.2018)
OpenSSH 8.0 supports quantum-computing resistent key exchange method - still experimental though.
https://www.openssh.com/txt/release-8.0

Share

iptables: Block traffic by country (Debian 10)

You need the package versions from at least Debian 10 testing for this to work. Installing specific packages from the testing branch is beyond the scope of this article, but there are many tutorials online.

  • Switch to legacy iptables (I did not try it with the new nftables packet filter that came with Debian 10):
sudo update-alternatives --config iptables 
There are 2 choices for the alternative iptables (providing /usr/sbin/iptables). 

 Selection    Path                       Priority   Status 
------------------------------------------------------------ 
 0            /usr/sbin/iptables-nft      20        auto mode 
* 1            /usr/sbin/iptables-legacy   10        manual mode 
 2            /usr/sbin/iptables-nft      20        manual mode 

Press <enter> to keep the current choice[*], or type selection number: 1
  • Install iptables module "geoip" (from testing) and dependencies:
sudo aptitude install xtables-addons-common/testing xtables-addons-dkms/testing libnet-cidr-lite-perl libtext-csv-xs-perl
  • Make sure you have the right version (from Debian testing):
apt show xtables-addons-common
...
Version: 3.5-0.1
...
  • Download and build geoip database (zipped CSV file from MaxMind):
sudo -i
mkdir /usr/share/xt_geoip/ 
cd /usr/share/xt_geoip/
/usr/lib/xtables-addons/xt_geoip_dl
cd GeoLite2-Country-CSV_* 
/usr/lib/xtables-addons/xt_geoip_build
cp *iv? ..
  • Check your iptables rules in INPUT chain. It should look something like this, if you already setup iptables:
# iptables --line-numbers -nL  INPUT

Chain INPUT (policy DROP) 
num  target     prot opt source               destination          
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
2    ACCEPT     ...
3    ACCEPT     ...
...
8    LOG        all  --  0.0.0.0/0            0.0.0.0/0            state INVALID,NEW LOG flags 0 level 4 prefix "DROP input:"
  • Add iptables rule to block all incoming traffic from e.g. Prague/Czech Republic. Make sure to insert the new rule after the RELATED/ESTABLISHED rule and before any other ACCEPT rules. In this example, the rule is inserted as line number 2.
iptables -I INPUT 2 -m geoip --src-cc CZ -j DROP
  • In the second example we block all traffic except the one that is originating from the United States. TCP traffic is not simply dropped, but spoofed by the DELUDE target.
iptables -I INPUT 2 -m geoip ! --src-cc US -j DROP
iptables -I INPUT 2 -p tcp -m geoip ! --src-cc US -j DELUDE

Important things to note:

  • You have to reinstall package "xtables-addons-common" with every new kernel version because it is compiled during package installation using the current kernel source (see /usr/src/xtables-addons-*).
  • For more information about the DELUDE target in the second example, see "man xtables-addons". It spoofs nmap scans and makes it harder for port scanners to scan the destination host. It is only valid for TCP traffic.
Share

Add entropy to KVM virtual guests (Why is key creation so slow?)

Problem

Cryptographic key creation (GnuPG, SSH, etc.) in virtual guests may be very slow because there is not enough entropy.

$ cat /proc/sys/kernel/random/entropy_avail 
7

Solution

Add /dev/urandom from virtual host in virt-manager. Click on "Add Hardware".

Add "RNG" device.

This is what will be added to the qemu xml file in /etc/libvirt/qemu:

<domain type='kvm'>
  ---
  <devices>
    ...
   <rng model='virtio'> 
     <backend model='random'>/dev/urandom</backend> 
     <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> 
   </rng> 
 </devices> 
</domain>

In the virtual guest, install "rng-tools" (Ubuntu 18.04).

$ sudo apt-get install rng-tools

If something goes wrong, the rngd daemon will complain in /var/log/syslog.

Oct 13 22:48:07 guest rngd: read error 
Oct 13 22:48:07 guest rngd: message repeated 99 times: [ read error] 
Oct 13 22:48:07 guest rngd: No entropy sources working, exiting rngd

If rngd is working correctly, check entropy level again.

$ cat /proc/sys/kernel/random/entropy_avail
3162
Share

Security Guidelines

Computer Security

Physical Device Security

  • Always completely switch off your computer and lock your computer safely away, even if you just visit the bathroom. Screen saver locking or putting the laptop into sleep mode is not enough (Cold Boot Attacks).
    https://blog.f-secure.com/cold-boot-attacks
  • Don't display anything important on your computer screen (Van-Eck-Phreaking).
    https://twitter.com/windyoona/status/1023503150618210304
    http://www.eweek.com/security/researchers-discover-computer-screens-emit-sounds-that-reveal-data
  • Don't type in anything important on your keyboard or touchscreen.
    http://www.eweek.com/security/researchers-discover-computer-screens-emit-sounds-that-reveal-data
  • Install USBGuard to protect against unknown USB devices.
    (Note that USB IDs and serial numbers of USB devices can easily be replicated. Once an attacker knows the type of USB device you are using, and its serial number, USBGuard can easily be bypassed. That means: Never lend someone your USB stick, never accept a USB device from untrustworthy persons ... which means anyone.)

Software Security

  • Always use fingerprints to identify certificates for important web services. Don't rely solely on CAs.
    https://www.theregister.co.uk/2018/09/06/certificate_authority_dns_validation/

Useful Links

  • Ubuntu Security
    https://www.ubuntu.com/security
  • Ubuntu Security Features Matrix
    https://wiki.ubuntu.com/Security/Features
  • End User Device Security Guidance for Ubuntu 18.04 LTS from the NCSC (National Cyber Security Center, part of GCHQ)
    https://www.ncsc.gov.uk/guidance/eud-security-guidance-ubuntu-1804-lts
Share

Password security - it is not about length or complexity

Password

Passwörter sollten nach Möglichkeit nicht im Klartext am Bildschirm angezeigt werden. Neben dem offensichtlichen Shoulder Surfing ("über die Schulter schauen"), gibt es auch sog. Seitenkanalangriffe in blickgeschützten Bereichen.

Das ursprünglich für ältere Röhrenmonitore entwickelte Van-Eck-Phreaking, bei dem die elektromagnetische Strahlung über größere Distanzen aufgezeichnet wird, lässt sich offenbar auch für moderne LCD-Monitore mit HDMI-Kabel ausnutzen. Aus der empfangenen elektromagnetischen Strahlung wird dann das ursprüngliche Monitorbild rekonstruiert. Die dazu notwendige Elektronik ist mittlerweile schon für ambitionierte Hobby-Bastler erschwinglich.

Einige Quellen im Internet weisen ebenso auf relativ hohe elektromagetische Strahlungen und akustische Signale von aktuellen PC-Grafikkarten und Flachbildschirmen/Touchscreens in Kombination mit Monitor- und Stromkabeln hin, die im Prinzip wie eine Antenne funktionieren.

Um Sicherheitsproblemen in diesem Bereich von vornherein aus dem Weg zu gehen, kann man z.B. moderne Passwortmanager verwenden, die Passwörter automatisch generieren und dann über die Zwischenablage in die Anwendung kopieren, ohne das Passwort selbst im Klartext eintippen oder auf dem Bildschirm anzeigen zu müssen.

Share

Top 5 questions you should never ask computer security experts

  1. If you can hack into my computer, why should I trust you?
  2. If there is an update for my software, does that mean that it was vulnerable for the last couple of years?
  3. Are printed documents safer than computers?
  4. Today's computer devices are insanely insecure (s. Security Guidelines). If I buy a PC, monitor, laptop, tablet or mobile phone online, why is there no option for e.g. protection against radio signal emission?
  5. I can break into any house by smashing the windows. Why should computers be safer than real world objects?

Absolute security is an illusion of the past (online and offline). The roof top has been blown off. It is now time to close the doors and windows downstairs to keep the rats out.

https://goo.gl/images/TDf4d1

Share

That was 2017

Ubuntu 16.04 LTS Security Notices

Overall USNs: 348

Highest CVE priority fixed by USN:

  • High: 61
  • Medium: 277
  • Low: 5

Bugfixes in Red Hat Enterprise Linux 7

https://www.redhat.com/security/data/metrics/

Critical: 45 vulnerabilities
** Average time for fixing: 2 days
** 15% were 0day
** 37% were within 1 day
** 100% were within 7 days
** 100% were within 14 days
** 100% were within 31 days
** 100% were within 90 days

Important: 137 vulnerabilities
**Average time for fixing: 39 days
** 22% were 0day
** 29% were within 1 day
** 63% were within 7 days
** 65% were within 14 days
** 69% were within 31 days
** 87% were within 90 days

Moderate: 308 vulnerabilities
**Average time for fixing: 165 days
** 3% were 0day
** 8% were within 1 day
** 20% were within 7 days
** 21% were within 14 days
** 25% were within 31 days
** 43% were within 90 days

Low: 103 vulnerabilities
**Average time for fixing: 264 days
** 0% were 0day
** 2% were within 1 day
** 7% were within 7 days
** 7% were within 14 days
** 7% were within 31 days
** 19% were within 90 days

Share

Top 20 reasons for choosing weak passwords

  1. Weak PasswordYou just don't care because the account does not contain sensitive data and you are not using your real name anyway.
  2. Typing in strong passwords with a combination of special characters and regular characters takes ages on smart phones and tablets.
  3. Computers can't be trusted anyway, so why bother with a complicated password?
  4. Nobody is interested in you anyway.
  5. Password is for a shared account. Explaining to someone the password "%&__!(E2-<"+?=-:*d3//#@" over the phone is just too nerve wrecking.
  6. You want to have access to the account in case of an emergency, and you are afraid to forget the password if it is too complicated.
  7. "12345" can not be so bad if everyone else is using it as a password.
  8. After using strong passwords for years, your wifi was hacked by a 13 year old neighbor kid who got bored playing World of Warcraft on a Saturday evening.
  9. When creating an account you first choose a password easy to remember, only to change it later to a much more secure password. Never happens.
  10. The real password is your username.
  11. You are a math genius: If "12345" is so highly likely to be guessed, why do these numbers never get picked by the national lottery?
  12. Two words: Quantum computers
  13. Passwords are for pussies: Secret information is hidden in porn movies using steganography.
  14. You are a celebrity who wants to get into the headlines.
  15. You want to become a celebrity and therefore use every way to get into the headlines.
  16. Wife wants to set a trap for her husband to see if he is spying on her. Chooses a weak password and checks login times regularly.
  17. What was the question? Passwords? ... yeah ... do you know where my skateboard is?
  18. You know that "12345" is not secure, but at least it's more secure than "1234".
  19. The account is only a temporary account. You use it once and then forget about it.
  20. The account was automatically created by a script.
Share