Quoting Alexander Franca <[EMAIL PROTECTED]> Sent on Wed, 4 May 2005 20:12:49 -0300 (BRT)
> N�o sei se aqui � o lugar correto pois � uma d�vida que n�o depende de > distribui��o. Bom... desculpem se � off. OK, s� procure n�o criar outra thread a partir de outra (respondendo uma outra mensagem). em MUAs como o Sylpheed, que mant�m as threads das mensagens, a tua msg apareceu "perdida" no meio dos mails aqui :) > 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. eu acho que faz diferen�a sim, mas tudo bem, n�o � o foco da tua quest�o. > Pelo o que entendi, essa regra limita para 2/segundo o n�mero de > requisi��es por conex�o. 1 por segundo, mas com um "bonus" podendo chegar a 4 no primeiro 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. mas seja mais generoso: levante o limite pra 100/s, por exemplo. eu uso 100/s, em conjunto com reducao do timeout tcp. > > 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? nao encare isso como quantidade de conexoes simult�neas, apenas *abertura* simult�nea de N conex�es. tu pode tranquilamente atender aos 1000 clientes, desde que eles n�o tentem conectar todos ao mesmo tempo. ou seja, eles conectam "com calma", e teu servidor ter� 1000 sess�es (j� conectadas) em andamento > > 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. n�o, pode ser do mesmo host. o limite que tu imp�s � pra syns, independentes de onde vieram. > 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). socket n�o � nada disso, � apenas um "descritor de arquivos" para rede. isso n�o entra no contexto do firewall, fica apenas como camada de abstra��o para acesso a rede por parte das aplica��es. > O que caracteriza um syn-flood? o que o nome diz, uma enchurrada de SYNs, apenas pra esgotar os recursos de sess�es TCP da m�quina. n�o precisa ser seguido por nenhum outro pacote, j� que o kernel ficar� esperando resposta do cliente at� dar timeout naquela sess�o, s� ent�o liberando os recursos alocados. > - 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? n�o. a� que entra raw sockets, que permitem a uma aplica��o enviar pacotes arbitr�rios (j� montados), direto. um syn-flood � uma queda de bra�o, ganha (geralmente) a maquina com mais recursos. > 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? DDoS :) usando um monte de maquinas pra afogar uma em espec�fico. > Ok, certamente a m�quina atacada sofreria mais, mas o n�mero de processos > da atacante tamb�m seria gigantesco. n�o necessariamente. tudo depende do que tu usa pra criar a enxurrada de SYNs. fazendo uma boa aplica��o, d� pra atolar mesmo m�quinas porradas usando maquinas menos potentes. mas se o campo de batalha for a internet, a� ainda tem o problema de banda. o atacante (ou atacantes) t�m que ter mais banda que o alvo. exite um monte de informa��o sobre isso tudo (descri��o, solu��es, ...), tanto em livros quanto na internet. sugiro que tu d� uma olhada em artigos cient�ficos, que costumam ter material mais "de ponta". um lugar pra procurar � no <http://citeseer.com/>. boa leitura :) -- Ricardo Nabinger Sanchez GNU/Linux #140696 [http://counter.li.org] Slackware Linux + FreeBSD "Keep grandma off the streets -- legalize bingo." -- GUS-BR - Grupo de Usuarios Slackware - BR http://www.slackwarebrasil.org/ http://www.linuxmag.com.br/mailman/listinfo/slack-users
