+ Responder ao Tópico



  1. #11
    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.

  2. Citação Postado originalmente por 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.
    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



  3. #13
    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

  4. Citação Postado originalmente por 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
    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...



  5. #15
    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?






Tópicos Similares

  1. estão tentando invadir meu servidor???
    Por ruanserver no fórum Servidores de Rede
    Respostas: 8
    Último Post: 17-01-2014, 10:42
  2. Estão tentando invadir meu servidor???
    Por Diangellys no fórum Redes
    Respostas: 18
    Último Post: 06-07-2013, 22:49
  3. ESTÃO TENTANDO INVADIR MEU SERVIDOR?
    Por dvse1 no fórum Redes
    Respostas: 4
    Último Post: 13-09-2010, 07:10
  4. Será que estão tentando invadir meu MK?
    Por gotch no fórum Redes
    Respostas: 19
    Último Post: 14-03-2007, 22:23
  5. Alguem tentando invadir meu Mikrotik?
    Por Arcanjo_tc no fórum Redes
    Respostas: 4
    Último Post: 31-12-2006, 11:00

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L