Salut,
Désolé ca va pas t'aider mais attention, 2 PCs dans un même
réseau/navigateur ne signifie pas du tout forcément la même requête
réseau..
Juste en parlant de proxy HTTP tu peux avoir:
- un poste qui sera configuré via son DHCP pour utiliser un proxy HTTP
via un proxy.pac:
- Les navigateurs IE/Chrome l'utiliseront via la conf windows mais pas
forcément Firefox.
- Un autre aura peut être des exceptions de proxy déclarées manuellement.
- un qui utilisera le même proxy pour le http ET https
- un dernier qui aura un proxy http et un autre pour le https.
Juste pour une histoire de proxy, chaque cas précédent aura une requete
différente (https, http over TLS, https over https,..)
Tu vas perdre quelques points de vue et cheveux mais je te conseille de
sortir combo curl/wireshark côté client PLUS une autre sonde pour comparer.
Dans mon cas perso, le FW modifiait les en-tetes TCP et cassait les
sessions TLS. Mes pcaps aux niveaux du SQUID, je voyais des paques émis
par le client que je ne retrouvait pas dans le pcap du dit client (testé
sous Wireshak Windows et GNU/Linux)... ça m'a rendu fou..
Bon courage! Tiens nous au jus quand tu trouves l'origine de ton probleme.
A+
V.
PS: On est vendredi, pour troller entre la MSS et MTU, je vous joint un de
mes petit code récent BASH/AWK completement useless
Ca va modifier la MSS vers les @IP qui vous scannent, c'est une défense
type "deception". (à ne pas utiliser en prod bien sur)
#!/usr/bin/env bash
export PATH="/bin:/usr/bin:/sbin"
# "pretty" useless AntiBruteForce bash script
# Deception Counter-mesure settings a 5bytes MSS window with the attacker
# 0. Get the ip/interface of your gateway
# 1. tailling logs
# 2. awk script matching failled auths (LOG_FILTER), extract @IP, execute
the FILTER inline script
# 3. set the MSS to 5bytes with the previous @ip (except WHITELIST)
# Vive La Commune!
# VARIABLES
# journalctl filter with IP
LOG_FILTER='$0 ~ /.*sshd.*failure.*/ || $0 ~ /smtpd.*lost connection after
EHLO from unknown.*/'
WHITELIST=('127.0.0.1' '192.168.1.254')
# TEST : /!\ CHANGED THE LAST 2 LINES !!
#DEBUG="echo " ; LOG_TEST="toto 8.8.8.8 toto" ; LOG_FILTER='toto.*toto'
# CODE NE PAS MODIFIER!
# -1. Check dependances
tools=('awk' 'sed' 'journalctl' 'ip')
for i in ${!tools[@]} ; do command -v "${tools[i]}" &> /dev/null || {
echo "manque ${tools[i]}" ; exit -1; }; done
#0.
read -r gw dev<<<$(ip route | awk '/default/ {print $3 " " $5}')
#3.
FILTER=$(cat <<EOF
echo '#!/usr/bin/env bash
if [[ "${WHITELIST[@]}" =~ "IP" ]] ; then exit; fi
echo Detected and filter 'IP/32'
${DEBUG} ip route add 'IP/32' via "${gw}" dev "${dev}" advmss 5 2>/dev/null'
EOF
)
#2.
AWK_SCRIPT=$(cat <<'EOF' | sed -e "s#LOG_FILTER#${LOG_FILTER}#g"
echo {
if( LOG_FILTER ){
if (match($0,/([0-9]+\.){3}[0-9]+/,ip)) { system(FILTER"| sed -e
\"s/IP/"ip[0]"/g\" |bash") }
}
}
EOF
)
#1.
# INVERT TO TEST / DEBUG
#echo -n "${LOG_TEST}" | awk -v FILTER="${FILTER}" -f <(${AWK_SCRIPT)
journalctl -af | awk -v FILTER="${FILTER}" -f <($AWK_SCRIPT)
On Thu, May 16, 2024 at 11:04 PM Jérôme Marteaux <[email protected]> wrote:
> Le 16/05/2024 à 09:34, Toussaint OTTAVI a écrit :
> >
> >
> > Le 15/05/2024 à 14:48, Hugues Voiturier a écrit :
> >> Mais quelle excellente idée de changer la MTU de l’interface sans
> >> changer la MSS,
> >
> > Je suppose que cela dépend des équipements. MSS = MTU moins les headers
> > (IP, TCP, IPsec...). Par défaut, le matériel que j'utilise calcule la
> > MSS tout seul en fonction de la MTU spécifiée. A vérifier dans la doc du
> > firewall, mais s'il ne le fait pas automatiquement, si on réduit la MTU,
> > il faut à priori réduire aussi la MSS à MTU - 40 (20 octets de header
> > TCP + 20 octets de header IP)
> >
> > --
> > Sinon, à ma connaissance, il n'y a pas de risque à spécifier une MTU (et
> > une MSS) trop petite (à part bien sûr la fragmentation excessive, qui
> > peut dégrader les performances).
>
> Ce n'est pas une bonne idée. Exemple avec ce schéma:
> CPE <------> PE
>
> Si la MTU du PE est à 1500 et celle du CPE est à 1492: lorsque le PE va
> envoyer des paquets à 1500 le CPE va les dropper.
> Et surtout le drop n'émet pas un paquet ICMP, donc si c'est du TCP la
> pile TCP doit interpréter ce drop comme un problème de MTU et pas une
> perte de paquet "classique", d'où le long délai pour établir une
> connexion (qui plus est en HTTPS avec la session SSL).
>
> Et inversement PE / CPE.
>
> La MTU doit toujours être identique des 2 côtés et il n'y a pas d'autre
> possibilité.
>
> $ ping -M do -s xxx ip
>
> peut parfaitement détecter des problèmes de MTU.
>
> >
> > 1492 est la valeur classique d'une MTU sur un lien WAN PPPoE.
> > Avec certains opérateurs, et en fonction de la façon dont ils collectent
> > le trafic pour le ramener sur leur infra, on peut être amenés à
> > descendre la MTU jusqu'à 1452 pour que le trafic passe bien.
>
> Ca c'est un problème, car la MTU est négociée par le PPPoE, est-ce que
> ton routeur a bien pris en compte la négo PPPoE ?
> Le LNS lui va envoyer des paquets à la MTU sans savoir que ton CPE a une
> MTU beaucoup petite.
>
> >
> > Pour ce que j'ai pu en voir, on n'a besoin de modifier la MTU que si
> > l'on monte soi-même la session PPPoE. Si l'opérateur fournit un routeur,
> > c'est lui qui se débrouille, et on garde une MTU normale de 1500 sur
> > l'interface Ethernet.
> >
>
> Normalement en IPv4 les routeurs fragmentent, à charge au destinataire
> de ré-assembler. Donc si c'est bien fait, le CPE doit arriver à
> fragmenter correctement.
> En IPv6 c'est l'émetteur qui doit fragmenter avant d'envoyer les paquets
> (d'où l'importance du PMTUd et de laisser passer ICMP).
>
> Jérôme
>
> --
> Jérôme Marteaux
>
>
>
> ---------------------------
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
