Problemas com porta 80 TCP

thiagoofsaint
(usa Debian)

Enviado em 22/03/2017 - 10:02h

Olá pessoal!


Tenho um servidor Debian 6, com um link dedicado da vivo de 10MB. De sábado pra cá esse link começou a ficar lento. enu tento, por exemplo, fazer um teste de ping para o uol e ele dá varias perdas durante o ping. Dei uma olhada no monitor do sistema da interface grafica do Debian, e notei que quando isso acontece (as perdas com o ping) o histórico da rede começa a trafegar com mais de 400.0 Mbit por segundo. Dei uma olhada no IPTRAF na esperança de descobrir alguma coisa, e quando vou na opção Statistical breakdowns > by TCP UDP ports > a interface da placa de rede onde esta conectado o link de internet. Nessa opção, mostra a porta TCP 80 com pacotes imensos, e troca de pacote intensa, justamente no momento em que meu link fica lento. esse foi o maximo que consegui avançar pra descobrir o problema deste servidor. vou ficar imensamente grato se alguém puder me ajudar. De antemão, agradeço a todos.

Bruno_Cavalcanti
(usa CentOS)

Enviado em 22/03/2017 - 10:09h

Você tem algum site hospedado internamente?

se sim, cuidado, provavelmente você está sendo usado como zumbi de Phishing, em um momento mais calmo tenta parar teu servidor de site e ve se o trafego diminui.

thiagoofsaint
(usa Debian)

Enviado em 22/03/2017 - 10:21h

Oi Bruno.


Site hospedado eu nao tenho, mas tenho um domínio de internet publicado, e dentro do meu servidor tenho um redirecionamento para o site onde esse domínio está hospedado.

ontem tambem rodei o fuser 80 tcp e vi que os processos exibidos estao em uso pelo apache2

você me recomenda, como teste, parar o bind9 e o apache2?

Bruno_Cavalcanti
(usa CentOS)

Enviado em 22/03/2017 - 11:29h

Só o apache2

provavelmente ele é o serviço que está respondendo para a porta 80 na sua rede.

para ele por minutos e nesses minutos com ele parado verifica como fica o trafego. se diminuir vc ja sabe que é ele.

se está usando o apache como reverso para um site apenas. Sugiro que faça o reverso de um Nginx e fique monitorando os acessos ao servidor com tcpdump.

Abraço e qualquer coisa estamos aqui.

thiagoofsaint
(usa Debian)

Enviado em 22/03/2017 - 14:04h

Oi Bruno. Neste momento o link está normalizado. Mas neste últimos três dias o link sempre normaliza das 13hs às 17hs (o que reforça o que você disse: que este servidor está sendo usado como zumbi). Quando voltar a lentidão, vou parar o apache e vou usar as opções que você me indicou. Feito isso, te dou um feedbaak aqui sobre a situação.

O que você me indica se o problema estiver de fato no apache?

Por enquanto, Muito obrigado, Bruno pela sua ajuda. Abraço.

thiagoofsaint
(usa Debian)

Enviado em 22/03/2017 - 16:26h

Há pouco recomeçou a lentidão. Não dei ainda um stop no apache2, mas dei um tcpdump -i ethX dst port 80, ao mesmo tempo que dou um ping para o site da uol. Reparei que quando o ping dá tempo esgotado, a tela do tcpdump dispara como no exemplo abaixo:

16:13:06.931637 IP server.ghb.net.br.20453 > 45.117.193.248.www: Flags [S], seq 1340437605:1340438368, win 63353, length 763
16:13:06.931674 IP server.ghb.net.br.29043 > 45.117.193.248.www: Flags [S], seq 1903378287:1903379048, win 61878, length 761
16:13:06.931705 IP server.ghb.net.br.41010 > 45.117.193.248.www: Flags [S], seq 2687650571:2687651343, win 61890, length 772
16:13:06.931734 IP server.ghb.net.br.15494 > 45.117.193.248.www: Flags [S], seq 1015469076:1015469868, win 61154, length 792
16:13:06.931741 IP server.ghb.net.br.6092 > 45.117.193.248.www: Flags [S], seq 399263326:399264113, win 62432, length 787
16:13:06.931755 IP server.ghb.net.br.9879 > 45.117.193.248.www: Flags [S], seq 647491705:647492493, win 65484, length 788
16:13:06.931768 IP server.ghb.net.br.47092 > 45.117.193.248.www: Flags [S], seq 3086259011:3086259808, win 61762, length 797
16:13:06.931775 IP server.ghb.net.br.2284 > 45.117.193.248.www: Flags [S], seq 149724492:149725258, win 65074, length 766
16:13:06.931787 IP server.ghb.net.br.1712 > 45.117.193.248.www: Flags [S], seq 112231016:112231818, win 60782, length 802
16:13:06.931802 IP server.ghb.net.br.39648 > 45.117.193.248.www: Flags [S], seq 2598415666:2598416448, win 62148, length 782
16:13:06.931822 IP server.ghb.net.br.29970 > 45.117.193.248.www: Flags [S], seq 1964166715:1964167488, win 64725, length 773
16:13:06.931829 IP server.ghb.net.br.22576 > 45.117.193.248.www: Flags [S], seq 1479557144:1479557938, win 61306, length 794
16:13:06.931840 IP server.ghb.net.br.ssh > 45.117.193.248.www: Flags [S], seq 1472289:1473053, win 60097, length 764
16:13:06.931847 IP server.ghb.net.br.32662 > 45.117.193.248.www: Flags [S], seq 2140555115:2140555878, win 65317, length 763
16:13:06.931859 IP server.ghb.net.br.12907 > 45.117.193.248.www: Flags [S], seq 845907974:845908748, win 65302, length 774
16:13:06.931873 IP server.ghb.net.br.33011 > 45.117.193.248.www: Flags [S], seq 2163417872:2163418678, win 61451, length 806
16:13:06.931892 IP server.ghb.net.br.10265 > 45.117.193.248.www: Flags [S], seq 672759660:672760428, win 60905, length 768
16:13:06.931899 IP server.ghb.net.br.52170 > 45.117.193.248.www: Flags [S], seq 3419048053:3419048828, win 62100, length 775
16:13:06.931911 IP server.ghb.net.br.62381 > 45.117.193.248.www: Flags [S], seq 4088249727:4088250518, win 60251, length 791
16:13:06.931923 IP server.ghb.net.br.15721 > 45.117.193.248.www: Flags [S], seq 1030316571:1030317378, win 64801, length 807
16:13:06.931930 IP server.ghb.net.br.26043 > 45.117.193.248.www: Flags [S], seq 1706785637:1706786428, win 63693, length 791
16:13:06.931950 IP server.ghb.net.br.23072 > 45.117.193.248.www: Flags [S], seq 1512093741:1512094523, win 62747, length 782
16:13:06.931957 IP server.ghb.net.br.15751 > 45.117.193.248.www: Flags [S], seq 1032312329:1032313118, win 61411, length 789

Aí quando o ping responde, o tcpdump volta ao normal, mas quando dá tempo esgotado de novo, recomeça esse erro acima, mas com outro IP.

Outra coisa que eu observei também foi o comando top. o processo que aparece no topo pra mim é desconhecido, um tal de fhybshcazp

top - 16:25:30 up 20:00, 5 users, load average: 3.68, 3.58, 3.05
Tasks: 168 total, 1 running, 167 sleeping, 0 stopped, 0 zombie
Cpu(s): 51.0%us, 39.4%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 9.6%si, 0.0%st
Mem: 1885068k total, 1174008k used, 711060k free, 292964k buffers
Swap: 3447800k total, 0k used, 3447800k free, 545968k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3132 root 20 0 43296 1176 212 S 61.6 0.1 712:09.00 fhybshcazp
4333 root 20 0 3888 1344 908 S 20.9 0.1 5:46.05 iptraf
1666 root 20 0 100m 28m 5952 S 10.3 1.5 131:20.84 Xorg
3508 server 20 0 85616 19m 14m S 6.6 1.1 85:52.98 gnome-system-mo
21 root 20 0 0 0 0 S 0.3 0.0 0:43.12 kondemand/0
1 root 20 0 2036 724 628 S 0.0 0.0 0:08.82 init

Como posso resolver isso? Pois quando isso acontece, o servidor chega até a 600.0 Mbit/s

Bruno_Cavalcanti
(usa CentOS)

Enviado em 22/03/2017 - 17:07h

O primeiro a ser feito é trocar a tecnologia de reverso que vc ta utilizando.

se vc tem um servidor http apenas para um redirect, faça esse redirect de um servidor nginx

depois que seu redirect tiver rodando do outro servidor normalmente. Tire esse cara que ta causando prejuiso do DNS, pae o apache da maquina e que os jogos comecem ....

de antemão descubra quem é esse cara do top

find / | grep nomedoservico
com isso encontrará tudo que tem esse nome

depois que encontrar abre os arquivos e ve o que esse cara realmente faz.

rode um carinha chamado Lynis nessa maquina.

e por ai vai. Boa sorte,

Se e somente se, depois disso tudo!! (Todas as suas precauções), você ainda estiver perdendo a banda.....

Va com tudo para cima do seu provedor!!!

vá sem medo. E guarde os logs.

thiagoofsaint
(usa Debian)

Enviado em 22/03/2017 - 17:20h

Olha isso:


/usr/bin/fhybshcazp
/etc/rc2.d/S90fhybshcazp
/etc/rc5.d/S90fhybshcazp
/etc/rc4.d/S90fhybshcazp
/etc/rc3.d/S90fhybshcazp
/etc/init.d/fhybshcazp
/etc/rc1.d/S90fhybshcazp


o que foi encontrado. Aí mato o processo, e a navegação volta ao normal. Passa 1min e começa de novo. Aí vou olhar no top e aparece outro processo esquisito, mas causando o mesmo problema:

top - 17:11:23 up 20:46, 6 users, load average: 1.46, 2.75, 3.37
Tasks: 171 total, 2 running, 169 sleeping, 0 stopped, 0 zombie
Cpu(s): 41.4%us, 4.0%sy, 0.0%ni, 54.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1885068k total, 1367364k used, 517704k free, 440132k buffers
Swap: 3447800k total, 0k used, 3447800k free, 551056k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
24866 root 20 0 25508 508 204 S 27.5 0.0 0:05.78 zehsovwvpp
1666 root 20 0 100m 28m 5952 S 9.9 1.5 136:00.19 Xorg


Se eu matar ele, tudo recomeça com outro nome. Mesmo parando o apache2 o problema persiste

thiagoofsaint
(usa Debian)

Enviado em 22/03/2017 - 17:26h

outra coisa que observei em comum nesses processos. o inicio de alguns arquivos

root@gateway:/etc/init.d# find / |grep wkkrelhipw
/usr/bin/wkkrelhipw
/etc/rc2.d/S90wkkrelhipw
/etc/rc5.d/S90wkkrelhipw
/etc/rc4.d/S90wkkrelhipw
/etc/rc3.d/S90wkkrelhipw
/etc/init.d/wkkrelhipw
/etc/rc1.d/S90wkkrelhipw


Veja que assim como o anterior, ele recria no rc2.d, rc3.d, rc4.d, rc1.d e rc5.d com a inicial S90. Será esse um caminho pra matar ele?

Bruno_Cavalcanti
(usa CentOS)

Enviado em 22/03/2017 - 18:46h

olha o conteudo dos arquivos do rc*

verifica ai..

e confirma se tem porta sobrecarregando a 80 com

netstat -[*****]

e verifica ai.

qqer coisa taca uma pá de cimento na porta 80 desse servidor.

https://www.cyberciti.biz/faq/iptables-block-port/


Abraço.

thiagoofsaint
(usa Debian)

Enviado em 27/03/2017 - 10:21h

Olá Bruno. Desculpe a demora pra te responder.


Achei o processo no TOP e bloqueei ele. daí em diante acabou a lentidão. Os processos continuam dentro do servidor, mas bloqueados.

Você me ajudou demais, cara! Muito obrigado. Abraço

Bruno_Cavalcanti
(usa CentOS)

Enviado em 27/03/2017 - 23:11h

Abraço parceiro.