Internet in Ägypten gekappt


Das war natürlich eine sehr drastische Maßnahme gewesen. Im ganzen Land das Internet zu kappen war keine wirklich gute Idee. Trotzdem bewundere ich den Erfindungsreichtum der Hackergruppen vor Ort. In solchen Fällen packen sie die Modems aus und versuchen sich mit FIDO. Wem FIDO nichts sagt, es ist eine Kommunikationsmöglichkeit, die auf jeden Schnickschnack von HTML verzichtet. Es wird eine reine Textnachricht übermittelt. Neben der Möglichkeit einem anderen Nutzer eine Nachricht zu senden (vergleichbar mit der heutigen eMail), bot FIDO so genannte Bretter an. Diese Bretter waren nach verschiedenen Themen sortiert, und boten eine Diskussionsplattform.

Neben Fido gab es 1984 auch ein Zerberus Netz, das von padeluun initiiert wurde. Im Gegensatz zu FIDO war Zerberus ein klassisches Mailboxnetz. Man wählte sich per Modem auf einem nächststehenden Computer ein, der eine Mailboxsoftware am Start hat. Diese Software regelt im wesentlichen die Benutzer und deren Aktionen. Bei meinem letzten Mailboxaufenthalt waren 20 Minuten vorgegeben, in der man seine Nachrichten lesen und schreiben konnte. Danach gab es eine Zwangstrennung um auch anderen Benutzern die Möglichkeit zu geben, sich einzuwählen. Wie in FIDO gab es auch hier die Möglichkeit zur Diskussion, oder zum einfachen Nachrichten versenden.

Vielleicht lohnt es sich, die alten Modems nicht wegzuwerfen, falls unsere Regierung den „Internet-Aus-Schalter“ auch installiert. 😉

Advertisements

openSUSE Weekly News, Issue 125 is out (German Podcast)


Die Wöchentlichen News des openSUSE Projektes.

http://wiki.opensuse.org/Weekly_news#Translations

Feedback an: sascha.manns@radiotux.de

openSUSE Weekly News (German Podcast)

Kinderschändung und die Richtlinie 2006/24/EG


Heute gab es auf netzpolitik.org einen Interessanten Artikel zu lesen: http://www.netzpolitik.org/2010/smile29-eu-mit-der-kipo-keule-gegen-google/

New Package: socialvpn


On the Market we knowing Programs like hamachi, that allows to create an Virtual Private Network (VPN). Inside the Opensource Projects i now found an similar Program called: socialvpn. It is Packaged in the home:saigkill Repository.  After installing the RPM, you find the Program under /usr/share/socialvpn. I’ve added an Initscript in the Package under /etc/init.d/socialvpn, that you can enable or disable with YaST/System/Runlevels.

For using socialvpn you authenticate yourself and the others via a Jabber Account. So if you haven’t an Jabber Account, you have to create one.

Now you run: „/usr/share/socialvpn/setup.sh“. In the following you have to enter your Jabber Account and Passwort. Then a new Certificate is created.

After starting socialvpn via Mono, you can use Firefox (or your Browser) and type: „http://127.0.0.1:58888/“. Then you can access all needed Settings. Now you can add your Friends Jabber Account. Before you can do that you must exchange the SVPN (Fingerprint from the socialvpn). Then you can add the Jabber Account and the SVPN from your friend. And if your Friend do the same, you have a running VPN.

Enjoy …

Update 3 Aug 2010: Sadly the socialVPN Program runs not anymore. The connect doesn’t work. So i’ve deleted the Packages from home:saigkill.

Wie man einen Wikipediaartikel liest


Diese Frage habe ich mir schon sehr oft gestellt. Neben der kürzlichen „Relevanzdiskussion“ stellt sich einem Wikipedianutzer immer die Frage, ob die Inhalte wirklich wahr sind, und wie man es prüfen kann. Kris Köhntopp einer der Aktivisten um Wikipedia zu verbessern hat einen interessanten Blog Artikel geschrieben, der sich genau mit dieser Frage beschäftigt. Viel Spaß beim Lesen…
http://blog.koehntopp.de/archives/2695-Wie-man-einen-Wikipedia-Artikel…-liest.html

openSUSE Weekly News, Ausgabe 93 (Podcast)


Icon-suse_wn

Die Wöchentlichen News des openSUSE Projektes.

Diese Woche:

* openSUSE 11.2 auf dem Weg zur finalen Version – Release Kanidat!

* Pavol Rusnak: RPM Summit auf der openSUSE Conference 2009

* linuxgravity.com: Manipulieren, konvertieren und editieren von audio und video

* Cornelius Schumacher: 4,273,291 lines von code

* LinuxSecurity.com/Bill Keys: Security Features of Firefox 3.0

http://en.opensuse.org/OpenSUSE_Weekly_News/93/Translations

Feedback an: saigkill@opensuse.org

[openSUSE Weekly News (German Podcast)]

Setup: Secure Nagios Server


Today i’ve found an interesting Article about setting up Nagios. This Webbased Monitor can observed through an Website on an Apache Server. Earlier i thought, that setting up an Nagios Server is difficult. But i’ve seen, that it is easy. I think i try it out.

(Author: Bill Keys via http://www.linuxsecurity.com; Thanks)

Introduction

Nagios is a monitoring software designed to let you know about problems on your hosts and networks quickly. You can configure it to be used on any network. Setting up a Nagios server on any Linux distribution is a very quick process however to make it a secure setup it takes some work. This article will not show you how to install Nagios since there are tons of them out there but it will show you in detail ways to improve your Nagios security.

You may be wondering why should I need to think about securing my Nagios server? Well, think about the amount of information the attacker can get if they compromise it.

All the examples below assumes you are using Ubuntu. However these examples will help any user running a Nagios server to make it more secure since the concepts will still apply.

Web interface

If you installed Nagios with one of the quick start guides out there, chances are that you setup the web interface. Since Nagios uses Apache to display it there are many security options.

Below is an example of apache configuration for a Nagios web interface:

Options ExecCGI
AllowOverride None
Order allow,deny
Allow from all
AuthName „Nagios Access“
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
Require valid-user

The ‚Allow from‘ option is used to provide access to only a certain IP address and/or network. The above example allows any IP address to access the web interface. The other security options are used for authentication. ‚AuthType‘ defines the type of authentication being used. There are two types you can choose from Basic or Digest. Basic authentication will transmit your passwords and username as clear text. However using Digest the passwords are transmitted as MD5 digests which is more secure then in clear text.

After making some security improvement we get the below.

Options ExecCGI
AllowOverride None
Order allow,deny
Allow from 192.168.4.
AuthName „Nagios Access“
AuthType Digest
AuthDigestFile /usr/local/nagios/etc/htpasswd.users
Require valid-user

Now only computers on the 192.168.4.0 network can have access to the web interface. Also we are now using Digest authentication instead of the insecure method of Basic authentication.

Now we need to add users and passwords to allow accesses to the web interface. To add a new user using digest authentication use the below command:

# htdigest -c /usr/local/nagios/etc/htpasswd.users realm username

Digest is more secure then Basic authentication but the best way keep your username and passwords safe is to use SSL.

Make sure that you restart apache if you make any configuration changes.

# /etc/init.d/apache2 restart

Best Practices

This sections lists some of the best security practices when setting up an Nagios server.

  • Don’t Run Nagios As Root
  • There should be an normal user called nagios. If Nagios is running as root then if Nagios gets compromised then the attacker can do anything they want to your system.

  • Lock Down The Check Result Directory
  • Make sure that only nagios has read/write access to the check result directory otherwise an attacker can send fake host and service checks. This directory is normal at /usr/local/nagios/var/spool/checkresults

  • Use Full Paths In Command Definitions
  • When defining commands, make sure to specify the full path and not the relative one to any scripts or binaries you’re executing.

  • Secure Remote Agents
  • Some example are NRPE, NSClient, and SNMP. Below we will look at steps to secure the NRPE remote agent.

Secure Remote agents

This sections we will look at ways you can make NRPE more secure. This remote agent is used to execute programs on an remote host for doing checks like the load or disk usage. Since we don’t want any programs or users being able to execute commands on our remote machines it’s important to spend some time to make NRPE more secure.

Since NRPE come with support for TCP wrappers we can define which hosts have access to it.

Example /etc/hosts.allow

nrpe:192.168.1.91

This will allow only 192.168.1.91 to be able to use this remote agent on this host. You should replace this with the IP address of your Nagios client. Note this should be used on both your Nagios server and client.

NRPE should never run as root or any other superusers it should only be run as a nagios user in the group nagios. In /etc/nagios/nrpe.cfg you can check weather or not it’s running as nagios.

Example part of /etc/nagios/nrpe.cfg

nrpe_user=nagios
nrpe_group=nagios

Another part of NRPE that can be a security hole is allowing command arguments. We don’t want attacks to send malicious arguments that can compromise our system. Some times we need to allow Nagios to send command arguments but if you don’t need it to be enable which most times they are not needed then you should definitely disable them.

To disable them edit /etc/nagios/nrpe.cfg and make sure that you have the below line:

dont_blame_nrpe=0

Make user you restart nrpe to if you make any changes to nrpe.cfg. For more information on how to secure NRPE please read the file called SECURITY in the packages source file.

Secure Communication channels

Any time you communicate over a network you should be thinking about how can I make this more secure. This is where SSL is needed.

NRPE allows you to enable it to use SSL but your package must have configured it with the –enable-ssl option. If NRPE is configured to use SSL note, both the client and the server instance must have it enabled to work.

Next we should also configure SSL so that we don’t send our web interfaces passwords in clear text.

# openssl genrsa -des3 -out server.3des-key 1024
# openssl rsa -in server.3des-key -out server.key
# openssl req -new -key server.key -x509 -out server.crt -days 365
# chmod 600 server.key
# rm server.3des-key
# mv server.crt /etc/ssl/
# mv server.key /etc/ssl/private/

Now that we have generated our certificate we need to tell Apache to use them.

In your Apache configuration you will need to add the SSLRequireSSL options for example:

SSLRequireSSL
Options ExecCGI
AllowOverride None
Order allow,deny
Allow from 192.168.4.
AuthName „Nagios Access“
AuthType Digest
AuthDigestFile /usr/local/nagios/etc/htpasswd.users
Require valid-user

Remember to restart Apache.

# /etc/init.d/apache2 restart

Where to go from here?

Now you should feel confident that your Nagios server is more secure from attack. The next step is to just install security updates when they are released.

Resources