Archive
BeezNest fixes new Chamilo security flaws in 48h
Secunia gave the Chamilo Security team full details of three security flaws detected in version 1.9.4 on Monday the 4th of March 2013. These flaws were detected by Fernando Muñoz, a regular contact for Chamilo in terms of security. We are very grateful for his and Secunia’s work.
Within less than 48 hours, the Chamilo Security team, part of BeezNest‘s development team, has reviewed, patched, published and communicated a fix to its community through the Chamilo wiki and Chamilo Security team’s Twitter account, doing its best effort to inform everyone in time.
In fact, a patch was available within 12h, but it took us some time to go through the right communication channels and make the patch accessible to the greatest number.
Our fast turn around time on this security issue is a reflection of the priority and focus we place on security. Security is more than a side item for us, it’s part of our core principles.
At Chamilo, we embrace security research and show our appreciation to all involved. Thank you for helping us make Chamilo better!
BeezNest offers hosting, development and maintenance services for any Chamilo LMS portal. Feel free to contact us for a quote if you need help. Chamilo is free software and you are absolutely not forced to use our services. We can help you out if you need it, that’s all!
Nginx Anti-DOS filter for Fail2Ban
We are currently trying out this Fail2Ban rule on one of our server, to block simple (but very upsetting) DOS attacks on Nginx automatically (after 30 seconds).
New filter in /etc/fail2ban/nginx-dos.conf:
# Fail2Ban configuration file # # Generated on Fri Jun 08 12:09:15 EST 2012 by BeezNest # # Author: Yannick Warnier # # $Revision: 1 $ # [Definition] # Option: failregex # Notes.: Regexp to catch a generic call from an IP address. # Values: TEXT # failregex = ^<HOST> -.*"(GET|POST).*HTTP.*"$ # Option: ignoreregex # Notes.: regex to ignore. If this regex matches, the line is ignored. # Values: TEXT # ignoreregex =
In our jail.local, we have (at the end of the file):
[nginx-dos] # Based on apache-badbots but a simple IP check (any IP requesting more than # 240 pages in 60 seconds, or 4p/s average, is suspicious) # Block for two full days. # @author Yannick Warnier enabled = true port = http,8090 filter = nginx-dos logpath = /var/log/nginx/*-access.log findtime = 60 bantime = 172800 maxretry = 240
Of course, in case you would be logging all resources of your site (images, css, js, etc), it would be really easy to get to those numbers as a normal user. To avoid this, use the access_log off directive of Nginx, like so:
# Serve static files directly
location ~* \.(png|jpe?g|gif|ico)$ {
expires 1y;
access_log off;
try_files $uri $uri/ @rewrite;
gzip off;
}
location ~* \.(mp3)$ {
expires 1y;
access_log off;
gzip off;
}
location ~* \.(css)$ {
expires 1d;
access_log off;
}
location ~* \.(js)$ {
expires 1h;
access_log off;
}
We’ll see how that works for us… (and report here)
20 most common passwords
I wouldn’t want this post to disappear, so just to make sure that the information is better spread on what passwords *not to use*, here is the list:
1. 123456
2. 12345
3. 123456789
4. Password
5. iloveyou
6. princess
7. rockyou
8. 1234567
9. 12345678
10. abc123
11. Nicole
12. Daniel
13. babygirl
14. monkey
15. Jessica
16. Lovely
17. michael
18. Ashley
19. 654321
20. Qwerty
Come on, people, get some imagination! This would seriously make the web a better place…
Related post about web security (I’ll find a better place to put it soon): http://www.softwarequalityconnection.com/2011/12/how-to-check-your-web-app-for-security-vulnerabilities/
m0n0wall
m0n0wall (http://m0n0.ch) est un dérivé embarqué de FreeBSD spécialisé en pare-feu (firewall).
Le but premier du projet était de générer un firewall très réduit en taille (pour pouvoir facilement le faire tenir sur une mémoire Flash) et très
rapide (au boot notamment). Le constat de départ est que les UNIX libres utilisent trop d’interpréteurs différents (ex.: shell, Perl, Python, PHP, …) pour
leurs scripts de démarrage (initscripts) et leur gestion.
Ils ont alors décidé de n’en garder qu’un, et comme ils voulaient une interface web pour leur firewall, ils ont sélectionné PHP.
Grâce à ces deux choix, ils ont obtenu un système très économe en espace disque (de telle sorte qu’on peut le mettre sur un tout petit média
selon la norme actuelle) et RAM.
Ensuite, ils se sont dit[1] qu’un fichier XML serait approprié pour stocker toute la configuration.
Et le résultat est qu’un seul fichier (XML) sauvegardé permet de restaurer un firewall en quelques instants, que les erreurs dans ce fichier sont faciles à trouver/éviter, et qu’on peut facilement le faire tourner depuis un média en lecture seule (read-only, comme un CD par exemple).
Associé au firewall de FreeBSD (pf), c’est probablement un ensemble de très bons choix qui mènent sans surprise à l’une des solutions de ce
genre les plus abouties[2].
Security flaw in Dokeos – tablesort library
A hacker found a new security flaw affecting all versions of Dokeos. Please apply the patch referred to in the following link as soon as possible:
Why adding . to the PATH on UNIX is BAD ?
This article was first written in December 2003 for
the BeezNest technical website (http://glasnost.beeznest.org/articles/96)
Some UNIX administrators find it handy to add «.» in the PATH (and some even put it at the beginning of the PATH). Why is this bad? On UNIX, everything is made so that you don’t have to do it. Anything not doing so can be considered buggy, and can be fixed easily.
Imagine someone has access to write a file in a otherwise harmless directory, like /tmp for example. Image now that that someone wants to do harm. He saves his file (a shell script for example) as ls and makes it executable. Now, you cd to /tmp and type ls. What happens?
Such a script could look like this:
#!/bin/bash rm -f ~/*
Now what?
Imagine now what could be done if this is done as root and read carefully this also: Why using root on UNIX is bad ?.
If you insist on adding «.» to the PATH [1], please do so at the end of the PATH, this is yet far safer.
[1] probably to get a similar behaviour than on MS-DOS & Windows
Netfilter – iptables on Debian
To create and save iptables rules the default Debian way, this is the way to go:
- create your rules using the CLI [1] iptables
- save them on the active rule by issuing a /etc/init.d/iptables save active
- create the rules for the inactive state (when booting, for example) and save them accordingly
That way, the rules will survive a reboot.
To delete a specific rule previously saved as above:
- go into /var/lib/iptables/active and take the line corresponding to the rule you want to delete and execute iptables with those parameters changing the beginning -A with -D
[1] Command Line Interface
This article was first written in October 2003 for
the BeezNest technical website (http://glasnost.beeznest.org/articles/88)
IDS – Intrusion Detection Systems
An IDS is a system to track any changes not planned to a system. It is often used on sensitive machines where any unauthorized access is purely prohibited but can also act as a fool-proof system, more like a monitoring system.
It works by checksumming or understanding the format of each file, and scrutinizing any suspect change to files. It is off course meant to report any abnormal activity.
There are many, many such tools, with various capabilities, for UNIX systems.
LIDS is such a system for GNU/Linux which needs a kernel patch to work
Logcheck is a log analyser
Logsurfer same as above
fcheck which can be used to monitor changes to any given filesystem
The Analysis Console for Intrusion Databases (ACID) is a PHP-based analysis engine to search and process a database of security events generated by various IDSes, firewalls, and network monitoring tools
Prelude Hybrid IDS is an innovative Hybrid Intrusion Detection system designed to be very modular, distributed, rock solid and fast
MIDAS is a cross platform Monitoring and NIDS server. The goal of this project is to build a robust and complete network/system monitoring suite that is capable of scaling to very large networks.
Tripwire can be used to monitor changes to any given set of files or directories
chkrootkit identifies whether the target computer is infected with a rootkit
This article was first written in October 2003 for
the BeezNest technical website (http://glasnost.beeznest.org/articles/87)
Why using root on UNIX/Linux is bad ?
A lot of people use the root account to do anything they need, just because it is easier…
This is a really bad idea, as that user can do anything to the system. Not only can he access/delete/modify any file and its permissions, but he can mount/unmount filesystems, kill/start/stop processes, add hardware to the machine, stop the machine, create/delete semaphores/pipes, … and all that even wiping out any evidence of the modifications applied.
Annoyingly, there is no real practical way of disabling the root user on a Unix system.
All that can, of course, be done even without the actual user knowing or willing it (a virus or another harmful script/program executed by root could do anything it wants).
Many times, people use the root account to compile programs. The problem is that most of the time, they don’t even check the makefiles, which could be really harmful. They should instead compile everything with another user, and only change to root to do the final make install.
An even worst idea is to allow remote or graphical connections using it. If someone (or something, like a virus) directly logged remotely as root, there isn’t any way to know who it was in fact. Forcing the logging as another user instead, and changing to root afterwards at least ensures the bad guy has to crack at least two accounts (root and a user). Moreover, when you know that the user account has been compromised, you can disable it, not root.
The problem is often just that the user has already done a lot of things as root and it would represent a lot of work to revert the rights and permissions on files to a regular user and/or test if everything works as user. It is a never-ending loop. We highly recommend you do not try to go further in that direction. Take the time to fix all this, your system will become much safer.
It might seem easier not to manipulate the permissions to exactly match what you need, especially when several people need to read and modify them. But in the long run, this is clearly not a solution.
sudo might be a practical solution to the problem.
This article was first written in October 2003 for
the BeezNest technical website (http://glasnost.beeznest.org/articles/86)
NIDS – Network Intrusion Detection System
A NIDS is a Network Intrusion Detection System, a system to detect intrusions from the network and take counter-measures ranging from (temporarily) blacklisting to logging through responding with specially crafted IP packets to slow down or kill the attacking host.
It extends the principle of IDS to the network. It is usually meant to run on a firewall or a sensitive server.
Snort is one such NIDS.
This article was first written in October 2003 for
the BeezNest technical website (http://glasnost.beeznest.org/articles/65)
Support this documentation
Authors
Jérôme Warnier
