Redireccionar ip atacante

umax · 27 May 2016

Hola!!

Alguien sabe algún método para redireccionar una ip que no para de tocar los cojones en el servidor? he bloqueado de forma manual la ip desde iptables, csf pero no hay manera. sigue con el ataque y me deja sin servicio por minutos.

PHP:

 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:114.79.183.153:33697 TIME_WAIT   -    <--- ip atacante
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:114.79.183.153:33968 TIME_WAIT   -                   
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:114.79.183.153:44780 TIME_WAIT   -                   
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:114.79.183.153:34190 TIME_WAIT   -                   
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:114.79.183.153:33838 TIME_WAIT   -                   
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:114.79.183.153:45713 ESTABLISHED 14232/httpd

Lo que quiero hacer es redireccionar dicha ip fuera de mi vps. gracias

saludos

Noname · 27 May 2016

Con iptables puedes hacerlo teniendo el ip_forward activado. Tan solo busca en google "iptables redirect ip" o en español "iptables redireccionar ip". :encouragement:

SnAFKe · 27 May 2016

Si es el mismo rango de IPs pues bloquea 114.79.183.0/24 o por dominio usando wildcard *.dvois.com caso extremo bloquea el país india.

clouding · 27 May 2016

A ver, con IP tables la línea sería tipo:

iptables -I INPUT -s 114.79.183.153 -j DROP

Con esto lo tendrías solucionado, pero me parece raro que la otra IP que sale sea la 127.0.0.1 que es el loopback ¿? Es decir, esa IP te esta intentando conectar al loopback en el 7080 ¿? Eso no tiene mucho sentido... Estás seguro que esa es la IP que te está atacando?

En cuanto a redireccionarla, solo agregas carga a tu servidor, lo mejor es hacer un DROP, porque sino el remedio es peor que la enfermedad...

Un saludo!

ceibanet · 27 May 2016

el ip redirect es perfecto, envialo a google y veremos que tan bien le va con ese ataque. Puede que todavia te haga un poco de carga en el servidor pero mucho menos que lo que te esta causando ahora.

iwantvps · 27 May 2016

Como te han comentado estimado hasle DROP y jamas volvera a molestar ese IP 🙂

estudiseno · 28 May 2016

Esa no será la ip de tu vps...? Usada por nginx como proxy a Apache....

umax · 28 May 2016

estudiseno dijo:
Esa no será la ip de tu vps...? Usada por nginx como proxy a Apache....

No, no lo es

- - - Actualizado - - -

clouding dijo:
A ver, con IP tables la línea sería tipo:

iptables -I INPUT -s 114.79.183.153 -j DROP

Con esto lo tendrías solucionado, pero me parece raro que la otra IP que sale sea la 127.0.0.1 que es el loopback ¿? Es decir, esa IP te esta intentando conectar al loopback en el 7080 ¿? Eso no tiene mucho sentido... Estás seguro que esa es la IP que te está atacando?

En cuanto a redireccionarla, solo agregas carga a tu servidor, lo mejor es hacer un DROP, porque sino el remedio es peor que la enfermedad...

Un saludo!

Te explico, por razones de seguridad no voy a indicar la ip real de mi vps, interpreto ip 127.0.0.1, he probado en asignar la regla que indicas iptables -I INPUT -s 164.132.238.24 -j DROP y ambas ip desde csf -d 164.132.103.24 pero sigue igual con el ataque.

El VPS lo tengo alojado en OVH y es vergonzoso que clientes de la misma plataforma me estén atacando mi propio vps, ya me puse en contacto con ellos vía teléfono, email abuse me están dando largas, se tiran la pelota uno al otro y sin solución.

Aquí ip reales de los atacantes:

PHP:

 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33514 CLOSE_WAIT  30748/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50000 CLOSE_WAIT  30238/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33449 CLOSE_WAIT  30681/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50732 ESTABLISHED -                   
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50653 ESTABLISHED 30968/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50702 ESTABLISHED 31019/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33688 ESTABLISHED 30928/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33466 CLOSE_WAIT  30698/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33629 CLOSE_WAIT  30869/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33379 CLOSE_WAIT  30609/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33361 CLOSE_WAIT  30591/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33784 ESTABLISHED 31026/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50069 CLOSE_WAIT  30172/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50727 ESTABLISHED 31043/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50650 ESTABLISHED 30965/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33496 CLOSE_WAIT  30729/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33542 ESTABLISHED 30776/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33633 CLOSE_WAIT  30873/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50136 CLOSE_WAIT  30477/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33369 CLOSE_WAIT  30599/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33730 ESTABLISHED 30970/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33568 CLOSE_WAIT  30803/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50621 CLOSE_WAIT  30936/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33630 CLOSE_WAIT  30870/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33775 ESTABLISHED 31017/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33687 ESTABLISHED 30927/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33353 CLOSE_WAIT  30583/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33337 CLOSE_WAIT  30567/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50293 CLOSE_WAIT  30598/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50629 ESTABLISHED 30944/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50178 TIME_WAIT   -                   
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33644 CLOSE_WAIT  30884/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50692 ESTABLISHED 31009/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33550 CLOSE_WAIT  30785/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33419 CLOSE_WAIT  30651/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50281 CLOSE_WAIT  30586/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33632 CLOSE_WAIT  30872/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33677 CLOSE_WAIT  30917/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50706 ESTABLISHED 31023/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50256 CLOSE_WAIT  30561/httpd

Tengo el firewall CSF me envia notificación por correo electrónico, fichero llamado netstat.txt y dentro del mismo lo que indico más arriba abreviado.

No se que tipo de ataque están utilizando, pero consiguen dejar durante media hora o más la maquina off con subidas de cpu a full

Saludos

estudiseno · 28 May 2016

Estrés al puerto 80... nginx delante o varnish y mitigas con eso

- - - Actualizado - - -

umax dijo:

No, no lo es

- - - Actualizado - - -

Te explico, por razones de seguridad no voy a indicar la ip real de mi vps, interpreto ip 127.0.0.1, he probado en asignar la regla que indicas iptables -I INPUT -s 164.132.238.24 -j DROP y ambas ip desde csf -d 164.132.103.24 pero sigue igual con el ataque.

El VPS lo tengo alojado en OVH y es vergonzoso que clientes de la misma plataforma me estén atacando mi propio vps, ya me puse en contacto con ellos vía teléfono, email abuse me están dando largas, se tiran la pelota uno al otro y sin solución.

Aquí ip reales de los atacantes:

PHP:

 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33514 CLOSE_WAIT  30748/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50000 CLOSE_WAIT  30238/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33449 CLOSE_WAIT  30681/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50732 ESTABLISHED -                   
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50653 ESTABLISHED 30968/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50702 ESTABLISHED 31019/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33688 ESTABLISHED 30928/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33466 CLOSE_WAIT  30698/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33629 CLOSE_WAIT  30869/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33379 CLOSE_WAIT  30609/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33361 CLOSE_WAIT  30591/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33784 ESTABLISHED 31026/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50069 CLOSE_WAIT  30172/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50727 ESTABLISHED 31043/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50650 ESTABLISHED 30965/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33496 CLOSE_WAIT  30729/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33542 ESTABLISHED 30776/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33633 CLOSE_WAIT  30873/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50136 CLOSE_WAIT  30477/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33369 CLOSE_WAIT  30599/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33730 ESTABLISHED 30970/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33568 CLOSE_WAIT  30803/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50621 CLOSE_WAIT  30936/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33630 CLOSE_WAIT  30870/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33775 ESTABLISHED 31017/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33687 ESTABLISHED 30927/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33353 CLOSE_WAIT  30583/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33337 CLOSE_WAIT  30567/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50293 CLOSE_WAIT  30598/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50629 ESTABLISHED 30944/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50178 TIME_WAIT   -                   
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33644 CLOSE_WAIT  30884/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50692 ESTABLISHED 31009/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33550 CLOSE_WAIT  30785/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33419 CLOSE_WAIT  30651/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50281 CLOSE_WAIT  30586/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33632 CLOSE_WAIT  30872/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.238.24:33677 CLOSE_WAIT  30917/httpd         
 tcp        0      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50706 ESTABLISHED 31023/httpd         
 tcp        1      0 ::ffff:127.0.0.1:7080 ::ffff:164.132.103.24:50256 CLOSE_WAIT  30561/httpd

Tengo el firewall CSF me envia notificación por correo electrónico, fichero llamado netstat.txt y dentro del mismo lo que indico más arriba abreviado.

No se que tipo de ataque están utilizando, pero consiguen dejar durante media hora o más la maquina off con subidas de cpu a full

Saludos

Prueba añadiendo esto a tu htaccess

Insertar CODE, HTML o PHP:

Order Deny,Allow
Deny from 164.132.238
Deny from 164.132.103

clouding · 28 May 2016

Hola,

Ten presente que poner una norma en iptables no cierra las conexiones abiertas, es decir, tienen que expirar. Y según como tengas el kernel configurado pueden tardar una varbaridad (El expire para TCPs en linux por defecto es realmente alto, de casi una semana diría).

Tienes que cambiar el valor:

net.netfilter.nf_conntrack_tcp_timeout_established

Puedes hacerlo con el sysctl, de memoría diría que es:

sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=7440

Ese es un valor más normal, rollo un par de horas y pico que es lo recomendado. También lo puedes bajar a p.e. 10 minutos poniéndolo a 600 y cuando veas que ya se han cerrado las conexiones ponerlo a 7440 que es un valor más normal.

Otra posibilidad es que te esté llegando por IPv6, cosa que dentro de ovh podría ser que tengan un backbone ipv6 y te llegue por ahí. En ese caso la norma que te he enviado no sirve porque es para IPv4 no IPv6.

En ese caso, solo tienes que usar el ip6tables de comando y poner la ip con el ffff tal y como te sale en el netstat, es decir:

ip6tables -I INPUT -s ::ffff:164.132.238.24 -j DROP

Aunque en ese caso la conexión tendría que salir listada como tcp6 y no como tcp, pero dependerá del comando que uses para el output supongo.

Un saludo!

Pompinchu · 29 May 2016

¿Dónde lo ves eso? Espero puedas solucionarlo.

umax · 29 May 2016

clouding dijo:
Hola,

Ten presente que poner una norma en iptables no cierra las conexiones abiertas, es decir, tienen que expirar. Y según como tengas el kernel configurado pueden tardar una varbaridad (El expire para TCPs en linux por defecto es realmente alto, de casi una semana diría).

Tienes que cambiar el valor:

net.netfilter.nf_conntrack_tcp_timeout_established

Puedes hacerlo con el sysctl, de memoría diría que es:

sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=7440

Ese es un valor más normal, rollo un par de horas y pico que es lo recomendado. También lo puedes bajar a p.e. 10 minutos poniéndolo a 600 y cuando veas que ya se han cerrado las conexiones ponerlo a 7440 que es un valor más normal.

Otra posibilidad es que te esté llegando por IPv6, cosa que dentro de ovh podría ser que tengan un backbone ipv6 y te llegue por ahí. En ese caso la norma que te he enviado no sirve porque es para IPv4 no IPv6.

En ese caso, solo tienes que usar el ip6tables de comando y poner la ip con el ffff tal y como te sale en el netstat, es decir:

ip6tables -I INPUT -s ::ffff:164.132.238.24 -j DROP

Aunque en ese caso la conexión tendría que salir listada como tcp6 y no como tcp, pero dependerá del comando que uses para el output supongo.

Un saludo!

Hola,

Hoy día haciendo todo lo que se me ha indicado vuelvo con lo mismo siguen con el ataque, ni con iptables reglas asignadas tampoco con .htaccess ahora bien voy a probar lo que me indicas clouding agregar en el fichero sysctl lo indicado, referente a ip6tbales creo que no lo tengo en uso, no estoy seguro, ¿como puedo saberlo? de todas formas le asignare dicha regla ip6tables, cuando dices (podría ser que tengan un backbone ipv6) a que te refieres? esto no se que es... soy algo novatillo jejeje gracias por toda la información que me estas brindando.

Un saludo

- - - Actualizado - - -

Pompinchu dijo:
¿Dónde lo ves eso? Espero puedas solucionarlo.

donde veo el que???

- - - Actualizado - - -

estudiseno dijo:
Estrés al puerto 80... nginx delante o varnish y mitigas con eso

- - - Actualizado - - -

Prueba añadiendo esto a tu htaccess

Insertar CODE, HTML o PHP:

Order Deny,Allow Deny from 164.132.238 Deny from 164.132.103

Tampoco funciona, gracias

estudiseno · 29 May 2016

Pues contrata un sysadmin. Por que sacar conclusiones sin ver con nuestros propios ojos el problema... es difícil.

Saludos.

umax · 29 May 2016

estudiseno dijo:
Pues contrata un sysadmin. Por que sacar conclusiones sin ver con nuestros propios ojos el problema... es difícil.

Saludos.

Prefiero hacerlo con ayuda y aprender de otros, no solo esta la solución por un sysadmin, dime que necesitas ver más? para aportarlo 🙂

iwantvps · 29 May 2016

umax dijo:
Prefiero hacerlo con ayuda y aprender de otros, no solo esta la solución por un sysadmin, dime que necesitas ver más? para aportarlo 🙂

Amigo con lo que se te ha dicho + suponiendo hayas buscado en google y aun no solucionas mejor contrata aguien te mire el FW porque no esta bloqueando como debiera saludos

SnAFKe · 29 May 2016

Insertar CODE, HTML o PHP:

perl /etc/csf/csftest.pl

umax · 30 May 2016

SnAFKe dijo:
Insertar CODE, HTML o PHP:

perl /etc/csf/csftest.pl

PHP:

[root@vps ~]# perl /etc/csf/csftest.pl
Testing ip_tables/iptable_filter...OK
Testing ipt_LOG...OK
Testing ipt_multiport/xt_multiport...OK
Testing ipt_REJECT...OK
Testing ipt_state/xt_state...OK
Testing ipt_limit/xt_limit...OK
Testing ipt_recent...OK
Testing xt_connlimit...OK
Testing ipt_owner/xt_owner...OK
Testing iptable_nat/ipt_REDIRECT...OK
Testing iptable_nat/ipt_DNAT...OK

RESULT: csf should function on this server
[root@vps ~]#

SnAFKe · 30 May 2016

Insertar CODE, HTML o PHP:

netstat -n | grep :80 |wc -l

500 > bad

Insertar CODE, HTML o PHP:

netstat -n | grep :80 | grep SYN |wc -l

100 > bad

Insertar CODE, HTML o PHP:

netstat -anp |grep 'tcp\|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

umax · 11 Jun 2016

Ya esta solucionado al parecer clouding, tenia la solución iba bien encaminado respecto a lo indicado IPv6, fue inhabilitar ipv6 sysctl.conf agregando:

PHP:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1

problema resuelto 🙂

MUCHAS GRACIAS

Redireccionar ip atacante

umax

Noname

SnAFKe

clouding

ceibanet

iwantvps

estudiseno

umax

estudiseno

clouding

Pompinchu

umax

estudiseno

umax

iwantvps

SnAFKe

umax

SnAFKe

umax