Ol� pessoal.
N�o sei se aqui � o lugar correto pois � uma d�vida que n�o depende de distribui��o. Bom... desculpem se � off.
Eu estava analizando a regra:
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 4 -j DROP
Acredito que tanto faz ser 'DROP' ou 'ACCEPT'. O restante das regras poderiam caracterizar melhor a regra. A quest�o n�o � essa.
A quest�o � que essa regra � normalmente apresentada para evitar syn-floods.
Pelo o que entendi, essa regra limita para 2/segundo o n�mero de requisi��es por conex�o.
A� entra minha quest�o.
Qualquer conex�o "leg�tima" inicia com o envio de um flag SYN para a m�quina com a qual se deseja conex�o.
Se eu estou limitando o n�mero de SYNs para 2 por segundo, a princ�pio eu estaria dizendo que s� posso atender a 2 requisi��es nesse segundo.
Logo, se eu tenho um serv ftp (por exemplo), eu estaria impedindo que mil usu�rios se conectassem ao meu serv "simult�neamente", afinal, num mesmo segundo o recebimento de 1000 SYNs seria inaceit�vel pela regra. Meu serv ftp seria um monstro in�til para servir muitos usu�rios.
N�o deixe seus olhos cairem ainda. Estou construindo o racioc�nio e sei que a afirma��o acima � equivocada.
O foco mesmo da minha quest�o �: porque isso n�o acontece?
Pelo o que estudei, essas 2 conex�es por segundo, para serem bloqueadas, deveriam partir da mesma m�quina, ou seja, caracterizar que um host X
qualquer est� solicitando duas conex�es nesse segundo.
Mas isso impediria que eu tivesse v�rios clientes ftp na minha pr�pria m�quina solicitando simult�neamente a m�quina que possui a regra. Poderia ser um procedimento normal do meu trabalho e portanto ser bloqueado n�o parece uma boa id�ia. Quem nunca abriu diversos clientes de um mesmo servi�o para facilitar o trabalho?
Me disseram que isso n�o ocorre porque a verifica��o considera que as conex�es s�o feitas pelos sockets e, portanto, para a regra funcionar, deveriam estar sendo enviados SYNs seguidos pelo mesmo socket.
Me pareceu uma afirma��o completamente absurda. Para mim socket � "at�mico", ou seja, ele n�o envia dois SYNs seguidos (n�o teria como).
Provavelmente isso � toda a minha d�vida.
E eis que completo:
O que caracteriza um syn-flood?
- Envios de SYNs da mesma m�quina seguidos de um RST ap�s o ACK do requisitado? Caso positivo, como a regra surtiria efeito sem prejudicar conex�es simultaneas leg�timas (tanto de uma mesma m�quina usando mil clientes quanto de clientes �nicos em mil m�quinas)?
- Envios de SYNs seguidos num tal volume que os ACKs do requisitado n�o seriam todos poss�veis a tempo? Caso positivo, como isso seria poss�vel? Ou melhor, para cada SYN enviado n�o seria necess�rio um socket? E portanto um SYN-flood n�o sobrecarregaria de processos tamb�m a m�quina atacante?
Afinal, como � poss�vel enviar uma sequ�ncia enorme de SYNs num espa�o curto de tempo sem sobrecarregar ao extremo a m�quina atacante tamb�m?
Ok, certamente a m�quina atacada sofreria mais, mas o n�mero de processos da atacante tamb�m seria gigantesco.
Algu�m pode jogar uma luz nesse p�ntano?
[]'s Alexander
-- GUS-BR - Grupo de Usuarios Slackware - BR http://www.slackwarebrasil.org/ http://www.linuxmag.com.br/mailman/listinfo/slack-users
