On Monday 16 December 2013 21:41:09 nb wrote:
> J'ai à peu près la même chose, avec les mêmes ip source.
>
> /var/log/apache2/error.log:[Sun Dec 15 13:05:38.268946 2013] [cgi:error]
> [pid 19838] [client 195.130.72.189:34087] malformed header from script
> 'php': Bad header: <b>Security Alert!</b> The PHP
ça doit être un script PHP <header .... > qui fait pas l'affaire ...
On Monday 16 December 2013 21:41:09 nb wrote:
> J'ai à peu près la même chose, avec les mêmes ip source.
>
> /var/log/apache2/error.log:[Sun Dec 15 13:05:38.268946 2013] [cgi:error]
> [pid 19838] [client 195.130.72.189:34087] malformed header from script
> 'php': Bad header: <b>Security Alert!</b> The PHP
ça doit être un script PHP <header .... > qui fait pas l'affaire ...
On Monday 16 December 2013 21:41:09 nb wrote:
> J'ai à peu près la même chose, avec les mêmes ip source.
>
> /var/log/apache2/error.log:[Sun Dec 15 13:05:38.268946 2013] [cgi:error]
> [pid 19838] [client 195.130.72.189:34087] malformed header from script
> 'php': Bad header: <b>Security Alert!</b> The PHP
ça doit être un script PHP <header .... > qui fait pas l'affaire ...
Le 16-12-2013, à 22:14:20 +0100, André Debian a écrit :
> On Monday 16 December 2013 21:41:09 nb wrote:
> > J'ai à peu près la même chose, avec les mêmes ip source.
> >
> > /var/log/apache2/error.log:[Sun Dec 15 13:05:38.268946 2013]
> > [cgi:error] [pid 19838] [client 195.130.72.189:34087] malformed header
> > from script 'php': Bad header: <b>Security Alert!</b> The PHP
>
> ça doit être un script PHP <header .... > qui fait pas l'affa ire ...
Et ça vient de partout :
/var/log/apache2# grep client error.log | grep Bad | awk '{print
$2,$3,$7,$8}' Dec 15 [client 46.182.111.182]
Dec 15 [client 46.182.111.182]
Dec 15 [client 200.217.64.150]
Dec 15 [client 200.217.64.150]
Dec 15 [client 46.28.107.211]
Dec 15 [client 46.28.107.211]
Dec 15 [client 195.246.16.33]
Dec 15 [client 195.246.16.33]
Dec 15 [client 199.181.113.126]
Dec 15 [client 199.181.113.126]
Dec 15 [client 107.20.169.255]
Dec 15 [client 107.20.169.255]
Dec 15 [client 31.210.106.39]
Dec 15 [client 89.136.120.205]
Dec 15 [client 89.136.120.205]
Dec 15 [client 31.210.106.39]
Dec 15 [client 112.125.125.113]
Dec 15 [client 112.125.125.113]
Dec 15 [client 212.86.21.238]
Dec 15 [client 212.86.21.238]
Dec 16 [client 31.210.106.39]
Dec 16 [client 54.235.249.209]
Dec 16 [client 54.235.249.209]
Dec 16 [client 195.62.168.113]
Dec 16 [client 195.62.168.113]
Dec 16 [client 201.216.248.178]
Dec 16 [client 201.216.248.179]
Dec 16 [client 107.20.180.238]
Dec 16 [client 107.20.180.238]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 31.210.106.39]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 65.77.64.30]
Dec 16 [client 65.77.64.30]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 182.48.191.174]
Dec 16 [client 182.48.191.174]
Dec 16 [client 82.100.48.6]
Dec 16 [client 82.100.48.6]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 75.101.183.156]
Dec 16 [client 75.101.183.156]
Dec 16 [client 192.151.144.234]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 46.10.158.43]
Dec 16 [client 46.10.158.43]
Dec 16 [client 192.151.144.234]
Dec 16 [client 31.210.106.39]
Dec 17 [client 192.151.144.234]
Dec 17 [client 64.251.23.220]
Dec 17 [client 64.251.23.220]
Dec 17 [client 50.56.234.109]
Dec 17 [client 50.56.234.109]
Dec 17 [client 87.252.248.44]
Dec 17 [client 87.252.248.44]
Dec 17 [client 195.145.53.226]
Dec 17 [client 195.145.53.226]
Dec 17 [client 77.247.215.168]
Dec 17 [client 77.247.215.168]
Dec 17 [client 187.53.208.44]
Dec 17 [client 187.53.208.44]
Dec 17 [client 203.202.248.130]
Dec 17 [client 203.202.248.130]
Dec 17 [client 50.17.216.179]
Dec 17 [client 50.17.216.179]
Dec 17 [client 103.5.5.27]
Dec 17 [client 103.5.5.27]
Dec 17 [client 62.63.52.41]
Dec 17 [client 62.63.52.41]
Dec 17 [client 58.210.133.244]
Dec 17 [client 58.210.133.244]
Dec 17 [client 112.199.87.92]
Dec 17 [client 112.199.87.92]
Dec 17 [client 50.19.80.107]
Dec 17 [client 50.19.80.107]
Dec 17 [client 89.136.120.205]
Dec 17 [client 31.210.106.39]
Dec 17 [client 72.167.113.216]
Dec 17 [client 72.167.113.216]
Dec 17 [client 92.63.96.106]
Dec 17 [client 92.63.96.106]
Dec 17 [client 203.172.161.8]
Dec 17 [client 203.172.161.8]
Dec 17 [client 31.210.106.39]
Dec 17 [client 89.136.120.205]
Le 16-12-2013, à 22:14:20 +0100, André Debian a écrit :
> On Monday 16 December 2013 21:41:09 nb wrote:
> > J'ai à peu près la même chose, avec les mêmes ip source.
> >
> > /var/log/apache2/error.log:[Sun Dec 15 13:05:38.268946 2013]
> > [cgi:error] [pid 19838] [client 195.130.72.189:34087] malformed header
> > from script 'php': Bad header: <b>Security Alert!</b> The PHP
>
> ça doit être un script PHP <header .... > qui fait pas l'affa ire ...
Et ça vient de partout :
/var/log/apache2# grep client error.log | grep Bad | awk '{print
$2,$3,$7,$8}' Dec 15 [client 46.182.111.182]
Dec 15 [client 46.182.111.182]
Dec 15 [client 200.217.64.150]
Dec 15 [client 200.217.64.150]
Dec 15 [client 46.28.107.211]
Dec 15 [client 46.28.107.211]
Dec 15 [client 195.246.16.33]
Dec 15 [client 195.246.16.33]
Dec 15 [client 199.181.113.126]
Dec 15 [client 199.181.113.126]
Dec 15 [client 107.20.169.255]
Dec 15 [client 107.20.169.255]
Dec 15 [client 31.210.106.39]
Dec 15 [client 89.136.120.205]
Dec 15 [client 89.136.120.205]
Dec 15 [client 31.210.106.39]
Dec 15 [client 112.125.125.113]
Dec 15 [client 112.125.125.113]
Dec 15 [client 212.86.21.238]
Dec 15 [client 212.86.21.238]
Dec 16 [client 31.210.106.39]
Dec 16 [client 54.235.249.209]
Dec 16 [client 54.235.249.209]
Dec 16 [client 195.62.168.113]
Dec 16 [client 195.62.168.113]
Dec 16 [client 201.216.248.178]
Dec 16 [client 201.216.248.179]
Dec 16 [client 107.20.180.238]
Dec 16 [client 107.20.180.238]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 31.210.106.39]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 65.77.64.30]
Dec 16 [client 65.77.64.30]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 182.48.191.174]
Dec 16 [client 182.48.191.174]
Dec 16 [client 82.100.48.6]
Dec 16 [client 82.100.48.6]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 75.101.183.156]
Dec 16 [client 75.101.183.156]
Dec 16 [client 192.151.144.234]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 46.10.158.43]
Dec 16 [client 46.10.158.43]
Dec 16 [client 192.151.144.234]
Dec 16 [client 31.210.106.39]
Dec 17 [client 192.151.144.234]
Dec 17 [client 64.251.23.220]
Dec 17 [client 64.251.23.220]
Dec 17 [client 50.56.234.109]
Dec 17 [client 50.56.234.109]
Dec 17 [client 87.252.248.44]
Dec 17 [client 87.252.248.44]
Dec 17 [client 195.145.53.226]
Dec 17 [client 195.145.53.226]
Dec 17 [client 77.247.215.168]
Dec 17 [client 77.247.215.168]
Dec 17 [client 187.53.208.44]
Dec 17 [client 187.53.208.44]
Dec 17 [client 203.202.248.130]
Dec 17 [client 203.202.248.130]
Dec 17 [client 50.17.216.179]
Dec 17 [client 50.17.216.179]
Dec 17 [client 103.5.5.27]
Dec 17 [client 103.5.5.27]
Dec 17 [client 62.63.52.41]
Dec 17 [client 62.63.52.41]
Dec 17 [client 58.210.133.244]
Dec 17 [client 58.210.133.244]
Dec 17 [client 112.199.87.92]
Dec 17 [client 112.199.87.92]
Dec 17 [client 50.19.80.107]
Dec 17 [client 50.19.80.107]
Dec 17 [client 89.136.120.205]
Dec 17 [client 31.210.106.39]
Dec 17 [client 72.167.113.216]
Dec 17 [client 72.167.113.216]
Dec 17 [client 92.63.96.106]
Dec 17 [client 92.63.96.106]
Dec 17 [client 203.172.161.8]
Dec 17 [client 203.172.161.8]
Dec 17 [client 31.210.106.39]
Dec 17 [client 89.136.120.205]
Le 16-12-2013, à 22:14:20 +0100, André Debian a écrit :
> On Monday 16 December 2013 21:41:09 nb wrote:
> > J'ai à peu près la même chose, avec les mêmes ip source.
> >
> > /var/log/apache2/error.log:[Sun Dec 15 13:05:38.268946 2013]
> > [cgi:error] [pid 19838] [client 195.130.72.189:34087] malformed header
> > from script 'php': Bad header: <b>Security Alert!</b> The PHP
>
> ça doit être un script PHP <header .... > qui fait pas l'affa ire ...
Et ça vient de partout :
/var/log/apache2# grep client error.log | grep Bad | awk '{print
$2,$3,$7,$8}' Dec 15 [client 46.182.111.182]
Dec 15 [client 46.182.111.182]
Dec 15 [client 200.217.64.150]
Dec 15 [client 200.217.64.150]
Dec 15 [client 46.28.107.211]
Dec 15 [client 46.28.107.211]
Dec 15 [client 195.246.16.33]
Dec 15 [client 195.246.16.33]
Dec 15 [client 199.181.113.126]
Dec 15 [client 199.181.113.126]
Dec 15 [client 107.20.169.255]
Dec 15 [client 107.20.169.255]
Dec 15 [client 31.210.106.39]
Dec 15 [client 89.136.120.205]
Dec 15 [client 89.136.120.205]
Dec 15 [client 31.210.106.39]
Dec 15 [client 112.125.125.113]
Dec 15 [client 112.125.125.113]
Dec 15 [client 212.86.21.238]
Dec 15 [client 212.86.21.238]
Dec 16 [client 31.210.106.39]
Dec 16 [client 54.235.249.209]
Dec 16 [client 54.235.249.209]
Dec 16 [client 195.62.168.113]
Dec 16 [client 195.62.168.113]
Dec 16 [client 201.216.248.178]
Dec 16 [client 201.216.248.179]
Dec 16 [client 107.20.180.238]
Dec 16 [client 107.20.180.238]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 31.210.106.39]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 65.77.64.30]
Dec 16 [client 65.77.64.30]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 182.48.191.174]
Dec 16 [client 182.48.191.174]
Dec 16 [client 82.100.48.6]
Dec 16 [client 82.100.48.6]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 75.101.183.156]
Dec 16 [client 75.101.183.156]
Dec 16 [client 192.151.144.234]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 46.10.158.43]
Dec 16 [client 46.10.158.43]
Dec 16 [client 192.151.144.234]
Dec 16 [client 31.210.106.39]
Dec 17 [client 192.151.144.234]
Dec 17 [client 64.251.23.220]
Dec 17 [client 64.251.23.220]
Dec 17 [client 50.56.234.109]
Dec 17 [client 50.56.234.109]
Dec 17 [client 87.252.248.44]
Dec 17 [client 87.252.248.44]
Dec 17 [client 195.145.53.226]
Dec 17 [client 195.145.53.226]
Dec 17 [client 77.247.215.168]
Dec 17 [client 77.247.215.168]
Dec 17 [client 187.53.208.44]
Dec 17 [client 187.53.208.44]
Dec 17 [client 203.202.248.130]
Dec 17 [client 203.202.248.130]
Dec 17 [client 50.17.216.179]
Dec 17 [client 50.17.216.179]
Dec 17 [client 103.5.5.27]
Dec 17 [client 103.5.5.27]
Dec 17 [client 62.63.52.41]
Dec 17 [client 62.63.52.41]
Dec 17 [client 58.210.133.244]
Dec 17 [client 58.210.133.244]
Dec 17 [client 112.199.87.92]
Dec 17 [client 112.199.87.92]
Dec 17 [client 50.19.80.107]
Dec 17 [client 50.19.80.107]
Dec 17 [client 89.136.120.205]
Dec 17 [client 31.210.106.39]
Dec 17 [client 72.167.113.216]
Dec 17 [client 72.167.113.216]
Dec 17 [client 92.63.96.106]
Dec 17 [client 92.63.96.106]
Dec 17 [client 203.172.161.8]
Dec 17 [client 203.172.161.8]
Dec 17 [client 31.210.106.39]
Dec 17 [client 89.136.120.205]
Voici un récent rapport de "logwatch" de mon serveur :
"A total of 19 sites probed the server
105.142.131.214
105.146.3.191
189.148.172.161
198.74.231.14
211.144.152.250
218.87.32.245
41.251.83.32
62.23.193.34
64.140.102.20
78.250.60.157
80.254.150.43
80.254.158.60
81.243.196.220
81.64.252.125
82.127.43.110
88.171.25.53
90.3.158.225
90.35.56.101
90.84.146.247"
Et ce message plus inquiétant :
" A total of 1 possible successful probes were detected (the
following URLs
contain strings that match one or more of a listing of strings that
indicate a possible exploit) : null HTTP Response 302"
André
On Tuesday 17 December 2013 21:48:00 steve wrote:Le 16-12-2013, à 22:14:20 +0100, André Debian a écrit :On Monday 16 December 2013 21:41:09 nb wrote:J'ai à peu près la même chose, avec les mêmes ip source.
/var/log/apache2/error.log:[Sun Dec 15 13:05:38.268946 2013]
[cgi:error] [pid 19838] [client 195.130.72.189:34087] malformed
header
from script 'php': Bad header: <b>Security Alert!</b> The PHP
ça doit être un script PHP <header .... > qui fait pas l'affaire ...
Et ça vient de partout :
/var/log/apache2# grep client error.log | grep Bad | awk '{print
$2,$3,$7,$8}' Dec 15 [client 46.182.111.182]
Dec 15 [client 46.182.111.182]
Dec 15 [client 200.217.64.150]
Dec 15 [client 200.217.64.150]
Dec 15 [client 46.28.107.211]
Dec 15 [client 46.28.107.211]
Dec 15 [client 195.246.16.33]
Dec 15 [client 195.246.16.33]
Dec 15 [client 199.181.113.126]
Dec 15 [client 199.181.113.126]
Dec 15 [client 107.20.169.255]
Dec 15 [client 107.20.169.255]
Dec 15 [client 31.210.106.39]
Dec 15 [client 89.136.120.205]
Dec 15 [client 89.136.120.205]
Dec 15 [client 31.210.106.39]
Dec 15 [client 112.125.125.113]
Dec 15 [client 112.125.125.113]
Dec 15 [client 212.86.21.238]
Dec 15 [client 212.86.21.238]
Dec 16 [client 31.210.106.39]
Dec 16 [client 54.235.249.209]
Dec 16 [client 54.235.249.209]
Dec 16 [client 195.62.168.113]
Dec 16 [client 195.62.168.113]
Dec 16 [client 201.216.248.178]
Dec 16 [client 201.216.248.179]
Dec 16 [client 107.20.180.238]
Dec 16 [client 107.20.180.238]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 31.210.106.39]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 65.77.64.30]
Dec 16 [client 65.77.64.30]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 182.48.191.174]
Dec 16 [client 182.48.191.174]
Dec 16 [client 82.100.48.6]
Dec 16 [client 82.100.48.6]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 75.101.183.156]
Dec 16 [client 75.101.183.156]
Dec 16 [client 192.151.144.234]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 46.10.158.43]
Dec 16 [client 46.10.158.43]
Dec 16 [client 192.151.144.234]
Dec 16 [client 31.210.106.39]
Dec 17 [client 192.151.144.234]
Dec 17 [client 64.251.23.220]
Dec 17 [client 64.251.23.220]
Dec 17 [client 50.56.234.109]
Dec 17 [client 50.56.234.109]
Dec 17 [client 87.252.248.44]
Dec 17 [client 87.252.248.44]
Dec 17 [client 195.145.53.226]
Dec 17 [client 195.145.53.226]
Dec 17 [client 77.247.215.168]
Dec 17 [client 77.247.215.168]
Dec 17 [client 187.53.208.44]
Dec 17 [client 187.53.208.44]
Dec 17 [client 203.202.248.130]
Dec 17 [client 203.202.248.130]
Dec 17 [client 50.17.216.179]
Dec 17 [client 50.17.216.179]
Dec 17 [client 103.5.5.27]
Dec 17 [client 103.5.5.27]
Dec 17 [client 62.63.52.41]
Dec 17 [client 62.63.52.41]
Dec 17 [client 58.210.133.244]
Dec 17 [client 58.210.133.244]
Dec 17 [client 112.199.87.92]
Dec 17 [client 112.199.87.92]
Dec 17 [client 50.19.80.107]
Dec 17 [client 50.19.80.107]
Dec 17 [client 89.136.120.205]
Dec 17 [client 31.210.106.39]
Dec 17 [client 72.167.113.216]
Dec 17 [client 72.167.113.216]
Dec 17 [client 92.63.96.106]
Dec 17 [client 92.63.96.106]
Dec 17 [client 203.172.161.8]
Dec 17 [client 203.172.161.8]
Dec 17 [client 31.210.106.39]
Dec 17 [client 89.136.120.205]
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Voici un récent rapport de "logwatch" de mon serveur :
"A total of 19 sites probed the server
105.142.131.214
105.146.3.191
189.148.172.161
198.74.231.14
211.144.152.250
218.87.32.245
41.251.83.32
62.23.193.34
64.140.102.20
78.250.60.157
80.254.150.43
80.254.158.60
81.243.196.220
81.64.252.125
82.127.43.110
88.171.25.53
90.3.158.225
90.35.56.101
90.84.146.247"
Et ce message plus inquiétant :
" A total of 1 possible successful probes were detected (the
following URLs
contain strings that match one or more of a listing of strings that
indicate a possible exploit) : null HTTP Response 302"
André
On Tuesday 17 December 2013 21:48:00 steve wrote:
Le 16-12-2013, à 22:14:20 +0100, André Debian a écrit :
On Monday 16 December 2013 21:41:09 nb wrote:
J'ai à peu près la même chose, avec les mêmes ip source.
/var/log/apache2/error.log:[Sun Dec 15 13:05:38.268946 2013]
[cgi:error] [pid 19838] [client 195.130.72.189:34087] malformed
header
from script 'php': Bad header: <b>Security Alert!</b> The PHP
ça doit être un script PHP <header .... > qui fait pas l'affaire ...
Et ça vient de partout :
/var/log/apache2# grep client error.log | grep Bad | awk '{print
$2,$3,$7,$8}' Dec 15 [client 46.182.111.182]
Dec 15 [client 46.182.111.182]
Dec 15 [client 200.217.64.150]
Dec 15 [client 200.217.64.150]
Dec 15 [client 46.28.107.211]
Dec 15 [client 46.28.107.211]
Dec 15 [client 195.246.16.33]
Dec 15 [client 195.246.16.33]
Dec 15 [client 199.181.113.126]
Dec 15 [client 199.181.113.126]
Dec 15 [client 107.20.169.255]
Dec 15 [client 107.20.169.255]
Dec 15 [client 31.210.106.39]
Dec 15 [client 89.136.120.205]
Dec 15 [client 89.136.120.205]
Dec 15 [client 31.210.106.39]
Dec 15 [client 112.125.125.113]
Dec 15 [client 112.125.125.113]
Dec 15 [client 212.86.21.238]
Dec 15 [client 212.86.21.238]
Dec 16 [client 31.210.106.39]
Dec 16 [client 54.235.249.209]
Dec 16 [client 54.235.249.209]
Dec 16 [client 195.62.168.113]
Dec 16 [client 195.62.168.113]
Dec 16 [client 201.216.248.178]
Dec 16 [client 201.216.248.179]
Dec 16 [client 107.20.180.238]
Dec 16 [client 107.20.180.238]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 31.210.106.39]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 65.77.64.30]
Dec 16 [client 65.77.64.30]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 182.48.191.174]
Dec 16 [client 182.48.191.174]
Dec 16 [client 82.100.48.6]
Dec 16 [client 82.100.48.6]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 75.101.183.156]
Dec 16 [client 75.101.183.156]
Dec 16 [client 192.151.144.234]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 46.10.158.43]
Dec 16 [client 46.10.158.43]
Dec 16 [client 192.151.144.234]
Dec 16 [client 31.210.106.39]
Dec 17 [client 192.151.144.234]
Dec 17 [client 64.251.23.220]
Dec 17 [client 64.251.23.220]
Dec 17 [client 50.56.234.109]
Dec 17 [client 50.56.234.109]
Dec 17 [client 87.252.248.44]
Dec 17 [client 87.252.248.44]
Dec 17 [client 195.145.53.226]
Dec 17 [client 195.145.53.226]
Dec 17 [client 77.247.215.168]
Dec 17 [client 77.247.215.168]
Dec 17 [client 187.53.208.44]
Dec 17 [client 187.53.208.44]
Dec 17 [client 203.202.248.130]
Dec 17 [client 203.202.248.130]
Dec 17 [client 50.17.216.179]
Dec 17 [client 50.17.216.179]
Dec 17 [client 103.5.5.27]
Dec 17 [client 103.5.5.27]
Dec 17 [client 62.63.52.41]
Dec 17 [client 62.63.52.41]
Dec 17 [client 58.210.133.244]
Dec 17 [client 58.210.133.244]
Dec 17 [client 112.199.87.92]
Dec 17 [client 112.199.87.92]
Dec 17 [client 50.19.80.107]
Dec 17 [client 50.19.80.107]
Dec 17 [client 89.136.120.205]
Dec 17 [client 31.210.106.39]
Dec 17 [client 72.167.113.216]
Dec 17 [client 72.167.113.216]
Dec 17 [client 92.63.96.106]
Dec 17 [client 92.63.96.106]
Dec 17 [client 203.172.161.8]
Dec 17 [client 203.172.161.8]
Dec 17 [client 31.210.106.39]
Dec 17 [client 89.136.120.205]
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/
201312181024.50064.andre_debian@numericable.fr
Voici un récent rapport de "logwatch" de mon serveur :
"A total of 19 sites probed the server
105.142.131.214
105.146.3.191
189.148.172.161
198.74.231.14
211.144.152.250
218.87.32.245
41.251.83.32
62.23.193.34
64.140.102.20
78.250.60.157
80.254.150.43
80.254.158.60
81.243.196.220
81.64.252.125
82.127.43.110
88.171.25.53
90.3.158.225
90.35.56.101
90.84.146.247"
Et ce message plus inquiétant :
" A total of 1 possible successful probes were detected (the
following URLs
contain strings that match one or more of a listing of strings that
indicate a possible exploit) : null HTTP Response 302"
André
On Tuesday 17 December 2013 21:48:00 steve wrote:Le 16-12-2013, à 22:14:20 +0100, André Debian a écrit :On Monday 16 December 2013 21:41:09 nb wrote:J'ai à peu près la même chose, avec les mêmes ip source.
/var/log/apache2/error.log:[Sun Dec 15 13:05:38.268946 2013]
[cgi:error] [pid 19838] [client 195.130.72.189:34087] malformed
header
from script 'php': Bad header: <b>Security Alert!</b> The PHP
ça doit être un script PHP <header .... > qui fait pas l'affaire ...
Et ça vient de partout :
/var/log/apache2# grep client error.log | grep Bad | awk '{print
$2,$3,$7,$8}' Dec 15 [client 46.182.111.182]
Dec 15 [client 46.182.111.182]
Dec 15 [client 200.217.64.150]
Dec 15 [client 200.217.64.150]
Dec 15 [client 46.28.107.211]
Dec 15 [client 46.28.107.211]
Dec 15 [client 195.246.16.33]
Dec 15 [client 195.246.16.33]
Dec 15 [client 199.181.113.126]
Dec 15 [client 199.181.113.126]
Dec 15 [client 107.20.169.255]
Dec 15 [client 107.20.169.255]
Dec 15 [client 31.210.106.39]
Dec 15 [client 89.136.120.205]
Dec 15 [client 89.136.120.205]
Dec 15 [client 31.210.106.39]
Dec 15 [client 112.125.125.113]
Dec 15 [client 112.125.125.113]
Dec 15 [client 212.86.21.238]
Dec 15 [client 212.86.21.238]
Dec 16 [client 31.210.106.39]
Dec 16 [client 54.235.249.209]
Dec 16 [client 54.235.249.209]
Dec 16 [client 195.62.168.113]
Dec 16 [client 195.62.168.113]
Dec 16 [client 201.216.248.178]
Dec 16 [client 201.216.248.179]
Dec 16 [client 107.20.180.238]
Dec 16 [client 107.20.180.238]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 31.210.106.39]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 65.77.64.30]
Dec 16 [client 65.77.64.30]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 82.94.238.2]
Dec 16 [client 182.48.191.174]
Dec 16 [client 182.48.191.174]
Dec 16 [client 82.100.48.6]
Dec 16 [client 82.100.48.6]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 31.210.106.39]
Dec 16 [client 89.136.120.205]
Dec 16 [client 75.101.183.156]
Dec 16 [client 75.101.183.156]
Dec 16 [client 192.151.144.234]
Dec 16 [client 72.167.113.216]
Dec 16 [client 72.167.113.216]
Dec 16 [client 31.210.106.39]
Dec 16 [client 46.10.158.43]
Dec 16 [client 46.10.158.43]
Dec 16 [client 192.151.144.234]
Dec 16 [client 31.210.106.39]
Dec 17 [client 192.151.144.234]
Dec 17 [client 64.251.23.220]
Dec 17 [client 64.251.23.220]
Dec 17 [client 50.56.234.109]
Dec 17 [client 50.56.234.109]
Dec 17 [client 87.252.248.44]
Dec 17 [client 87.252.248.44]
Dec 17 [client 195.145.53.226]
Dec 17 [client 195.145.53.226]
Dec 17 [client 77.247.215.168]
Dec 17 [client 77.247.215.168]
Dec 17 [client 187.53.208.44]
Dec 17 [client 187.53.208.44]
Dec 17 [client 203.202.248.130]
Dec 17 [client 203.202.248.130]
Dec 17 [client 50.17.216.179]
Dec 17 [client 50.17.216.179]
Dec 17 [client 103.5.5.27]
Dec 17 [client 103.5.5.27]
Dec 17 [client 62.63.52.41]
Dec 17 [client 62.63.52.41]
Dec 17 [client 58.210.133.244]
Dec 17 [client 58.210.133.244]
Dec 17 [client 112.199.87.92]
Dec 17 [client 112.199.87.92]
Dec 17 [client 50.19.80.107]
Dec 17 [client 50.19.80.107]
Dec 17 [client 89.136.120.205]
Dec 17 [client 31.210.106.39]
Dec 17 [client 72.167.113.216]
Dec 17 [client 72.167.113.216]
Dec 17 [client 92.63.96.106]
Dec 17 [client 92.63.96.106]
Dec 17 [client 203.172.161.8]
Dec 17 [client 203.172.161.8]
Dec 17 [client 31.210.106.39]
Dec 17 [client 89.136.120.205]
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
On Tuesday 17 December 2013 12:42:48 Jean-Jacques Doti wrote:Il semble qu'une règle iptables dans ce genre bloque la plupart de
ces tentatives :
-A INPUT -p tcp -m tcp --dport 80 -m string --string "Host:
xxx.xxx.xxx.xxx" --algo bm --to 600 -j DROP
Peut-on utiliser la syntaxe de cette règle iptables telle quelle ?
On Tuesday 17 December 2013 12:42:48 Jean-Jacques Doti wrote:
Il semble qu'une règle iptables dans ce genre bloque la plupart de
ces tentatives :
-A INPUT -p tcp -m tcp --dport 80 -m string --string "Host:
xxx.xxx.xxx.xxx" --algo bm --to 600 -j DROP
Peut-on utiliser la syntaxe de cette règle iptables telle quelle ?
On Tuesday 17 December 2013 12:42:48 Jean-Jacques Doti wrote:Il semble qu'une règle iptables dans ce genre bloque la plupart de
ces tentatives :
-A INPUT -p tcp -m tcp --dport 80 -m string --string "Host:
xxx.xxx.xxx.xxx" --algo bm --to 600 -j DROP
Peut-on utiliser la syntaxe de cette règle iptables telle quelle ?
Le 17/12/2013 17:30, a écrit :
> On Tuesday 17 December 2013 12:42:48 Jean-Jacques Doti wrote:
>> Il semble qu'une règle iptables dans ce genre bloque la plupart de
>> ces tentatives :
>> -A INPUT -p tcp -m tcp --dport 80 -m string --string "Host:
>> xxx.xxx.xxx.xxx" --algo bm --to 600 -j DROP
> Peut-on utiliser la syntaxe de cette règle iptables telle quelle ?
Ben oui : tu ajoutes juste "iptables" devant ou tu la colles dans un
fichier mangé par iptables-restore et ça roule.
⦠à condition, bien entendu, de remplacer les xxx par ton ad resse IP
publique (pour les explications : ça rejette les connexions sur le p ort TCP 80
qui font des requêtes HTTP en utilisant l'adresse IP comme nom de si te
plutôt qu'un "vrai" nom)
Le 17/12/2013 17:30, andre_debian@numericable.fr a écrit :
> On Tuesday 17 December 2013 12:42:48 Jean-Jacques Doti wrote:
>> Il semble qu'une règle iptables dans ce genre bloque la plupart de
>> ces tentatives :
>> -A INPUT -p tcp -m tcp --dport 80 -m string --string "Host:
>> xxx.xxx.xxx.xxx" --algo bm --to 600 -j DROP
> Peut-on utiliser la syntaxe de cette règle iptables telle quelle ?
Ben oui : tu ajoutes juste "iptables" devant ou tu la colles dans un
fichier mangé par iptables-restore et ça roule.
⦠à condition, bien entendu, de remplacer les xxx par ton ad resse IP
publique (pour les explications : ça rejette les connexions sur le p ort TCP 80
qui font des requêtes HTTP en utilisant l'adresse IP comme nom de si te
plutôt qu'un "vrai" nom)
Le 17/12/2013 17:30, a écrit :
> On Tuesday 17 December 2013 12:42:48 Jean-Jacques Doti wrote:
>> Il semble qu'une règle iptables dans ce genre bloque la plupart de
>> ces tentatives :
>> -A INPUT -p tcp -m tcp --dport 80 -m string --string "Host:
>> xxx.xxx.xxx.xxx" --algo bm --to 600 -j DROP
> Peut-on utiliser la syntaxe de cette règle iptables telle quelle ?
Ben oui : tu ajoutes juste "iptables" devant ou tu la colles dans un
fichier mangé par iptables-restore et ça roule.
⦠à condition, bien entendu, de remplacer les xxx par ton ad resse IP
publique (pour les explications : ça rejette les connexions sur le p ort TCP 80
qui font des requêtes HTTP en utilisant l'adresse IP comme nom de si te
plutôt qu'un "vrai" nom)
On Wed, 18 Dec 2013 18:54:37 +0100 wrote:
> Comment savoir si iptables tournent en mémoire comme
> un processus ? "ps aux | grep iptables" ou "ps aux | grep
> filter" , ne donnent rien.
iptables n'est pas un process, il est directement rattaché au
réseau au niveau kernel.
On Wed, 18 Dec 2013 18:54:37 +0100 andre_debian@numericable.fr wrote:
> Comment savoir si iptables tournent en mémoire comme
> un processus ? "ps aux | grep iptables" ou "ps aux | grep
> filter" , ne donnent rien.
iptables n'est pas un process, il est directement rattaché au
réseau au niveau kernel.
On Wed, 18 Dec 2013 18:54:37 +0100 wrote:
> Comment savoir si iptables tournent en mémoire comme
> un processus ? "ps aux | grep iptables" ou "ps aux | grep
> filter" , ne donnent rien.
iptables n'est pas un process, il est directement rattaché au
réseau au niveau kernel.
Comment savoir si iptables tournent en mémoire comme
un processus ? "ps aux | grep iptables" ou "ps aux | grep
filter" , ne donnent rien.
Comment savoir si iptables tournent en mémoire comme
un processus ? "ps aux | grep iptables" ou "ps aux | grep
filter" , ne donnent rien.
Comment savoir si iptables tournent en mémoire comme
un processus ? "ps aux | grep iptables" ou "ps aux | grep
filter" , ne donnent rien.
On Wednesday 18 December 2013 19:01:27 Bzzz wrote:On Wed, 18 Dec 2013 18:54:37 +0100 wrote:Comment savoir si iptables tournent en mémoire comme
un processus ? "ps aux | grep iptables" ou "ps aux | grep
filter" , ne donnent rien.
iptables n'est pas un process, il est directement rattaché au
réseau au niveau kernel.
Donc, seule la commande :
# iptables -L
permet de vérifier ?
andré
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
On Wednesday 18 December 2013 19:01:27 Bzzz wrote:
On Wed, 18 Dec 2013 18:54:37 +0100 andre_debian@numericable.fr wrote:
Comment savoir si iptables tournent en mémoire comme
un processus ? "ps aux | grep iptables" ou "ps aux | grep
filter" , ne donnent rien.
iptables n'est pas un process, il est directement rattaché au
réseau au niveau kernel.
Donc, seule la commande :
# iptables -L
permet de vérifier ?
andré
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/
201312181907.38005.andre_debian@numericable.fr
On Wednesday 18 December 2013 19:01:27 Bzzz wrote:On Wed, 18 Dec 2013 18:54:37 +0100 wrote:Comment savoir si iptables tournent en mémoire comme
un processus ? "ps aux | grep iptables" ou "ps aux | grep
filter" , ne donnent rien.
iptables n'est pas un process, il est directement rattaché au
réseau au niveau kernel.
Donc, seule la commande :
# iptables -L
permet de vérifier ?
andré
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Quand on lance ./firewall, un message est affiché s'il y a des erreurs.
Comme vous ne semblez pas avoir ajouté de script pour bloquer les
règles, vous pouvez vous bloquer sur le port 22 volontairement, puis
vous débloquer en faisant repartir la machine (reboot).
"... vous pouvez vous bloquer sur le port 22 volontairement ..." :
Un script permet de restaurer les règles à chaque reboot :
+++++++++++++++++++++++++++++++++++++++++++++
#!/bin/sh
### BEGIN INIT INFO
# Provides: iptables flushing
# Required-Start: $local_fs $remote_fs $network $syslog
# Required-Stop: $local_fs $remote_fs $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
#X-Interactive: false
# Short-Description: Demarrage du script lors de la sequence de boot
# Description: mise a jour des regles iptables
### END INIT INFO
IPTABLES=/sbin/iptables
echo "flushing iptables rules...."
sleep 1
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
++++++++++++++++++++++++++++++++++++++++++++++
chmod +x iptables_flush.sh
./iptables_flush.sh
update-rc.d firewall defaults
Le 18 déc. 13 à 19:07, a écrit :
> On Wednesday 18 December 2013 19:01:27 Bzzz wrote:
>> On Wed, 18 Dec 2013 18:54:37 +0100 wrote:
>>> Comment savoir si iptables tournent en mémoire comme
>>> un processus ? "ps aux | grep iptables" ou "ps aux | grep
>>> filter" , ne donnent rien.
>>
>> iptables n'est pas un process, il est directement rattaché au
>> réseau au niveau kernel.
>
> Donc, seule la commande :
> # iptables -L
> permet de vérifier ?
>
> andré
>
> --
> Lisez la FAQ de la liste avant de poser une question :
> http://wiki.debian.org/fr/FrenchLists
>
> Pour vous DESABONNER, envoyez un message avec comme objet
> "unsubscribe"
> vers
> En cas de soucis, contactez EN ANGLAIS
> Archive: http://lists.debian.org/
>
Quand on lance ./firewall, un message est affiché s'il y a des erreurs.
Comme vous ne semblez pas avoir ajouté de script pour bloquer les
règles, vous pouvez vous bloquer sur le port 22 volontairement, puis
vous débloquer en faisant repartir la machine (reboot).
"... vous pouvez vous bloquer sur le port 22 volontairement ..." :
Un script permet de restaurer les règles à chaque reboot :
+++++++++++++++++++++++++++++++++++++++++++++
#!/bin/sh
### BEGIN INIT INFO
# Provides: iptables flushing
# Required-Start: $local_fs $remote_fs $network $syslog
# Required-Stop: $local_fs $remote_fs $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
#X-Interactive: false
# Short-Description: Demarrage du script lors de la sequence de boot
# Description: mise a jour des regles iptables
### END INIT INFO
IPTABLES=/sbin/iptables
echo "flushing iptables rules...."
sleep 1
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
++++++++++++++++++++++++++++++++++++++++++++++
chmod +x iptables_flush.sh
./iptables_flush.sh
update-rc.d firewall defaults
Le 18 déc. 13 à 19:07, andre_debian@numericable.fr a écrit :
> On Wednesday 18 December 2013 19:01:27 Bzzz wrote:
>> On Wed, 18 Dec 2013 18:54:37 +0100 andre_debian@numericable.fr wrote:
>>> Comment savoir si iptables tournent en mémoire comme
>>> un processus ? "ps aux | grep iptables" ou "ps aux | grep
>>> filter" , ne donnent rien.
>>
>> iptables n'est pas un process, il est directement rattaché au
>> réseau au niveau kernel.
>
> Donc, seule la commande :
> # iptables -L
> permet de vérifier ?
>
> andré
>
> --
> Lisez la FAQ de la liste avant de poser une question :
> http://wiki.debian.org/fr/FrenchLists
>
> Pour vous DESABONNER, envoyez un message avec comme objet
> "unsubscribe"
> vers debian-user-french-REQUEST@lists.debian.org
> En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
> Archive: http://lists.debian.org/
> 201312181907.38005.andre_debian@numericable.fr
Quand on lance ./firewall, un message est affiché s'il y a des erreurs.
Comme vous ne semblez pas avoir ajouté de script pour bloquer les
règles, vous pouvez vous bloquer sur le port 22 volontairement, puis
vous débloquer en faisant repartir la machine (reboot).
"... vous pouvez vous bloquer sur le port 22 volontairement ..." :
Un script permet de restaurer les règles à chaque reboot :
+++++++++++++++++++++++++++++++++++++++++++++
#!/bin/sh
### BEGIN INIT INFO
# Provides: iptables flushing
# Required-Start: $local_fs $remote_fs $network $syslog
# Required-Stop: $local_fs $remote_fs $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
#X-Interactive: false
# Short-Description: Demarrage du script lors de la sequence de boot
# Description: mise a jour des regles iptables
### END INIT INFO
IPTABLES=/sbin/iptables
echo "flushing iptables rules...."
sleep 1
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
++++++++++++++++++++++++++++++++++++++++++++++
chmod +x iptables_flush.sh
./iptables_flush.sh
update-rc.d firewall defaults
Le 18 déc. 13 à 19:07, a écrit :
> On Wednesday 18 December 2013 19:01:27 Bzzz wrote:
>> On Wed, 18 Dec 2013 18:54:37 +0100 wrote:
>>> Comment savoir si iptables tournent en mémoire comme
>>> un processus ? "ps aux | grep iptables" ou "ps aux | grep
>>> filter" , ne donnent rien.
>>
>> iptables n'est pas un process, il est directement rattaché au
>> réseau au niveau kernel.
>
> Donc, seule la commande :
> # iptables -L
> permet de vérifier ?
>
> andré
>
> --
> Lisez la FAQ de la liste avant de poser une question :
> http://wiki.debian.org/fr/FrenchLists
>
> Pour vous DESABONNER, envoyez un message avec comme objet
> "unsubscribe"
> vers
> En cas de soucis, contactez EN ANGLAIS
> Archive: http://lists.debian.org/
>
On Wednesday 18 December 2013 19:40:28 Philippe Gras wrote:Quand on lance ./firewall, un message est affiché s'il y a des
erreurs.
Comme vous ne semblez pas avoir ajouté de script pour bloquer les
règles, vous pouvez vous bloquer sur le port 22 volontairement, puis
vous débloquer en faisant repartir la machine (reboot).
J'ai rajouté une règle dans le fichier exécutable /etc/firewall et
relancer sous /etc #./firewall
(pas de messages d'erreur)
J'ai vérifié par # iptables -L
et la règle est bien rajoutée.
Je ne comprends pas :"... vous pouvez vous bloquer sur le port 22 volontairement ..." :
Comment fait-on et quelle est l'utilité.
Merci.
andréUn script permet de restaurer les règles à chaque reboot :
+++++++++++++++++++++++++++++++++++++++++++++
#!/bin/sh
### BEGIN INIT INFO
# Provides: iptables flushing
# Required-Start: $local_fs $remote_fs $network $syslog
# Required-Stop: $local_fs $remote_fs $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
#X-Interactive: false
# Short-Description: Demarrage du script lors de la sequence de boot
# Description: mise a jour des regles iptables
### END INIT INFO
IPTABLES=/sbin/iptables
echo "flushing iptables rules...."
sleep 1
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
++++++++++++++++++++++++++++++++++++++++++++++
chmod +x iptables_flush.sh
./iptables_flush.sh
update-rc.d firewall defaults
Le 18 déc. 13 à 19:07, a écrit :On Wednesday 18 December 2013 19:01:27 Bzzz wrote:On Wed, 18 Dec 2013 18:54:37 +0100
wrote:Comment savoir si iptables tournent en mémoire comme
un processus ? "ps aux | grep iptables" ou "ps aux | grep
filter" , ne donnent rien.
iptables n'est pas un process, il est directement rattaché au
réseau au niveau kernel.
Donc, seule la commande :
# iptables -L
permet de vérifier ?
andré
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
On Wednesday 18 December 2013 19:40:28 Philippe Gras wrote:
Quand on lance ./firewall, un message est affiché s'il y a des
erreurs.
Comme vous ne semblez pas avoir ajouté de script pour bloquer les
règles, vous pouvez vous bloquer sur le port 22 volontairement, puis
vous débloquer en faisant repartir la machine (reboot).
J'ai rajouté une règle dans le fichier exécutable /etc/firewall et
relancer sous /etc #./firewall
(pas de messages d'erreur)
J'ai vérifié par # iptables -L
et la règle est bien rajoutée.
Je ne comprends pas :
"... vous pouvez vous bloquer sur le port 22 volontairement ..." :
Comment fait-on et quelle est l'utilité.
Merci.
andré
Un script permet de restaurer les règles à chaque reboot :
+++++++++++++++++++++++++++++++++++++++++++++
#!/bin/sh
### BEGIN INIT INFO
# Provides: iptables flushing
# Required-Start: $local_fs $remote_fs $network $syslog
# Required-Stop: $local_fs $remote_fs $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
#X-Interactive: false
# Short-Description: Demarrage du script lors de la sequence de boot
# Description: mise a jour des regles iptables
### END INIT INFO
IPTABLES=/sbin/iptables
echo "flushing iptables rules...."
sleep 1
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
++++++++++++++++++++++++++++++++++++++++++++++
chmod +x iptables_flush.sh
./iptables_flush.sh
update-rc.d firewall defaults
Le 18 déc. 13 à 19:07, andre_debian@numericable.fr a écrit :
On Wednesday 18 December 2013 19:01:27 Bzzz wrote:
On Wed, 18 Dec 2013 18:54:37 +0100 andre_debian@numericable.fr
wrote:
Comment savoir si iptables tournent en mémoire comme
un processus ? "ps aux | grep iptables" ou "ps aux | grep
filter" , ne donnent rien.
iptables n'est pas un process, il est directement rattaché au
réseau au niveau kernel.
Donc, seule la commande :
# iptables -L
permet de vérifier ?
andré
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/
201312181907.38005.andre_debian@numericable.fr
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/
201312182004.52299.andre_debian@numericable.fr
On Wednesday 18 December 2013 19:40:28 Philippe Gras wrote:Quand on lance ./firewall, un message est affiché s'il y a des
erreurs.
Comme vous ne semblez pas avoir ajouté de script pour bloquer les
règles, vous pouvez vous bloquer sur le port 22 volontairement, puis
vous débloquer en faisant repartir la machine (reboot).
J'ai rajouté une règle dans le fichier exécutable /etc/firewall et
relancer sous /etc #./firewall
(pas de messages d'erreur)
J'ai vérifié par # iptables -L
et la règle est bien rajoutée.
Je ne comprends pas :"... vous pouvez vous bloquer sur le port 22 volontairement ..." :
Comment fait-on et quelle est l'utilité.
Merci.
andréUn script permet de restaurer les règles à chaque reboot :
+++++++++++++++++++++++++++++++++++++++++++++
#!/bin/sh
### BEGIN INIT INFO
# Provides: iptables flushing
# Required-Start: $local_fs $remote_fs $network $syslog
# Required-Stop: $local_fs $remote_fs $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
#X-Interactive: false
# Short-Description: Demarrage du script lors de la sequence de boot
# Description: mise a jour des regles iptables
### END INIT INFO
IPTABLES=/sbin/iptables
echo "flushing iptables rules...."
sleep 1
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
++++++++++++++++++++++++++++++++++++++++++++++
chmod +x iptables_flush.sh
./iptables_flush.sh
update-rc.d firewall defaults
Le 18 déc. 13 à 19:07, a écrit :On Wednesday 18 December 2013 19:01:27 Bzzz wrote:On Wed, 18 Dec 2013 18:54:37 +0100
wrote:Comment savoir si iptables tournent en mémoire comme
un processus ? "ps aux | grep iptables" ou "ps aux | grep
filter" , ne donnent rien.
iptables n'est pas un process, il est directement rattaché au
réseau au niveau kernel.
Donc, seule la commande :
# iptables -L
permet de vérifier ?
andré
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/