OVH Community, votre nouvel espace communautaire.

hack serveur, je ne comprends pas comment...


johnny57
16/09/2016, 15h45
D'autant plus que certains forcent les portes, alors autant leurs compliquer la vie.

cassiopee
16/09/2016, 13h47
Je t'en prie, si je peux rendre service

Clairement, sur Internet, il faut considérer que c'est la jungle et que si on laisse la moindre petite porte ouverte,
tôt ou tard, il y aura quelqu'un pour rentrer par là dans le serveur.

johnny57
16/09/2016, 13h26
c'est gentil de me rassurer cassiopee

cassiopee
16/09/2016, 11h41
"Vous aussi, si tout le monde vous en voulait, vous seriez paranoïaques" (Desproges)

johnny57
16/09/2016, 11h25
dovecot.conf est aussi actif.

autant pour moi, celui là prends bien en compte la ligne qui m'a effrayée ^^' Depuis le hack je suis un peu parano.

Nowwhat
16/09/2016, 11h07
T'as fait ce constat 'à vu' - ou tu utilise fail2ban-regex pour tester tes règles ?

Code:
root@ns311465:/etc/fail2ban/filter.d# fail2ban-regex  /var/log/courier/courier.log /etc/fail2ban/filter.d/courierlogin.conf /etc/fail2ban/filter.d/courierlogin.conf

Running tests
=============

Use ignoreregex file : /etc/fail2ban/filter.d/courierlogin.conf
Use   failregex file : /etc/fail2ban/filter.d/courierlogin.conf
Use         log file : /var/log/courier/courier.log


Results
=======

Failregex: 13 total
|-  #) [# of hits] regular expression
|   1) [13] ^\s*(<[^.]+\.[^.]+>)?\s*(?:\S+ )?(?:kernel: \[ *\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?(?:courier)?(?:imapd?|pop3d?)(?:login)?(?:-ssl)?(?:\(\S+\))?[\]\)]?:?|[\[\(]?(?:courier)?(?:imapd?|pop3d?)(?:login)?(?:-ssl)?(?:\(\S+\))?[\]\)]?:?(?:\[\d+\])?:?)?\s(?:\[ID \d+ \S+\])?\s*LOGIN FAILED, user=.*, ip=\[\]$
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [6040] MONTH Day Hour:Minute:Second
`-

Lines: 6040 lines, 0 ignored, 13 matched, 6027 missed
Missed line(s): too many to print.  Use --print-all-missed to print all 6027 lines
J'en ai donc 13 .....
Genre
Code:
Sep 16 02:45:35 ns311465 pop3d: LOGIN FAILED, user=staff@PAPY-TEAM.ORG, ip=[::ffff:80.82.64.239]
qui passe à la trappe pour une semaine ou deux.


Attention : /etc/fail2ban/filter.d/courierlogin.conf existe pour les logs de 'courier' - pas pour 'dovecot'. (ne mélange pas 'courier' avec 'mail' - 'courier' est le nom d'un service d'accès POP/IMAP, comme dovecot.
Pourquoi tu n'utilise pas "/etc/fail2ban/filter.d/dovecot.conf" - car t'as pas 'courier' mais "dovecot" (tes logs me le disent)

cassiopee
16/09/2016, 11h02
Lorsque l'on veut mettre au point une expression régulière pour un fichier de log donné,
il y a un outil très pratique pour cela "fail2ban-regex" :

Cf https://doc.ubuntu-fr.org/fail2ban Lire à partir de "3. Configuration avancée".

johnny57
16/09/2016, 10h54
mince. J'avais simplement suivis le tuto de bbr18, je corrigerai ça.

Autre point, sauf erreur de ma part, la config pour postfix ne peut pas fonctionner :

# Fail2Ban filter for courier authentication failures
#

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf

[Definition]

_daemon = (?:courier)?(?:imapd?|pop3d?)(?:login)?(?:-ssl)?

failregex = ^%(__prefix_line)sLOGIN FAILED, user=.*, ip=\[\]$

ignoreregex =

# Author: Christoph Haas
# Modified by: Cyril Jaquier
Puisque quand on regarde le mail.log :

Sep 16 09:21:00 ns335976 dovecot: pop3-login: Aborted login (auth failed, 1 attempts in 18 secs): user=, method=PLAIN, rip=72.27.202.48, lip=37.187.153.80, session=
Sep 16 09:21:03 ns335976 dovecot: pop3-login: Aborted login (auth failed, 1 attempts in 19 secs): user=, method=PLAIN, rip=72.27.202.48, lip=37.187.153.80, session=
Sep 16 09:21:05 ns335976 dovecot: pop3-login: Aborted login (auth failed, 1 attempts in 19 secs): user=, method=PLAIN, rip=72.27.202.48, lip=37.187.153.80, session=
Sep 16 09:21:06 ns335976 dovecot: pop3-login: Aborted login (auth failed, 1 attempts in 20 secs): user=, method=PLAIN, rip=72.27.202.48, lip=37.187.153.80, session=
on devrait plutôt remplacer login failed par aborted login ? Et adapter la suite jusqu'à user avec un passe partout comme .* non ?

Je ne suis pas un champion des regex mais ça pourrait donner ça, qu'en pensez vous ? :



failregex = ^%(__prefix_line)Aborted login (auth failed, .* attempts in .* secs): user=.*, ip=\[\]$
Le petit s devant login sur la regex actuelle doit être supprimé je suppose, on doit parler de sLOGIN c'est ça ?

Nowwhat
16/09/2016, 10h09
Citation Envoyé par johnny57
Question concernant le paramétrage de fail2ban, ici : https://www.how-to.ovh/viewtopic.php...3ee3592c43#p36

ces directives :

logpath = /var/log/apache*/*access_log
logpath = /var/log/virtualmin/*_access_log
sont à ajouter où dans le jail.conf ?
Nullepart !!

Ouvre jail.conf d'abord.
Il faut le lire.
Puis, je te file cette astuce :
Tu va trouver ceci (très important !) :

# To avoid merges during upgrades DO NOT MODIFY THIS FILE
# and rather provide your changes in /etc/fail2ban/jail.local
Donc : TES jails à toi, il faut le créer dans
/etc/fail2ban/jail.local

C'est là ou tu déclare (exemple) :
Code:
...
[ssh]
enabled = true
port	= ssh
filter	= sshd
action   = iptables[name=sshd, port=22, protocol=tcp]
#           sendmail[name=sshd, dest=monmail@mon-domaine.fr, sender=fail2ban@mon-domaine.fr]
logpath  = /var/log/auth.log
maxretry = 1
bantime  = 259200
...
Car ....
Un mise à jour de fail2ban va mettre à jour aussi le fichier /etc/fail2ban/jail.conf - tu risque de perdre tes modifs.
(ok, il va te donne un choix : garder ton fichier modifié - mettre la nouvelle en place - ou une combinaison)
La mise à jour ne va pas toucher le fichier 'à toi' : /etc/fail2ban/jail.local

johnny57
16/09/2016, 09h53
Question concernant le paramétrage de fail2ban, ici : https://www.how-to.ovh/viewtopic.php...3ee3592c43#p36

ces directives :

logpath = /var/log/apache*/*access_log
logpath = /var/log/virtualmin/*_access_log
sont à ajouter où dans le jail.conf ?

cassiopee
12/08/2016, 18h50
Hé oui, ça confirme ce que je disais précédemment sur la manipulation des dates des fichiers.

Le décalage à droite dans le code source est également un classique pour essayer
de planquer un code pirate.

En dehors de la comparaison avec une sauvegarde récente (qui reste le moyen le plus fiable),
un autre moyen de repérer les scripts modifiés est de rechercher via un grep récursif tout ou
partie du code pirate ajouté.

Très souvent le script pirate va modifier à l'identique des dizaines de scripts PHP du site web original.
(30 ou 40 scripts PHP modifiés est fréquent).

Bien entendu, il est possible que d'autres scripts PHP aient été modifiés avec d'autres instructions
pirates. Ces autres scripts ne seront alors pas repérés par le grep, sauf s'il y a des points communs
(type utilisation commune de "eval()", "base64_decode()", etc.)

johnny57
12/08/2016, 16h35
Je pense avoir trouvé comment le pirate pouvait recréer des fichiers. Des fichiers de prestashop avait été modifié sans que la date de dernière modif ne bouge d'une seule seconde pour inclure sur la première ligne mais avec plusieurs dizaines de tabulations de sorte à ce que le code même sur un écran 1920 pixels ne soit pas visible à l'écran sans scroler à droite. Je ne le comprends pas du tout, je ne saurai donc dire à quel point il est dangereux. J'ai téléchargé l'intégralité du site en local et winmerge compare le tout, attendons de voir ce que ça donne.

bbr18
11/08/2016, 17h07
tu en as quelque unes là, mais suffit de chercher un peu sur le web http://trac.evolix.net/infogerance/wiki/HowtoFail2Ban

bbr18
11/08/2016, 16h58
ce sont des jails parmi tant d'autres, tu actives celles qui te sont utiles
tout est possible, il suffit de créer tes règles, ou en trouver de toutes faites ou adapter à ton utilisation
tu peux remettre les règles que tu avais sur la R3, par contre adapte bien le chemin des logs
et côté firewall pour les ports que je suis la seule à utiliser, par exemple le 10000, je n'autorise que mes IP donc là pas besoin de fail12ban, etc.

johnny57
11/08/2016, 15h41
Quand je me suis fais hacker via ftp c'était parce que le précédent serveur avait été attaqué par la fameuse énorme faille shell de fin 2014. Ovh m'ayant à cette époque envoyé un mail me disant avoir bloqué une tentative de hack, je pensais que les donnée étaient sauve. Après changement de serveur, comme j'ai simplement tout déplacé, il a été possible de rentrer via ftp. Voilà pourquoi depuis cette date, je désactive proftpd puisque il n'y a que moi à me connecter et je le fais en sftp. A noter qu'il n'y a eu que celui là en ftp. Le précédent et premier de la liste c'était une faille linux et le dernier en date une faille d'un module prestashop.

Bon, pour le jail.conf, je pense partir là dessus. Il y a certains points qui ne sont pas évoqués dans le tuto de bbr18, des évolutions de fail2ban probablement.

# Fail2Ban configuration file.
#
# This file was composed for Debian systems from the original one
# provided now under /usr/share/doc/fail2ban/examples/jail.conf
# for additional examples.
#
# Comments: use '#' for comment lines and ';' for inline comments
#
# To avoid merges during upgrades DO NOT MODIFY THIS FILE
# and rather provide your changes in /etc/fail2ban/jail.local
#

# The DEFAULT allows a global definition of the options. They can be overridden
# in each jail afterwards.

[DEFAULT]

# "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not
# ban a host which matches an address in this list. Several addresses can be
# defined using space separator.
ignoreip = 127.0.0.1/8

# External command that will take an tagged arguments to ignore, e.g. ,
# and return true if the IP is to be ignored. False otherwise.
#
# ignorecommand = /path/to/command
ignorecommand =

# "bantime" is the number of seconds that a host is banned.
bantime = 1296369

# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime = 600
maxretry = 3

# "backend" specifies the backend used to get files modification.
# Available options are "pyinotify", "gamin", "polling" and "auto".
# This option can be overridden in each jail as well.
#
# pyinotify: requires pyinotify (a file alteration monitor) to be installed.
# If pyinotify is not installed, Fail2ban will use auto.
# gamin: requires Gamin (a file alteration monitor) to be installed.
# If Gamin is not installed, Fail2ban will use auto.
# polling: uses a polling algorithm which does not require external libraries.
# auto: will try to use the following backends, in order:
# pyinotify, gamin, polling.
backend = auto

# "usedns" specifies if jails should trust hostnames in logs,
# warn when reverse DNS lookups are performed, or ignore all hostnames in logs
#
# yes: if a hostname is encountered, a reverse DNS lookup will be performed.
# warn: if a hostname is encountered, a reverse DNS lookup will be performed,
# but it will be logged as a warning.
# no: if a hostname is encountered, will not be used for banning,
# but it will be logged as info.
usedns = warn

#
# Destination email address used solely for the interpolations in
# jail.{conf,local} configuration files.
destemail = root@localhost

#
# Name of the sender for mta actions
sendername = Fail2Ban

# Email address of the sender
sender = fail2ban@localhost

#
# ACTIONS
#

# Default banning action (e.g. iptables, iptables-new,
# iptables-multiport, shorewall, etc) It is used to define
# action_* variables. Can be overridden globally or per
# section within jail.local file
banaction = iptables-multiport

# email action. Since 0.8.1 upstream fail2ban uses sendmail
# MTA for the mailing. Change mta configuration parameter to mail
# if you want to revert to conventional 'mail'.
mta = sendmail

# Default protocol
protocol = tcp

# Specify chain where jumps would need to be added in iptables-* actions
chain = INPUT

#
# Action shortcuts. To be used to define action parameter

# The simplest action to take: ban only
action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]

# ban & send an e-mail with whois report to the destemail.
action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-whois[name=%(__name__)s, dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s", sendername="%(sendername)s"]

# ban & send an e-mail with whois report and relevant log lines
# to the destemail.
action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s, chain="%(chain)s", sendername="%(sendername)s"]

# Choose default action. To change, just override value of 'action' with the
# interpolation to the chosen action shortcut (e.g. action_mw, action_mwl, etc) in jail.local
# globally (section [DEFAULT]) or per specific section
action = %(action_)s

#
# JAILS
#

# Next jails corresponds to the standard configuration in Fail2ban 0.6 which
# was shipped in Debian. Enable any defined here jail by including
#
# [SECTION_NAME]
# enabled = true

#
# in /etc/fail2ban/jail.local.
#
# Optionally you may override any other parameter (e.g. banaction,
# action, port, logpath, etc) in that section within jail.local

[ssh]

enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6

[dropbear]

enabled = false
port = ssh
filter = dropbear
logpath = /var/log/auth.log
maxretry = 6

# Generic filter for pam. Has to be used with action which bans all ports
# such as iptables-allports, shorewall
[pam-generic]

enabled = false
# pam-generic filter can be customized to monitor specific subset of 'tty's
filter = pam-generic
# port actually must be irrelevant but lets leave it all for some possible uses
port = all
banaction = iptables-allports
port = anyport
logpath = /var/log/auth.log
maxretry = 6

[xinetd-fail]

enabled = true
filter = xinetd-fail
port = all
banaction = iptables-multiport-log
logpath = /var/log/daemon.log
maxretry = 2


[ssh-ddos]

enabled = true
port = ssh
filter = sshd-ddos
logpath = /var/log/auth.log
maxretry = 6


# Here we use blackhole routes for not requiring any additional kernel support
# to store large volumes of banned IPs

[ssh-route]

enabled = false
filter = sshd
action = route
logpath = /var/log/sshd.log
maxretry = 6

# Here we use a combination of Netfilter/Iptables and IPsets
# for storing large volumes of banned IPs
#
# IPset comes in two versions. See ipset -V for which one to use
# requires the ipset package and kernel support.
[ssh-iptables-ipset4]

enabled = false
port = ssh
filter = sshd
banaction = iptables-ipset-proto4
logpath = /var/log/sshd.log
maxretry = 6

[ssh-iptables-ipset6]

enabled = false
port = ssh
filter = sshd
banaction = iptables-ipset-proto6
logpath = /var/log/sshd.log
maxretry = 6


#
# HTTP servers
#

[apache]

enabled = false
port = http,https
filter = apache-auth
logpath = /var/log/apache*/*error.log
maxretry = 6

# default action is now multiport, so apache-multiport jail was left
# for compatibility with previous (<0.7.6-2) releases
[apache-multiport]

enabled = true
port = http,https
filter = apache-auth
logpath = /var/log/apache*/*error.log
maxretry = 6

[apache-noscript]

enabled = false
port = http,https
filter = apache-noscript
logpath = /var/log/apache*/*error.log
maxretry = 6

[apache-overflows]

enabled = false
port = http,https
filter = apache-overflows
logpath = /var/log/apache*/*error.log
maxretry = 2

[apache-modsecurity]

enabled = false
filter = apache-modsecurity
port = http,https
logpath = /var/log/apache*/*error.log
maxretry = 2

[apache-nohome]

enabled = false
filter = apache-nohome
port = http,https
logpath = /var/log/apache*/*error.log
maxretry = 2

# Ban attackers that try to use PHP's URL-fopen() functionality
# through GET/POST variables. - Experimental, with more than a year
# of usage in production environments.

[php-url-fopen]

enabled = false
port = http,https
filter = php-url-fopen
logpath = /var/www/*/logs/access_log

# A simple PHP-fastcgi jail which works with lighttpd.
# If you run a lighttpd server, then you probably will
# find these kinds of messages in your error_log:
# ALERT – tried to register forbidden variable ‘GLOBALS’
# through GET variables (attacker '1.2.3.4', file '/var/www/default/htdocs/index.php')

[lighttpd-fastcgi]

enabled = false
port = http,https
filter = lighttpd-fastcgi
logpath = /var/log/lighttpd/error.log

# Same as above for mod_auth
# It catches wrong authentifications

[lighttpd-auth]

enabled = false
port = http,https
filter = suhosin
logpath = /var/log/lighttpd/error.log

[nginx-http-auth]

enabled = false
filter = nginx-http-auth
port = http,https
logpath = /var/log/nginx/error.log

# Monitor roundcube server

[roundcube-auth]

enabled = true
filter = roundcube-auth
port = http,https
logpath = /var/log/roundcube/userlogins


[sogo-auth]

enabled = false
filter = sogo-auth
port = http, https
# without proxy this would be:
# port = 20000
logpath = /var/log/sogo/sogo.log


#
# FTP servers
#

[vsftpd]

enabled = false
port = ftp,ftp-data,ftps,ftps-data
filter = vsftpd
logpath = /var/log/vsftpd.log
# or overwrite it in jails.local to be
# logpath = /var/log/auth.log
# if you want to rely on PAM failed login attempts
# vsftpd's failregex should match both of those formats
maxretry = 6


[proftpd]

enabled = true
port = ftp,ftp-data,ftps,ftps-data
filter = proftpd
logpath = /var/log/proftpd/proftpd.log
maxretry = 6


[pure-ftpd]

enabled = false
port = ftp,ftp-data,ftps,ftps-data
filter = pure-ftpd
logpath = /var/log/syslog
maxretry = 6


[wuftpd]

enabled = false
port = ftp,ftp-data,ftps,ftps-data
filter = wuftpd
logpath = /var/log/syslog
maxretry = 6


#
# Mail servers
#

[postfix]

enabled = true
port = smtp,ssmtp,submission
filter = postfix
logpath = /var/log/mail.log


[couriersmtp]

enabled = true
port = smtp,ssmtp,submission
filter = couriersmtp
logpath = /var/log/mail.log


#
# Mail servers authenticators: might be used for smtp,ftp,imap servers, so
# all relevant ports get banned
#

[courierauth]

enabled = true
port = smtp,ssmtp,submission,imap2,imap3,imaps,pop3,pop3s
filter = courierlogin
logpath = /var/log/mail.log


[sasl]

enabled = true
port = smtp,ssmtp,submission,imap2,imap3,imaps,pop3,pop3s
filter = postfix-sasl
# You might consider monitoring /var/log/mail.warn instead if you are
# running postfix since it would provide the same log lines at the
# "warn" level but overall at the smaller filesize.
logpath = /var/log/mail.log

[dovecot]

enabled = true
port = smtp,ssmtp,submission,imap2,imap3,imaps,pop3,pop3s
filter = dovecot
logpath = /var/log/mail.log

# To log wrong MySQL access attempts add to /etc/my.cnf:
# log-error=/var/log/mysqld.log
# log-warning = 2
[mysqld-auth]

enabled = false
filter = mysqld-auth
port = 3306
logpath = /var/log/mysqld.log


# DNS Servers


# These jails block attacks against named (bind9). By default, logging is off
# with bind9 installation. You will need something like this:
#
# logging {
# channel security_file {
# file "/var/log/named/security.log" versions 3 size 30m;
# severity dynamic;
# print-time yes;
# };
# category security {
# security_file;
# };
# };
#
# in your named.conf to provide proper logging

# !!! WARNING !!!
# Since UDP is connection-less protocol, spoofing of IP and imitation
# of illegal actions is way too simple. Thus enabling of this filter
# might provide an easy way for implementing a DoS against a chosen
# victim. See
# http://nion.modprobe.de/blog/archive...-dns-fail.html
# Please DO NOT USE this jail unless you know what you are doing.
#[named-refused-udp]
#
#enabled = false
#port = domain,953
#protocol = udp
#filter = named-refused
#logpath = /var/log/named/security.log

[named-refused-tcp]

enabled = false
port = domain,953
protocol = tcp
filter = named-refused
logpath = /var/log/named/security.log

[freeswitch]

enabled = false
filter = freeswitch
logpath = /var/log/freeswitch.log
maxretry = 10
action = iptables-multiport[name=freeswitch-tcp, port="5060,5061,5080,5081", protocol=tcp]
iptables-multiport[name=freeswitch-udp, port="5060,5061,5080,5081", protocol=udp]

[ejabberd-auth]

enabled = false
filter = ejabberd-auth
port = xmpp-client
protocol = tcp
logpath = /var/log/ejabberd/ejabberd.log


# Multiple jails, 1 per protocol, are necessary ATM:
# see https://github.com/fail2ban/fail2ban/issues/37
[asterisk-tcp]

enabled = false
filter = asterisk
port = 5060,5061
protocol = tcp
logpath = /var/log/asterisk/messages

[asterisk-udp]

enabled = false
filter = asterisk
port = 5060,5061
protocol = udp
logpath = /var/log/asterisk/messages

# Ajouter les definitions si vous ne l'avez pas fait a l'etape precedente
[apache-phpmyadmin]
enabled = true
port = http,https
filter = apache-phpmyadmin
logpath = /var/log/apache*/*error.log
logpath = /var/log/virtualmin/*_error_log
maxretry = 3

[apache-w00tw00t]
enabled = true
filter = apache-w00tw00t
port = all
banaction = iptables-allports
port = anyport
logpath = /var/log/apache*/access.log
logpath = /var/log/virtualmin/*_access_log
maxretry = 1
bantime = 864000

[apache-wp-login]
# activer si vous utilisez wordpress
enabled = false
port = http,https
filter = apache-wp-login
logpath = /var/log/apache*/access.log
/var/log/virtualmin/*_access.log
maxretry = 3

# Jail for more extended banning of persistent abusers
# !!! WARNING !!!
# Make sure that your loglevel specified in fail2ban.conf/.local
# is not at DEBUG level -- which might then cause fail2ban to fall into
# an infinite loop constantly feeding itself with non-informative lines
[recidive]

enabled = false
filter = recidive
logpath = /var/log/fail2ban.log
action = iptables-allports[name=recidive]
sendmail-whois-lines[name=recidive, logpath=/var/log/fail2ban.log]
bantime = 604800 ; 1 week
findtime = 86400 ; 1 day
maxretry = 5

# See the IMPORTANT note in action.d/blocklist_de.conf for when to
# use this action
#
# Report block via blocklist.de fail2ban reporting service API
# See action.d/blocklist_de.conf for more information
[ssh-blocklist]

enabled = false
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest="%(destemail)s", sender="%(sender)s", sendername="%(sendername)s"]
blocklist_de[email="%(sender)s", apikey="xxxxxx", service="%(filter)s"]
logpath = /var/log/sshd.log
maxretry = 20


# consider low maxretry and a long bantime
# nobody except your own Nagios server should ever probe nrpe
[nagios]
enabled = false
filter = nagios
action = iptables[name=Nagios, port=5666, protocol=tcp]
sendmail-whois[name=Nagios, dest="%(destemail)s", sender="%(sender)s", sendername="%(sendername)s"]
logpath = /var/log/messages ; nrpe.cfg may define a different log_facility
maxretry = 1
Les points qui me posent question.

Pour ceux dont on ne parle pas dans le tuto :
ssh-route
ssh-iptables-ipset4
ssh-iptables-ipset6
apache-modsecurity
apache-nohome
php-url-fopen
lighthttpd-fastcgi
lighthttpd-auth
nginx-http-auth
sogo-auth
pysqld-auth
freeswitch
ejabberd-auth
asterisk-tcp
asterisk-udp

et enfin toute la partie récidive

celles qui manquent
[http-get-dos] de plus, dans l'exemple du tuto on retrouve : ignoreip = 168.192.0.1 ça ne devrait pas être 192.168.0.1 plutôt ?


les autres questions
apache à false ?
le tuto rajoute une surveillance de wordpress, on pourrait faire de même pour prestashop ?
on ban les ip qui cherche phpmyadmin, on ne pourrait pas faire de même pour les gens qui génèrent trop de 404 de manière générale? Le pirate qui a exploité la faille d'un module en a recherché plein avant d'en trouver un qui soit installé. Une telle directive l'aurait ban avant l'intrusion.

bbr18
11/08/2016, 15h12
sans risque c'est vite dit, pas indexé dans google, ok mais les robots qui scannent le net eux s'en fichent et ils exploiteront les failles s'ils en trouvent
tes précédents hacks étaient liés au FTP, en priorité commence par empêcher que chaque user puisse accéder ailleurs que chez lui, sur le panel, vas dans :
Limites et Validation, FTP Directory Restrictions et là tu coches : All virtual servers et Virtual server's home directory
(par défaut c'est dans la racine du /home, là ce sera dans /home/user)

johnny57
11/08/2016, 14h43
Je n'ai mis qu'un site desindéxé de google parce que j'avais eu un soucis avec l'ip sur l'ancien serveur. C'était pour me faire la main sans risque.

bbr18
11/08/2016, 11h42
oui il y en a ^^ mais tu aurais du commencer par tout sécuriser avant de mettre tes sites
fail2ban : https://www.how-to.ovh/viewtopic.php?f=10&t=19

johnny57
11/08/2016, 11h23
on va y arriver en effet, par exemple la bonne configuration de fail2ban.

tu as sur ton site des tutos de sécurisation ?

bbr18
11/08/2016, 11h00
et aussi pense à regarder les tutos pour sécuriser un minimum ton serveur

johnny57
11/08/2016, 10h22
Non, mais maintenant c'est fait. Je ne sais pas si j'aurai d'autres soucis avec ce nouveau serveur pour la migration, mais en tout cas dés maintenant un très grand merci à tout ceux qui ont pris la peine de m'aider sur ce fil.

sich
11/08/2016, 10h14
il faut probablement installer php5-mcrypt (de mémoire pour le nom du module)

[EDIT] ha, en retard, ça m'apprendra à rafraichir la page avant de répondre [/EDIT]

bbr18
11/08/2016, 10h10
as-tu installé mcrypt ?
( apt-get update && apt-get install php5-mcrypt )

johnny57
11/08/2016, 09h33
C'était un problème de chmod en effet. J'ai regardé avec history ce que j'avais fais après rsync et j'avais une faute de frappe sur l'user encre, j'avais mis enrce.

Avec le encre:encre et les chmod du tuto ça fonctionne. Enfin, presque ^^' Plus de 403 soit, mais une erreur 500 :

mod_fcgid: stderr: PHP Fatal error: Call to undefined function mcrypt_encrypt() in /home/encre/public_html/classes/Rijndael.php on line 51
un appel à une fonction qui n'existe pas bloque manifestement le site. étrange, parce que le site était fonctionnel sur la R3.

janus57
11/08/2016, 09h01
Bonjour,

Virtualmin n'a pas une option dans le panel du serveur pour vérifier et corriger les permissions si elles sont pas bonnes ?

Sinon vite faite j'ai trouvé des topics qui parlent de "virtualmin fix-domain-permissions --all-domains" pour le faire en SSH

Car si virtualmin arrive à corriger les permissions et que cela ne fonctionne pas y a 90% de chance que ce soit un mauvais chmod (et cela peu arriver plus souvent qu'on ne le pense).

Cordialement, janus57

bbr18
11/08/2016, 07h09
Par défaut c'est FCGId sauf si tu as forcé sur un autre mode
comment as-tu transféré ton site ? rsync entre les 2 serveurs ou manuellement en ftp ?
détailler comment tu as procédé pourrait aider à trouver ce qui cloche
une méthode qui fonctionne parfaitement : créer le virtualhost, puis transférer les données de home/user/www dans /home/user/public_html et ensuite faire chmod et chown pour que tout soit ok

cassiopee
11/08/2016, 01h35
1) Il faudrait regarder quel est le mode d'exécution de PHP de ce VirtualHost ?

Une fois dans le VirtualHost en question, c'est dans "Server Configuration" puis "Website Options"
et là, quelle est la valeur pour "PHP script execution mode" ?

2) Quels sont les droits Unix :

- du fichier ".htaccess"
- du répertoire "public_html"
- du répertoire "/home/encre"

?

johnny57
10/08/2016, 22h55
Qu'on se comprenne bien, je n'impose pas une vérité. Je cherche à comprendre pourquoi exemple:users fonctionne et pas exemple:exemple.

J'aurai aimé que ça fonctionne simplement, mais ce n'est pas le cas. Si je continue à en parler ici ce n'est pas pour dire j'ai raison vous vous trompez. C'est pour trouver pourquoi ça ne fonctionne pas comme ça devrait. Si vous me donnez des pistes à creuser je suis preneur parce que là, je ne sais où chercher.

bbr18
10/08/2016, 18h25
j'ai migré plusieurs dizaines de domaines de la R2 vers virtualmin et je n'ai jamais eu ce problème, tu as du faire quelque chose de travers à un moment donné, mais comme le dit Cassiopee, tu risques une nouvelle fois de créer des failles et te faire hacker (déjà 3 fois en 2 ans d'après tes posts sur ce forum), mais tu peux continuer comme tu le sens...

cassiopee
10/08/2016, 18h16
Citation Envoyé par johnny57
Le fait d'avoir changé le htaccess de groupe (en même temps que les autres fichiers) a débloqué la situation.
Mais il n'y a aucune raison de changer le groupe d'appartenance pour que le système fonctionne normalement,
le (vrai) problème est ailleurs.

( sinon, comment expliques-tu que chez tout le monde, les ".htaccess" fonctionnent parfaitement avec "user:groupe" ? )

En revanche, tôt ou tard, avoir mis "users" te posera des problèmes (piratage d'un des sites web qui amène au piratage des autres,
problèmes de permissions avec les backups, etc.)

Mais bon, fais comme tu veux, je n'insiste pas davantage.

bbr18
10/08/2016, 17h38
Avant, tous les répertoires de home/encre était en encre:encre et ça ne marchait pas. J'ai fais un chown sur /home/encre/public_html pour le passer en encre:users et ça fonctionne.
à bidouiller de la sorte tu vas créer des problèmes ailleurs et tu risques de rendre virtualmin bancal

johnny57
10/08/2016, 17h26
Citation Envoyé par cassiopee
Le souci est qu'il suffit, par exemple, de rendre le fichier ".htaccess" inaccessible à Apache pour que le problème semble résolu,
alors qu'il n'en est rien. (Apache ne pouvant plus du tout accéder au fichier, il l'ignore donc ça ne déclenche plus d'erreur)
C'est l'inverse, c'est justement parce que le fichier htaccess était inaccessible du fait du mauvais groupe que le serveur livrait une 403. Le fait d'avoir changé le htaccess de groupe (en même temps que les autres fichiers) a débloqué la situation.

Avant, tous les répertoires de home/encre était en encre:encre et ça ne marchait pas. J'ai fais un chown sur /home/encre/public_html pour le passer en encre:users et ça fonctionne.

Citation Envoyé par bbr18
dans ton .htaccess as-tu modifié le chemin ? car avant c'était /home/user/www maintenant c'est /home/user/public_html
Il n'est fait aucune référence au /home dans mon htaccess.
Pour le chown, je suis obligé de faire exemple:users, exemple:exemple ne fonctionne pas comme je suis en train d'en parler depuis plusieurs messages

bbr18
10/08/2016, 16h12
dans mon tuto je mets ceci, et il faut le faire si tu as utilisé rsync pour ta migration :
Code:
chown -R exemple:exemple /home/exemple/public_html
find /home/exemple/public_html -type d -exec chmod 755 "{}" \;
find /home/exemple/public_html -type f -exec chmod 644 "{}" \;
dans ton .htaccess as-tu modifié le chemin ? car avant c'était /home/user/www maintenant c'est /home/user/public_html

cassiopee
10/08/2016, 15h06
Citation Envoyé par johnny57
ben, le simple fait d'avoir changé le propriétaire du répertoire public_html et ses sous répertoires à suffit à corriger le problème.
Le souci est qu'il suffit, par exemple, de rendre le fichier ".htaccess" inaccessible à Apache pour que le problème semble résolu,
alors qu'il n'en est rien. (Apache ne pouvant plus du tout accéder au fichier, il l'ignore donc ça ne déclenche plus d'erreur)

Pour info, l'erreur était la suivante dans le log :
Je pencherais plutôt pour un problème de droits Unix. Soit sur le fichier ".htaccess" lui-même,
soit dans un des répertoires parents ("/home/encre" et "/home/encre/public_html" en l'occurence).

Le fichier ".htaccess" est normalement en "-rw-r--r--".
Le répertoire "/home/encre/public_html" est normalement en "drwxr-x---".
et le répertoire "/home/encre" est normalement en "drwxr-x---" également.

Et ces 3 niveaux sont en "utilisateur:groupe" pour ce qui du propriétaire (où "groupe" = "utilisateur").

En tout cas, avoir "users" comme groupe à ce niveau n'est pas la configuration normale de Virtualmin.
Selon les droits Unix des fichiers/répertoires, cela pourrait permettre à un utilisateur d'un site A
d'aller se ballader dans un site B, par exemple.

C'est afin d'éviter ça que chaque utilisateur est "enfermé" dans son propre groupe.

PS : Eventuellement, il faudrait regarder quel est le mode d'exécution de PHP de ce VirtualHost ?

C'est dans "Server Configuration" puis "Website Options" et là, la valeur
pour "PHP script execution mode" ?

johnny57
10/08/2016, 14h21
ben, le simple fait d'avoir changé le propriétaire du répertoire public_html et ses sous répertoires à suffit à corriger le problème. Pour info, l'erreur était la suivante dans le log :

[Wed Aug 10 08:51:47.791401 2016] [core:crit] [pid 3023] (13)Permission denied: [client 66.249.64.38:39436] AH00529: /home/encre/public_html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/home/encre/public_html/' is executable

cassiopee
10/08/2016, 13h49
Il y a différentes manières d'ajouter une IP failover avec Virtualmin.

- soit faire ce que tu as fais, c'est-à-dire modifier à la main le fichier "/etc/network/interfaces" puis utiliser l'adresse IP dans Virtualmin
- soit ajouter directement dans Virtualmin l'adresse IP failover, ce dernier fera le nécessaire dans "interfaces" puis utiliser l'adresse IP dans Virtualmin

La deuxième approche se passe en fait dans Webmin :

- cliquer en haut à gauche sur "webmin" pour basculer dans cette partie
- ouvrir l'onglet "Networking" dans le menu principal à gauche
- cliquer sur "Network configuration"
- cliquer à droite sur l'icône "Network interfaces"
- enfin cliquer sur "Add a new interface"

Là saisir le nom qui correspond (à savoir "eth0:0", "eth0:1", "eth0:2", etc.), saisir l'adresse IP failover,
laisser le reste par défaut et cliquer en bas sur "Create and apply".

C'est terminé, l'IP failover est désormais utilisable dans Virtualmin

Dans Virtualmin, on aura ensuite à choisir si on veut que cette IP soit :

- dédiée à un seul site web ("dedicated IP")
- partagée par plusieurs sites web ("shared IP")

En général, c'est "shared", donc il faudra l'ajouter dans Virtualmin
dans "Adresses and Networking" puis "Shared IP Adresses".

Bien entendu, on ne fait tout çà qu'une seule fois, lors de l'installation
d'une IP failover.

Lors de la création ultérieure d'un VirtualHost, il suffira de dire qu'il utilise telle ou telle
adresse IP failover, partagée ou dédiée selon.

- - - Mise à jour - - -

Citation Envoyé par johnny57
alors un truc m'échappe. Pourquoi quand les dossiers étaient en utilisateur:utilisateur j'avais une erreur 403 ?
Une erreur 403, cela correspond à pas mal d'erreurs possibles. Il faut aller voir dans le fichier d'erreur d'Apache du VirtualHost en question.

C'est dans "/var/log/virtualmin", il y a deux fichiers de logs par VirtualHost. "xxxx_access_log" et "xxxxx_error_log".

Par exemple, il se peut que le fichier ".htaccess" contienne une directive obsolète ou encore qu'il fasse référence à un
fichier dont le répertoire ne correspond plus dans le nouvel environnement.

johnny57
10/08/2016, 13h45
alors un truc m'échappe. Pourquoi quand les dossiers étaient en utilisateur:utilisateur j'avais une erreur 403 ?

cassiopee
10/08/2016, 13h34
Non, avec Virtualmin ce n'est pas "utilisateur:utilisateur" mais "utilisateur:groupe", comme avec
n'importe quel Unix, simplement il se trouve qu'il y a un groupe par utilisateur et qui porte
le même nom que l'utilisateur. (cf le contenu du fichier "/etc/group").

Dans la Release, il n'y a qu'un seul groupe pour tous les utilisateurs et il s'appelle "users".

johnny57
10/08/2016, 12h59
J'ai trouvé, il y a un truc étrange. Les fichiers et repertoires créés par virtualmin sont en "utilisateur:utilisateur" alors qu'ils devraient être en "utilisateur:users" un paramétrage à rectifier dans virtualmin ?

johnny57
09/08/2016, 18h10
Donc maintenant inutile de modifier le fichier pour les suivantes, uniquement dans virtualmin ? Ou il faudra faire les 2 à chaque fois ?

Pour bbr18 :

Je suis en train de suivre ton tuto migration release/debian. Après un rsync les fichiers étant root il faut faire un chown utilisateur:utilisateur non ?

Le site ne s'affiche pas malgré tout ça, il me met :

Forbidden

You don't have permission to access / on this server.
Server unable to read htaccess file, denying access to be safe

bbr18
09/08/2016, 17h35
il faut d'abord les ajouter dans Adresses et réseau puis Shared IP Addresses, ensuite dans ton serveur virtuel, tu valides l'ip concernée
par contre si tu avais modifié ton fichier avant d'installer virtualmin, elles auraient été reconnues automatiquement

johnny57
09/08/2016, 16h42
J'utilise les ip fail over avec la R3 pour que chaque domaine ai son IP. Dans virtualmin, si je ne me trompe je dois cliquer créer un nouveau serveur", mais, malgré que j'ai ajouté :

auto eth0:0
iface eth0:0 inet static
address IP.DE.FAIL.OVER
netmask 255.255.255.255
broadcast IP.DE.FAIL.OVER
dans /etc/network/interfaces et redémarré avec /etc/init.d/networking restart

dans la création donc, je dois renseigner à la main cette IP dans la case "interface virtuelle sur l'IP" pour que le domaine y soit rattaché ?

johnny57
09/08/2016, 15h48
Citation Envoyé par bbr18
c'est quand même pas compliqué et TOUT sera installé
ensuite tu vas sur le panel : https://ns122346.eu:10000
Je dois être poisseux, l'url de webmin ne répond pas... J'ai tenté d'ouvrir adresseipduserveur:10000 et ça ne donne rien


Edit :

J'ai changé le port, fait un restart de webmin et ça roule.

sich
09/08/2016, 14h36
Citation Envoyé par johnny57
Ben le technicien OVH me disait que plesk est plus simple d'utilisation et plus proche de la facilité d'utilisation d'une R3 que ne l'est virtualmin. Précision, la licence plesk est comprise dans le prix de location du serveur. Pas de surcoût pour moi donc.

Si je décide de partir sur virtualmin, je devrais prendre une débian nue et tout installer genre postfix etc ? Parce qu'ovh ne propose pas de distri packagé avec virtualmin.
En même temps quand on prends un serveur c'est justement pour personnaliser ses services et configurer sois même la machine....
Sinon on prends du mutualisé ou un infogérant... Ne pas savoir configurer ses services sur un serveur c'est comme conduire une voiture sans permis.

Nous avons une chance énorme dans le monde du libre il existe des tonnes de docs sur le net pour apprendre justement. Prendre plesk et penser que l'on ne doit pas s'occuper de la sécurité du serveur n'est pas raisonnable du tout.

amha il est préférable de partir sur virtualmin avec debian... Le net regorge de doc pour cette config et ce sera pour toi l'occasion d'apprendre.

Après si malgré tout tu n'as pas le temps ou l'envie d'apprendre passe par les services d'un infogérant ou par de l'hébergement mutualisé....

Il ne viendrait à l'idée de personne de prendre une voiture sans jamais avoir conduit, sans rien connaitre à la mécanique et sans jamais l'amener à un garagiste... Il serait pas mal qu'il en soit de même pour les serveurs. Un serveur mal géré pose de nombreux problèmes de sécurité sur le net (virus / spam / ...).

Dernier point, plesk étant une usine à gaz totalement fermée tu n'auras probablement pas bcp d'aide sur le forum ici pour du support. Alors qu'une distrib de base, même avec virtualmin, tu auras probablement des gens en mesure de t'aider.

désolé pour ma minute pénible

bbr18
09/08/2016, 14h15
oui c'est ça

- - - Mise à jour - - -

enfin quand ce sera fini, tu auras juste à cliquer dans le menu sur : Installer scripts, puis choisir phpmyadmin et/ou Roundcube si tu en as besoin

johnny57
09/08/2016, 14h12
Si je comprends bien c'est l'installation de virtualmin qui package le tout c'est ça ?

Quelles sont les limites de la version gratuite ?

bbr18
09/08/2016, 14h09
Citation Envoyé par johnny57
Je n'ai pas dis que c'était compliqué ^^' mais il faudra quand même tout installer à la main, postfix, certificat dkim, roundcube, fail2ban etc... Plus long qu'une installation automatisée. Cassiopee disait que c'était packagé : https://forum.ovh.com/showthread.php...l=1#post676366 comme une release. Je pensais donc qu'ovh avait un package avec virtualmin.
mais NON !
tu installes Debian nu sur le manager puis en ssh tu tapes :
Code:
wget software.virtualmin.com/gpl/scripts/install.sh && chmod +x install.sh
puis
Code:
./install.sh -y
c'est quand même pas compliqué et TOUT sera installé
ensuite tu vas sur le panel : https://ns122346.eu:10000

johnny57
09/08/2016, 14h01
Je n'ai pas dis que c'était compliqué ^^' mais il faudra quand même tout installer à la main, postfix, certificat dkim, roundcube, fail2ban etc... Plus long qu'une installation automatisée. Cassiopee disait que c'était packagé : https://forum.ovh.com/showthread.php...l=1#post676366 comme une release. Je pensais donc qu'ovh avait un package avec virtualmin.

Nowwhat
09/08/2016, 13h58
Pas mal du tout, Plesk, effectivement.

Mais sache :
Tu seras quand même obligé de maitriser ton OS - quoi qu'il arrive.
Ajoute sur ça : le doc de Plesk .....
(Et ainsi t'auras ton usine-à-gaz ....)

Virtualmin : de mémoire, ça s'installe sur un Debian 'nu' comme ça : https://www.virtualmin.com/download.html
Autrement dit : disons que c'est facile

johnny57
09/08/2016, 13h53
Ben le technicien OVH me disait que plesk est plus simple d'utilisation et plus proche de la facilité d'utilisation d'une R3 que ne l'est virtualmin. Précision, la licence plesk est comprise dans le prix de location du serveur. Pas de surcoût pour moi donc.

Si je décide de partir sur virtualmin, je devrais prendre une débian nue et tout installer genre postfix etc ? Parce qu'ovh ne propose pas de distri packagé avec virtualmin.

bbr18
09/08/2016, 13h36
en tous cas il y a un problème de fond sur ce que tu héberges, tu en es à 3 hacks :
https://forum.ovh.com/showthread.php...3%A9-en-rescue
https://forum.ovh.com/showthread.php...eur-hack%C3%A9
tu devrais revoir ta politique de sécurité et utiliser des trucs qui ont fait leurs preuves ^^

bbr18
09/08/2016, 13h29
la grande différence se situe sur le support (franchement pas indispensable), les applis installables en 1 clic de la version pro, s'installent en 1 ligne style apt-get install application, enfin beaucoup pensent toujours que c'est mieux si c'est payant (et cher bien sûr )
Et puis il est possible d'installer la version GPL puis la faire évoluer vers la pro si besoin (1 clic + CB) ^^

janus57
09/08/2016, 13h00
Bonjour,

edit : je ne vois aucun intérêt à payer la licence pour Virtualmin, toutes les réponses sont sur le Web et sur leur forum et la licence gratuite (GPL) comprend toutes les fonctionnalités
c'est utile pour ceux qui veulent les fonctionnalités de virtualmin pro (voir tableau du premier lien "vs") ou le support privatif.

Après chacun son choix, y en a qui sont plus "confiant" quand il payent un support. (et c'est toujours moins cher que plesk…)

Cordialement, janus57

bbr18
09/08/2016, 12h53
Différences entre Virtualmin et Plesk :
- Virtualmin : gratuit, ne modifie pas la distribution sur laquelle il est installé, simple d'approche
- Plesk : payant, panel hyper propriétaire
un conseil, prends un vps à 2 euros, installe Virtualmin, fais des tests, et là tu verras si cela te convient (regarde mes tutos, tout est expliqué de A à Z), ne te laisse pas séduire par le fait que Plesk s'installe directement dans le manager, Virtualmin est très simple à installé et une fois fait tu n'auras que des avantages.
edit : je ne vois aucun intérêt à payer la licence pour Virtualmin, toutes les réponses sont sur le Web et sur leur forum et la licence gratuite (GPL) comprend toutes les fonctionnalités

janus57
09/08/2016, 12h49
Citation Envoyé par johnny57
Le technicien ovh me conseil plutot un plesk qu'un virtualmin, qu'en pensez vous ?
Bonjour,

si vous voulez absolument un système "boite noir" avec licence, pourquoi pas.
Par contre je pense que ave plesk faut absolument oublier la bidouille via SSH comme on peu se le permettre via virtualmin qui laisse l'OS en dessus quasiment de base (plesk lui a plutôt tendance à "parasiter" l'os de base).

Sinon virtualmin aussi dispose d'une solution de licence avec support.

Cf : https://www.virtualmin.com/vs
+ https://www.virtualmin.com/buy/virtualmin

Cordialement, janus57

johnny57
09/08/2016, 11h05
Le technicien ovh me conseil plutot un plesk qu'un virtualmin, qu'en pensez vous ?

cassiopee
06/08/2016, 15h21
Ah non pas du tout, tout cela est préinstallé, comme avec la Release.

A la base la Release d'OVH est un module supplémentaire (le fameux "ovhm") du panel de gestion "webmin".
Virtualmin est également un module supplémentaire de webmin.

johnny57
06/08/2016, 14h14
Ok, mais, si je comprend bien, à l'inverse d'une release d'ovh, si je m'oriente sur un debian par exemple, il me faudra installer tout ce qui est nécessaire comme un serveur ftp, mail (postfix par exemple) etc ?

bbr18
06/08/2016, 14h02
Citation Envoyé par johnny57
je vais me pencher sur ce point. Si d'autres ont des avis sur la distri à choisir je suis preneur. J'aimais bien le confort de webmin sur la R3 et cette facilité d'ajouter des sites. J'aimerai une distri qui offre le même confort. Je ne sais pas si virtualmin propose ce genre de choses.
justement tu auras webmin et la même facilité que ovhm pour ajouter des domaines (sur ma signature tu trouveras des tutos pour installer virtualmin et aussi pour passer de R3 à Virtualmin)

johnny57
06/08/2016, 13h55
En effet, la première fois que j'ai changé de serveur c'était pour la même raison. Quand fin 2014 une grosse faille a été découverte sur la distri utilisée sur la R2 et que idem, le serveur a été attaqué. Sauf que ce coup là avait été bien plus grave par le vol de tous les identifiants serveur.

Je vais me pencher sur ce point. Si d'autres ont des avis sur la distri à choisir je suis preneur. J'aimais bien le confort de webmin sur la R3 et cette facilité d'ajouter des sites. J'aimerai une distri qui offre le même confort. Je ne sais pas si virtualmin propose ce genre de choses. Po

J'utilise le serveur pour héberger plusieurs sites web différents. Il me faut donc quelque chose de "prévu pour" à la manière de la R3.

cassiopee
06/08/2016, 12h39
Oui, c'est le genre d'événement qui est souvent le déclencheur d'une grosse mise à jour ou d'une migration

Le couple Debian + Virtualmin est une bonne alternative à la Release 2/3.

johnny57
06/08/2016, 11h14
C'est exactement cet exploit qui a été appliqué en effet.

J'avais déjà redémarré le serveur pour éviter ce genre de soucis de code encore en RAM. Je pense justement changer de serveur pour repartir sur une distri moins vieille que la R3 de toutes façons. On va dire que c'est le moment ^^'

cassiopee
05/08/2016, 01h36
Citation Envoyé par johnny57
Quand j'ai constaté de nouveaux ajout, aucune requête POST dans les log apache ne collait avec la date de création de ses nouveaux fichiers. C'est ce qui est étrange à mes yeux. Et si ça avait été en GET on verrait clairement dans les logs la manip.
Il est possible qu'un script PHP du pirate tournait/tourne en RAM tout simplement. Dans ce cas, le simple fait de
redémarrer Apache suffit à le dégager. C'est d'ailleurs une façon de faire qui se répand car elle laisse très peu de traces
(et notamment aucun script pirate à analyser dans le disque dur puisque tout se passe en RAM).

Ce qui m'inquiète c'est que tu dise qu'on peut manipuler la date de modification d'un fichier.
Oui, c'est ce qui permet de modifier un fichier en ensuite de lui remettre sa date d'avant modification.
Il ne faut donc pas trop se fier aux dates des fichiers pour repérer quelque chose.

Disons qu'une recherche sur les fichiers ayant une date de modification récente est utile
mais il ne faut surtout pas s'en contenter.

On peut ajouter un "grep -R ..." afin de trouver des expressions souvent présentes dans les bouts
de codes ajoutés (type "eval" ou encore "base64"). Bien évidemment il peut y avoir pas mal
de faux positifs.

Mais si le pirate est bon, il aura crypté tout ça, donc aucune recherche à base d'expression régulière
ne donnera de résultat, donnant une fausse impression que tout va bien.

D'où ma recommendation de comparer via un "diff" avec une sauvegarde récente.

Là ça permet vraiment de vérifier quels sont les fichiers modifiés, même si la date a été trafiquée
et que le code PHP ajouté est chiffré.

Ce qui me conforte aussi dans la non compromission totale du serveur. Si le pirate avait un accès SSH au serveur il pourrait facilement rétablir les droits sur les répertoires et réinjecter des fichiers.
Disons que, sur le principe, c'est mieux de tout réinstaller, c'est certainement la meilleure garantie
que l'on repart sur des bases saines.

Maintenant dans la pratique, si rien n'indique une effraction supérieure à celle d'un seul site web ...
(pas de compte utilisateur ajouté dans "/etc/passwd", pas de fichier bizarre à la racine du disque ou autre
répertoire système, etc.) c'est vrai que l'on peut être tenté de ne pas aller plus loin dans la reprise
en main du serveur.

PS: Il s'est sans doute passé quelque chose de proche de ça : https://www.youtube.com/watch?v=HXbDNPh0aTc

johnny57
05/08/2016, 00h34
Comme je l'ai décrit dans mes précédents messages, c'est ce qui c'est passé. Utilisation d'une fonction d'upload d'un module qui était bien à jour pour télécharger un premier script puis ça a fait des petits. En plus, deux fichiers de prestashop avaient été modifiés. Le contrôleur de login du back office, et un fichier index d'un des répertoires. J'ai supprimé ce qui devait l'être, restauré des versions saines des fichiers prestashop qui avaient été modifiés.

Quand j'ai constaté de nouveaux ajout, aucune requête POST dans les log apache ne collait avec la date de création de ses nouveaux fichiers. C'est ce qui est étrange à mes yeux. Et si ça avait été en GET on verrait clairement dans les logs la manip.

Ce qui m'inquiète c'est que tu dise qu'on peut manipuler la date de modification d'un fichier.

Pour l'instant, je n'ai pas constaté de nouvelle intrusion, le passage en 555 de tous les répertoires semble tenir bon. Ce qui me conforte aussi dans la non compromission totale du serveur. Si le pirate avait un accès SSH au serveur il pourrait facilement rétablir les droits sur les répertoires et réinjecter des fichiers.

cassiopee
04/08/2016, 23h28
Avec un outil comme Prestashop installé, la piste la plus vraisemblable est soit une faille dans Prestashop lui-même
(il faut avoir la toute dernière version en date, comme pour un CMS de type WordPress, SPIP, etc.) , soit d'un
plugin, addon ajouté à Prestashop. Là aussi mise à jour indispensable.

Très souvent le pirate va :

1) uploader un ou plusieurs scripts (PHP ou autre) via cette faille

2) à l'aide du script uploadé en 1) il va modifier un des nombreux scripts PHP de l'outil utilisé (ici de Prestashop)
afin d'ajouter une backdoor. Généralement ça tient en une seule ligne de PHP, du genre "eval()" d'une variable
PHP transmise via POST, dans ce genre :

Code:
 eval ($_POST[plmzdzxed5plm]);
Cela permet au pirate de reprendre le contrôle du site web (si jamais l'administrateur a "fait le ménage"
dans les autres scripts uploadés par le pirate + mise à jour de l'outil du site, fermant ainsi la faille initiale)
via un appel apparemment anodin dans les logs puisque la partie suspecte, le contenu de la variable POSTée,
n'est pas noté dans les logs d'Apache et que le script PHP appelé fait partie intégrante de l'outil
(il est donc appelé très souvent par les visiteurs normaux du site web).

Le mieux est alors de comparer automatiquement les fichiers actuels avec une sauvegarde récente
(au hasard, avec la commande "diff" utilisée récursivement, y compris en excluant des répertoires
de type "cache", "logs", "tmp", etc. qui seront forcément différents et risqueraient de générer
de nombreux faux positifs)

La date des fichiers étant manipulable sous Unix, même si un fichier présente une certaine date (ancienne)
dans un "ls", cela ne veut pas du tout dire que ce fichier n'a pas été modifié récemment.

johnny57
04/08/2016, 20h20
Je doute fortement que le serveur soit entièrement corrompu. Si c'était le cas, pourquoi ne s'attaquerait-il qu'à un seul site ? Il y a plusieurs sur le serveur, aucun n'est attaqué. Il n'y a qu'un seul site sur lequel je retrouve des fichiers. Si corruption il y a j'ai peur que ce soit de prestashop avec une injection de script, faut que je fouille la base de données pour voir si je trouve des trucs louches.

buddy
04/08/2016, 17h01
Rk hunter n'a rien trouvé c'est différent de rien de problématique.
1) il travaille sur le système
2) il compare par rapport à une base de données


Un backdoor ne laisse pas de trace si le mec est pas débile. Et si c'est ton serveur qui exécute le code de manière autonome c'est normal que tu n'aies rien dans les lois ssl FTP et apache.

Bref faut formater et réinstaller ça prendra surement moins de temps.

johnny57
04/08/2016, 13h40
htaccess de wordpress modifié, ça bloque aussi ici maintenant.

J'ai installé rk hunter, résultat, rien de problématique. Donc pas de rootkit sur le serveur. ça ne m'explique toujours pas comment les nouveaux fichiers sont créés. En attendant, j'ai passé tous les dossiers en 555, ça devrait empêcher toute création de nouveau fichier mais ce n'est pas une solution.

Précision, j'ai également vérifier les logs de connexion SSH, aucune connexion depuis une autre IP que la mienne.

johnny57
03/08/2016, 22h31
Si il en a un pour réécriture des urls en effet. Je soupçonnais bien que ce soit le facteur bloquant mais je ne trouvais pas ça logique. Je vais essayer.

buddy
03/08/2016, 21h38
à tout hasard, wordpress n'aurait pas lui aussi un .htaccess ? si oui, je te conseille de copier coller les règles de crawltract dans le .htaccess qui se trouve dans le répertoire du wordpress

johnny57
03/08/2016, 21h32
fail2ban est aussi paramétré. Mais sauf erreur de ma part, fail2ban ne bloque pas une XSS à première tentative.

bbr18
03/08/2016, 17h08
fail2ban serait bien plus adapté ^^

johnny57
03/08/2016, 16h42
La R3 était obsolète à sa sortie alors ^^' de mémoire quand j'ai changé de serveur elle venait de sortir de beta

ben le module était à jour.

Quand je dis standard je parle du www du site en question soit /home/site/www.

Je suis certain que le fichier n'a même pas été créé puisque la création devait se faire sur ce chemin : /home/$user_idx/public_html/

Autre question, j'ai une série de règle dans mon htaccess pour limiter les risques de hack générée par un programme qui s'appelle crawlprotect. Elles fonctionnent bien, sauf dans le répertoire /blog qui héberge un wordpress. Si je test une action interdire sur le site dans un répertoire ou non ça bloque bien, sauf dans le repertoire blog. Une idée du pourquoi ?

buddy
03/08/2016, 14h17
Citation Envoyé par johnny57
Oui elle est obsolète mais elle ne l'était pas quand j'ai pris le serveur il y a un an et demi environ, oui elle a des inconvénients, oui je vais en changer. Mais en attendant, un des scripts installé avait pour but de récupérer le etc/passwd du serveur et le retranscrire dans un txt dans le répertoire www du site hacké. Manque de bol pour le pirate, le chemin vers ce www n'est pas standar, du fait de la release. Donc le fichier n'a pas été créé, et donc, n'a pas été récupéré. Il y a quand même des avantages à sortir du moule ^^'
PHP 5.3 n'est plus maintenu depuis 2 ans (Aout 2014 ) .. donc on peut quand même considéré qu'elle était déjà obsolète.

Normalement aucune distribution n'a de site dans le www "standard". (moi généralement je mets une page 404 que l'on obtient dans l'on tape http://ip.du.serveur/ * ).

D'ailleurs es-tu sur qu'il n'est pas accessible avec http://ip.du.serveur/nomdufichier.txt ?

Enfin, avoir des versions à jour aussi généralement çà évite de se faire pirater.

johnny57
03/08/2016, 14h06
Oui elle est obsolète mais elle ne l'était pas quand j'ai pris le serveur il y a un an et demi environ, oui elle a des inconvénients, oui je vais en changer. Mais en attendant, un des scripts installé avait pour but de récupérer le etc/passwd du serveur et le retranscrire dans un txt dans le répertoire www du site hacké. Manque de bol pour le pirate, le chemin vers ce www n'est pas standar, du fait de la release. Donc le fichier n'a pas été créé, et donc, n'a pas été récupéré. Il y a quand même des avantages à sortir du moule ^^'

bbr18
03/08/2016, 13h58
release 3 d'ovh (centos 6) parfaitement à jour
hum... tu sais quand même que cette distribution est obsolète et que les mises à jour sont anecdotiques (combien de fois par an ? ) ?
Ton serveur est compromis, il faut le réinstaller, profites-en pour mettre une distribution récente avec des mises à jour fréquentes (Debian ou Centos avec Virtualmin ne te dépayseront pas du système des releases - webmin, etc. c'est largement aussi simple mais sans les inconvénients de distributions hyper propriétaires)

fritz2cat
03/08/2016, 13h27
Parfois on trouve aussi des ou des dans la base de données... pour pirater les visiteurs de ton site.

johnny57
03/08/2016, 13h22
est ce qu'il est possible de savoir ce qui a créé un fichier ? Par exemple, un accès FTP, un script php ou autre ?

buddy
03/08/2016, 13h08
Comme je l'ai dit avant, il n'y a peut être pas que les fichiers prestashop qui sont compromis ...

Le mieux est de réinstaller tout l'OS ..

johnny57
03/08/2016, 12h52
J'ai réussi avec tes 2 liens à lister tous les fichiers. Je les ai stocké en BDD avec leur date de modif pour ensuite faire un tri décroissant de date.

J'ai examiné chaque fichiers et tous les fichiers ajoutés depuis le hack ont bien été neutralisés. Les fichiers prestashop qui avaient été modifiés ont été restaurés par leur version d'origine.

J'ai redémarré le serveur hier soir pour couper toute connexion en cours, mais manifestement, ça ne suffit pas.

buddy
03/08/2016, 12h50
Tu peux aussi utiliser find avec l'optime -mtime

ex : find . -mtime -3 -print

http://www.linux-france.org/article/memo/node126.html

fritz2cat
03/08/2016, 12h29
Utilise des checksum
Code:
md5sum `find . -type f`

buddy
03/08/2016, 11h35
winmerge peut comparer des centaines de fichiers à la fois et t'indiquer uniquement ceux qui ont des différences. si il y en a des dizaines et des dizaines ce ne doit pas être normal.

pour php .

une trouver au hasard parmi tant d'autres qui liste tous les fichiers : http://www.phpascal.com/programmatio...epertoire.html

il faut tout stocker dans un tableau et regarder la date : http://php.net/manual/fr/function.filemtime.php et ensuite les trier.

johnny57
03/08/2016, 11h22
Je pense passer à autre chose en effet, malheureusement ce n'est pas la priorité pour l'instant. Ma priorité est de rétablir le site hacké.

Comparer les 80.000 fichiers de ce site à la main avec winmerge n'est pas possible.

Pour le tri des fichiers j'ai trouvé find en SSH mais impossible, trop de fichiers concernés je ne peux donc tous les lire à l'écran. En version php je n'ai rien trouvé qui me liste tous les fichiers d'un répertoire et des sous répertoires.

buddy
03/08/2016, 11h11
pour PHP et la tri des fichiers dans date, il y en a plein sur le net.

Sinon tu télécharge winmerge et tu compares les fichiers php de prestashop actuels avec ceux de tes sauvegardes / backups.

mais il faut garder à l'esprit que la release 3 est en fin de vie et qu'il va falloir passer à autre chose. Virtualmin + debian par exemple.

johnny57
03/08/2016, 10h55
Le module a été supprimé, il ne servait pas. Je viens de me rendre compte d'un truc. Les date et heure de création de ces fichiers correspondent à la seconde à l'heure à laquelle j'ai regénéré le htaccess de prestashop parce que j'ai des bizarerie dans l'affichage coté front office. C'est la 2ème fois que je constate ce genre d'ajout de fichier pendant que je suis en train de faire des manip. Comme si un fichier presta avait été corrompu pour y ajouter du code qui ferait ces ajouts de fichiers. Je pensais les avoir tous supprimés ou restauré, je recommence donc tout à 0.

Une solution pour lister via un script php par exemple les fichiers par ordre de dates décroissante ?

buddy
03/08/2016, 10h45
Le serveur semble compromis plus largement ...

Il faudrait le réinstaller et vérifier que prestashop et le module sont bien dans leur dernière version est à jour. et si oui, faire remonter la faille au créateur du module et le désactiver entre temps ...

johnny57
03/08/2016, 10h30
J'ai vérifié la liste des cronjob qui est très longue, je n'ai rien vu de suspect. Je sais que WSO a été installé et que ça permet beaucoup de choses, mais je n'en sait pas plus. Il y a eu un accès autorisé et plusieurs bloqués par un système de sécurité que j'ai installé sur le serveur. Je suis en train de supprimer d'ailleurs à l'instant même une série de fichiers ajoutés hier soir.

buddy
03/08/2016, 10h07
La release 3 d ovh déjà utilise une version abandonnée de php... Je conseille de partir sur autre chose... Debian avec virtualmin par exemple.

Si il a eu accès au serveur avec le hack il peut avoir installé un accès ssl ou un cron qui récupère ses fichiers..

johnny57
03/08/2016, 10h00
Ben j'ai supprimé tous les fichiers qui avaient été ajoutés sur le serveur. Les logs apache ne montrent aucun appel de fichier précédent la création de celui qui apparaîtrait. Je n vois donc pas où aurait pu être posé un backdoors pour qu'apache ne log pas l'accès.

release 3 d'ovh (centos 6) parfaitement à jour
php 5.3.3
presta est en 1.6, je précise que ce n'est pas prestashop en lui même qui a été visé mais un module tiers.

buddy
03/08/2016, 09h49
Il a pu laisser des backdoors la première fois.

Quelle est la distribution ?
Est elle bien à jour ?
Quelle est la version de php qui tourne ?

Quelle est la version de prestashop ?

johnny57
02/08/2016, 22h34
Bonjour,

J'ai découvert que le 14/07 au matin une faille d'un module prestashop a été exploitée pour ajouter un fichier sur le serveur qui a ensuite fait des petits :

201.76.44.161 - - [14/Jul/2016:04:48:54 +0200] "GET ///modules//homepageadvertise2/slides/hous.php?up=shell?up=shell HTTP/1.0" 404 144542 "-" "-"
201.76.44.161 - - [14/Jul/2016:04:48:56 +0200] "POST //modules/productpageadverts//uploadimage.php HTTP/1.1" 302 - "-" "curl/7.49.1"
201.76.44.161 - - [14/Jul/2016:04:48:57 +0200] "GET ///modules/productpageadverts//slides/hous.php?up=shell HTTP/1.0" 302 - "-" "-"
201.76.44.161 - - [14/Jul/2016:04:48:57 +0200] "GET ///modules/productpageadverts//slides/hous.php?up=shell?up=shell HTTP/1.0" 404 144542 "-" "-"
201.76.44.161 - - [14/Jul/2016:04:48:58 +0200] "POST //modules/homepageadvertise//uploadimage.php HTTP/1.1" 302 - "-" "curl/7.49.1"
201.76.44.161 - - [14/Jul/2016:04:48:59 +0200] "GET ///modules/homepageadvertise//slides/hous.php?up=shell HTTP/1.0" 302 - "-" "-"
201.76.44.161 - - [14/Jul/2016:04:49:00 +0200] "GET ///modules/homepageadvertise//slides/hous.php?up=shell?up=shell HTTP/1.0" 404 144541 "-" "-"
201.76.44.161 - - [14/Jul/2016:04:49:01 +0200] "POST //modules/jro_homepageadvertise//uploadimage.php HTTP/1.1" 302 - "-" "curl/7.49.1"
201.76.44.161 - - [14/Jul/2016:04:49:02 +0200] "GET ///modules/jro_homepageadvertise//slides/hous.php?up=shell HTTP/1.0" 302 - "-" "-"
201.76.44.161 - - [14/Jul/2016:04:49:03 +0200] "GET ///modules/jro_homepageadvertise//slides/hous.php?up=shell?up=shell HTTP/1.0" 404 144545 "-" "-"
201.76.44.161 - - [14/Jul/2016:04:49:04 +0200] "POST //modules/attributewizardpro//file_upload.php HTTP/1.1" 302 - "-" "curl/7.49.1"
201.76.44.161 - - [14/Jul/2016:04:49:05 +0200] "POST //modules/attributewizardpro.OLD//file_upload.php HTTP/1.1" 302 - "-" "curl/7.49.1"
201.76.44.161 - - [14/Jul/2016:04:49:06 +0200] "POST //modules//advancedslider/ajax_advancedsliderUpload.php?action=submitUploadI mage%26id_slide=php HTTP/1.1" 302 - "-" "curl/7.49.1"
201.76.44.161 - - [14/Jul/2016:04:49:07 +0200] "POST //modules/cartabandonmentpro/upload.php HTTP/1.1" 200 12 "-" "curl/7.49.1"
201.76.44.161 - - [14/Jul/2016:04:49:08 +0200] "POST //modules//videostab/ajax_videostab.php?action=submitUploadVideo%26id_p roduct=upload HTTP/1.1" 302 - "-" "curl/7.49.1"
54.173.140.170 - - [14/Jul/2016:04:49:08 +0200] "GET /appareillage-composable-entree-de-gamme/65417-odace-detect-tt-charg-blc-3606480319488-produit.html?codesf=4422890239 HTTP/1.1" 200 32874 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.130 Safari/537.36"
201.76.44.161 - - [14/Jul/2016:04:49:09 +0200] "GET ///modules//advancedslider/uploads/hous.php.png?up=shell HTTP/1.0" 302 - "-" "-"
201.76.44.161 - - [14/Jul/2016:04:49:10 +0200] "GET ///modules//advancedslider/uploads/hous.php.png?up=shell?up=shell HTTP/1.0" 404 1041 "-" "-"
201.76.44.161 - - [14/Jul/2016:04:49:10 +0200] "GET ///modules//cartabandonmentpro/uploads/hous.php.png?up=shell HTTP/1.0" 200 32 "-" "-"
201.76.44.161 - - [14/Jul/2016:04:49:11 +0200] "GET ///modules//videostab/uploads/hous.php.mp4?up=shell HTTP/1.0" 302 - "-" "-"
201.76.44.161 - - [14/Jul/2016:04:49:12 +0200] "GET ///modules//videostab/uploads/hous.php.mp4?up=shell?up=shell HTTP/1.0" 404 144538 "-" "-"
201.76.44.161 - - [14/Jul/2016:04:49:13 +0200] "GET ///modules/up.php HTTP/1.0" 200 39 "-" "-"
à partir de là de multiples fichiers ont été créés. Je les ai tous repérés et effacés. Depuis, un fichier a réapparu mais sans que je puisse comprendre comment il a été créé. Dans les logs apache il n'y a pas d'appel d'un fichier qui aurait pu le créer. Le serveur ftp du serveur est désactivé, je n'utilise que la connexion sftp pour me connecter moi même quand j'en ai besoin.

Une idée de comment je pourrai retrouver la trace d'entrée ?