Estão tendando invadir meu sistema!!!

[alexandresamorim]

Galera estou tendo problemas de tentativa invasão em meu sistema..
Tenho o ip da pessoa mas o que fazer!!! Como agir!!


Obrigado

Alexandre Amorim

[1c3m4n]

iptables -I INPUT -s IP -j DROP

e se por acasoo ip for de alguma empresa (nao adsl ou modem) tenta entrar em contato com o responsavel desse ip e avisa que alguem ta tentando faze caca

[Brenno]

iptables -I INPUT -s IP -j DROP

e se por acasoo ip for de alguma empresa (nao adsl ou modem) tenta entrar em contato com o responsavel desse ip e avisa que alguem ta tentando faze caca

troque o DROP por REJECT

iptables -I INPUT -s IP -j REJECT

a diferença do DROP para REJECT eh que no REJECT o pacote ao chega no fw, o FW envia a Resposta a pessoa que ta tentando te ataka q a porta ta fechada, enquanto ao drop ele n envia nada, com isso a pessoa que ta atakando vai saber que aquela porta escutando,"Ativa".

já tentou da um telnet para uma maquina q ta escutando a porta 22 do ssh?

ex telnet ip 22

se tiver drop a regra para porta 22 , ele fica la aguardando...
se tiver reject na mesma hora ele recebe uma msg que a porta n exite, mesma coisa de da um telnet para uma porta que n esta ativa.

por isso que eu prefiro o REJECT.

não sei se deu para explica bem, mas quem tiver duvidas, basta testar.

abraço

[felco]

Usa DROP nao usa REJECT ¬¬

[Brenno]

Usa DROP nao usa REJECT ¬¬

hehehehee sem comentarios

[alexandresamorim]

MUITO OBRIGADO ATODOS ACHO QUE ASSIM DE UMA FORMA DE OUTRA DROP OU REJECT ESTAREI SEGURO..



GRATO
alexandreamorim

[mantunespb]

[quote="Brenno"]

iptables -I INPUT -s IP -j DROP

troque o DROP por REJECT

iptables -I INPUT -s IP -j REJECT

Concordo com o brenno em usar REJECT é melhor...


Márcio

[felco]

"The big difference between REJECT and DROP is that REJECT results in an ICMP error being returned. What is this for? Let's look at excerpts from relevant standards document, STD0003 (RFC1122):

3.2.2.1 Destination Unreachable: RFC-792

A Destination Unreachable message that is received MUST be
reported to the transport layer. The transport layer SHOULD
use the information appropriately; for example, see Sections
4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol
that has its own mechanism for notifying the sender that a
port is unreachable (e.g., TCP, which sends RST segments)
MUST nevertheless accept an ICMP Port Unreachable for the
same purpose.

Independente de você rejeitar ou dropar um pacote com um bom port scan seu resultado sera o mesmo, poís é presumivel que uma porta que esteja dropando um pacote esteja ouvindo, a diferença está que enquanto o reject irá facilitar um port-scan um drop irá em contra-partida retardar o port-scan por ele não enviar respostas enquanto dropa o "source" fica congelado aguardado uma resposta sobre a porta.
Claro existe maneiras de burlar essa espera por time-out mas, no nosso caso, um IP inteiro irá ser dropado então ele nunca tera resposta.

Se voce esta bloqueando um serviço de usuarios legitimos a maneira correta é Rejeitar o pacote, não há porque causar um delay no cliente,
dropando os pacotes dele você so irá causar delay, travamentos de programas, porque se voce bloquear uma porta com reject voce tera um erro em menos de 1 segundo enquanto se você dropar você não terá uma resposta em menos de 189 segundos.

[felco]

Eu não seria tão legal com alguem que está tentando invadir meu PC... mas anyway... você decide :P

Galera estou tendo problemas de tentativa invasão em meu sistema..

Como vc sabe que estao tentando te invadir? O que vc analisou? Como sou iniciante, gostaria de saber analisar isso!

Obrigado.

[whinston]

infelizmente temos que agir igual aos americanos
tão atacando a gente? mete ataque no cara tb.. ou pelo menos, fecha as portas..

pq no Brasil isto não dá nada.. vc cata o IP do cara, 99% é da Telefonica.
vc manda email pro abuse, liga lá e nunca vira nada

ou seja, use um IDS, não deixa ativo o que não for usar e atualize sempre seu sistema. proteja-se, pq ngm + o fará por vc.

[Brenno]

"The big difference between REJECT and DROP is that REJECT results in an ICMP error being returned. What is this for? Let's look at excerpts from relevant standards document, STD0003 (RFC1122):

3.2.2.1 Destination Unreachable: RFC-792

A Destination Unreachable message that is received MUST be
reported to the transport layer. The transport layer SHOULD
use the information appropriately; for example, see Sections
4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol
that has its own mechanism for notifying the sender that a
port is unreachable (e.g., TCP, which sends RST segments)
MUST nevertheless accept an ICMP Port Unreachable for the
same purpose.

Independente de você rejeitar ou dropar um pacote com um bom port scan seu resultado sera o mesmo, poís é presumivel que uma porta que esteja dropando um pacote esteja ouvindo, a diferença está que enquanto o reject irá facilitar um port-scan um drop irá em contra-partida retardar o port-scan por ele não enviar respostas enquanto dropa o "source" fica congelado aguardado uma resposta sobre a porta.
Claro existe maneiras de burlar essa espera por time-out mas, no nosso caso, um IP inteiro irá ser dropado então ele nunca tera resposta.

Se voce esta bloqueando um serviço de usuarios legitimos a maneira correta é Rejeitar o pacote, não há porque causar um delay no cliente,
dropando os pacotes dele você so irá causar delay, travamentos de programas, porque se voce bloquear uma porta com reject voce tera um erro em menos de 1 segundo enquanto se você dropar você não terá uma resposta em menos de 189 segundos.

ai eh que ta, o tempo que eu falei e q vc falou, so ocorre se a porta esta ativa, ou seja, se vc tem uma porta "ativa" 22, mas tem um regra drop nessa porta, se alguem passa porta scan, ele vai saber q existe um ssh no teu fw na porta 22, ele sabe disso por causa do tempo q o DROP da, enquanto o REJECT já mesma hora avisa q n existe nada nessa porta, entao pq usar o DROP?

pro atakante saber q tem uma porta ativa e tentar bular o fw?
garanto que contra porta scan eficiente o tempo que o drop causa isso n dificulta em nada.

isso eu to falando se o FW n tiver um ids na frente.

até agora não vi a vantagem de usar o DROP.

por isso que eu recomendo o REJECT, ele nunca vai saber que tua porta 22 ta ativa

abraço

[whinston]

o que eu tinha de conceito sobre isto era o seguinte
o drop apenas ignora e manda pro lixo
o reject manda 1 resposta pra quem perguntou: cai fora

teoricamente, vc falar "cai fora" é atiçar quem perguntou se tem algo ativo
ou seja, seria o contrário da discussão

[Brenno]

o que eu tinha de conceito sobre isto era o seguinte
o drop apenas ignora e manda pro lixo
o reject manda 1 resposta pra quem perguntou: cai fora

teoricamente, vc falar "cai fora" é atiçar quem perguntou se tem algo ativo
ou seja, seria o contrário da discussão

pra acaba com essa discução, bora fazer o teste na pratica, chega de bla bla bla..

na sua maquina fw se vc n tem nada rodando na porta 22 blz, se tiver o ssh, desligue ele, logo em seguinda de uma maquina da sua rede interna, digite o comando:
telnet ip_do_fw 22
ao executa o comando, a msn que vai aparece eh essa
aaa@debian:~$ telnet 192.168.1.1 22
Trying 192.168.1.1...
telnet: Unable to connect to remote host: Connection refused

agora levante o ssh no seu fw na porta 22 e cria essa regra
iptables -I INPUT -p tcp --dport 22 -j REJETC

novamente de o comando: telnet ip_do_fw 22
logo em seguinda vai aparece a mesma msg
aaa@debian:~$ telnet 192.168.1.1 22
Trying 192.168.1.1...
telnet: Unable to connect to remote host: Connection refused

agora troque a regra de REJECT para DROP
iptables -I INPUT -p tcp --dport 22 -j DROP

e execute novamente o comando: telnet ip_do_fw 22
agora vai acontece diferente, vai fica assim:

aaa@debian:~$ telnet 192.168.1.1 22
Trying 192.168.1.1....
ai vai fica assim acho que 1 ou 2 minutos e vai aparece outra msg
telnet: Unable to connect to remote host: Connection refused

antes de fala, eh bom testar ne? teoria eh bom, mas n eh tudo. a teoria sempre tem que andar de mãos dadas com a pratica.

sem +
abraço a todos...

[whinston]

não entendi cara..
vc subiu a regra de drop na 22 e viu a msg
vc subiu a regra de reject e tentou conecta na porta 70? não teria que ser na mesma prota 22 pra ver a msg?

[Brenno]

não entendi cara..
vc subiu a regra de drop na 22 e viu a msg
vc subiu a regra de reject e tentou conecta na porta 70? não teria que ser na mesma prota 22 pra ver a msg?

a porta eh 22, errei , mas ja corrigir.

vlw

[whinston]

fiz o mesmo teste aqui, só que com a porta 25, axo que dá na mesma

telnet xxx 25
Trying xxxx...
Connected to localhost.localdomain (xxx).

iptables -A INPUT -p tcp --dport 25 -j REJECT
telnet xxx 25
Conectando-se a xxx...Não foi possível abrir conexão com host na port
25: conexão falhou
*demorou 15 seg.

limpei as regras, com X F e Z e rodei
iptables -A INPUT -p tcp --dport 25 -j DROP
Conectando-se a xxx...Não foi possível abrir conexão com host na port
25: conexão falhou
*demorou 15 seg.

estranho que ambos demoraram 15 segundos!
eu achei que o reject fosse de imediato, mas não foi.

[Brenno]

fiz o mesmo teste aqui, só que com a porta 25, axo que dá na mesma

telnet xxx 25
Trying xxxx...
Connected to localhost.localdomain (xxx).

iptables -A INPUT -p tcp --dport 25 -j REJECT
telnet xxx 25
Conectando-se a xxx...Não foi possível abrir conexão com host na port
25: conexão falhou
*demorou 15 seg.

limpei as regras, com X F e Z e rodei
iptables -A INPUT -p tcp --dport 25 -j DROP
Conectando-se a xxx...Não foi possível abrir conexão com host na port

a REJECT eh imediato,

se n foi tem algo errado,

acompanhe o pacote se ta passando pela sua regra no fw.

iptables -L -v |more

[felco]

whinston a distro do breno deve funcionar com o REJECT + tcp rst...
O fato eh que quando vc da um REJECT vc envia uma resposta logo vc se mostra ativo quando vc da um DROP vc nao envia resposta nenhuma
Independente do metodo um atacante sabe como funciona... isso nao fara diferenca...
Porem vamos analizar um spyware windows... ele funciona automaticamente, se ele tentar abrir uma conexao eh receber uma resposta mesmo que seja de falha ele, na sequencia, inicia outra conexao... caso nao receba nenhuma resposta tera que aguardar, imagine agora o MSN... se recebe uma resposta de erro tenta usar outro server para conectar... se nao recebe resposta acredita nao haver conexao com a internet... porque? porque ele é politicamente correto... ele entende que deveria receber um icmp tipo 3 caso contrario nao há conexao.

[Brenno]

whinston a distro do breno deve funcionar com o REJECT + tcp rst...
O fato eh que quando vc da um REJECT vc envia uma resposta logo vc se mostra ativo quando vc da um DROP vc nao envia resposta nenhuma
Independente do metodo um atacante sabe como funciona... isso nao fara diferenca...
Porem vamos analizar um spyware windows... ele funciona automaticamente, se ele tentar abrir uma conexao eh receber uma resposta mesmo que seja de falha ele, na sequencia, inicia outra conexao... caso nao receba nenhuma resposta tera que aguardar, imagine agora o MSN... se recebe uma resposta de erro tenta usar outro server para conectar... se nao recebe resposta acredita nao haver conexao com a internet... porque? porque ele é politicamente correto... ele entende que deveria receber um icmp tipo 3 caso contrario nao há conexao.

primeiro lugar, não se trata de distro e sim de iptables
em segundo lugar ao falar que o REJECT enviar a msn e o DROP não, eh bom deixa claro que a msg que o REJECT enviar eh a mesma msg que vc ira recebe se a porta esta "inativa", não tem como vc saber se a msg que vc ta recebendo eh de REJECT ou porta inativa. eh bom deixa isso claro. já deu um EXEMPLO CLARO disso.

até agora n vi nem uma vantagem de usar o DROP

abraço