find file types in a path (recursively) and copy them all to 1 location

Find file types in a path (recursively) and copy them all to 1 location:

find /path/to/directory -name "*.mp3" -exec cp {} /some/other/dir/ \;

*.mp3 could be “.jpg or *.whatever.

Setting up OpenVPN on your Debian-based Linux Server

I’ve written extensively about using SSH to to create a “poor man” proxy to protect your data when connecting to an untrusted network (for example in a Starbucks cafe or a hotel). Using an SSH connection with a SOCKS5 proxy is often cumbersome and not all applications natively support the SOCKS protocol.

A simpler method from the client side (although more complicated to set up on the server end) would be to configure your home Linux server to serve as an OpenVPN server. You would then configure your laptop or Android-based mobile device (or any Apple devices) to use the OpenVPN client. An OpenVPN client will force all traffic (including DNS requests) through the home Linux computer and force all Internet-based traffic out of your home Internet connection.

Below are the steps to configure your OpenVPN server and an overview of using the OpenVPN client. It’s important that these steps be done in order.

This HowTo assumes you’re running a variation of a debian-based operating system such as Ubuntu or Linux Mint. Setting up an OpenVPN server requires a moderate level of understanding of the Linux operating system. I don’t recommend this for users new to Linux as it may be difficult to troubleshoot problems.

For these commands, it’s best to just switch to root using the “su” command. Once you’re root, you’ll initially want to update your repositories:

apt-get update

Next, you’ll want to install OpenVPN and easy-rsa.

Once installed the sample OpenVPN configuration file needs to be extracted to /etc/openvpn so it can then be edited for our specific installation.

gunzip -c /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz > /etc/openvpn/server.conf

Once extracted, you’ll want to edit this file.

pico /etc/openvpn/server.conf

The server.conf file will look something like this:

# Diffie hellman parameters.

# Generate your own with:

# openssl dhparam -out dh1024.pem 1024

# Substitute 2048 for 1024 if you are using

# 2048 bit keys.

dh dh1024.pem

You will want to edit the last line and change it from dh dh1024.pem to …

dh dh2048.pem

This will double the key length of the key that is generated, increasing security.

Next, you’ll want to look for this section:

# If enabled, this directive will configure

# all clients to redirect their default

# network gateway through the VPN, causing

# all IP traffic such as web browsing and

# and DNS lookups to go through the VPN

# (The OpenVPN server machine may need to NAT

# or bridge the TUN/TAP interface to the internet

# in order for this to work properly).

;push “redirect-gateway def1 bypass-dhcp”

Remove the semicolon from the last line “redirect-gateway def1 bypass-dhcp” so the VPN server passes on clients’ web traffic to its destination.

push “redirect-gateway def1 bypass-dhcp”

The next section you’ll want to edit will look like this:

# Certain Windows-specific network settings

# can be pushed to clients, such as DNS

# or WINS server addresses. CAVEAT:

# http://openvpn.net/faq.html#dhcpcaveats

# The addresses below refer to the public

# DNS servers provided by opendns.com.

;push “dhcp-option DNS 208.67.222.222”

;push “dhcp-option DNS 208.67.220.220”

Here, you’ll remove the semicolons as well for the last two lines so it looks like the 2 lines below:

push “dhcp-option DNS 208.67.222.222”

push “dhcp-option DNS 208.67.220.220”

The above 2 lines will instruct OpenVPN to use OpenDNS to handle all DNS requests. This is important so that any DNS requests do not leak outside of the encrypted tunnel.

The next area to modify in server.conf is here:

# You can uncomment this out on

# non-Windows systems.

;user nobody

;group nogroup

Remove the semicolons from the last 2 lines so it looks like this:

user nobody

group nogroup

By default, OpenVPN runs as the root user and thus has full access to the system. The above modification will confine OpenVPN to the user nobody and group nogroup. This is an unprivileged user with no default login capabilities and is an appropriate method to secure your OpenVPN server from any abuses from an OpenVPN client.

Save your changes and exit pico.

The line belowis a sysctl setting which tells the server’s kernel to forward traffic from client devices out to the Internet. Otherwise, the traffic will stop at the server. From your command prompt as root, enter this command:

echo 1 > /proc/sys/net/ipv4/ip_forward

We need to make this permanent so the server still forwards traffic after rebooting. To accomplish this you will edit the following file:

pico /etc/sysctl.conf

Near the top of the sysctl file, you will see:

# Uncomment the next line to enable packet forwarding for IPv4

#net.ipv4.ip_forward=1

Remove the # from net.ipv4.ip_forward. It should look like this when done:

net.ipv4.ip_forward=1

Save your changes and exit pico.

Now, you’ll need some special settings in your Firewall. By default Ubuntu and Linux Mint come with UFW (Uncomplicated Firewall). If you do not have this already installed, install it. Furthermore you may want to install gUFW or the graphical front-end to Uncomplicated Firewall so you can more easily manage your firewall in the future.

First set ufw to allow SSH. In the command prompt, ENTER:

ufw allow ssh

We use OpenVPN over UDP, so ufw must also allow UDP traffic over port 1194.

ufw allow 1194/udp

The ufw forwarding policy needs to be set as well. We’ll do this in ufw’s primary configuration file.

pico /etc/default/ufw

Look for DEFAULT_FORWARD_POLICY=”DROP”. This must be changed from DROP to ACCEPT. It should look like this when done:

DEFAULT_FORWARD_POLICY=”ACCEPT”

Next we will add additional ufw rules for network address translation and IP masquerading of connected clients.

pico /etc/ufw/before.rules

Make the top of your before.rules file look like below. The area in bold for OPENVPN RULES must be added:

#

# rules.before

#

# Rules that should be run before the ufw command line added rules. Custom

# rules should be added to one of these chains:

# ufw-before-input

# ufw-before-output

# ufw-before-forward

#

# START OPENVPN RULES

# NAT table rules

*nat

:POSTROUTING ACCEPT [0:0]

# Allow traffic from OpenVPN client to eth0

-A POSTROUTING -s 10.8.0.0/8 -o eth0 -j MASQUERADE

COMMIT

# END OPENVPN RULES

# Don’t delete these required lines, otherwise there will be errors

*filter

Save your changes and now enable UFW with the following command:

ufw enable

Enabling ufw will return the following prompt:

Command may disrupt existing ssh connections. Proceed with operation (y|n)?

Answer y. The result will be this output:

Firewall is active and enabled on system startup

To check ufw’s primary firewall rules:

ufw status

The status command should return these entries:

Status: active

To Action From

— —— —-

22 ALLOW Anywhere

1194/udp ALLOW Anywhere

22 (v6) ALLOW Anywhere (v6)

1194/udp (v6) ALLOW Anywhere (v6)

It is important to add port 1194, UDP protocol to your home router. That port and protocol will have to be forwarded to the internal IP address of your Linux server. This is a critical step otherwise you will not be able to reach your OpenVPN Linux computer from outside your home.

Creating a Certificate Authority and Server-Side Certificate & Key:

It is now time to set up our own Certificate Authority (CA) and generate a certificate and key for the OpenVPN server. OpenVPN supports bidirectional authentication based on certificates, meaning that the client must authenticate the server certificate and the server must authenticate the client certificate before mutual trust is established. We will use Easy RSA’s scripts we copied earlier to do this.

First copy over the Easy-RSA generation scripts.

cp -r /usr/share/easy-rsa/ /etc/openvpn

Then make the key storage directory.

mkdir /etc/openvpn/easy-rsa/keys

Easy-RSA has a variables file we can edit to create certificates exclusive to our person, business, or whatever entity we choose. This information is copied to the certificates and keys, and will help identify the keys later.

pico /etc/openvpn/easy-rsa/vars

The variables below marked in bold should be changed according to your preference.

export KEY_COUNTRY=”US

export KEY_PROVINCE=”Any state or province

export KEY_CITY=”Any city

export KEY_ORG=”Any company name or make something up

export KEY_EMAIL=”someone@somewhere.com

export KEY_OU=”SomeOrganizationalUnitOrMakeUpAName

In the same vars file, also edit this one line shown below. For simplicity, we will use server as the key name. If you want to use a different name, you would also need to update the OpenVPN configuration files that reference server.key and server.crt.

export KEY_NAME=”server”

We need to generate the Diffie-Hellman parameters; this can take several minutes.

openssl dhparam -out /etc/openvpn/dh2048.pem 2048

Now let’s change directories so that we’re working directly out of where we moved Easy-RSA’s scripts to earlier in Step 2.

cd /etc/openvpn/easy-rsa

(This step below is important!!) Initialize the PKI (Public Key Infrastructure). Pay attention to the dot (.) and space in front of ./vars command. That signifies the current working directory (source). Please note the SPACE between each of the dots below!

. ./vars

The output from the above command is shown below. Since we haven’t generated anything in the keys directory yet, the warning is nothing to be concerned about.

NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys

Now we’ll clear the working directory of any possible old or example keys to make way for our new ones.

./clean-all

This final command below builds the certificate authority (CA) by invoking an interactive OpenSSL command. The output will prompt you to confirm the Distinguished Name variables that were entered earlier into the Easy-RSA’s variable file (country name, organization, etc.).

./build-ca

Simply press ENTER to pass through each prompt. If something must be changed, you can do that from within the prompt.

Generate a Certificate and Key for the Server

Still working from /etc/openvpn/easy-rsa, now enter the command to build the server’s key. Where you see server marked in red is the export KEY_NAME variable we set in Easy-RSA’s vars file earlier.

./build-key-server server

Similar output is generated as when we ran ./build-ca, and you can again press ENTER to confirm each line of the Distinguished Name. However, this time there are two additional prompts:

Please enter the following ‘extra’ attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

Both should be left blank, so just press ENTER to pass through each one.

Two additional queries at the end require a positive (y) response:

Sign the certificate? [y/n]

1 out of 1 certificate requests certified, commit? [y/n]

The last prompt above should complete with:

Write out database with 1 new entries

Data Base Updated

Move the Server Certificates and Keys

OpenVPN expects to see the server’s CA, certificate and key in /etc/openvpn. Let’s copy them into the proper location.

cp /etc/openvpn/easy-rsa/keys/{server.crt,server.key,ca.crt} /etc/openvpn

You can verify the copy was successful with:

ls /etc/openvpn

You should see the certificate and key files for the server.

At this point, the OpenVPN server is ready to go. Start it and check the status.

service openvpn start

service openvpn status

The status command should return:

VPN ‘server’ is running

Congratulations! Your OpenVPN server is operational. If the status message says the VPN is not running, then take a look at the /var/log/syslog file for errors such as:

Options error: –key fails with ‘server.key’: No such file or directory

That error indicates server.key was not copied to /etc/openvpn correctly. Re-copy the file and try again.

Generate Certificates and Keys for Clients

So far we’ve installed and configured the OpenVPN server, created a Certificate Authority (CA), and created the server’s own certificate and key. Here we use the server’s CA to generate certificates and keys for each client device which will be connecting to the VPN. These files will later be installed onto the client devices such as a laptop or smartphone.

Key and Certificate Building

It’s ideal for each client connecting to the VPN to have its own unique certificate and key. This is preferable to generating one general certificate and key to use among all client devices.

Note: By default, OpenVPN does not allow simultaneous connections to the server from clients using the same certificate and key. (See duplicate-cn in /etc/openvpn/server.conf.)

To create separate authentication credentials for each device you intend to connect to the VPN, you should complete this step for each device, but change the name client1 below to something different such as MyTablet1 or Laptop1 or any other unique name you prefer. With separate credentials per device, they can later be deactivated at the server individually, if need be. The remaining examples in this tutorial will use client1 as our example client device’s name.

As we did with the server’s key, now we build one for our client1 example. You should still be working out of /etc/openvpn/easy-rsa.

./build-key client1

Once again, you’ll be asked to change or confirm the Distinguished Name variables and these two prompts which should be left blank. Press ENTER to accept the defaults.

Please enter the following ‘extra’ attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

As before, these two confirmations at the end of the build process require a (y) response:

Sign the certificate? [y/n]

1 out of 1 certificate requests certified, commit? [y/n]

If the key build was successful, the output will again be:

Write out database with 1 new entries

Data Base Updated

The example client configuration file should be copied to the Easy-RSA key directory too. We’ll use it as a template which will be downloaded to client devices for editing. In the copy process, we are changing the name of the example file from client.conf to client.ovpn because the .ovpn file extension is what the clients will expect to use in the OpenVPN client program.

cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/easy-rsa/keys/client.ovpn

You can repeat this section again for each client, replacing client1 with the appropriate client name throughout.

At this point, we need to unify the client’s certificate and keys to a singular OpenVPN file for transfer to the client device.

There are several methods for managing the client files but the easiest uses a unified profile. This is created by modifying the client.ovpn template file to include the server’s Certificate Authority, and the client’s certificate and its key. Once merged, only the single client.ovpn profile needs to be imported into the client’s OpenVPN application.

We will create a single profile for our client1 device on the local computer we downloaded all the client files to. This local computer could itself be an intended client or just a temporary work area to merge the authentication files. The original client.ovpn template file should be duplicated and renamed. How you do this will depend on the operating system of your local computer.

Note: The name of your duplicated client.ovpn doesn’t need to be related to the client device. The client-side OpenVPN application will use the file name as an identifier for the VPN connection itself. Instead, you should duplicate client.ovpn to whatever you want the VPN’s nametag to be in your operating system. For example: work.ovpn will be identified as work, school.ovpn as school, etc.

In this tutorial, we’ll name the VPN connection home so home.ovpn will be the file name referenced from this point on. Once named, we then must open home.ovpn in a text editor; you can use whichever editor you prefer.

The first area of attention will be for the public IP address of your home connection. If your public IP address changes often, you ought to purchase a fully qualified domain name (FQDN) and place that (instead of your constantly-hanging IP) near the top of the file, change my-server-1 to reflect your home OpenVPN server’s public IP (e.g. the IP of your home cable-modem connection or the fully qualified domain name attached to your public IP).

# The hostname/IP and port of the server.

# You can have multiple remote entries

# to load balance between the servers.

remote my-server-1 1194

Next, find the area shown below and uncomment (remove the # symbol) user nobody and group nogroup, just like we did in server.conf in Step 1.

# Downgrade privileges after initialization

user nobody

group nogroup

The area given below needs the three lines shown to be commented out so we can instead include the certificate and key directly in the home.ovpn file. It should look like this when done:

# SSL/TLS parms.

# . . .

#ca ca.crt

#cert client.crt

#key client.key

To merge the individual files into the one unified profile, the contents of the ca.crt, client1.crt, and client1.key files are pasted directly into the .ovpn profile using a basic XML-like syntax. The XML at the end of the file should take this form:

<ca>
(insert ca.crt here)
</ca>
<cert>
(insert client1.crt here)
</cert>
<key>
(insert client1.key here)
</key>

When finished, the end of the file should be similar to this abbreviated example:

<ca>
—–BEGIN CERTIFICATE—–
. . .
—–END CERTIFICATE—–
</ca>

<cert>
Certificate:
. . .
—–END CERTIFICATE—–
. . .
—–END CERTIFICATE—–
</cert>

<key>
—–BEGIN PRIVATE KEY—–
. . .
—–END PRIVATE KEY—–
</key>

The client1.crt file has some extra information in it; it’s fine to just include the whole file.

Save the changes and exit. We now have a unified OpenVPN client profile (.ovpn file) to configure our client1.

Once you’ve merged & saved your certificate and key files into your master .ovpn file, you need to copy this .ovpn file to your client device (e.g. laptop, smartphone or tablet).

Once copied, you would simply install the OpenVPN software and IMPORT the .ovpn file. Once imported you should be able to activate the VPN tunnel. To be sure you’re using the VPN tunnel for your traffic, all you really need to do is visit any WhatIsMyIP webpage to check your public IP. Assuming you’re outside your home Internet connection, you’d visit any WhatIsMyIP web page (such as https://www.whatismyip.com/) and check your public IP. Activate your OpenVPN client using your .ovpn file and then re-visit the https://www.whatismyip.com/ page. Your IP ought to now be the same IP as your home IP address.

Furthermore, to check if your DNS lookups are leaking or not, you’ll want to check out https://www.dnsleaktest.com/ and run a standard test. The test will tell you out of which IP your DNS requests are being routed. They ought to be the same IP as your home Internet connection where your OpenVPN server resides.

If there’s any questions on installing your OpenVPN client on any of your devices, a Google Search should provide plenty of instructional material on how to install the OpenVPN client on your particular device.

On Android for example, it should be as easy as visiting the Android market, installing the OpenVPN app and running it. Once opened, import the .ovpn file you have just created and activate it.

It’s important to understand that the exact same .ovpn file cannot be used on more than one device at the same time. You’ll need to create new keys and certificates (while also copying the ca.crt which never changes) into new & unique .ovpn files for each new device you want to connect with a VPN. So long as each device has its own unique .ovpn file, they can all connect concurrently.

Enjoy!

Hilarious: Little girl hacks into her father’s computer using her Raspberry Pi

This video is precious. This precocious little girl can’t be more than 8 or 9 year’s old. She uses her Raspberry Pi to SSH into her father’s Mac and doesn’t readily reveal how she got his password either …!

She run’s a who command to list up her father’s shells, runs a top command to find a specific process that she knows indicates the application her father is currently working in and proceeds to wreak havoc.

This is hilarious and amusing to watch. Here’s the link to the Reddit discussion on the video as well.

How to securely backup LUKS-encrypted partitions, incrementally.

These days, security is at the forefront of many computer users’ minds. Running your primary machine with encryption is important to ensure privacy and security. Generally, the most common form of partition level encryption for Linux machines is the LUKS encryption specification which is directly supported by the Linux kernel.

Most file level backup applications (like rsync) require that the partition already be decrypted so it can backup the files. This is inherently insecure in that the partition must remain open/decrypted for the backup to take place. In addition, the backed up files at the destination will be unencrypted.

The solution is to backup the encrypted partition in its raw, encrypted form, directly at the block level. Should a restore ever be necessary, you’d restore the entire partition data back to an empty partition whereupon you can then mount the LUKS partition and decrypt the data.

Enter: Bdsync. It is not yet available in the Debian or Ubuntu/Mint repositories, but it can be directly downloaded. I hope in the near future this application will be added to the repositories for easier installation.

From the Bdsync manpage:

Bdsync can be used to synchronize block devices over a network. It generates a “binary patchfile” in an efficient way by comparing checksums of blocks of the local block device LOCDEV and the remote block device REMDEV.

This binary patchfile can be sent to the remote machine and applied to its block device REMDEV, after which the local blockdev LOCDEV and the remote block device REMDEV are synchronized.

bdsync was built to do the only thing rsync isn’t able to do: synchronize block devices.

Essentially Bdsync generates an MD5 hash checksums for each data block on the partition. It compares them between the source and destination. If there’s any differences for any block, just that block is copied to the destination. It works very much like rsync, just at the block level.

When used for the first time, Bdsync will have to copy every data block to the destination (via scp) which will take a while since it is essentially going to copy the entire partition.

The command to run a Bdsync on your partition will look something like this:

# bdsync "ssh root@remote_host bdsync --server" /dev/sdx1 /dev/copysdx1 | gzip > /some_local_path/sdx1-bdsync.gz

This will ssh to the remote host (server) and run Bdsync on the local partition and copy pipe it through gzip for compression to a path on the remote host side. I recommend trying this backup and restore process first on a test virtual machine as the source-data and then copy it out to the server hosting the virtual machine. Then try to do a restore to the virtual machine. If all goes well, you’ll feel comfortable with the process to do it for real.

For a restore, you’d simply run bdsync in reverse, with the “source” being the remote host copy of the partition and the destination being what you want to restore to.

In addition Bdsync works on any block device such as LVM volumes and RAID volumes. The destination for the copies also does not have to be network-based. They can easily copy to local, external USB drives.

This blog post may seem a bit sparse on the details and I know I’m just covering the broad strokes, but doing a block level incremental backup is an advanced topic and not meant for the uninitiated.

The Ultimate Open Source Software List for 2015

A master list of over 1200 applications organized by category, this Ultimate Open Source Software List is a great repository of applications if you’re looking for a solution to a specific problem. From backup applications to cloud infrastructure to paint programs and games, the list is expansive and thorough and listed alphabetically by category. Each item has its own link out to the project’s homepage for further details.

Though it would be nice if it offered a master index of categories at the front, as it’s currently laid out you have to page through the entire list Web 1.0 style.

Backup your GMail to your local hard drive, or any other Google service based files

Here’s a great feature by Google – they allow you to backup (download) your Gmail, Calendar, Contacts, the contents of your Google Drive, Google Books, Google Voice, Hangouts and other services that may host your content.

This is great if you want a local backup of all your data.

Unfortunately, it seems you cannot ask for a backup of your GMail from a certain date (assuming you’ve already done a full backup of your GMail recently), so you’d have to run this master/full backup over and over again if you wanted to obtain periodic backups of your new emails since your last backup/download.

The process kicks off in the background on Google’s servers and depending on how much data you have to backup the process can take hours or days. Eventually you’ll get an email with a link letting you know the zipping (or tar/gZip ) process is complete and you can then download the files. Google will automatically create multiple zip files if your content is >2GB.

The archive files you create from this process will stay on Google’s servers for one week.

Here’s the link to backup any service: https://www.google.com/settings/takeout/custom

If you want to specifically see a shorter list, you can try this URL: https://www.google.com/settings/takeout/custom/gmail,calendar

…or this https://www.google.com/settings/takeout/custom/gmail,calendar,contacts

 

Source.

BAD USB!

BadUSB – Turning devices evil. Once reprogrammed, benign devices can turn malicious in many ways, including:

  1. A device can emulate a keyboard and issue commands on behalf of the logged-in user, for example to exfiltrate files or install malware. Such malware, in turn, can infect the controller chips of other USB devices connected to the computer.
  2. The device can also spoof a network card and change the computer’s DNS setting to redirect traffic.
  3. A modified thumb drive or external hard disk can – when it detects that the computer is starting up – boot a small virus, which infects the computer’s operating system prior to boot.

For the security conscious, USB devices should be considered potentially as risky as contaminated hypodermic needles. Of course to infect a machine it will require physical access to the computer, but once infected the entire computer can never be trusted again.

A BadUSB device can actually replace a system’s BIOS. Wiping & reinstalling the operating system will do nothing as the corrupted firmware of the USB device is outside the control of an operating system installation. Apparently, this security hole has been known for some time and has already been weaponized.

There is no known fix to this security hole.

Hopefully USB manufacturers can issue a patch that can be applied universally to pre-existing firmware.

Sources: One, two.

Mail Server in a Box

Pretty interesting group of applications. I can see where this has merit for easy deployment of a mail server, though I think SPAM filtering might be a headache.

 

Mail-in-a-Box

NetHogs: A simple ‘net top’ tool

A great little application that runs in a shell prompt to let you know which applications are eating your bandwidth – live.

sudo apt-get install nethogs

Then run . . .

sudo nethogs

. . . from your shell prompt and enjoy the detailed information!

One odd caveat though: I had a Windows virtual machine running under Virtualbox that was using about 150Kbps and NetHogs did not list it by application, instead it listed it by IP address – in this case, the IP address of the virtual machine along with source and destination port numbers. It also did not attribute the traffic to eth0, but left the device blank.

I was expecting it to list the application, but I suppose in some scenarios (especially virtualization) all the available information may not be immediately available to NetHogs and so it will simply default to source/destination IP & port number.

(Source)

Command line based bandwidth speed test

Speedtest-CLI

Simply retrieve the python script:

wget -O speedtest-cli https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py

Then make the downloaded script executable and execute it (the below commands assume you’re in the same directory as the downloaded file):

chmod +x ./speedtest-cli
./speedtest-cli

Execute the command and enjoy a hassle-free, simple bandwidth speed test application from your shell prompt.

(Source)

Convert MKV files to M4V files

MKV files are great — the format offers excellent compression and high quality video bit for bit. I do find that when I try to play MKV files on my Blu-Ray or Samsung TV (via USB device) it will not fast forward or rewind. The fix is to change the container to an mpeg 4 video container.

Here’s the simple command: (-threads 0 = use all CPU cores)

ffmpeg -threads 0 -i input.mkv -vcodec copy -acodec copy -absf aac_adtstoasc output.m4v

How to secure public WIFI connections on PC’s, Laptops and Android devices

Wifi connections are convenient and are nearly essential these days for most users. However, securing your connection can be complex and difficult, especially if using a free wifi hotspot at an airport, hotel or cafe.

If you have the option, using a VPN is often a simple, effective way to create a secure connection. However, not everyone has a VPN server available and may want a homegrown/personal solution. Here, secure shell is the best way to go.

This blog post will cover how to secure your wireless connection from prying eyes when using free or paid public wifi when using Linux. Even if the free/public wifi is “secured” with encryption, you don’t want to trust these 3rd parties as you have no control over who else has access to the network or how it’s configured.

Securing your wireless connection could be done in Windows as well, through Putty and I may cover that in another post in the future.

Doing this will require a Intermediate understanding of the bash shell, the dynamics of SSH, public IP’s, port forwarding, as well as the concept of SOCKS Proxies.

It will require that you can reach your home Linux server over SSH from an outside public IP address. If you’re not sure how to do that, you should research that separately. It’s pretty simple in that it requires you to forward a port of your choice to your Linux server, whether on the DMZ or in your LAN, making sure your SSH service will answer to SSH calls on that port number. I would also suggest that you never run SSH on it’s default port (22) on your home Linux box, you’ll want that changed to a non-standard port and forward that port to your Linux box. Use the -p <port number> option in the SSH command to SSH out to your Linux box on the port number of your choice. For example:

 ssh -D 7890 server-ip-address -p 50004

I’ll discuss the -D option later in this post.

Before you try to connect to any public WIFI, you want to make sure your browser is configured to use the SOCKS Proxy protocol that will take advantage of the SSH connection. In FIREFOX, that’s under EDIT/PREFERENCES then ADVANCED, then the NETWORK tab, then click on SETTINGS.

You’ll want to remember the default proxy configuration here so you can change this setting back when you no longer wish to use the SSH encrypted tunnel for web traffic. In this menu, you’ll want to select a MANUAL PROXY CONFIGURATION.

Go down to SOCKS HOST and type in “localhost” (without quotes) and to the right, the port number (e.g. 7890, see the SSH command below). You’ll also want to select SOCKS v5, then click OK, then CLOSE settings.

This is only good for the actual web browsing data, but will not cover your DNS requests. Someone sniffing your packets on that free/public wifi will still be able to see your DNS requests and could return false DNS data to your machine, redirecting you to fake websites causing all sorts of issues (like man-in-the-middle attacks and other problems). The fix here is to make sure Firefox is set up to tunnel all DNS requests through the SOCKS Proxy. To do this, open a tab in your FIREFOX browser and in the address bar type: about:config. This will take you to the core FIREFOX settings.

From there, you’ll want to search for socks. Look for network.proxy.socks_remote_dns and double click that line to make sure the value changes from false to true. If It’s already true, leave it alone and exit the tab. You won’t need to save this change as it’s automatically saved once the setting is changed. You can close this tab after confirming this change.

There is no graphical way to do this in CHROME, so you’ll need to execute CHROME with your SOCKS Proxy settings directly from command line:

google-chrome --proxy-server="socks5://localhost:7890"

… where 7890 is the correct port number used for your dynamic SOCKS Proxy. This single command for CHROME will funnel all your web traffic as well as your DNS requests through the SSH SOCKS Proxy.

Once you’ve confirmed your browser of choice is properly configured, open a command prompt and SSH to your home Linux box.

ssh -D 7890 server-ip-address

… where -D tells SSH that you want to engage dynamic application-level port forwarding using the SOCKS protocol on your local computer’s port number 7890. You can choose any port you like.

As a side note, any application capable of using the SOCKS Proxy protocol can concurrently take advantage of this same connection and offer secure data exchange between your current public/wifi connection and your Linux SSH server.

You’ll want to confirm your browser is streaming it’s web requests through your Linux box as well as your DNS requests. The easy way to check your web traffic is just go to www.whatismyip.com — which will tell you your current public IP address. This should be a familiar IP as it ought to be your home public IP address and not the public IP of your free/public wifi.

To check that your DNS requests are being translated by your Linux box and not by the DNS server of the free/public wifi, you’ll want to type this command in your Linux SSH shell:

sudo tcpdump -i eth0 port 53

All DNS requests occur on port 53. This command will show on-screen any traffic that passes your Linux box on port 53. All you’ll need to do is enter that command, then keep an eye on it while you browse to any webpage (like www.cnn.com), you should immediately see traffic showing DNS translation requests for cnn.com as well as any ads loading from various ad providers.

If you see no traffic on your command prompt after browsing to a web page, your DNS translations are being handled by the free/public wifi and you may be in danger as your website requests may be redirected.

I should add that this method also works very well if you’re stuck behind a firewall that has some sort of access restriction. Even if you’re on a wired connection, you can use the above method to bypass nearly any restriction.

For example, if you’re in a wired or wireless network where you’re trying to access GMail and GMail is blocked for some reason, you can use the above method to securely access the GMail website, tunneling through your encrypted SSH session. The local content filter will not detect your attempt to reach GMail because the web request as well as all DNS requests are transmitted in the encrypted SSH tunnel. All they will see is the encrypted (inaccessible) traffic to your home public IP.

In some cases, your local Internet provider may restrict SSH from a protocol level (regardless of port number) — this is very rare though. Should that be the case, you will not be able to use this method at all to securely tunnel to your home Internet connection.

In other cases, hotels or other entities may require you to sign a EULA agreement before allowing any traffic AT ALL out to the Internet. This means you need to fire up your browser and try to access the internet (without any tunneled encryption or security measures) and their DNS servers will automatically redirect your browser to a custom hotel web page to sign off on the EULA. Once you do, they record your MAC address and then add it to their access control list to allow general access the Internet for the 24 or 48 hours, or whatever period you’ve purchased.

The problem here, is that once you’ve fired up your browser without securing the connection, a man-in-the-middle attack can already take place and grab a hold of your browser and execute some nasty lines of javascript code or other code without your knowledge. In this scenario, you can’t fire up your SSH tunnel without first opening your browser and exposing it to this security risk. One might think they’d be in a catch-22 here, but there’s a simple fix: Live-CD or Live-USB Linux boot!

In this instance, if you cannot make your SSH connection without first signing the hotel’s EULA, you would make sure to bring with you a Live-USB (or Live-CD) version of Linux (like Linux Mint or Fedora or any flavor you prefer). This is a read-only version of Linux that you can use on a public PC (like the crappy hotel PC in the “business lounge” if you want some privacy) or you can use it on your own travel laptop just for scenarios like this. You would boot up your Live-Linux USB and then access their WIFI, open your browser (without any proxy settings), browse to their default home EULA page, sign the EULA and then immediately log off and shut down.

At this point, your wireless MAC address is already cached in their access control list as an authorized device for Internet access. You can then follow the procedure at the top of this blog post to effectively and securely access the internet on a homemade encrypted tunnel.

For Android devices it can be done using a combination of ConnectBot and the FIREFOX mobile browser. I’m not aware of a way to do this with the CHROME browser in android. Though if the hotel or other entity forces that EULA page before Internet access is allowed, you may be out of secure options on a rigid Android device, since there’s no Live-Boot options for an Android device.

Another option is if you have a laptop with you as well as an android tablet or phone, you can configure your laptop to share your wifi connection and you can have your android device tunnel through your laptop’s already-established secure wifi to reach the Internet.

In ConnectBot you’ll want to create a Dynamic SOCKS proxy and choose a local port (like 7890) and configure your Linux Box public IP and port number (or the IP and port number of your laptop with its already-established secure wifi connection that you’ve shared in your hotel room or cafe). If you’re not sure how to use ConnectBot, you should research that separately.

In FIREFOX for Android, you’ll also browse to about:config just like in the full desktop version. Be sure to search for socks and and make sure your network.proxy.socks is set for 127.0.0.1, your network.proxy.socks_port is set for 7890 (or whatever port number you like) and your network.proxy.socks_remote_dns is true. Also make sure that your network.proxy.socks_version is set for 5.

In addition, you’ll want to search for proxy.type in the about:config settings page and look for network.proxy.type and make sure it’s set for the number 1. This tells FIREFOX to use your manual proxy settings which were all the settings configured in the previous paragraph. Without setting network.proxy.type to 1, it will ignore the settings in the prior paragraph.

The default should be 0, which means no proxy. Your FIREFOX browser for Android may have a different default for network.proxy.type. This link will show you the 5 different proxy settings types (note there is no value 3 in that listing).

Be sure to change this setting back to its default when you no longer wish to have FIREFOX use the SSH encrypted tunnel for web traffic.

SSH: On the fly port forwarding.

[Post Updated]

Once inside an SSH session, you may realize that you need to reach another box via the local port redirect (-L 1234:192.168.0.5:23 for example).

Most people think you need to kill your SSH session to add a new -L option, then reinitiate the SSH session; this is NOT true.

You can open an internal SSH shell within an SSH session to add new redirects!

From within an SSH session, simply type (the ~ is the tilde character, which is shift + the key to the left of the number 1)

~# then hit

~C then hit (capital C)

Then type: help and <enter>

You’ll see a listing of available commands. To add a new local redirect, just type

-L 4567:192.168.0.12:5900, then hit <enter>

…and voilà, you’ve added a new local redirect. Just hit <enter> once, and you’ll be dropped back into command line.

There are other escape-commands. Just type ~? from within an SSH session for more escape-commands.

Just press <enter> on a line by itself to return back to the SSH session.

FYI: This also works for remote redirects, as well.

Here’s a Google search link offering more info:

For those who need the USS Enterprise engine noise in the background

SoX is the “Sound Exchange”  –  the swiss army knife of audio manipulation in Linux. It offers a lot of functionality.

One of the cool/nerdy things you can do with SoX is generate tones or white noise.

To that end, if you’d like to hear the USS Enterprise’s warp engines running in the background while you go about your nerdy business, simply type this command at your shell prompt, assuming SoX is installed. This is better than finding a clip on the internet and looping it.

[Nerd Alert]
play -c2 -n synth whitenoise band -n 100 24 band -n 300 100 gain +20

There is an alternate (lower in volume) version you can try:

play -c2 -n synth whitenoise band -n 100 24 band -n 300 100 gain +4  synth whitenoise lowpass -1 100 lowpass -1 100  lowpass -1 100 gain +2

[/Nerd Alert]
To end it, simple hit ctrl-c. Play around with the gain and other numbers if you’d like to tweak it.

…make it so.

[source]

Something wicked happened resolving packages.medibuntu.org

Looks like the medibuntu folks have called it quits on their repository.

Anyone who still has medibuntu in their Linux repos should remove it. If they don’t, they’ll see error messages similar to this when they perform their periodic sudo apt-get update command:

Something wicked happened resolving 'packages.medibuntu.org:http' (-5 - No address associated with hostname)

or

http://packages.medibuntu.org precise Release: The following signatures were invalid: NODATA 1 NODATA 2

Some Google searches imply this is a DNS issue when in fact, medibuntu has gone offline.

The simple fix is to remove medibuntu from your repository. There’s a single command that can do this for you:

sudo sed -i '/^deb http:\/\/packages.medibuntu.org*/d' /etc/apt/sources.list /etc/apt/sources.list.d/*.list


Thanks to this forum thread for the details.

The poor man’s SSH server, complete with DNS redirects.

For years I’ve been using SSH (redirecting local ports to IPs within range of the SSH server) as a poor man’s version of a VPN. It’s more convenient for me and also, my VPN server manufacturer doesn’t have a proper VPN client for linux <smirk>. Of course when running Windows in a VM, I get to use my native VPN client, but when in Linux natively, I have to resort to SSH.

Windows users would use Putty to SSH to servers, whereas in Linux, I just use the ssh application native to Linux.

Normally, I have a pretty long ssh command with a lot of local redirects, at least 20 … but I’ve recently discovered a python-based SSH server, where the client automatically redirects all traffic (similar to a socks proxy) through the SSH server, including DNS requests.

I have not yet tested this application, though I plan to — however it seems robust enough that it might be able to replace my 3-line-long SSH command and also make my poor man VPN a bit more robust.

It’s worth trying and at the very least, when I get some time my blog post here will remind me to try it.

Links:

sshuttle

Here’s a HowTo document.

Public Key Encryption – a depthful explanation for beginners: Part 2

In my last post I briefly discussed and posted videos discussing the basic concepts of public key encryption. In this post I shall go over the basic process of creating a public/private key pair for yourself as well as basic usage for exporting, importing keys and sending files and/or messages.

First of all, I located what seems to be a well done how-to document on Tutonics. They seem to do a pretty good job. So if my explanation seems confusing at all, take a look at their how-to.

From the Linux command prompt, type:

gpg --gen-key

You will see the following output:

 Read the rest of this entry »

Public Key Encryption – a depthful explanation for beginners: Part 1

I’ve been asked by various people recently about encryption for secure communications. This is a very complex topic involving very advanced principles. Implementing a method to communicate securely over a digital connection (such as e-mail or live chat) can be very difficult for the average user.

Over a series of blog posts, I shall attempt to give a basic introduction (offering a variety of links and videos) to public key cryptography and ways to implement it to achieve relatively secure communications.

Most people tend to do better with videos than with big blocks of text, so I’ll offer here a few videos that help explain the concepts involved. Some of them are old – one specifically is a 5 year old video, which is still current in its technical details because advances in cryptography come slowly, but all of these videos go a long way in explaining the specific concepts involved and the basic commands involved in using Public Key Encryption.

You may find yourself watching some of these videos a few times to fully understand the concepts involved. But once understood, the actual mechanics of generating the keys and encrypting the messages in Linux (or Windows) is relatively simple, though unfortunately not quick or convenient. This is why many people don’t bother to use public key encryption as it’s a bit cumbersome to use, but it’s still the best method to secure communications through the Internet.

Read the rest of this entry »

Godmother of Unix admins Evi Nemeth presumed lost at sea

Evi Nemeth (73 years old) literally wrote the book on Unix. From The Register:

The New Zealand authorities have formally called off the search for the sailing cruiser Nina, and say its seven-person crew, which includes Evi Nemeth who for the last 30 years has written the system administration handbooks for Unix and Linux, is now presumed lost at sea.

[…] Nemeth was born in 1940 and earned her PhD in mathematics in 1971 before entering computer science in 1980. Her math skills were proven when she found problems with the “Diffie–Hellman problem” used for cryptography, but for systems administrators she is best known for her seminal handbooks on network management.

In 1989 she wrote the 1989 Unix System Administration Handbook, which she revised in 1995 and 2000. She also published the Linux Administration Handbook in 2002 (revised in 2006) and in 2010 authored the combined Unix and Linux System Administration Handbook.

All are best-sellers and explain the basics of network topology and administration simply and without recourse to hype. Nemeth saw the need to simplify the arcane language of the IT industry, a language that sometimes did more harm than good.

“Many people equate the word ‘daemon’ with the word ‘demon,’ implying some kind of Satanic connection between Unix and the underworld,” she wrote. “This is an egregious misunderstanding. ‘Daemon’ is actually a much older form of ‘demon’; daemons have no particular bias towards good or evil, but rather serve to help define a person’s character or personality.”

“The ancient Greeks’ concept of a ‘personal daemon’ was similar to the modern concept of a ‘guardian angel’ – ‘eudaemonia’ is the state of being helped or protected by a kindly spirit. As a rule, Unix systems seem to be infested with both daemons and demons.”

[…]Like any offshore sailor, Nemeth would have been aware of the risks and accepted them. If the Nina is lost with all hands, we can at least take comfort from the fact that Nemeth died doing something she loved.

The entire article can be read here.

Also, additional information about the ship and crew here.

Another article here with a photo of Evi Nemeth.

One more article with some more details about her life and another photo.

Alternative to SoundConverter: PACPL. The Perl Audio Converter.

I’ve had issues with SoundConverter on Linux. It wouldn’t always transcode my FLAC files to MP3 (or any other format for that matter). It would often just cut out … stopping the transcoding at random points in each FLAC file. It also was very light on features.

I was researching ways to manually transcode FLAC files into MP3 (for the purposes of listening to audio files on-the-go on my phone, while taking up less space) and thought about doing it via command line. After making sure FLAC and LAME were both installed on my machine, just running:

for f in *.flac; do flac -cd "$f" | lame -b 320 - "${f%.*}".mp3; done

This command will work straight from a shell prompt or as a script, so long as all the files you want to transcode are in ONE directory. If you want to do it recursively (as well as handle directories with spaces or multiple spaces) you need a more complex bash script.

My alternative solution was much better and more versatile. The Perl Audio Converter: PACPL.

This does more than SoundConverter and is more stable. Unlike SoundConverter, it supports normalization, which really helps for audio files that are a bit low on volume. Since in this audio batch I had about 12.5 gigs of FLAC files that I wanted to transcode into MP3, I just copied the entire directory, creating a duplicate. I then ran this command:

pacpl -t mp3 --bitrate 192 -r ./ --normalize --delete

This command will convert everything below the ./ current path and transcode every audio file (regardless of file type) into MP3 (-t mp3) at a bitrate of 192 (–bitrate 192). The -r will do this job recursively from the current directory. It will also normalize (–normalize) each file and then delete (–delete) the original source/input file.

When the script was done a few hours later, my duplicate directory was now an MP3 version of the original directory, at about 1/3rd the size.

There are plenty of options that make PACPL much more versatile than SoundConverter (though there’s no GUI to PACPL, it’s just run from command line).

You can apt-get it from most debian based repositories (sudo apt-get install pacpl) and then just to a man paclp for more information.

The project hasn’t been updated since 2009, but it appears to be quite versatile if you check out their website. It also supports CD Audio ripping with CDDB lookup. It can also work under Windows leveraging Cygwin.

From their site:

Perl Audio Converter is a tool for converting multiple audio types from one format to another. It supports AAC, AC3, AIFF, APE, AU, AVR, BONK, CAF, CDR, FAP, FLA, FLAC, IRCAM, LA, LPAC, M4A, MAT, MAT4, MAT5, MMF, MP2, MP3, MP4, MPC, MPP, NIST, OFR, OFS, OGG, PAC, PAF, PVF, RA, RAM, RAW, SD2, SF, SHN, SMP, SND, SPX, TTA, VOC, W64, WAV, WMA, and WV. It can also convert audio from the following video formats: RM, RV, ASF, DivX, MPG, MKV, MPEG, AVI, MOV, OGM, QT, VCD, SVCD, M4V, NSV, NUV, PSP, SMK, VOB, FLV, and WMV.

A CD ripping function with CDDB support, batch conversion, tag preservation for most supported formats, independent tag reading/writing, and extensions for Amarok, Dolphin, and Konqueror are also provided.

Richard Stallman Inducted into the 2013 Internet Hall of Fame

from FSF.org

The Internet Hall of Fame inducted Stallman for his contributions as creator of the GNU Project, main author of the GNU General Public License, and his philosophical contributions as founder of the free software movement.

Stallman has been named an Innovator, a category which recognizes and celebrates individuals who made outstanding technological, commercial, or policy advances and helped to expand the Internet’s reach.

Stallman had this to say upon his induction: “Now that we have made the Internet work, the next task is to stop it from being a platform for massive surveillance, and make it work in a way that respects human rights, including privacy.”

The Free Software Foundation congratulates Stallman and all of the other inductees, and thanks them for their contributions to the Internet.

A complete list of 2012 and 2013 Internet Hall of Fame inductees and their bios can be found at http://www.internethalloffame.org.

How to record your desktop with audio from a mic feed in Linux

Simple command, using FFMPEG:

ffmpeg -f x11grab -r 25 -s 1360x768 -i :0.0 -f alsa -ac 2 -sameq -i pulse -vol 500 ./output.mkv

Change your desktop resolution from 1360×768 to match your desktop. If needed, the option “-vol 500” amplifies the volume 5x. This may be needed on some mics that do not have any mic boost set (I had to use it on mine). You can increase this number to 1000 or 2000 (10x, 20x), etc.

The “-r 25” is the frame rate option. You can increase this to 30 or decrease it if you want to reduce the file size without compromising quality, but the video will miss a lot of moments in between captures: 25 should be the lowest setting.

You can run a “man ffmpeg” to research what each options does, but this will give a well-compressed video file with audio for a screen capture of your desktop.

TMate – instant terminal sharing

This reminds me of TeamViewer, but for the terminal shell.

TMate.

I haven’t yet had a need to share my terminal with anyone, but this is amusing and could be useful someday. Some of you may find it very helpful.

Convert Flash Videos (.flv) to MPEG with FFMPEG

If you download YouTube videos (using youtube-dl for example) you may want to convert them to mpeg for people who may have troubel viewing FLV files (perhaps Windows users who aren’t very technical).

The easy command is:

ffmpeg -i ./input.flv -sameq -ar 44100 ./output.mpg

The -sameq tells ffmpeg to maintain the same video quality as the original and -ar tells ffmpeg set an audio sampling frequency of CD quality (44100). This works in reverse, of course.

How to extend your SUDO timeout

This annoyed me for a while. The default timeout on SUDO in Linux is pretty short …. and I wanted it extended.

The easy way to do it is:

sudo visudo

Then, look for the line:

Defaults        env_reset

From here, simply add to the end of the line:

Defaults        env_reset,timestamp_timeout=2

Where the 2 is the number of minutes you want your SUDO credentials to last before you’ll be asked to re-enter the password. No need to add a space between the comma.

Pretty easy.

Older posts «

Fetch more items