Tag Archives: Security

DDOS protection

Did you ever wondered what cloudflare [1] is? It is basically an protection against Distributed Denial of Service attack [2], where your server is attacked via a massive flood of incoming traffic, trying to overload your server.

But there is an easy and cost saving way to protect your server – of course if you are running it on Linux. Simply check DDoS Deflate from github [3]. After installing, the script checks frequently your incoming traffic. Once an IP address generates a critial mass of incoming traffic attempts, the IP address is blocked.

Just consider that you might want to whitelist certain IP addresses or domains – for that check the manual.

Update 2017/12/12:

After installing DDoS Deflate [3] on jvr.at, the impact can be seen on the statistics of the website. No more peak pointing out a DoS attack since beginning of December.

 

 

[1] Cloudflare.com

[2] Wikipedia, Denial of Service Attack

[3] Github, DDoS Deflate

 

Howto set-up your own cloud with Seafile

Based on all the NSA sniffing and the recent article about who provides whom which information [1] I decided to set-up my own cloud on my private server. And actually – it was surprisingly easy! Searching around the internet seafile [2] seemed to be the most appropriate solution, since it is open-source, provides a nice web interface and actually has a client for all common operating system and devices.

So log in at the server – get root and download the server via wget:

root@jvr:~# wget https://bitbucket.org/haiwen/seafile/downloads/seafile-server_3.0.3_x86-64.tar.gz
--2014-05-18 16:26:06--  https://bitbucket.org/haiwen/seafile/downloads/seafile-server_3.0.3_x86-64.tar.gz
Resolving bitbucket.org... 131.103.20.168, 131.103.20.167
Connecting to bitbucket.org|131.103.20.168|:443... connected.
HTTP request sent, awaiting response... 302 FOUND
Location: http://cdn.bitbucket.org/haiwen/seafile/downloads/seafile-server_3.0.3_x86-64.tar.gz [following]
--2014-05-18 16:26:07--  http://cdn.bitbucket.org/haiwen/seafile/downloads/seafile-server_3.0.3_x86-64.tar.gz
Resolving cdn.bitbucket.org... 54.230.13.87, 54.230.13.88, 54.230.13.118, ...
Connecting to cdn.bitbucket.org|54.230.13.87|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 18399709 (18M) [application/x-tar]
Saving to: `seafile-server_3.0.3_x86-64.tar.gz'
100%[============================================================================================>] 18,399,709  51.0M/s   in 0.3s    
2014-05-18 16:26:07 (51.0 MB/s) - `seafile-server_3.0.3_x86-64.tar.gz' saved [18399709/18399709]
root@jvr:~#

Of course now we have to unzip the file:

root@jvr:~# tar xzf seafile-server_3.0.3_x86-64.tar.gz
root@jvr:~# cd seafile-server-3.0.3/

So just before we install, there are some packages which are required. For my system I needed to install the following additional packages:

root@jvr:~# apt-get install python python-setuptools python-simplejson python-imaging

If there is anything else missing, seafile will anyway note it during the installation, so no need to panic. So let’s get to the installation itself:

root@jvr:~/seafile-server-3.0.3# ./setup-seafile.sh

Follow the installation instructions – it should be quite straight forward. If you face any issue, the Seafile wiki [3] should be quite helpful. I installed the seafile server under /usr/share/ while I keep the data storage under /opt/seafile-data. If everything goes fine, the seafile server should be running with the following services under the listed ports:

port of ccnet server:         10001
port of seafile server:       12001
port of seafile httpserver:   8082
port of seahub:               8000

Please note that the sea hub service, which provides the web-end of the seafile server, needs to be started separately. 

root@jvr:/usr/share/seafile-server-3.0.3# ./seahub.sh

Ok, so far so good, everything should be up and running and you should be able to login via the web-interface on port 8000.

The next thing I’ve done was to create the links under /etc/init.d/ as follows and add both in the default run levels, so that the services fires up on a restart/start automatically:

root@jvr:/opt# cd /etc/init.d/
root@jvr:/etc/init.d# ln -s /usr/share/seafile-server-latest/seafile.sh .
root@jvr:/etc/init.d# ln -s /usr/share/seafile-server-latest/seahub.sh .
root@jvr:/etc/init.d# update-rc.d seafile.sh defaults
root@jvr:/etc/init.d# update-rc.d seahub.sh defaults

And now the tricky part. Since you might have noticed in my other blog entries [4],[5],[6] I am a bit security fanatic. Therefore I’d like to secure certain critical parts additionally. This time I’ll do this for the seafile web-service. So first I create an additional site within the apache configuration under /etc/apache2/sites-available/seafile with the following content:

<VirtualHost seafile.jvr.at:443>
       ServerName seafile.jvr.at 
       HostnameLookups Double                                             
       CustomLog /var/log/apache2/access.log combined env=!dontlog        
       SetEnvIf Request_URI "^/u" dontlog                                 
       ErrorLog /var/log/apache2/error.log                                
       Loglevel warn                                                      
       SSLEngine On                                                       
       SSLCertificateFile /etc/apache2/ssl/apache.pem                              
      <Proxy *>                                                          
          AuthUserFile /srv/seafile/.htpasswd                       
          AuthName EnterPassword                                     
          AuthType Basic                                              
          require user seafile_user                                        
          Order Deny,allow                                           
          Allow from all                                             
       </Proxy>                                                                   
       ProxyPass / http://localhost:8000/                                 
       ProxyPassReverse / http://localhost:8000/                         
</VirtualHost>

Now let’s create the htaccess file within the according directory:

root@jvr:~# mkdir /srv/seafile
root@jvr:~# cd /srv/seafile
root@jvr:/srv/seafile# htpasswd -cm /srv/seafile/.htpasswd seafile_user

Link the apache site to the sites-enabled and reload the apache service:

root@jvr:~# cd /etc/apache2/sites-enabled/
root@jvr:/etc/apache2/sites-enabled# ln -s ../sites-available/seafile .
root@jvr:/etc/apache2/sites-enabled# /etc/init.d/apache2 reload
* Reloading web server config apache2 [ OK ] 
root@jvr:/etc/apache2/sites-enabled#

And of course, disable the external access to the port 8000 on your firewall. Your web service should be now accessible with an extended htaccess security. Side note – since within certain companies certain ports are locked, it additionally enables you to access the service via https.

[1] Gizmodo.com, Which Tech Companies Protect Your Data From the Government?

[2] Seafile.com, Next-generation Open Source Cloud Storage

[3] github.com, Seafile: Deploy/Upgrade Seafile Server

[4] jvr.at, Basic Security for Linux Hosts 

[5] jvr.at, Book Review: The Cuckoo’s Egg

[6] jvr.at, Anonymous SSH over Tor and disconnect without a trace 

 

Basic security for Linux hosts

After reading Cuckoo’s egg from Clifford Stoll [1] I got a bit unsure if my Linux server is basically set-up secure enough. Even if the story about the hacker is quite old, it is neither the less highlighting the importance for security and to be careful enough when connecting a machine to the net.

Additionally having some history and experience in Security, I decided to have a closer look on my Linux server to double-ensure security.

1.) Passwords

First of all – and the issue of many problems – passwords. So let’s create a password which has no relation to the user, the content or the server itself. Passwords should have a certain length, numbers, lower and upper-case characters – and at least a special character. If your brain is unable to generate such a password, you can use the pwgen command under Linux.

root@lvps5-35-244-75:~# pwgen -y 12

Since we now have created a secure password, we should limit our remote access to certain users. In addition we should disable remote access for the privileged root account, since to whatever reason somebody might be able to log in as root, there would be no more limitations or boundaries to change, modify or destroy our system. Therefore simply edit the following line in the /etc/ssh/sshd_config:

PermitRootLogin no

Afterwards, do a simple restart of the sshd to reload the configuration.

/etc/init.d/sshd restart

In addition, since most of our system might have several accounts – you should question yourself if all of them require ssh access.

 2.) Automatic Security Updates

To enable automatic security related updates under Ubuntu you should install the unattended-upgrades package.

apt-get install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Further details in regards to the unattended upgrades and specifics can be found under [3]. Personal note: As for my installation, the unattended-upgrade was not doing the upgrades automatically, I simply added the command into my crontab to be fired up each day at 03:00.  To change your crontab use:

crontab -e

and add the following line

0 3 * * * /usr/bin/unattended-upgrade

In relation to this topic, also quite helpful I would see the apticron package, which should automatically inform you about package updates.

apt-get install apticron
vim /etc/apticron/apticron.conf

 

3.) Disable external root access

Also one of the basic security todos after a server set-up should be the disabling of the remote root ssh login. This can be easily done by changing the following parameter in /etc/ssh/sshd_config:

PermitRootLogin  no

Please note that a change onthe sshd requires a restart of the service, which can be done via:

/etc/init.d/sshd restart

4.) Take a look beyond the walls: Check for additional services

I see it as quite helpful to do an external scan of which services are available. This can be done quite easy and straightforward via nmap. So let’s install it and do a quick scan:

root@abc:~# apt-get install nmap
root@abc:~# nmap -f xyz.com
Starting Nmap 5.00 ( http://nmap.org ) at 2013-11-06 23:16 CET
 Interesting ports on jvr.at (5.35.244.75):
 Not shown: 985 closed ports
 PORT     STATE SERVICE
 21/tcp   open  ftp
 22/tcp   open  ssh
 25/tcp   open  smtp
 53/tcp   open  domain
 80/tcp   open  http
 106/tcp  open  pop3pw
 110/tcp  open  pop3
 143/tcp  open  imap
 443/tcp  open  https
 465/tcp  open  smtps
 587/tcp  open  submission
 993/tcp  open  imaps
 995/tcp  open  pop3s
 3306/tcp open  mysql
 8443/tcp open  https-alt

Of course there are a lot more of security related tipps & tricks, but I thought this might be a starting point. Another starting point, which I find quite useful is [2].

 

[1] Clifford Stoll, CUCKOO’S EGG

[2] Ravi Saive, 25 Hardening Security Tips for Linux

[3] Ubuntu Help, Automatic Security Updates

Book Review: The Cuckoo’s Egg

Clifford Stoll’s The Cockoo’s Egg [1] was written in 1989 and is based on a real-life hacker story.

The story itself starts with the introduction how Clifford, as an astronomer, who got captured by the mainframes of Lawrence Berkeley Lab as an administrator.

On of his first tasks was to figure out a glitch in the accounting system which resulted into a 75cent difference. At this point Clifford didn’t know where this would lead him. Taking the login-time as a basis for the accounting system, it turned out that there is a former user active, who basically has moved to England some time ago. Neither the less the user is active and seems to be logged into their system locally. His username is Sventek.

Beeing suspicious that it might be a hacker, Clifford starts to monitor Sventek’s activities and soon it turns out that he is right. Equipped with computers, teletypes and printers which he has borrowed from different departments, Cliff watches every keystroke hit by “Sventek”. He monitored the  Tymnet [2] connection, where the hacker usually connects. Tymnet was basically an international network connecting the major cities. The big advantage was that the university had only 5 Tymnet connections, therefore it required less resources to monitor – but still he need to “borrow” the equipment. Beeping twice as soon as somebody logs into the systems, Cliff was unable to have a good sleep under his desk, as some people check their mails at night as well. Neither the less, the hacker has logged on and left a trace on the typewriter. Based on this Cliff was able to find out how the hacker became superuser – via a cuckoo’s egg. Via a bug in the GNU-Emacs Editor [3], Sventek was able to replace the atrun job scheduler [4] with an own version. As soon as the new atrun fires up, it enabled to become the superuser rights – that’s the cuckoo’s egg. Having this concrete proofs, Cliff tried to approach the FBI, CIA, NSA, and other agencies, everybody was interested but nobody felt responsible nor saw the need to react.

Watching the hacker from day to day breaking into foreign systems, Cliff usually tries to contact the local system administrators to set certain actions like resetting the passwords and/or updating the system. Over the time he gets more and more frustrated and furthermore his boss makes pressure to close up the shop.

Back and forth, Cliff was able to trace the Hacker to the German Datex Network, but for a further trace a search warrant was required. Starting to get an international case, certainly the FBI and the CIA got more interested into it. Finally they managed to receive the search warrant. The only open problem was now to keep the hacker long enough on the line to complete the trace. In one of the discussions between Cliff and his girlfriend, the operation Showerhead was born to overcome this problem. The idea was simple: create files, which should interest the hacker. And how to do that? Take any kind of scientific or research documents and replace Mr. with General, Professors with Sergeant and Major and add some “spicy” words. Furthermore they created a project name called SDINET and made up some mail traffic in those regards. In one of their mails the also noted that if further information regards the access to SDINET was required they should contact the secretary via the postal way. Not having a thought that somebody would actually really apply, a letter was received and immediately confiscated by the FBI.

In addition the hacker started downloading all those made-up files, enabling Cliff to call Tymnet and start the trace. Finally the FBI received the number, but did not share it with Cliff. Never being told who’s the real hacker, he at least got the information that they searched his home, and recovered all his equipment. A few weeks later, the story was on the news. Hackers closely related to the CCC [5] has been involved, but finally arrested.

Cliff, finally returned to his job as an astronomer and got married.

The other side of the story was a part of a German movie called: “23 – Nichts ist so wie es schein” [6] which I can highly recommend to watch (for those who understand German).

[1] Clifford Stoll, The Cuckoo’s Egg

[2] Wikipedia, Tymnet

[3] GNU Emacs

[4] unix.com, atrun manpage

[5] Chaos Computer Club

[6] Wikipedia.de, 23 Nichts ist so wie es scheint