Chrome et le javascript

Dsls — Wed, 03 Sep 2008 08:52:00 +0200

Test ACID2 ... ok

Test ACID3 ... 74/100

Tests Javascript : (tests réalisés avec SunSpider)

TEST	COMPARISON	Firefox 3.0.1	Chrome
TOTAL :	2.62x as fast	7513.4ms +/- 9.3%	2864.0ms +/- 7.6%
3d:	2.48x as fast	651.6ms +/- 26.6%	262.8ms +/- 103.0%
cube:	3.08x as fast	255.4ms +/- 40.2%	83.0ms +/- 126.7%
morph:	2.84x as fast	179.2ms +/- 24.6%	63.2ms +/- 10.4%
raytrace:	1.86x as fast	217.0ms +/- 22.6%	116.6ms +/- 140.8%
access:	6.02x as fast	879.6ms +/- 18.6%	146.2ms +/- 23.6%
binary-trees:	18.0x as fast	165.4ms +/- 25.3%	9.2ms +/- 24.2%
fannkuch:	7.79x as fast	383.4ms +/- 20.5%	49.2ms +/- 29.1%
nbody:	3.83x as fast	216.0ms +/- 19.6%	56.4ms +/- 28.4%
nsieve:	3.66x as fast	114.8ms +/- 31.5%	31.4ms +/- 41.3%
bitops:	5.54x as fast	524.0ms +/- 13.9%	94.6ms +/- 20.0%
3bit-bits-in-byte:	19.1x as fast	145.4ms +/- 21.8%	7.6ms +/- 37.7%
bits-in-byte:	8.45x as fast	143.6ms +/- 20.0%	17.0ms +/- 41.0%
bitwise-and:	4.70x as fast	90.2ms +/- 33.7%	19.2ms +/- 18.0%
nsieve-bits:	2.85x as fast	144.8ms +/- 14.8%	50.8ms +/- 29.3%
controlflow:	25.8x as fast	124.0ms +/- 17.1%	4.8ms +/- 33.8%
recursive:	25.8x as fast	124.0ms +/- 17.1%	4.8ms +/- 33.8%
crypto:	4.62x as fast	467.4ms +/- 19.8%	101.2ms +/- 22.4%
aes:	3.87x as fast	150.8ms +/- 35.1%	39.0ms +/- 38.3%
md5:	4.49x as fast	167.2ms +/- 35.5%	37.2ms +/- 28.3%
sha1:	5.98x as fast	149.4ms +/- 33.2%	25.0ms +/- 25.6%
date:	3.99x as fast	2367.2ms +/- 15.9%	592.8ms +/- 27.5%
format-tofte:	6.70x as fast	2109.2ms +/- 14.3%	314.8ms +/- 30.3%
format-xparb:	??	258.0ms +/- 30.8%	278.0ms +/- 40.5%
math:	3.44x as fast	652.2ms +/- 20.0%	189.6ms +/- 23.7%
cordic:	2.56x as fast	266.8ms +/- 25.9%	104.2ms +/- 33.7%
partial-sums:	3.22x as fast	200.0ms +/- 37.8%	62.2ms +/- 31.6%
spectral-norm:	7.99x as fast	185.4ms +/- 26.5%	23.2ms +/- 41.2%
regexp:	1.85x as slow	283.6ms +/- 22.2%	525.0ms +/- 19.1%
dna:	1.85x as slow	283.6ms +/- 22.2%	525.0ms +/- 19.1%
string:	1.65x as fast	1563.8ms +/- 14.2%	947.0ms +/- 22.1%
base64:	1.72x as fast	172.0ms +/- 34.9%	100.2ms +/- 39.1%
fasta:	5.17x as fast	406.0ms +/- 28.8%	78.6ms +/- 46.5%
tagcloud:	-	269.6ms +/- 10.3%	238.2ms +/- 31.3%
unpack-code:	1.45x as fast	500.6ms +/- 13.2%	344.4ms +/- 22.6%
validate-input:	-	215.6ms +/- 15.5%	185.6ms +/- 44.0%

Y'a pas à dire, c'est prometteur...reste à voir ce que donnera ce même test face à TraceMonkey

Apache2, fail2ban, bots et script kiddies

Dsls — Mon, 17 Mar 2008 08:52:00 +0100

Histoire de changer de sujet, un premier article technique sur la configuration d'apache2 et de fail2ban pour se prémunir de quelques attaques et autres scans de votre serveur web.

En regardant vos logs apache de plus près, vous verrez probablement des requêtes du genre :

195.5.132.17 - - [16/Mar/2008:04:56:50 +0100] "GET /index.php?page=http://www.maichantsite.com/echo.txt? HTTP/1.1" 403 211 "-" "libwww-perl/5.805"

C'est en général l'oeuvre de scripts scannant un site web, à la traque d"un éventuel exploit possible. Les pages mentionnées contiennent en général, un petit script vérifiant la configuration php pour les plus gentils (mic22, par exemple), jusqu'à des jolis bots se connectant à IRC par la suite, pour les moins polis ...

fail2ban est un outil permettant de déclencher des traitements donnés lorsque des lignes fichiers de log correspondent à des critères donnés. Il est typiquement utilisé pour bannir des adresses IP qui tentent de se connecter via SSH sur un serveur.

Attention ! Les solutions proposées ici ne permettent pas de se prémunir de toutes les attaques (loin de là ^[1]), mais éventuellement de limiter quelques dégats collatéraux. En effet, fail2ban analyse les fichiers a posteriori, ce qui signifie que ce qu'il voit s'est déjà passé sur la machine... on ne le dira jamais assez, soyez à l'écoute des mises à jour de vos applications php (et autres), et faites des updates réguliers.

Configuration de PHP

Comme indiqué dans la note précédente, la solution décrite dans cet article ne rendra pas votre serveur étanche à toutes les attaques, elle permettra juste d'empêcher les répétitions d'attaques depuis la même machine. Une sécurisation de PHP est souvent bénéfique, en cas de faille non encore trouvée, surtout si vos applications ne font pas usage de tout.

Il est en général de bon ton de mettre les lignes suivantes dans votre php.ini (dans /etc/php5/apache2/php.ini sur une debian/ubuntu avec php5) :

disable_functions = exec,passthru,popen,proc_open,shell_exec,system

Configuration d'Apache

Force est de constater qu'une grande partie des scripts sus-cités gardent leur user-agent. Même si c'est facilement modifiable par l'attaquant, et n'est en aucun cas un gage de sécurité, il est bon de mettre ce genre de ligne dans la configuration de son apache :

BrowserMatchNoCase "^.*libwww.*$" denyua

Puis dans un .htaccess à la base de son site :

Deny from env=denyua

Cela bannira purement et simplement tout user-agent contenant libwww (et notamment le fameux "libwww-perl/5.805")

Configuration de fail2ban

L'idée ici, est de bannir un utilisateur qui aura transmis une URL "saugrenue". Sera considérée comme URL "saugrenue" toute URL de type GET contenant "http://" dans la query string. A noter que fail2ban propose déjà un filtre apache-badbots.conf qui permet d'identifier des user-agent anormaux. Nous allons ajouter 2 fichiers de configuration spécifiques aux traitements que l'on souhaite faire :

/etc/fail2ban/filter.d/apache-baduri.conf : ce fichier va détecter les URLS bizarres. Il contient les lignes suivantes :

[Definition]
# Option:  failregex
# Values:  TEXT
#
failregex = ^<HOST> -.*"GET\[^"]*=http://\[^"]*".*$

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

/etc/fail2ban/action.d/apachedenyfrom.conf : ce fichier ajoute un "deny from ip" dans un .htaccess

[Definition]

# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#
actionstart =

# Option:  actionend
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
#
actionstop =

# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
actioncheck =

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
#
actionban = IP=<ip> &&
            echo "Deny from $IP" >> <file>

# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:      IP address
#            number of failures
#            unix timestamp of the ban time
# Values:  CMD
#
actionunban = IP=<ip> && sed -i.old /Deny\ from\ $IP/d 

[Init]

# Option:  file
# Notes.:  hosts.deny file path.
# Values:  STR  Default:  /etc/hosts.deny
#
file = /var/www/.htaccess

Il nous suffit juste alors de définir les règles qui vont vien dans /etc/fail2ban/jail.conf, en y ajoutant la section :

[apache-baduri]

enabled = true
port    = http, https
filter  = apache-baduri
logpath = /var/log/apache2/access.log
action = sendmail[name=APACHE_BADURI, dest=mail_destinataire, logpath=%(logpath)s]
        apachedenyfrom[file=emplacement_du_htaccess_a_generer]
maxretry = 1

(remplacer mail_destinataire, emplacement_du_htaccess_a_generer et /var/log/apache2/access.log par les valeurs adéquates

Notes