ANALISI/PROTO


####################################

Nslookup - Dig (linux)

-Determinare server di posta -


Quando si invia un’email il sistema deve conoscere il server SMTP incaricato di recapitare la posta elettronica di un dato dominio.
Questa operazione viene effettuata tramite un’interrogazione al DNS, alla ricerca dei record MX.
Ho scritto “dei record” perché i record MX, ovvero le informazioni che il DNS utilizza per identificare i server di posta elettronica, potrebbero essere più di uno.
Possiamo conoscere quale server gestisce la posta interrogando il DNS manualmente.
Per farlo è possibile utilizzare nslookup dalla linea di comando.

Apriamo una shell (cmd.exe su Windows) ed entriamo in nslookup digitando il nome del comando:
C:\nslookup
 
Otterremo l’accesso al prompt di nslookup:
Server predefinito:  resolver1.opendns.com
Address:  208.67.222.222
 
Per effettuare l’interrogazione dobbiamo specificare che siamo alla ricerca di record MX:
> set q=mx
dove q sta per query.

A questo punto non rimane che digitare il nome del dominio di cui vogliamo ottenere gli indirizzi dei server SMTP:
> set q=mx
> pillolhacking.net
Server:  resolver1.opendns.com
Address:  208.67.222.222
 
Risposta da un server non di fiducia:
pillolhacking.net       MX preference = 10, mail exchanger = m-04b.th.seeweb.it
pillolhacking.net       MX preference = 20, mail exchanger = smtp-avas.seeweb.it
La risposta del DNS mostra i due server che gestiscono la posta di pillolhacking.net.

Quando qualcuno scrive un’email a pillolhacking.net, il server incaricato di recapitarla è m-04b.th.seeweb.it.

Da notare i valori MX preference che indicano la priorità di utilizzo del server.
Il numero più basso indica la priorità maggiore.
Il server con il valore MX preference più basso (in genere 10) viene utilizzato per inviare la posta; gli altri sono utilizzati come backup nel caso in cui il server principale non dovesse esere disponibile.

Per curiosità possiamo guardare a casa di altri più celebri sistemi come Google:
> gmail.com
Server:  resolver1.opendns.com
Address:  208.67.222.222
 
Risposta da un server non di fiducia:
gmail.com       MX preference = 10, mail exchanger = alt2.gmail-smtp-in.l.google
.com
gmail.com       MX preference = 50, mail exchanger = gsmtp147.google.com
gmail.com       MX preference = 50, mail exchanger = gsmtp183.google.com
gmail.com       MX preference = 5, mail exchanger = gmail-smtp-in.l.google.com
gmail.com       MX preference = 10, mail exchanger = alt1.gmail-smtp-in.l.google
.com
 
 
Example
nslookup openskills.info


####################################

Microsoft NTLM

Windows Challenge/Response (NTLM) is the authentication protocol used on networks that include systems running the Windows operating system and on stand-alone systems.
The Microsoft Kerberos security package adds greater security than NTLM to systems on a network. Although Microsoft Kerberos is the protocol of choice, NTLM is still supported. NTLM must also be used for logon authentication on stand-alone systems. For more information about Kerberos, see Microsoft Kerberos.
NTLM credentials are based on data obtained during the interactive logon process and consist of a domain name, a user name, and a one-way hash of the user's password. NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user's password over the wire. Instead, the system requesting authentication must perform a calculation that proves it has access to the secured NTLM credentials.
Interactive NTLM authentication over a network typically involves two systems: a client system, where the user is requesting authentication, and a domain controller, where information related to the user's password is kept. Noninteractive authentication, which may be required to permit an already logged-on user to access a resource such as a server application, typically involves three systems: a client, a server, and a domain controller that does the authentication calculations on behalf of the server.
The following steps present an outline of NTLM noninteractive authentication. The first step provides the user's NTLM credentials and occurs only as part of the interactive authentication (logon) process.
  1. (Interactive authentication only) A user accesses a client computer and provides a domain name, user name, and password. The client computes a cryptographic hash of the password and discards the actual password.
  2. The client sends the user name to the server (in plaintext).
  3. The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client.
  4. The client encrypts this challenge with the hash of the user's password and returns the result to the server. This is called the response.
  5. The server sends the following three items to the domain controller:
    • User name
    • Challenge sent to the client
    • Response received from the client
  6. The domain controller uses the user name to retrieve the hash of the user's password from the Security Account Manager database. It uses this password hash to encrypt the challenge.
  7. The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful.
Your application should not access the NTLM security package directly; instead, it should use the Negotiate security package. Negotiate allows your application to take advantage of more advanced security protocols if they are supported by the systems involved in the authentication. Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos unless it cannot be used by one of the systems involved in the authentication.



####################################

MTU

Maximum Transmission Unit

Da Wikipedia, l'enciclopedia libera.
In telecomunicazioni con Maximum Transmission Unit (MTU) (in italiano Unità massima di trasmissione) si indica le dimensioni massime in byte di un pacchetto dati che può essere inviato attraverso un protocollo di comunicazione in una rete di telecomunicazioni. Tale parametro è di solito associato alle interfacce di comunicazione quali schede di rete o porte seriali.
Il concetto di MTU si ripresenta a diversi livelli, assumendo diversi nomi, ma il termine MTU indica propriamente la dimensione massima del pacchetto in IP. IP viene molto spesso trasportato su ethernet, che ha normalmente uno spazio massimo di 1500 byte per il campo dati, a cui si aggiungono 18 byte [14 byte di intestazione ethernet + 4 byte di Cyclic redundancy check (CRC)], portando la dimensione massima del frame ethernet a 1518 byte. La MTU tipica su Internet è quindi di 1500 byte. Di questi, 20 sono normalmente occupati dall'header IP. Se viene utilizzato il protocollo TCP, questo occupa normalmente altri 20 byte per i propri header. Il carico pagante (segmento) di un pacchetto TCP è quindi tipicamente di 1460 byte. TCP possiede un meccanismo per negoziare il "Maximum Segment Size" (dimensione massima del segmento, o MSS). Normalmente, MSS = MTU - 40.

Indice

 [nascondi

MTU in IP e frammentazione [modifica]

Quando un host deve trasmettere un pacchetto IP, terrà conto della MTU dell'interfaccia su cui trasmette il pacchetto. Lungo il suo percorso, il pacchetto potrà però incontrare collegamenti con una MTU inferiore, su cui non potrà essere trasmesso come tale. In questi casi, il router IP che deve trasmettere un pacchetto su una interfaccia che ha un MTU inferiore alla dimensione del pacchetto, effettua automaticamente la frammentazione, ovvero divide il pacchetto in due o più pacchetti più piccoli. I frammenti del pacchetto originale sono contrassegnati in modo che il protocollo IP di destinazione sia in grado di riassemblare i pacchetti nell'originale.
Un qualsiasi router lungo il cammino potrebbe dover frammentare un pacchetto, e l'host di destinazione dovrà ricostruire il pacchetto originale dai frammenti.

Evitare la frammentazione [modifica]

La frammentazione consente a IP di lavorare correttamente su una rete composta di collegamenti con MTU eterogenea, ma è una operazione onerosa per i router e per l'host che riceve i pacchetti frammentati, quindi si cerca di evitarla quando possibile.
Viene detto "MTU del cammino" il più piccolo MTU di uno qualsiasi dei collegamenti che compongono il "cammino" dall'indirizzo della fonte a quello di destinazione. Visto in un altro modo, l'MTU del cammino è il più grosso valore dell'MTU che può attraversare il "cammino" senza essere ulteriormente frammentato.
L'RFC 1191 descrive "La scoperta dell'MTU del cammino" (in inglese "Path MTU Discovery", o più brevemente "PMTU discovery"), una tecnica per determinare l'MTU del cammino tra due host IP, così che quella frammentazione possa essere evitata. Un host invia inizialmente un pacchetto IP della dimensione corrispondente alla MTU locale con il bit DF (Don't Fragment --- Non Frammentare) settato a uno. Se un router lungo il cammino ha bisogno di frammentare il pacchetto, ma questo ha il bit DF a uno, il router lo abbandona, e manda un pacchetto ICMP di tipo "datagramma troppo grosso" all'indirizzo sorgente per segnalare il problema. Nel pacchetto ICMP è indicato anche l'MTU del link che ha causato l'abbandono. Questa operazione viene ripetuta finché il pacchetto non giunge a destinazione. L'host sorgente in questo modo "impara" il più grosso MTU che può passare attraverso quel cammino senza frammentarsi. L'operazione può essere eventualmente ripetuta se il percorso viene modificato.
Sfortunatamente un numero crescente di reti bloccano tutto il traffico ICMP a causa dell'erronea convinzione che ciò migliori la sicurezza e questo impedisce alla scoperta dell'MTU del cammino di funzionare. Il sintomo di questa situazione è che una connessione funziona fino a quando deve trasmettere pacchetti di piccole dimensioni, ma si blocca quando viene inviato un grosso blocco di dati, che viene diviso in pacchetti di dimensione massima (per esempio con IRC un client potrebbe vedere fino al "nospoof ping" ma non ottenere risposta dopo di esso, poiché il grosso numero di messaggi di benvenuto blocca la connessione).
Ad esempio, sulle moderne reti ethernet LAN, l'MTU è di 1500 byte. Sistemi come il PPPoE lo riducono, rendendo necessaria la scoperta dell'MTU del cammino, con la possibilità di rendere inaccessibili i siti che si trovino dietro ad un firewall mal configurato.
In questi casi, una soluzione spesso adottata è la modifica in transito dell'MSS dei pacchetti TCP. Questa funzionalità è presente in molti router, e andrebbe idealmente configurata sui router a cui è connesso il collegamento di MTU inferiore. Si tratta di una operazione che modifica il contenuto di un pacchetto in transito (TCP fa parte del carico pagante di IP, e quindi non dovrebbe essere modificato da un router IP), e quindi viola il principio di semplicità e di comunicazione end-to-end di Internet. Inoltre, risolve il problema solo per TCP, non per UDP (che non ha un analogo della MSS) o altri protocolli di trasporto.
Un'altra soluzione meno elegante e subottimale è abbassare la MTU sulle interfacce degli host o dei router per portarle a pari con la MTU del cammino.


####################################