NGINX (pronounced as engine-x) is a versatile (reverse) proxy service for Linux which can be used for many purposes. This post gives a relative small and easy example that I use at home for accessing insecure web services in my home. These are:
- Domoticz
Free and opensource Domotica software - SabNZBd
Free and opensource software for downloading binaries from usenet. Available for multiple operating systems - Sonarr
(former NZBDrone) is a so-called PVR (personal video recorder) for Usenet users, which checks multiple RSS feeds (also called Indexer) for new episodes of the shows you're following.
These services run on different platforms and are not protected by username/password or encryption. Something that's not done if you want to access this over the Internet.
To get secure access to these services you might want to use a VPN solution into your home, but you can also achieve this by using a reverse proxy that 'protects' these services.
I run my NGINX reverse proxy on Ubuntu Linux, but it will also run on the average Raspberry Pi.
Last year I implemented an ISPConfig3 configuration
for personal use. Mainly to host some e-mail domains, and perhaps some
basic websites. This setup relatively easy to implement a should have
been a breeze to maintain.... Untill I got an email from the provider
last Tuesday, mentioning that my Linux VPS was attacking other hosts
around the world..... *GASP*.. my VPS had (most likely) been assimilated
into a botnet of some sort, and it was flooding a ton of other hosts.
When you create (SSL)VPN access for you employees, you might enable split-tunneling to save corporate bandwidth. No split-tunneling means that all traffic is forwarded into the VPN tunnel. So if you browse the internet with an active VPN, the traffic goes through the VPN, and accesses the Internet through the corporate Internet connection. This isn't a big problem with a couple of employees, but with hundreds on the road or working from home, this might frustrate the employees in the building.
When you install a Perfect Server based on Centos and ISPConfig v3.x, the system / 'installer' creates for the components self-signed certificates. All these certificates will generate different warnings in your browser, mail clients etc. So time to eliminate those warnings.
First I needed to find out where all those certificates are located, and what there formats are. In my case, there are three services that use SSL/TLS in some form;
- Postfix SMTP service
- Courier IMAP service
- http / Apache2 webservice
Checking the configuration files will reveal their locations.
A fairy long title, but it describes exactly what this post is about. Once again a post about a Microsoft product and the way it works (or rather doesn't work) with your average Internet standard.
This week I was busy with RADIUS, 802.1x, PKI and the protection of websites with SSL encryption. For the implementation of 802.1x, I needed a PKI environment, so I used the Microsoft Certificate Services for that purpose. Along the way, I needed an SSL certificate for an internal website, but this particular website needed to work properly based on different FQDN's and or IP addresses without throwing warining or errors regarding the SSL connection.
The way to do this is to add Subject Alternative Names (SAN) to the certificate. This enables you to access the website in different ways, e.g.;
- Access a webmail host from the internet based on its official FQDN (https://webmail.somedomain.com)
- Access the same webmail host from the inside of the corporate lan based on its internal name (https://webmail.acme.local)
- And access the host from legacy DNS-unaware software on its IP address (https://192.168.1.254)
By default, the J-Web interface (GUI for the Juniper SRX firewalls) has SSL enabled. Like most devices with SSL out-of-the-box, the protection is based on a self-signed certificate. Self-signed certificates are easy (they come basically out-of-the-box), but they tend to nag you every time you connect to the GUI. So, it's time to install a proper certificate.
In this case, I use the XCA (1) software to create a new certificate. This certificate is signed by my own root CA, which I installed on all of my devices and Operating Systems. Basically, I trust myself.....
According to the Juniper support pages on SSL certificate usage, I found out that the certificates are to be in the PEM format. No problem for XCA.
The Fritzbox 7340 is the only real available VDSL modem/router in the Netherlands. Too bad, since it has some bugs (but what piece of software hasn't???). Fortunately, the router works well, just as long as you use it as the only networking device in your (small) network.
In the last couple of days I've been busy to add the Juniper SRX100 branch firewall to my local home network. The idea was the following:
- The Fritzbox (FB) will remain the Internet router
- My web/mail/ssh server is placed behind the SRX100
- All the individual portforward rules in the Fritzbox are directed to the SRX100 by selecting the 'Exposed Host' in the FB.
For many, the world is was in disarray. It seems that the Twitters have been hacked (read: defaced) by the infamous (never heard of them though) Iranian Cyber Army.
Twitter rerouted to an Iranian Cyber Army page.
Since I encountered some problems with flash on certain websites, I decided to check if my Flash player has been updated since 1972. Normally you can check the Flash settings (incl auto-update functions) through a page on the Adobe/Macromedia website. Which is weird, since you would think that this is a local setting (incl. privacy settings and audio functionalities).... But no. Macromedia/Adobe decided that you have to do that through their website.
The reason being that they can check whatever you are doing with your player.......
;)