> Si j'ai bien lu tu laisses passer le trafic MySQL pour tout le monde avant de logger.
Oui, en effet. Ce n’est peut être pas une bonne chose, mais est-ce
qu’on n’est pas obligé de faire comme ça de toute façon pour accéder
aux données des sites sur le port 80 ? Je n’en sais fichtre rien !
> Si j'ai bien lu tu laisses passer le trafic MySQL pour tout le monde avant de logger.
Oui, en effet. Ce n’est peut être pas une bonne chose, mais est-ce
qu’on n’est pas obligé de faire comme ça de toute façon pour accéder
aux données des sites sur le port 80 ? Je n’en sais fichtre rien !
> Si j'ai bien lu tu laisses passer le trafic MySQL pour tout le monde avant de logger.
Oui, en effet. Ce n’est peut être pas une bonne chose, mais est-ce
qu’on n’est pas obligé de faire comme ça de toute façon pour accéder
aux données des sites sur le port 80 ? Je n’en sais fichtre rien !
Le 20/06/2015 12:31, Samuel a écrit :iptables -A INPUT -d 5.135.191.38 -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.' -j DROP
Ce genre de test sur du contenu, je le mettrais plutôt une fois que tout le reste marche.
Pour faire une parenthèse :
D'autres me reprendront si je me trompe, mais ce genre de traitement de contenu n'est pas recommandé avec netfilter.
Par exemple ta commande empêchera d'envoyer via webmail un email avec le texte 'matché.
Il vaut mieux travailler au niveau applicatif avec par exemple (pour ton exemple du port 80) un module apache : modsecurity ou même les rewriterules du module 'rewrite' d'apache qui collent à ton besoin.
Mais c'est un autre travail
Samuel.
--
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: https://lists.debian.org/
Le 20/06/2015 12:31, Samuel a écrit :
iptables -A INPUT -d 5.135.191.38 -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.' -j DROP
Ce genre de test sur du contenu, je le mettrais plutôt une fois que tout le reste marche.
Pour faire une parenthèse :
D'autres me reprendront si je me trompe, mais ce genre de traitement de contenu n'est pas recommandé avec netfilter.
Par exemple ta commande empêchera d'envoyer via webmail un email avec le texte 'matché.
Il vaut mieux travailler au niveau applicatif avec par exemple (pour ton exemple du port 80) un module apache : modsecurity ou même les rewriterules du module 'rewrite' d'apache qui collent à ton besoin.
Mais c'est un autre travail
Samuel.
--
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: https://lists.debian.org/558557CB.3050001@ingescom.com
Le 20/06/2015 12:31, Samuel a écrit :iptables -A INPUT -d 5.135.191.38 -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.' -j DROP
Ce genre de test sur du contenu, je le mettrais plutôt une fois que tout le reste marche.
Pour faire une parenthèse :
D'autres me reprendront si je me trompe, mais ce genre de traitement de contenu n'est pas recommandé avec netfilter.
Par exemple ta commande empêchera d'envoyer via webmail un email avec le texte 'matché.
Il vaut mieux travailler au niveau applicatif avec par exemple (pour ton exemple du port 80) un module apache : modsecurity ou même les rewriterules du module 'rewrite' d'apache qui collent à ton besoin.
Mais c'est un autre travail
Samuel.
--
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: https://lists.debian.org/
Le 20/06/2015 12:31, Samuel a écrit :Le 20/06/2015 12:02, Philippe Gras a écrit :
Jai modifié le script qui établit les règles un peu tous les jours pour essayer de résoudre ce problème, alors
il est possible que je me sois mélangé les pinceaux.
Je vous lai mis sous la même url pour que vous puissiez deviner la chronologie des versions, parce que jai
commenté les versions précédentes et ne les ai pas écrasées.
En regardant vite fait :
iptables -A INPUT -p tcp --dport 80 -s 54.77.203.73 -j DROP
iptables -A INPUT -p tcp --dport 80 -s 162.158.68.167 -j REJECT --reject-with icmp-port-unreachable
Comme discuté ici-même je crois, faut regrouper (pour la lisibilité) et rester sur du REJECT, pas DROP :
iptables -A INPUT -p tcp --dport 80 -s 54.77.203.73,162.158.68.167 -j REJECT
----------
iptables -A INPUT -d 5.135.191.38 -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.' -j DROP
Ce genre de test sur du contenu, je le mettrais plutôt une fois que tout le reste marche.
-----------
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT
C'est un peu large comme accès, je mettrais plutôt du genre (exemple sur une chaine FORWARD à compléter selon besoins ):
iptables -A FORWARD -i $lan -o $fai -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type destination-unreachable -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type time-exceeded -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type parameter-problem -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type fragmentation-needed -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type source-quench -j ACCEPT
--------------
As-tu vraiment un DNS public ? :
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT
Je n'ai pas regardé en détail, juste vite fait.
Il faut reprendre à zéro ça sera plus simple en fonction de tes besoins et réécrire chaque règle en suivant la règle :
1) politique par défaut en DROP
2) on ACCEPT au cas par cas en sécurisant au maximum
3) On REJECT tout le reste avec éventuellement des logs.
Il ne faut pas oublier de glisser en 1bis) les règles pour bloquer les ennuyeux (sur des ports ouverts) comme j'ai pu le voir :
1) politique par défaut en DROP
1bis) iptables -A INPUT -p tcp --dport 80 -s 54.77.203.73,162.158.68.167 -j REJECT
2) on ACCEPT au cas par cas en sécurisant au maximum
3) On REJECT tout le reste avec éventuellement des logs.
Samuel.
Le 20/06/2015 12:31, Samuel a écrit :
Le 20/06/2015 12:02, Philippe Gras a écrit :
Jai modifié le script qui établit les règles un peu tous les jours pour essayer de résoudre ce problème, alors
il est possible que je me sois mélangé les pinceaux.
Je vous lai mis sous la même url pour que vous puissiez deviner la chronologie des versions, parce que jai
commenté les versions précédentes et ne les ai pas écrasées.
En regardant vite fait :
iptables -A INPUT -p tcp --dport 80 -s 54.77.203.73 -j DROP
iptables -A INPUT -p tcp --dport 80 -s 162.158.68.167 -j REJECT --reject-with icmp-port-unreachable
Comme discuté ici-même je crois, faut regrouper (pour la lisibilité) et rester sur du REJECT, pas DROP :
iptables -A INPUT -p tcp --dport 80 -s 54.77.203.73,162.158.68.167 -j REJECT
----------
iptables -A INPUT -d 5.135.191.38 -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.' -j DROP
Ce genre de test sur du contenu, je le mettrais plutôt une fois que tout le reste marche.
-----------
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT
C'est un peu large comme accès, je mettrais plutôt du genre (exemple sur une chaine FORWARD à compléter selon besoins ):
iptables -A FORWARD -i $lan -o $fai -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type destination-unreachable -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type time-exceeded -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type parameter-problem -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type fragmentation-needed -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type source-quench -j ACCEPT
--------------
As-tu vraiment un DNS public ? :
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT
Je n'ai pas regardé en détail, juste vite fait.
Il faut reprendre à zéro ça sera plus simple en fonction de tes besoins et réécrire chaque règle en suivant la règle :
1) politique par défaut en DROP
2) on ACCEPT au cas par cas en sécurisant au maximum
3) On REJECT tout le reste avec éventuellement des logs.
Il ne faut pas oublier de glisser en 1bis) les règles pour bloquer les ennuyeux (sur des ports ouverts) comme j'ai pu le voir :
1) politique par défaut en DROP
1bis) iptables -A INPUT -p tcp --dport 80 -s 54.77.203.73,162.158.68.167 -j REJECT
2) on ACCEPT au cas par cas en sécurisant au maximum
3) On REJECT tout le reste avec éventuellement des logs.
Samuel.
Le 20/06/2015 12:31, Samuel a écrit :Le 20/06/2015 12:02, Philippe Gras a écrit :
Jai modifié le script qui établit les règles un peu tous les jours pour essayer de résoudre ce problème, alors
il est possible que je me sois mélangé les pinceaux.
Je vous lai mis sous la même url pour que vous puissiez deviner la chronologie des versions, parce que jai
commenté les versions précédentes et ne les ai pas écrasées.
En regardant vite fait :
iptables -A INPUT -p tcp --dport 80 -s 54.77.203.73 -j DROP
iptables -A INPUT -p tcp --dport 80 -s 162.158.68.167 -j REJECT --reject-with icmp-port-unreachable
Comme discuté ici-même je crois, faut regrouper (pour la lisibilité) et rester sur du REJECT, pas DROP :
iptables -A INPUT -p tcp --dport 80 -s 54.77.203.73,162.158.68.167 -j REJECT
----------
iptables -A INPUT -d 5.135.191.38 -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.' -j DROP
Ce genre de test sur du contenu, je le mettrais plutôt une fois que tout le reste marche.
-----------
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT
C'est un peu large comme accès, je mettrais plutôt du genre (exemple sur une chaine FORWARD à compléter selon besoins ):
iptables -A FORWARD -i $lan -o $fai -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type destination-unreachable -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type time-exceeded -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type parameter-problem -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type fragmentation-needed -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type source-quench -j ACCEPT
--------------
As-tu vraiment un DNS public ? :
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT
Je n'ai pas regardé en détail, juste vite fait.
Il faut reprendre à zéro ça sera plus simple en fonction de tes besoins et réécrire chaque règle en suivant la règle :
1) politique par défaut en DROP
2) on ACCEPT au cas par cas en sécurisant au maximum
3) On REJECT tout le reste avec éventuellement des logs.
Il ne faut pas oublier de glisser en 1bis) les règles pour bloquer les ennuyeux (sur des ports ouverts) comme j'ai pu le voir :
1) politique par défaut en DROP
1bis) iptables -A INPUT -p tcp --dport 80 -s 54.77.203.73,162.158.68.167 -j REJECT
2) on ACCEPT au cas par cas en sécurisant au maximum
3) On REJECT tout le reste avec éventuellement des logs.
Samuel.
Le 20 juin 2015 à 13:04, Samuel a écrit :Le 20/06/2015 12:31, Samuel a écrit :Le 20/06/2015 12:02, Philippe Gras a écrit :iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT
C'est un peu large comme accès, je mettrais plutôt du genre (exemple sur une chaine FORWARD à compléter selon besoins ):
iptables -A FORWARD -i $lan -o $fai -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type destination-unreachable -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type time-exceeded -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type parameter-problem -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type fragmentation-needed -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type source-quench -j ACCEPT
Merci pour cette suggestion qui me semble très intéressante… Je vais creuser ce qu’est le ICMP et le LAN avant,
parce que je n’ai pas encore bien compris de quoi il s’agissait.
Le 20 juin 2015 à 13:04, Samuel <debian-user-french-2010@ingescom.com> a écrit :
Le 20/06/2015 12:31, Samuel a écrit :
Le 20/06/2015 12:02, Philippe Gras a écrit :
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT
C'est un peu large comme accès, je mettrais plutôt du genre (exemple sur une chaine FORWARD à compléter selon besoins ):
iptables -A FORWARD -i $lan -o $fai -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type destination-unreachable -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type time-exceeded -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type parameter-problem -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type fragmentation-needed -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type source-quench -j ACCEPT
Merci pour cette suggestion qui me semble très intéressante… Je vais creuser ce qu’est le ICMP et le LAN avant,
parce que je n’ai pas encore bien compris de quoi il s’agissait.
Le 20 juin 2015 à 13:04, Samuel a écrit :Le 20/06/2015 12:31, Samuel a écrit :Le 20/06/2015 12:02, Philippe Gras a écrit :iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT
C'est un peu large comme accès, je mettrais plutôt du genre (exemple sur une chaine FORWARD à compléter selon besoins ):
iptables -A FORWARD -i $lan -o $fai -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type destination-unreachable -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type time-exceeded -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type parameter-problem -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type fragmentation-needed -j ACCEPT
iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type source-quench -j ACCEPT
Merci pour cette suggestion qui me semble très intéressante… Je vais creuser ce qu’est le ICMP et le LAN avant,
parce que je n’ai pas encore bien compris de quoi il s’agissait.
Bonjour,
Le samedi 20 juin 2015, Philippe Gras a écrit...Si j'ai bien lu tu laisses passer le trafic MySQL pour tout le monde avant de logger.Oui, en effet. Ce nest peut être pas une bonne chose, mais est-ce
quon nest pas obligé de faire comme ça de toute façon pour accéder
aux données des sites sur le port 80 ? Je nen sais fichtre rien !
Normalement, par défaut (il me semble), MySQL n'écoute que sur l'adresse
locale. Tu aurais modifié la configuration ?
Car, si ton serveur MySQL, et ton serveur ouèbe sont sur la même
machine, alors les sites ouèbe doivent être "configurés" pour accéder au
serveur sql sur localhost et tu n'as nul besoin d'avoir une écoute sur
une interface publique.
De plus, MySQL, au niveau de ses droits d'accès, peut se paramétrer pour
restreindre les accès des clients distants (colonne Host de la table
mysql.user).
Tu as donc 3 niveaux de blocage possible, en fonction de tes besoins :
- la conf du serveur /etc/mysql/my.cnf
- les droits d'accès sur le serveur
- iptables
--
jm
--
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: https://lists.debian.org/
Bonjour,
Le samedi 20 juin 2015, Philippe Gras a écrit...
Si j'ai bien lu tu laisses passer le trafic MySQL pour tout le monde avant de logger.
Oui, en effet. Ce nest peut être pas une bonne chose, mais est-ce
quon nest pas obligé de faire comme ça de toute façon pour accéder
aux données des sites sur le port 80 ? Je nen sais fichtre rien !
Normalement, par défaut (il me semble), MySQL n'écoute que sur l'adresse
locale. Tu aurais modifié la configuration ?
Car, si ton serveur MySQL, et ton serveur ouèbe sont sur la même
machine, alors les sites ouèbe doivent être "configurés" pour accéder au
serveur sql sur localhost et tu n'as nul besoin d'avoir une écoute sur
une interface publique.
De plus, MySQL, au niveau de ses droits d'accès, peut se paramétrer pour
restreindre les accès des clients distants (colonne Host de la table
mysql.user).
Tu as donc 3 niveaux de blocage possible, en fonction de tes besoins :
- la conf du serveur /etc/mysql/my.cnf
- les droits d'accès sur le serveur
- iptables
--
jm
--
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: https://lists.debian.org/20150620125311.GA5151@espinasse
Bonjour,
Le samedi 20 juin 2015, Philippe Gras a écrit...Si j'ai bien lu tu laisses passer le trafic MySQL pour tout le monde avant de logger.Oui, en effet. Ce nest peut être pas une bonne chose, mais est-ce
quon nest pas obligé de faire comme ça de toute façon pour accéder
aux données des sites sur le port 80 ? Je nen sais fichtre rien !
Normalement, par défaut (il me semble), MySQL n'écoute que sur l'adresse
locale. Tu aurais modifié la configuration ?
Car, si ton serveur MySQL, et ton serveur ouèbe sont sur la même
machine, alors les sites ouèbe doivent être "configurés" pour accéder au
serveur sql sur localhost et tu n'as nul besoin d'avoir une écoute sur
une interface publique.
De plus, MySQL, au niveau de ses droits d'accès, peut se paramétrer pour
restreindre les accès des clients distants (colonne Host de la table
mysql.user).
Tu as donc 3 niveaux de blocage possible, en fonction de tes besoins :
- la conf du serveur /etc/mysql/my.cnf
- les droits d'accès sur le serveur
- iptables
--
jm
--
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: https://lists.debian.org/
Whouah ! Génial. Donc, je peux dropper tout le monde à l’exception de
l’IP de mon serveur, de son IP locale (127.0.0.1) et de la plage IP
sur laquelle mon FAI m’envoie ?
> - les droits d'accès sur le serveur
De quel serveur parles-tu ? Le serveur Web (NginX) ?
Whouah ! Génial. Donc, je peux dropper tout le monde à l’exception de
l’IP de mon serveur, de son IP locale (127.0.0.1) et de la plage IP
sur laquelle mon FAI m’envoie ?
> - les droits d'accès sur le serveur
De quel serveur parles-tu ? Le serveur Web (NginX) ?
Whouah ! Génial. Donc, je peux dropper tout le monde à l’exception de
l’IP de mon serveur, de son IP locale (127.0.0.1) et de la plage IP
sur laquelle mon FAI m’envoie ?
> - les droits d'accès sur le serveur
De quel serveur parles-tu ? Le serveur Web (NginX) ?
Bonjour,
Le samedi 20 juin 2015, Philippe Gras a écrit...Whouah ! Génial. Donc, je peux dropper tout le monde à lexception de
lIP de mon serveur, de son IP locale (127.0.0.1) et de la plage IP
sur laquelle mon FAI menvoie ?
Je ne comprends pas trop ce que tu veux dire. Mais :
- Si le serveur sql et le serveur ouèbe (Nginx) sont sur la même
machine, tu mets le bind-address de mysql sur 127.0.0.1, et tu donnes
les grant de tes utilisateurs de tes sites ouèbe sur
Et tu peux dropper tout le monde. Ce qui ne devrait même pas, en
théorie, être nécessaire puisque l'accès n'est pas autorisé. Mais qui
va soulager le serveur sql.
- Si le serveur sql et le serveur ouèbe ne sont pas sur les même
machine, tu mets le bind-address sur l'ip publique, tes utilisateurs
sql sur , et tu droppes tout le monde sauf
le serveur ouèbe.
- Si, personnellement, tu veux accéder au serveur sql depuis une autre
machine (un autre client mysql en ligne de commande par ex.), il te
faut mettre le bind-address sur l'ip publique, et ouvrir pour l'ip de
ton client distant. Quoique dans ce cas, tu peux ouvrir une session
ssh et lancer le client mysql en local.
Je ne sais pas si j'ai été vraiment clair
- les droits d'accès sur le serveur
De quel serveur parles-tu ? Le serveur Web (NginX) ?
Du serveur MySQL. Vois la syntaxe de l'instruction GRANT de MySQL, qui
permet de renseigner les droits d'accès pour un utilisateur sur un hôte
client (et donc REVOKE également si tu as des GRANT dont tu veux te
débarrasser).
--
jm
--
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: https://lists.debian.org/
Bonjour,
Le samedi 20 juin 2015, Philippe Gras a écrit...
Whouah ! Génial. Donc, je peux dropper tout le monde à lexception de
lIP de mon serveur, de son IP locale (127.0.0.1) et de la plage IP
sur laquelle mon FAI menvoie ?
Je ne comprends pas trop ce que tu veux dire. Mais :
- Si le serveur sql et le serveur ouèbe (Nginx) sont sur la même
machine, tu mets le bind-address de mysql sur 127.0.0.1, et tu donnes
les grant de tes utilisateurs de tes sites ouèbe sur leUser@localhost.
Et tu peux dropper tout le monde. Ce qui ne devrait même pas, en
théorie, être nécessaire puisque l'accès n'est pas autorisé. Mais qui
va soulager le serveur sql.
- Si le serveur sql et le serveur ouèbe ne sont pas sur les même
machine, tu mets le bind-address sur l'ip publique, tes utilisateurs
sql sur leUser@ip-du-serveur-ouebe, et tu droppes tout le monde sauf
le serveur ouèbe.
- Si, personnellement, tu veux accéder au serveur sql depuis une autre
machine (un autre client mysql en ligne de commande par ex.), il te
faut mettre le bind-address sur l'ip publique, et ouvrir pour l'ip de
ton client distant. Quoique dans ce cas, tu peux ouvrir une session
ssh et lancer le client mysql en local.
Je ne sais pas si j'ai été vraiment clair
- les droits d'accès sur le serveur
De quel serveur parles-tu ? Le serveur Web (NginX) ?
Du serveur MySQL. Vois la syntaxe de l'instruction GRANT de MySQL, qui
permet de renseigner les droits d'accès pour un utilisateur sur un hôte
client (et donc REVOKE également si tu as des GRANT dont tu veux te
débarrasser).
--
jm
--
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: https://lists.debian.org/20150620200048.GB5151@espinasse
Bonjour,
Le samedi 20 juin 2015, Philippe Gras a écrit...Whouah ! Génial. Donc, je peux dropper tout le monde à lexception de
lIP de mon serveur, de son IP locale (127.0.0.1) et de la plage IP
sur laquelle mon FAI menvoie ?
Je ne comprends pas trop ce que tu veux dire. Mais :
- Si le serveur sql et le serveur ouèbe (Nginx) sont sur la même
machine, tu mets le bind-address de mysql sur 127.0.0.1, et tu donnes
les grant de tes utilisateurs de tes sites ouèbe sur
Et tu peux dropper tout le monde. Ce qui ne devrait même pas, en
théorie, être nécessaire puisque l'accès n'est pas autorisé. Mais qui
va soulager le serveur sql.
- Si le serveur sql et le serveur ouèbe ne sont pas sur les même
machine, tu mets le bind-address sur l'ip publique, tes utilisateurs
sql sur , et tu droppes tout le monde sauf
le serveur ouèbe.
- Si, personnellement, tu veux accéder au serveur sql depuis une autre
machine (un autre client mysql en ligne de commande par ex.), il te
faut mettre le bind-address sur l'ip publique, et ouvrir pour l'ip de
ton client distant. Quoique dans ce cas, tu peux ouvrir une session
ssh et lancer le client mysql en local.
Je ne sais pas si j'ai été vraiment clair
- les droits d'accès sur le serveur
De quel serveur parles-tu ? Le serveur Web (NginX) ?
Du serveur MySQL. Vois la syntaxe de l'instruction GRANT de MySQL, qui
permet de renseigner les droits d'accès pour un utilisateur sur un hôte
client (et donc REVOKE également si tu as des GRANT dont tu veux te
débarrasser).
--
jm
--
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: https://lists.debian.org/
- les droits d'accès sur le serveur
De quel serveur parles-tu ? Le serveur Web (NginX) ?
Du serveur MySQL. Vois la syntaxe de l'instruction GRANT de MySQL, qui
permet de renseigner les droits d'accès pour un utilisateur sur un hôte
client (et donc REVOKE également si tu as des GRANT dont tu veux te
débarrasser).
--
jm
--
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: https://lists.debian.org/
- les droits d'accès sur le serveur
De quel serveur parles-tu ? Le serveur Web (NginX) ?
Du serveur MySQL. Vois la syntaxe de l'instruction GRANT de MySQL, qui
permet de renseigner les droits d'accès pour un utilisateur sur un hôte
client (et donc REVOKE également si tu as des GRANT dont tu veux te
débarrasser).
--
jm
--
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: https://lists.debian.org/20150620200048.GB5151@espinasse
- les droits d'accès sur le serveur
De quel serveur parles-tu ? Le serveur Web (NginX) ?
Du serveur MySQL. Vois la syntaxe de l'instruction GRANT de MySQL, qui
permet de renseigner les droits d'accès pour un utilisateur sur un hôte
client (et donc REVOKE également si tu as des GRANT dont tu veux te
débarrasser).
--
jm
--
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: https://lists.debian.org/
Le 19/06/2015 16:31, Philippe Gras a écrit :Comment puis-je vérifier la configuration d'iptables ?
iptables -L -n
Le 19/06/2015 16:31, Philippe Gras a écrit :
Comment puis-je vérifier la configuration d'iptables ?
iptables -L -n
Le 19/06/2015 16:31, Philippe Gras a écrit :Comment puis-je vérifier la configuration d'iptables ?
iptables -L -n
ça fait un mois environ que j'ai des trucs comme ça avec netstat -antp :
-----------------------------------------------------------------------------------------------------------
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:36852 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:53921 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:56058 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:16231 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:30945 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 186.2.161.165:1675 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:58255 SYN_RECV -
-----------------------------------------------------------------------------------------------------------
D'après ce que je comprends, la requête aboutit sur un port lambda
et demande quelque chose sur celui de MySQL.
Le service tourne sur un socket
il n'y a rien dans la colonne du PID.
ça fait un mois environ que j'ai des trucs comme ça avec netstat -antp :
-----------------------------------------------------------------------------------------------------------
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:36852 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:53921 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:56058 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:16231 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:30945 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 186.2.161.165:1675 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:58255 SYN_RECV -
-----------------------------------------------------------------------------------------------------------
D'après ce que je comprends, la requête aboutit sur un port lambda
et demande quelque chose sur celui de MySQL.
Le service tourne sur un socket
il n'y a rien dans la colonne du PID.
ça fait un mois environ que j'ai des trucs comme ça avec netstat -antp :
-----------------------------------------------------------------------------------------------------------
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:36852 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:53921 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:56058 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:16231 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:30945 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 186.2.161.165:1675 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:58255 SYN_RECV -
-----------------------------------------------------------------------------------------------------------
D'après ce que je comprends, la requête aboutit sur un port lambda
et demande quelque chose sur celui de MySQL.
Le service tourne sur un socket
il n'y a rien dans la colonne du PID.
