One of the most promising tools of the last view years – the platform independent DAW Bitwig Studio has eventually been released yesterday. It is available for MacOS, Windows and Linux. Bitwig is a Berlin based company, originally founded by former Ableton developers. The relation to Ableton is something that put the expectations of Bitwig to a comparative high level in the field of DAWs.
We’re gonna check out Bitwig in depth during the next few days and let you know what we think. In the meantime: get yourself a demo run for free. Since the save and export feature is disabled in the normal demo version, we recommend to go for a trial license, which requires registration. Head over to https://www.bitwig.com/en/account/register.html and give the next generation of platform independent DAWs a serious go.
In our Linux Debian section the following articles have been published during the last weeks:
How to secure your Debian server by changing the SSH port number (read tutorial here)
How to secure your Debian server by setting up SSH for passwordless login via public- and private-key cryptography (read tutorial here)
How to secure your Debian server by updating the buggy openSSH Debian package (read tutorial here)
How to secure your Debian server by configuring a GUI based Firewall named Firestarter (read tutorial here)
How to simplify Debian administration by setting up a graphical interface (GNOME) to be used via VNC connection thru an SSH tunnel (read tutorial here)
I. Abstract
This time we’re gonna set up a LAMP (Linux – Apache – MySQL – PHP) webserver. Furthermore we will consider the basic security implications for such a server. Follow us into the amazing world of Debian server configurations. This article will take you about 60 minutes to follow straightforward (and well it took us a lot more than those 60 minutesto prepare, but nevermind, just click our sponsor to help us, when you found the tutorial helpful).
II. Requirements
Hic at nunc, we need to have an SSH connection (better is a running VNC connection (read tutorial here) to our Debian server, because dumbed down: to eventually access the webserver from all over the web, we will configure our firewall using the Firestarter GUI – read tutorial here)
III. Install and test Apache 2 and PHP 5
III. Part I. Installing Apache 2 and PHP 5
We assume you logged into your server as root. Enter that command:
server$ apt-get install apache2 php5 libapache2-mod-php5
(yes we can use the apt-get install command to install more than just one package, in this case we use it to install three packages consecutively)
III. Part II. Creating a PHP test file
Standard path of your www web folder will be /var/www . For checking if everything went well, we simply create a phpinfo script. Take your favourite editor like vi, vim, joe or nano. We use nano…
server$ nano /var/www/test.php
Fill that command into your editor:
<?php phpinfo(); ?>
And save and exit (in nano: ctrl+x).
III. Part III: Checking via VNC
When you followed all our other articles about configuring a server, you will have the Firestarter running as a frontend to the iptables firewall. At this point we highly recommend to still block and disallow any incoming connections on port 80, since we will install phpmyadmin and it would be available from all over the net. For Firestarter this means: the only port that has been opened by you explicitly still is the SSH port.
For testing our php environment it is much safer to perform an SSH tunneled VNC connection and start a browser on that server. Which points to http://127.0.0.1/test.php
When everything went well, you will see your server specific PHP configuration.
As this file simply tells to much server internals and since we really don’t need it anymore, we strongly recommend removing it now.
server$ rm /var/www/test.php
A file like that is easily forgotten and could become a serious security danger…
IV. Install MySQL, PHP5 connector and phpMyAdmin
IV. Part I. Installing MySQL
We still assume, you’re logged into your server as root. Enter the following command:
server$ apt-get install mysql-server mysql-client php5-mysql
(this time we again install three packages, we could have installed php and mysql even in one step, means we would have supplied an apt-get install with six commands)
IV. Part II. Configuring MySQL
All of us know about the bad guys being outside. We can make their lives a little more difficult by applying a default root password for MySQL. Do the following as root:
server$ mysql -u root
(login as user root)
mysql> USE mysql;
mysql> UPDATE user SET Password=PASSWORD('yournewpasswordgoeshere') WHERE user='root';
mysql> FLUSH PRIVILEGES;
mysql> quit;
V. Installing phpMyAdmin
You are logged into your server as root, aren’t you? Enter those commands:
server$ apt-get install phpmyadmin
V. Part I. Security precautions for phpMyAdmin I
During the installation of phpMyAdmin a symbolic link will be created to make phpMyAdmin available under that address: http://yourserver.net/phpmyadmin.
We feel this is not a good idea and not a very secure way here. Even if you already set the MySQL root password, it is no good idea to leave standard settings at that, since all the bad guys know this, aswell. So we have two options. First we just put an .htaccess file into that folder. That would work, but has the little disadvantage, that it would show the bad guys that the address http://yourserver.net/phpmyadmin really exists. Therefore we prefer option 2: we make phpMyAdmin available from localhost (means from within the server) only and move it to a new place and make it accessible on a specific port only (we use a non privileged port for that). We still can access our beloved phpMyAdmin simply via SHH tunneled http or SSH tunneled VNC directly on the server.
server$ unlink /var/www/phpmyadmin
(we remove the symbolic link, means pointing to http://yourserver.net/phpmyadmin won’t return any results anymore)
V. Part II. Security precautions for phpMyAdmin II
Since even we still cannot access phpMyAdmin, we need to change the Apache configuration a little bit. Take your favourite editor (we again use nano here) and do that:
server$ nano /etc/apache2/sites-available/default
Right in the beginning of that file change (old):
NameVirtualHost *
to (new):
NameVirtualHost *:80 NameVirtualHost *:8780
Then change (old):
<VirtualHost *>
to (new):
<VirtualHost *:80>
and after the closing </VirtualHost> tag, we insert this:
<VirtualHost *:8780> Alias /my-pma-is-not-accessible/ "/usr/share/phpmyadmin/"
<Directory "/usr/share/phpmyadmin/">
Options Indexes Multiviews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>
</VirtualHost>
As we can see, we specify 127.0.0.1 (localhost) as the only Allow from address and bind access to port 8780. So our phpMyAdmin will now be accessible from http://localhost:8780/my-pma-is-not-accessible (== port 8780) only. Since port 8780 is behind our firewall and is not accessible from outside, we are quite safe for the beginning.
V. Part III. Security precautions for phpMyAdmin III
As mentioned before we got two ways for accessing our beloved phpMyAdmin now. The first is simply using our VNC connection and start a browser on our server machine and let it point to http://localhost:8780/my-pma-is-not-accessible. The second way is simply forwarding the port 8780 to our local client browser via SSH tunnel.
Having bound the phpmyadmin access to the new port 8780 solves here another issue: forwarding of privileged ports would require root privileges on a client machine. Our somewhat unpurified trick to make Apache listening on a second non privileged port allows us forwarding to a client machine without a hitch.
Let’s edit /ect/apache2/ports.conf
server$ nano /ect/apache2/ports.conf
Let’s make it listen to that second port mentioned. Inside the ports.conf add this parameter
Listen 127.0.0.1:8780
By now you might guess what this configuration targets at. It creates a listen port for apache on our beloved port 8780 but only for network cards that have the IP address 127.0.0.1. Means in case our firewall would go down and port scanning would give results, there wouldn’t be any results from port 8780…
After that we simply restart our Apache via:
server$ /ect/init.d/apache2 restart
VI. Setting up SSH tunnel for http connection
Ok now we almost made it. For security precautions and for server performance reasons it makes sense to not use VNC connections all the time, although it works. But as it is more comfy to edit phpMyAdmin on your local client machine, we simply set up an SSH tunnel thru our server’s firewall and let it forward http from within the server to our local machine.
This can simply be done by entering this on your client’s terminal:
Congratulations, you’re almost done. You can now start a webbrowser of your choice and let it point to:
http://localhost:8780/my-pma-is-not-accessible
et voilà, you’re smack in your phpMyAdmin interface.
Killing your tunnel (and all other running SSH connections) can be done by simply entering on your client machine:
client$ killall ssh
VII. Conclusions
We hope you had some fun by conquering this learning curve. There are several points that we only touched on. We might consider applying other security features like faked error reports. We will deal with those faked error reports (means returning a 404 instead of 403) and comprehensive security techniques in forthcoming articles, because this would have lead us here astray.
If you found this article helpful: why not considering our sponsor’s offers? Thanks for re-enacting and now for something completely different: our sponsor …
All of us know, there are lots of bad guys out there just trying to brute force our ssh ports. The following article provides information about the first steps to be performed when setting up a new webserver running Debian Etch.
For security reasons we recommend applying these how to’s before proceeding
Mandatory: How to secure your Debian server by updating the buggy openSSH Debian package (read tutorial here)
Optional: How to secure your Debian server by changing the SSH port number (read tutorial here)
The following howto will show you how to enable SSH login without a server based password (passwordless login) and how to disable password login in general on your server.
II. Generate SSH public- private-key pair
Generate keypair on your Linux client machine (works on Cygwin and Mac OS X as well!) client$ mkdir ~/.ssh client$ chmod 700 ~/.ssh client$ cd .ssh client$ ssh-keygen -q -f id_rsa -t rsa
You will be asked to provide a passphrase to encrypt your private key. Although you might leave this empty, we strongly recommend to provide it – for you own safety
In the folder called .ssh you will then find those two files: id_rsa > contains private-key (encrypted with your passphrase) id_rsa.pub > contains public-key (to be put on your Etch Webserver)
III. Upload public-key to server
In detail: the output of id_rsa.pub (which in fact is a textfile) is pushed via ssh on your root’s homefolder and being saved there as id_rsa.remote: client$ cat id_rsa.pub | ssh root@yourdomain.net cat “>“ id_rsa.remote
IV. Activate public- private-key authentication
log in to your server client$ ssh root@yourdomain.net (provide your password)
you may install nano (if you like vim, stay with vim), imho nano is faster for simpler tasks, but vim is much more powerful, so having both is no loss ;-) server$ apt-get install nano
Edit SSH configuration to allow public-key login server$ nano /etc/ssh/sshd_config
Allow AuthorizedKeysFile only (still in sshd_config) AuthorizedKeysFile %h/.ssh/authorized_keys
Disallow Password driven login (still in sshd_config) # Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
Copy uploaded id_rsa.remote to .ssh folder server$ cp id_rsa.remote .ssh/authorized_keys
V. Test your configuration
Don’t log out of your server, instead open a second terminal on your client machine to test your new configuration: client2$ ssh root@yourdomain.net
(provide the passphrase for your private-key)
If everything works well, congratulations you’re done, consider clicking our sponsor (non offensive Google Adsense) to help maintaining this project free for all of you…
VI. Kindly Sponsored by
VII. Further steps
If you didn’t already do it. For further improving your server’s security you probably want to change ssh port address from 22 to anything else? Read here, how to do that…
“and first for something complete different”: Muzaq… coding or administrating system can’t do without gooood muzaq. Check our latest tunes here :-)
Are you also tired of those weird guys, script kiddies and wanna-be-hackers, who are trying to ssh your server on port 22? All those connection attempts cost your server time and in the end your money.
I. Abstract:
By just changing the standard ssh port of your server you can reduce the amount of unwanted login attempts quite effectivly. Simply because it would take too much time for these ugly guys to find out about your specific configuration. Although this is just a basic proactive measure, it is statistically proven that a significant amount of these kiddies do decide to move on to try to hack another server.
II. Requirements
The following lines are being applied to a Debian Etch based box. Other distros should work similar, but I am not experienced with them. Moreover there is no specific knowledge required.
III. Edit sshd_config
get your favourite editor by hand (no matter if this is vi, vim, nano, joe or any other thing), here nano is sufficient. Btw: nano comes preinstalled on Mac OS boxes. In case it is absent I am quite familiar with vim aswell, but imho nano is much faster for simpler tasks like the one we’re going to solve and vim is much more powerful for complex operations.
nano /etc/ssh/sshd_config
see the line, where that code is written: # What ports, IPs and protocols we listen for
Port 22
change this port to whatever port you like. May I suggest 8722 ?
IV. Recommendations for testing
If you are using a firewall (you should!!) don’t forget to open that port! Otherwise you won’t be able to login on that port ;-)
For testing purposes (like when you don’t have physical access to that server) I would really recommend to not edit the sshd_config by just changing that line:
# What ports, IPs and protocols we listen for
Port 22
I’d rather recommend to add a second port, like that: # What ports, IPs and protocols we listen for
Port 22
Port 8722
Your server will then listen on two ssh ports!
The advantage is: if anything (like) firewall doesn’t work you are not locked out of your box and won’t have to much hazzle with running a recovery console and so on.
V. Restart ssh deamon to apply changes
Ok let’s get our new (added or changed) ssh port running: /etc/init.d/ssh restart
VI. Login again
then open a new terminal and try to connect with the switch “-p” (port) ssh myuser@mydomain.com -p 8722
if the login attempt works on port 8722, you can remove “Port 22” from your sshd_config (restart ssh deamon then again)
otherwise login on port 22 as usual and fix your firewall settings
Don’t hesitate to leave a comment. In case that explanations where helpful do us the favor and visit our sponsor (Google). Thanks…
I. Abstract
Some of you may already have experienced the same phenomenon. We wanted to secure one of our servers and disallow any password login. We configured the passwordless login to use ssh and use public-, private-key mode (see here) instead. But after having saved the sshd_config file, we eventually couldn’t reconnect to our Debian server from our Cygwin console. Instead we received a buffer error. The following lines show what we did and a somewhat not 100% clean workaround.
II. What did we do?
we set up a Debian Etch server to use Public and Private Key authentication only (see here how to do it)
we edited the sshd_config server$ nano /etc/ssh/sshd_config
we set PasswordAuthentication No
we saved sshd_config and quit vim
we restarted out beloved ssh deamon server$ /etc/init.d/ssh restart
we then logged out and found that we cannot login by entering client$ ssh -o PreferredAuthentications=publickey root@somedomain.com
arghhhhh…
III. Workaround
we examined the errors: buffer_get_ret: trying to get more bytes 4 than in buffer 0
buffer_get_int: buffer error
After fumbling here and there we just removed the known_hosts file on the local client client$ rm ~/.ssh/known_hosts
we reauthorized the domain and guess what?
The error vanished
obviously the known_hosts was modified to have a line break somewhere in the middle of the public-key. I suspect openSSHp to have caused this incident
If the above solved your problem aswell, please help us maintaining this site by visiting our sponsors:
One of the most promising tools of the last view years – the platform independent DAW Bitwig Studio has eventually been released yesterday. It is available for MacOS, Windows and Linux. Bitwig is a Berlin based company, originally founded by former Ableton developers. The relation to Ableton is something that put the expectations of Bitwig to a comparative high level in the field of DAWs.
