Category: security

There were times when we were looking for simple yet unorthodox solutions; and this case was one of them. Imagine, if there was a Windows 2012 server with its standard VPN service (RAS, or, Remote Access, actually), configured and operational. The only problem was that static IP of the server (as seen by a connected user) was not up at all times. For instance, assume DHCP IP range for VPN clients was 172.0.2.1 – 172.0.2.199. That makes first address of the range, 172.0.2.1 the server’s address that is accessible by VPN clients (inside VPN tunnel). When server just started that IP would be down – not even pingable, let alone not routable. The IP address becomes live as soon as first VPN client is connected from outside to the RAS service. That presented a challenge for application jobs configured to run in both modes: locally on the server and from remote locations connected to the server. We would configure 172.0.2.1 as a universal connection point for all the applications and grant proper server firewall exclusions, though… they would not be able to connect if no external users connected to the VPN service yet.

Just a quick note as we have had a few reports lately that Shrewsoft VPN client package for Mac OS X (El Capitan release) was missing in main homebrew repository. That caused troubles for folks trying to use our recipe on that subject from last year.

Another showcase with Palo Alto PA-3020 firewall hardware device by Palo Alto Networks running PAN OS 6.0 (PA-3000 series). This time we would like to discuss a use of multiple IP addresses on the external interface. Say, you are running into a situation where more than one HTTPS web services should be offered to the public, but they are based on separate hardware resources internally. The simple solution would be to use another IP address for incoming connection on TCP port 443 and create another NAT policy rule for that additional address.

It is typical for a Windows server to have a auto-generated self-signed certificate for its Remote Desktop service. Not a good practice. Especially when RDP service is exposed on the internet (via TCP port 3389 that would be open in firewall). Here are a few simple steps to install a valid SSL certificate to be used with RDP to protect the host identity and encrypt your remote desktop sessions properly.

Reports surfaced recently that bypassing authentication of a Linux system equipped with Grub2 versions from 1.98 (December, 2009) to 2.02 (December, 2015) is as easy as pressing backspace key 28 times when the boot loader prompts for a username.

When we got to upgrade our Macbook Pro to the all new Mac OS X 10.11, we surely liked its slick new style and interface improvements. And what not to like. The only drawback was that our Shrew Soft VPN client has fallen victim of the new ship commander.

A new edition of The Debian Administrator’s Handbook by Raphaël Hertzog, Roland Mas—the third one counting only English editions, and the seventh if the first four French-only are included—has been issued by Freexian. Shortly after the first English edition, communal experience with the book has justified the the in its title, the book becoming both the most widely read introduction into Debian and the most used single handbook, leaving out the documentation itself, of course.

Nice and short overview of vulnerabilities hiding inside SSL tunnels from BlueCoat:

Today our challenge was to create a simple setup that is often called inbound TCP port forwarding, or, a pinhole with a more (or less) advanced firewall device. The network appliance for this cosmetic surgery was one of the recent PAN (Palo Alto Networks) PA-3000 series running PAN OS 6.0. First of all, do not do it. Again, do not do it. And again: please, do not create a destination port forwarding from external network interface into an internal or trusted network behind the firewall. There are other (proper!) techniques that would be better to use for remote network access, dedicated line or VPN (stands for Virtual Private Networking), for instance. Modern VPNs have little overhead and lots of security benefits. Though, for testing purposes only, we have decided to ignore our own advice which was just mentioned above for 3 times.

What if you had an existing SSL certificate for your static website, say running Apache2 web server. What if you needed to re-use same certificate for a new dynamic Java-based website running Tomcat instance that you were just adding. That would include following steps: