-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 25 mai 04, � 08:12, Salim Gasmi a �crit :
At 5/25/2004 03:26 AM, Olivier Warin wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 24 mai 04, � 23:59, Pascal Gloor a �crit :
- prise de trace pendant quelques minutes sur la machine cible (tcpdump)estimee (un simple |
- analyse des traces, tri des attaquants par nb d'attaques sur la periodegrep | awk xxx | uniq -c etc. fait l'affaire).
cela marche assez bien tant que le nombre d'ip sources est limite (capacite
de l'access-list/ipfw/autres).
Sinon une solution qui marche bien (teste et approve) mais qui
malheureusement est couteuse, c'est le 'guard' de riverhead (faisant partie
de groupe cisco depuis peu). http://www.riverhead.com/pr/guard.html
Je rejoins l'idee de Jerome, plutot que d'investir dans du materiel couteux qui sera obsolete un jour ou l'autre a bon coup de tcpdump minutieux cad en regardant bien les champs des paquets spoofe qui passent, notamment TTL, les flags (SYN/ACK/URG/RST ...) et aussi les numeros de sequences TCP suivie de regles adequat dans un firewall stateful (a etat) genre PF devraient deja resoudre une partie, si ce n'est pas l'integralite, du probleme.
Cordialement
/Olivier
Malheureusement, j'ai deja essay� de voir un semblant de logique dans les packets mais sans succes .
C'est totalement aleatoire (en tous cas cela le semble bien), ni l'IP source
ni le port source, ni les flags, ttl et autres ne semblent avoir de point commun .
A titre d'info sur un echantillon de 60000 packets SYN, l'ip la plus reperesent�e est a 110 packets .
En tous cas, merci pour vos commentaires.
Salim
Bonjour,
SYN PROXY
By default, pf(4) passes packets that are part of a tcp(4) handshake be-
tween the endpoints. The synproxy state option can be used to cause
pf(4) itself to complete the handshake with the active endpoint, perform
a handshake with the passive endpoint, and then forward packets between
the endpoints.
No packets are sent to the passive endpoint before the active endpoint
has completed the handshake, hence so-called SYN floods with spoofed
source addresses will not reach the passive endpoint, as the sender can't
complete the handshake.
The proxy is transparent to both endpoints, they each see a single con-
nection from/to the other endpoint. pf(4) chooses random initial se-
quence numbers for both handshakes. Once the handshakes are completed,
the sequence number modulators (see previous section) are used to trans-
late further packets of the connection. Hence, synproxy state includes
modulate state and keep state.
Rules with synproxy will not work if pf(4) operates on a bridge(4).
En reference, je te conseille de lire: http://www.onlamp.com/pub/a/bsd/2004/04/15/pf_developers.html
Note que syn proxy est "casse" dans OBSD -current depuis fin avril mais le probleme n'affecte pas
les releases et devrait etre resolu rapidement.
http://www.mail-archive.com/pf%40benzedrine.cx/msg04231.html
En clair, tu mets un vraie firewall qui tourne sous un vrai systeme d'exploitation sur le lien de ton server http et tu regardes le resultat :)
Cordialement
/Olivier
- --
Warin Olivier
Xview dot net - Net & Web Services for Un*x Geeks
The Caudium Webserver (http://www.caudium.net)
"Ce n'est pas parce que les choses sont difficiles que nous n'osons pas
mais c'est parce que nous n'osons pas que les choses sont difficiles."
S�n�que
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)iD8DBQFAszkOsBj9sTvtXyoRAlUVAKDHIZG4Vo1kPRT65bdcgvkU2LxHfwCfXV+w OiQcDA8y8vxrUiNkMKNZoCU= =PBpV -----END PGP SIGNATURE-----
---------------------------- Liste de diffusion du FRnOG http://www.frnog.org/ ----------------------------------------------- Archives : http://www.frnog.org/archives.php -----------------------------------------------
