Connessione riuscita alle porte 2000 e 5060 nonostante il filtraggio

Question

Connessione riuscita alle porte 2000 e 5060 nonostante il filtraggio

#1 da (3 voti)

7

Eseguo il mio router (basato su Ubuntu) e ho configurato iptables per eliminare tutti i pacchetti in ingresso per impostazione predefinita. Con mia sorpresa, l'esecuzione di una scansione nmap (dal lato WAN) mostra due porte aperte relative a VOIP:

nmap -Pn -v --reason XXX.net

Starting Nmap 7.60 ( https://nmap.org ) at 2018-03-28 09:52 CEST
Initiating Parallel DNS resolution of 1 host. at 09:52
Completed Parallel DNS resolution of 1 host. at 09:52, 0.09s elapsed
Initiating Connect Scan at 09:52
Scanning XXX.net (XXX.XXX.XXX.XXX) [1000 ports]
Discovered open port 21/tcp on XXX.XXX.XXX.XXX
Discovered open port 22/tcp on XXX.XXX.XXX.XXX
Discovered open port 5060/tcp on XXX.XXX.XXX.XXX
Discovered open port 2000/tcp on XXX.XXX.XXX.XXX
Completed Connect Scan at 09:52, 5.17s elapsed (1000 total ports)
Nmap scan report for XXX.net (XXX.XXX.XXX.XXX)
Host is up, received user-set (0.035s latency).
Not shown: 995 filtered ports
Reason: 995 no-responses
PORT     STATE  SERVICE    REASON
21/tcp   open   ftp        syn-ack ttl 52
22/tcp   open   ssh        syn-ack ttl 54
113/tcp  closed ident      reset ttl 254
2000/tcp open   cisco-sccp syn-ack ttl 61
5060/tcp open   sip        syn-ack ttl 61

Read data files from: /usr/local/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 5.33 seconds

ftp e ssh sono corretti, poiché questi due servizi sono configurati sul router. Ma cisco-sccp e sip che si aprono sono notizie per me.

In effetti, una connessione telnet ad entrambe le porte ha esito positivo:

telnet XXX.net 2000
Trying XXX.XXX.XXX.XXX...
Connected to XXX.net.
Escape character is '^]'.

telnet XXX.net 5060
Trying XXX.XXX.XXX.XXX...
Connected to XXX.net.
Escape character is '^]'.

Ma l'esecuzione di netstat -talpn sul router mentre la sessione telnet è attiva non mostra alcuna connessione stabilita per nessuna delle due porte. E il registro mostra che iptables elimina i pacchetti:

Mar 27 20:52:16 router DROP INPUT  IN=ppp0 OUT= MAC=MM:MM:MM:M SRC=YYY.YYY.YYY.YYY DST=XXX.XXX.XXX.XXX LEN=60 TOS=00 PREC=0x00 TTL=51 ID=39215 DF PROTO=TCP SPT=52200 DPT=2000 SEQ=106277563 ACK=0 WINDOW=42340 SYN URGP=0 MARK=0

dove YYY.YYY.YYY.YYY è l'IP di cui telnet connette.

La mia diagnosi è corretta?

Se sì, come può telnet stabilire una connessione, anche se i pacchetti vengono rilasciati sul router? Chi sta ascoltando sulle porte 2000 e 5060?

voip ports nmap iptables

posta Christian David 27.03.2018 - 21:13

fonte

1 risposta

Leggi altre domande sui tag voip ports nmap iptables

L'esecuzione di un browser in modalità compatibilità Windows può essere un problema di sicurezza? Flask debug = True exploitation

score 3 · Accepted Answer

C'è qualcosa tra lo scanner e la destinazione che sta rispondendo per conto della destinazione, spoofing il suo indirizzo di origine in modo tale da sembrare essere il bersaglio stesso. Quando hai eseguito la scansione Nmap come root con --reason -v , mostrava i valori TT Time-to-Live (TTL) dei pacchetti di risposta per ciascuna porta:

PORT     STATE  SERVICE    REASON
21/tcp   open   ftp        syn-ack ttl 52
22/tcp   open   ssh        syn-ack ttl 54
113/tcp  closed ident      reset ttl 254
2000/tcp open   cisco-sccp syn-ack ttl 61
5060/tcp open   sip        syn-ack ttl 61

Il campo TTL inizia con un certo numero (in genere 128 o 64) e viene decrementato da ciascun router IP o hop intermedio. Se qualsiasi campo TTL ricevuto è inaspettatamente alto, può significare che il pacchetto è arrivato più vicino allo scanner del previsto, cioè da uno degli hop.

Hai detto che 21 e 22 dovevano essere aperti. Hanno valori TTL diversi, il che potrebbe significare che uno di essi (FTP) viene inoltrato a un sistema all'interno della rete, o potrebbe significare che vi è un certo routing asimmetrico in corso che determina un percorso diverso ogni volta. Ma la vera domanda è oltre il 2000 e il 5060, che sono 7 hop più vicini della distanza più vicina prevista. Questi sono quasi certamente intercettati.

Dovresti essere in grado di determinare quale hop intercetta il traffico conducendo un traceroute. Nmap può essere usato per fare questo, se si limita il suo traffico alla porta in questione:

nmap --traceroute -Pn -p 2000 example.com

Questo mostrerà una serie di luppolo che culminerà in quello "dal" target. In realtà è più probabile che sia l'hop oltre l'ultimo hop in questa lista. Confrontalo con il traceroute per una porta che agisce come previsto. Ad esempio, se la tua scansione appare così:

# nmap --traceroute -Pn -p 2000 example.com
TRACEROUTE (using port 2000/tcp)
1   2.04 ms  gateway (192.168.1.1)
2   14.37 ms 10.100.96.1
3   15.60 ms example.com (192.0.2.5)

# nmap --traceroute -Pn -p 22 example.com
TRACEROUTE (using port 22/tcp)
1   2.04 ms  gateway (192.168.1.1)
2   14.37 ms 10.100.96.1
3   15.60 ms 182.23.16.88
4   10.11 ms 182.23.16.82
5   44.73 ms example.com (192.0.2.5)

L'ultimo hop comune è 10.100.96.1. L'hop successivo nella sequenza è 182.23.16.88, che è probabilmente quello che sta falsificando la risposta.

Per quanto riguarda perché queste porte potrebbero essere falsificate, noto che SCCP (port 2000) e SIP (porta 5060) sono entrambi servizi VoIP. Forse il tuo ISP non vuole che tu stia utilizzando un server VoIP, un client o un relay e stia usando questo metodo per impedirlo?