Sistema OS: Slackware 12.

Não vou entrar em detalhes da instalação do Slackware aqui, pois não é esse o foco.

Só pedimos que quando estiver instalando o Slackware, não coloque as configurações de sua placa de rede. Deixe como automático, pois todas as configurações das placas vão ficar em um único arquivo.

Mãos a obra!

1. Primeiro vamos levantar nossas placas de rede e criar os arquivos responsáveis pelas rotas dos ips.

Crie um arquivo com o nome de "ethup".

# touch /bin/ethup

Dentro do arquivo coloque primeiro as configurações de sua placa de internet. Ex:


Em seguida dê permissão a este arquivo:

# chmod +x /bin/ethup

[1] Comentário enviado por elgio em 12/06/2008 - 18:20h:

Pelo bem da humanidade, fico CAÇANDO estes terríveis equivocos:

# PROTEÇÃO CONTRA SYN-FLOODS
-A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT

Tu ACABOU de tornar negação de serviço no teu servidor uma tarefa SUPER HIPER FÁCIL:
http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=7070

No mais, achei o artigo um mero despejo de configurações que se enquadram apenas no teu cenário e sem explicações do porque tu faz cada configuração (porque N interfaces virtuais por exemplo? Onde está o "Amarrando" o Mac que consta no resumo?)

Enfim...

[2] Comentário enviado por y2h4ck em 13/06/2008 - 10:11h:


Concordo com Elgio (viu Elgio como não sou do contra ???rsrs).

Ficou tudo mto jogado no ar...

[3] Comentário enviado por elgio em 13/06/2008 - 10:56h:

Puxa, Francisco!

Na boa, tira LOGO esta regra de Syn flood fajuta e liga syn cookie. Qualquer um MUITO FACILMENTE pode derrubar teu servidor com um simples comando:

hping3 --fast --rand-source -p 80 -S TEU-IP

Isto envia MUITO mais syns por segundo, lotando teu limit do iptables e fazendo com que o PROPRIO iptables tire teu servidor do para conexoes legitimas. E o --rand-source falsifica o Ip de origem. Além do --fast ainda tem o --flood que é ainda mais rápido, mas o --fast já é suficiente.

Cara, SYN FLOOD com sucesso só se o atacante tiver muitoas máquinas. Mas com esta idiotice do iptable bloquear, fica brincadeira de criança fazer. Fique alerta.

E y24ck: nunca te considerei do contra. Justamente o contrário, te admiro muito e li os teus artigos.

[4] Comentário enviado por fsoaress76 em 13/06/2008 - 13:07h:

"elgio" sobre seu artigo ainda nao tinha visto, mais foi boa sua colocação.
quanto a amarração de ip+mac

na página "Script das regras do iptables" no final tem:



# CLIENTE_1
-A Users -m mac -s 10.100.1.2 -j RETURN --mac 00:00:ee:96:2d:8e
# CLIENTE_2
-A Users -m mac -s 10.100.2.2 -j RETURN --mac 00:15:ff:33:11:e1
# CLIENTE_3
-A Users -m mac -s 10.100.3.2 -j RETURN --mac 00:05:9e:88:55:3f
# CLIENTE_4
-A Users -m mac -s 10.100.4.2 -j RETURN --mac 00:0e:ee:aa:ee:57
#CLIENTE_5
-A Users -m mac -s 10.100.5.2 -j RETURN --mac 00:0a:22:00:44:bb

# CASO QUEIRA DEIXAR LIVRE O IP SEM AMARRAR COM A MAC
-A Users -s 10.100.6.2 -j RETURN

é bem mais simples do que outras regras que usam três linha só para liberá um ip.

[5] Comentário enviado por elgio em 13/06/2008 - 13:35h:

Ok. Não tinha visto os macs porque não li todos os codigos do firewall.

Uma dica então: é sempre bom poder manter as regras iptables o minimo possível. Tu fizeste isto bem com o RETURN em uma lista separada (assim, se houverem 300 macs e um mac casar com a primeira, nao sera avaliada pelas outras 298, como acontece quando pessoas fazem isto assim:

-A FORWARD -m mac -s 10.100.5.2 --mac ! 00:0a:22:00:44:bb -j DROP
(dropando se nao for do MAC)

Ainda assim, eu acho muito mais eficiente fazer isto por ARP estatico. Porque?

porque ARP eh uma coisa que a maquina sempre fara. Como tu conhece o IP e mac, se for ESTATICO, ficara ainda MAIS RAPIDO, pois o roteador nao precisará perguntar via ARP broadcast quem é o IP:

arp -s 10.100.5.2 00:0a:22:00:44:bb

Para ARPS estaticos o roteador nunca pergunta o MAC, logo se vier do ip 10.100.5.2 com outro MAC o cara ficara OFF, pois o gateway sempre ira mapear 10.100.5.3 para 00:0a:22:00:44:bb. Eu ainda uso isto para evitar que alguns espertinhos usem ips livres:

# IP 10.100.5.55 nao esta alocado ainda!
arp -s 10.100.5.2 00:01:00:01:00:01 (arp INVALIDO)

[6] Comentário enviado por chikinho_fenix em 28/01/2009 - 19:53h:

tentei entender seu artigo, mas confesso que nao achei em lugar algun referencia a esse topico

"Para essas regras funcionarem, devemos certificar que temos o seguinte arquivo no diretório /etc/init.d/functions, sem este arquivo essas regras de iptables não funcionarão"

o que conterá nesse arquivo.

[7] Comentário enviado por fsoaress76 em 28/01/2009 - 20:41h:

chikinho_fenix

Este arquivo tem mais de 550 linhas nao da para colocar aqui.

mais no final ele retorna isso...

+- assim
O "OK" aparece em cor VERDE

Nivelando todas as regras do usuarios - definido chains: [ OK ]
verificando todas as regras do usuarios - definido chains: [ OK ]
Aplicando régras do firewall dos iptables: [ OK ]
firewall ativado [ OK ]

se tiver um erro diz qual é a linha, etc, etc