TCP MSS

L'MSS (Maximum segment size) è un parametro TCP che indica la quantità massima di paylod (unità di misura byte) che un dispositivo di comunicazione può gestire senza frammentare il pacchetto.

Per una comunicazione ottimale, il numero di byte nel segmento dati e nell'intestazione deve essere inferiore al numero di byte nell'unità massima di trasmissione (MTU).

 

Di default sarà 40 byte in meno di MTU. Quindi se l'MTU di un PC ha di default 1500 byte, invierà un MSS di 1460 byte.

Se la rete di comunicazione ha un valore MTU inferiore, ma il PC client non ne è a conoscenza, invierà il suo valore MSS di 1460 byte al server. Il server penserà quindi che il client possa ricevere 1500 byte (1460 MSS layer4 +20 ip header +20 TCP header) e invierà un pacchetto con una dimensione di 1500 byte. Ora, se l'MTU è inferiore da qualche parte nel percorso, il pacchetto può essere frammentato. Se il bit DF (don't fragment) è impostato, il pacchetto può essere eliminato, il che può causare ritardi o lentezza nella rete.

IL TEST PING:

 

Per trovare il valore MSS/MTU ottimale della rete, eseguire il 'ping test' per trovare l'MTU, quindi ridurre quel valore di 40 e impostarlo come tcp-mss nella policy del firewall.

Windows:

ping -f -l 1472 <indirizzo IP del server>

 

MAC OS:

ping -D -s <dimensione> <ip_server> 

Linux:

ping -M do -s <dimensione> <ip_server>

Per 1500 byte MTU, 1500-28 (20 byte = intestazione IP e 8 byte = intestazione ICMP) = 1472

Questi comandi non permetteranno di deframmentare il pacchetto, quindi modificare la dimensione fino a che il ping fallirà, questo determinerà la dimensione massima possibile.

Supponiamo che sia possibile effettuare un ping con una dimensione di 1400 ma non con una dimensione di 1401, ciò significa che il valore MTU è 1400+28=1428 byte. La soluzione è o correggere l'MTU nel dispositivo di rete o impostare il TCP MSS nella policy del firewall su 1428-40=1388 byte.

Su firewall Fortigate

config firewall policy

    edit <policy id>

         set tcp-mss-sender <mss value>

         set tcp-mss-receiver <mss value>

tcp-mss-sender:    valore del TCP MSS del mittente, modificherà il campo TCP MSS nel pacchetto TCP syn.

tcp-mss-receiver:  valore del TCP MSS del ricevitore, modificherà il campo TCP MSS nel pacchetto TCP syn.

Traffico attraverso VPN IPsec:

C'è un header IPSec extra. Dipende dall'algoritmo di crittografia e autenticazione. AES-256 e SHA1 hanno un massimo di 73 byte, e un altro algoritmo potrebbe avere byte leggermente diversi.

Per un MTU da 1500 byte, l'MSS per un tunnel TCP su IPSec è 1500-20(intestazione IP)-20(intestazione TCP)-73(intestazione IPSec) = 1387.

Per i tunnel IPSec, l'MTU e il TCP MSS possono essere configurati per ogni interfaccia del tunnel e hanno la precedenza sulle impostazioni definite dai criteri.

config system interface

edit "IPSecTunnelName"

set mtu-override enable

set mtu <MTU Value>

set tcp-mss <MSS Value>

Debug traffic VOIP su Fortigate

Se all'interno della vostra LAN avete un centralino VOIP e ha problemi con il provider, questi sono i passaggi per un corretto troubleshooting
Dopo aver individuato le policy di traffico tra il centralino e provider, provare a cambiarle da Flow a Proxy
Provate a disabilitare la funzione ALG, di default è impostata in proxy, provare a metterla in kernel.
FW# config system settings
FW(settings)# set default-voip-alg-mode proxy-based/kernel-helper-based
Provate a cancellare il SIP helper
FW# config system session-helper
FW(session-helper)# show
FW(session-helper)# edit 13
        set name sip
        set protocol 17
        set port 5060
FW(session-helper)# delete 13 
Se queste soluzioni non dovessero funzionare, ripristinare come prima e procedere con il debug 
Verificare se la sessione viene correttamente instaurata:
FW# diagnose system session filter src <IP centralino>
FW# diagnose system session filter dst <IP provider>
FW# diagnose system session list
L'output che dovreste trovare è il seguente:
session info: proto=17 proto_state=01 duration=142250 expire=3596 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=4
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ helper=rsh vlan_cos=255/255
state=local
statistic(bytes/packets/allow_err): org=9376719/61304/1 reply=3930213/32743/1 tuples=2
tx speed(Bps/kbps): 65/0 rx speed(Bps/kbps): 27/0
orgin->sink: org out->post, reply pre->in dev=13->0/0->13 gwy=0.0.0.0/10.5.27.238
hook=out dir=org act=noop 10.5.27.238:16844->173.243.132.165:514(0.0.0.0:0)
hook=in dir=reply act=noop 173.243.132.165:514->10.5.27.238:16844(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=0 auth_info=0 chk_client_info=0 vd=0
serial=0161f3cf tos=ff/ff app_list=0 app=0 url_cat=0
rpdb_link_id = 00000000
dd_type=0 dd_mode=0
Prestate attenzione al protocollo utilizzato e alla policy che viene usata. 
Se la sessione viene instaurata, vedere le chiamate attive
FW#diagnose sys sip-proxy calls list | grep -B7 -A3 <numero di telefono da filtrare>
  vdom 0 (root) vrf 0 call 7f5a40ed9600
    call-id: 9017997241972024165753@<IP provider>
    txn 7f5a40efa300 (INVITE)
      cseq 102 dir 1 state 11 status 200 expiry 143 HA 1
      i_session: 7f5a40e35000  r_session: 7f5a40e35000
      register: not-present
      from: sip:<numero sorgente>@10.39.31.123;user=phone
      to: sip:<numero destinazione>@10.39.31.20;user=phone
      src: <IP centralino>:5060
      dst: <IP provider>:5060
Se ancora ci sono problemi, provate a tracciare il flusso.
FW#  diagnose debug console timestamp enable
FW#  diagnose debug flow filter saddr <IP centralino>
FW#  diagnose debug flow show function-name enable
FW#  diagnose debug flow show iprope enable
FW#  diagnose debug enable
FW# diagnose debug flow trace start 1000
Prestare attenzione se nel debug compare un messaggio del genere
msg="iprope_in_check() check failed on policy 0, drop
potrebbe voler dire che l'IP che sta usando il centralino per uscire è usato da un VIP che ha l'ARP reply abilitato, la soluzione è disabilitare l'arp replay al VIP 
 

 

 

 

Script Python per accesso agli switch Cisco

Di seguito uno script Python che esegue l'accesso a due switch (possibile estendere la lista aggiungendo più IP) e fa lo show version

Lo script è stato testato su ambiente Debian con Python 3.10

$python -m pip install netmiko   -> importare la libreria netmiko

$touch script_ssh_cisco.py         -> creare il file

$vi script_ssh_cisco.py

import netmiko
from netmiko import ConnectHandler
device = ["10.5.1.13", "10.5.1.11"]
for x in device:
    cisco = {
        'device_type': 'cisco_ios',
        'ip':   x,
        'username': 'admin',
        'password': 'password',
        'secret': 'password',
    }
    print(' ')
    print(x)
    net_connect =ConnectHandler(**cisco)
    net_connect.enable()
    output =net_connect.send_command('show version | include IOS')
    print(output)

alla sezione password sostituire "password" con la password dell'utente admin, sempre tra " "

alla sezione secret sostituire "password" con la password di enable, sempre tra " "

$chmod u+x script_ssh_cisco.py   -> dare i permessi di esecuzione

$python script_ssh_cisco.py          -> lanciare lo script

 

10.5.1.13

Cisco IOS Software, C2960L Software (C2960L-UNIVERSALK9-M), Version 15.2(6)E2b, RELEASE SOFTWARE (fc3)

 

10.5.1.11

IOS (tm) C2950 Software (C2950-I6K2L2Q4-M), Version 12.1(22)EA13, RELEASE SOFTWARE (fc2)

Autenticazione Radius su Cisco Catalyst

(config)# radius server Test

(config)# address ipv4 10.7.1.20 auth-port 1645 acct-port 1646 -> andiamo a definire IP e porte

 (config)# timeout 5- -> andiamo a definire quanti sec. attendere prima della ritrasmissione

 (config)# retransmit 2 -> andiamo a definire quanti tentativi deve fare verso il radius

 (config)# key *******

adesso andiamo a creare un gruppo dove metteremo all'interno il nostro server Radius, per resilienza si consiglia di configurare due server e aggiungerli entrambi al gruppo.

Io ho creato solo la parte di "authentication" in quanto la password di enable preferisco metterla di volta in volta. E' stato configurato l'account locale admin, in modo che se il radius non dovesse essere disponibile è possibile collegarsi in locale, dopo GRP-TEST è stato definito il metedo di backup che è local-case

(config)# username admin secret 5 $1$VRx0$divcXTBZeAQVN2IJSGV7n.

(config)# aaa new-model

!

(config)# aaa group server radius GRP-TEST

 server name Test

!

aaa authentication login default group GRP-TEST local-case

Successivamente è necessario configurare il servizio sul Server Windows, impostare le policy con gli IP autorizzati e la key, per la configurazione della parte Windows potete fare riferimento al post:

Authentication Fortinet with Radius

!!Attenzione" l'autenticazione tra switch e Radius avviene in PAP, quando si configura la policy è necessario inserire il flag su PAP

Autenticazione LDAP su server CentOS 7

La guida è per sistemi CentOS 7, ma credo che non ci siano problemi su CentOS 8 o derivate Debian
installare i pacchetti:
yum install openldap-clients nss-pam-ldapd

Procedere con l'autoconfigurazione:
authconfig --enableldap \
--enableldapauth \
--ldapserver=test.local o indirizzo IP \
--ldapbasedn="dc=test,dc=local" \
--enablemkhomedir \
--update

Il comando "enablemkhomedir" farà in modo che all'accesso verrà creata la /home directory.
Creare su active directory un utente di servizio per l'integrazione e copiare il "distinguishedName"

Modificare il file /etc/nslcd.conf
# The distinguished name of the search base.
base dc=test,dc=local
# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.

binddn inserire il distinguishedName precedentemente copiato
binddn cn=ldaplinux,ou=Servizio,dc=test,dc=local

# The credentials to bind with.
# Optional: default is no credentials.
# Note that if you set a bindpw you should check the permissions of this file.
bindpw "inserire la password dell'account di servizio"
bindpw passwd

deccomentare tutta la parte riferita a Active Directory

# Mappings for Active Directory

pagesize 1000
referrals off
idle_timelimit 800
filter passwd (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
map    passwd uid              sAMAccountName
map    passwd homeDirectory    unixHomeDirectory
map    passwd gecos            displayName
filter shadow (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
map    shadow uid              sAMAccountName
map    shadow shadowLastChange pwdLastSet
filter group  (objectClass=group)

Salvare e uscire

Riavviare il servizio:

#systemctl restart nslcd

A questo punto è necessario modificare gli attributi per l'account che dovrà autenticarsi.

Sulla macchina Linux verificare l'account modiificato su Active Directory

#id adm_ep_test

uid=5000(adm_ep_test) gid=100(users) gruppi=100(users)

Fare un test d'accesso:

#ssh adm_ep_test@localhost

adm_ep_test@localhost's password: 

Creating directory '/home/adm_ep_test'.

Last login: Mon May  9 15:17:42 2022 from ::1

 

Backup Switch HP e Aruba

Una soluzione a costo zero per il backup degli switch HP e Aruba, sta nell'usare SFTP. Per fare ciò è necessaria una macchina Windows che possa raggiungere gli switch.

Nel mio caso, ho installato una VM con Windows Server 2019 Datacenter

I programmi necessari sono:

WinSCP, Notepad ++, Backup_Switch

Scaricare tutti e tre, installare WinSCP e Notepad ++, estrarre il file zip e salvarlo possibilmente su un percorso differente da C:\ (nel mio caso, ho aggiunto un secondo disco e messo sotto E:\)

Per prima cosa è necessario preparare lo switch alla esportazione della configurazione in SFTP

entrare in config

(config)# crypto key generate ssh

(config)# ip ssh

(config)# ip ssh filetransfer

!!!Attenzione!!! abilitando ip ssh file transfer verrà abilitato SFTP ma verrà disabilitato TFTP, quindi per aggiornare i firmware bisognerà utilizzare un SFTP Server.

(config)# exit

# write memory

Visto che è stato abilitato l'SSH si consiglia di disabilitare il telnet:

(config)# no telnet-server

in quanto è un protocollo non sicuro

A questo punto accedere tramite WinSCP allo switch

Andare su Sessione e cliccare su Informazione server/protocollo

Copiare il Fingerprint SHA-256 e l'Algoritmo, cliccare su Sessione e terminarla.

Aprire successivamente il file .csv che era presente nel file ZIP che è stato precedentemente estratto e compilare come nella figura qui sotto, sarà necessario inserire hostname o IP address, user, password, algoritmo e chiave SHA

E' necessario modificare i file Backup Network Switches.cmd e Backup Network Switches.ps1 inserendo i percorsi corretti dove sono presenti il file switches.csv e la cartella Backups.

A questo punto lanciando il file Backup Network Switches.cmd, lo script si collegherà allo switch e salverà la configurazione nella cartella Backup.

A completamente di tutto, si può impostare uno schedular per lanciare lo script ogni giorno o come meglio si vuole schedulare il backup.

Esempio:

Vecchie connessioni samba con Linux

 Se ci si connette a vecchie connessioni samba è necessario abilitare smb1

modificare il file:

/etc/samba/smb.conf

aggiungere sotto [global]

server min protocol = NT1
client min protocol = NT1
allow insecure wide links = yes

Se invece si cerca di accedere da un server/pc Windows a una condivisione samba su Linux e l'autenticazione non dovesse funzionare, è necessario fare un troubleshooting del problema. Nel mio caso sulla macchina linux ho eseguito un tcpdump per poi analizzarlo con wireshark.

Il comando da dare è:

tcpdump -i "nome interfaccia" -w /home/emy/sniffer.pcap

provare a fare l'autenticazione e poi analizzarlo aprendo il file con Wireshark

Nel mio caso ho visto che il server Windows faceva una richiesta NTLMSSP ma il pc linux la rifiutava, restituendo il messaggio "Error: STATUS_MORE_PROCESSING_REQUIRED"

per risolvere il problema, nel file smb.conf aggiungere sempre sotto [global]

ntlm auth = yes