[Lista ArNOG] Tráfico no valido en ITX

Jose Gaspoz gaspozj en is.com.ar
Sab Nov 5 12:36:34 ART 2016


Fernando:


Si te fijas en el trafico de salida de la Wan en ese caso, vas a ver paquetes 
con origen 10.0.0.0/26 saliendo por la Wan sin trasladar.


Si no me equivoco es porque el MK en ese caso esta haciendo PAT y usa el 
connexion tracking para hacer el mapeo (puerto interno a Pat puerto externo 
del 200.1.2.3) y esto esta orientado a la conexion. SI la conexion termina 
por un RST externo , el MK corta la conexion y los paquetes que salen 
despues de eso del origen correspondiente no la encuentran, entonces no 
tienen politica de puertos disponible y salen sin natear.


Si te fijas, siempre en la wan que tiene un mascarade va a ver trafico 
saliente con ips internas.


El el caso de otro SO no orientados a la conexion, no usa la politica de 
tracking para el nateo , por lo que siempre traslada un PAT por mas que las 
conexiones se corten.


NO obstante seria menester Bloquear ese trafico en MK con reglas de salida.


Saludos


José
 
 

-----Original Message-----
 From: "Fernando R. Soto" <fsoto en fi.uba.ar>
 To: <lista en arnog.com.ar>, "'Eduardo Tealdi Saad'" <eduardots en amc.com.ar>
 Date: Sat, 5 Nov 2016 11:51:09 -0300
 Subject: Re: [Lista ArNOG] Tráfico no valido en ITX
 


Hola Jose.  Podrias explicarlo mas? Pq no me quedo claro. 

 

Si el Mk tiene un regla asi:

chain=srcnat action=src-nat to-addresses=200.1.2.3 src-address=10.0.0.0/26 
log=no log-prefix=""

 

cual seria el caso donde el MK no lo natee cuando el paquete salga por la 
wan del router?

 

 

De: lista-bounces en arnog.com.ar [mailto:lista-bounces en arnog.com.ar] En nombre 
de Jose Gaspoz
Enviado el: sábado, 5 de noviembre de 2016 11:16 a. m.
Para: lista en arnog.com.ar; Eduardo Tealdi Saad <eduardots en amc.com.ar>
Asunto: Re: [Lista ArNOG] Tráfico no valido en ITX

 


El caso es que algunos con Mikrotik natean directamente en el borde, y como 
es por conexion, cuando viene un Reset de la conexion desde el destino, el 
tracking del MK da de baja la conexion, por lo que por ejemplo el Reset que 
viene despues desde el host no encuentra el tracking y el nat no lo agarra 
por lo que sale sin trasladar.


 


Si se ponen a ver el tráfico interno que sale sin trasladar desde un MK que 
tiene src-nat o mascarade en su Wan van a ver que es mucho.


 


Esto ocurre por mas que filtren los inválidos de entrada... porque es de 
salida.


 


Saludos


 


Jose 



 

 


-----Original Message-----
From: Eduardo Tealdi Saad <eduardots en amc.com.ar>
To: lista en arnog.com.ar
Date: Fri, 4 Nov 2016 18:08:00 -0300
Subject: Re: [Lista ArNOG] Tráfico no valido en ITX


 Mas facil, habilita MikroTik Neighbor Discovery protocol (MNDP)  y fijate 
quien aparece. si no filtran esto o MAC-server, menos van a filtrar la 
salida de IPs privadas, invalidas o algo peor.


 





O sobre el tunel de PaisDigital





 


Saludos Eduardo


 


 


El 4/11/2016 a las 9:45 a. m., Uriel Rozenbaum escribió:








Hola Pablo,

Nosotros también recibimos un montón de trafico del NAP con origenes 
privados; digo montón porque debería ser 0 y sorprende un poco que alguien 
se haya olvidado el filtro.

También lo mandamos a masa con filtros ya que todo lo que sea privado 
(entrante o saliente, sin distinci{on) que quiera salir por un transito, se 
descarta.

Podríamos impulsar una movida para incentivar a meter filtros, ya que es 
fácil detectar a quién se le escapa:

Yo en lo personal tomo una captura en la interfaz que va al NAP, solamente 
filtrando con la red 10.0.0.0/8 (como ejemplo nomás). Luego la analizo con 
wireshark y veo cuales son las MAC que me llegan:



Despues buscas esas MAC en la tabla ARP para ver a que IP corresponden:
? (200.0.17.107) at 00:12:1e:82:aa:79 [ether] on vlan106
? (200.0.17.121) at d4:ca:6d:01:2e:34 [ether] on vlan106
? (200.0.17.184) at d4:ca:6d:98:98:5a [ether] on vlan106

Despues en el looking glass ves de quien es cada IP:


BGP neighbor is 200.0.17.107,  remote AS 18747, external link
 Description: MIEMBRO: IFX (IFX)

BGP neighbor is 200.0.17.121,  remote AS 27881, external link
 Description: MIEMBRO: IPNEXT SA (IPN)

BGP neighbor is 200.0.17.184,  remote AS 263196, external link
 Description: MIEMBRO: Telwinet (TWN)


Si, me puse la gorra de buchón, pero es por el bien de todos.










 


 


On Thu, Nov 3, 2016 at 5:54 PM, Pablo Moran <pmoran en telecentro.net.ar> wrote:







Buenas tardes. 





 


    Escribo para compartirles esta lista de flujos IP que nos llegan por 
nuestra ITX con C ABASE, nos llama mucho la atención las redes de origen de 
estos flujos, redes privadas RFC1918 (192.168/16, 172.16/12, 10.0/8), que 
intentan acceder redes públicas de nuestra red, esto es solo un extracto 
hay muchos mas flujos que llegan de forma continua. Aclaro que no nos afecta 
debido a que aplicamos filtros en la interfaz de la ITX, los paquetes no 
llegan al destino, pero evidentemente si hay algo que está generando este 
tráfico. 

 


Dicho lo anterior les hago la siguiente consulta

 


¿Alguno de ustedes vio algo parecido o reconoce si estas IPs privadas 
pertenecen a los segmentos que utilizan en sus redes de clientes o redes 
coorporativas?

 

Aggregated flows 455Top 50 flows ordered by bytes:Date first seen          
Duration Proto      Src IP Addr:Port           Dst IP Addr:Port   Out Pkt   
In Pkt Out Byte  In Byte Flows2016-11-03 14:13:40.973     0.000 TCP          
10.6.3.21:61083 <->    190.55.61.221:443          0        1        0     
1003     12016-11-03 10:36:08.445     0.000 TCP       10.33.31.164:46510 <-> 
   190.55.61.204:443          0        1        0      999     12016-11-03 
11:46:07.408     0.000 TCP        192.168.0.4:35958 <->    181.47.248.88:80  
         0        1        0      603     12016-11-03 12:59:09.727     0.000 
TCP          
10.5.1.11:25971 <->     168.83.77.30:80           0        1        0      
590     12016-11-03 06:02:32.451     0.000 TCP          10.1.1.81:443   <->  
 186.19.111.211:32964        0        1        0      393     12016-11-03 
05:57:05.811     0.000 TCP       10.50.114.20:993   <->    
186.18.173.54:62261        0        1        0      156     12016-11-03 
15:59:48.333     0.000 UDP      10.19.193.204:43832 <->     
186.23.58.52:50321        0        1        0      145     12016-11-03 
11:56:51.840     0.000 UDP      10.19.193.204:43832 <->   
181.46.106.174:18118        0        1        0      145     12016-11-03 
06:39:45.140     0.000 UDP         10.3.152.2:35906 <->  
255.255.255.255:5678         0        1        0      140   �
� 12016-11-03 08:24:56.444     0.000 TCP       172.19.15.47:50831 <->     
186.18.65.49:16836        0        1        0      140     12016-11-03 
12:45:38.058     0.000 TCP       10.1.219.250:38911 <->    181.44.74.138:443 
         0        1        0      129     12016-11-03 11:05:07.253     0.000 
TCP        10.1.212.68:48728 <->    181.44.74.147:443          0        1    
    0      129     12016-11-03 15:31:37.815     0.000 TCP         
10.1.212.2:55810 <->    181.44.74.163:443          0        1        0      
129     12016-11-03 06:26:24.664     0.000 UDP        10.225.2.20:5678  <->  
255.255.255.255:5678         0        1        0      127     12016-11-03 
11:46:07.438     0.000 TCP       10.255.255.6:15250 <->     
181.45.139.2:50186   
     0        1        0      108     12016-11-03 14:00:06.547     0.000 TCP  
     10.255.255.6:57865 <->   181.46.165.236:46582        0        1        
0      108     12016-11-03 14:32:08.541     0.000 TCP       
10.255.255.6:53342 <->     181.45.27.38:58732        0        1        0     
 108     12016-11-03 12:51:15.782     0.000 TCP       10.154.10.48:59850 <-> 
   186.18.65.179:28579        0        1        0      108     12016-11-03 
11:02:26.444     0.000 TCP       10.1.219.209:47448 <->    190.55.61.208:443 
         0        1        0      105     12016-11-03 13:23:10.777     0.000 
UDP      192.168.10.57:63398 <->   186.23.224.163:57585        0        1    
    0       91     12016-11-03 09:07:02.552     0.000 TCP         
172.30.1.4:143   <->   181.44.218.105:50508        0        1        0       
85     12016-11-03 15:15:18.797     0.000 TCP         10.90.0.23:49694 <->   
181.47.248.210:443          0        1        0       76     12016-11-03 
10:46:34.385     0.000 UDP     192.168.244.50:60345 <->   200.115.192.89:53  
         0        1        0       75     12016-11-03 15:50:20.988     0.000 
UDP       192.168.0.22:63176 <->   181.47.248.205:443          0        1    
    0       72     12016-11-03 10:59:50.265     0.000 UDP     
192.168.85.100:30166 <->    190.55.61.210:443          0        1        0   
    67     12016-11-03 11:11:03.211     0.000 TCP       10.194.0.192:1236  
<->      186.18.86.1:44487        0        1        0       64     
12016-11-03 11:19:53.552     0.000 UDP       10.160.50.51:63530 <->     
200.16.99.17:53           0        1        0       64     12016-11-03 
12:26:03.474     0.000 TCP     172.17.255.250:49670 <->    
186.19.62.108:17146        0        1        0       60     12016-11-03 
08:38:05.822     0.000 UDP     192.168.244.50:55041 <->   200.115.192.30:53  
         0        1        0       60     12016-11-03 10:28:49.934     0.000 
UDP     192.168.244.50:44206 <->   200.115.192.89:53           0        1    
    0       60     12016-11-03 13:30:40.562     0.000 TCP         
10.1.90.13:8003  <->   181.44.126.234:47774        0        1        0       
60     1
 


Esperamos novedades.

 


Desde ya muchas gracias. 

 


Saludos.

 



Pablo Fernandez Moran 


Ing. de Backbone 



54 11 15-6516-3730 || pmoran en telecentro.net.ar 


 



 


_______________________________________________
Lista mailing list
Lista en arnog.com.ar
http://mailmancabase.interdotnet.com.ar/mailman/listinfo/lista 

 





_______________________________________________Lista mailing 
listLista en arnog.com.arhttp://mailmancabase.interdotnet.com.ar/mailman/listinfo/lista



-- Eduardo Tealdi SaadAdministrador de RedCooperativa Mariano AcostaSuperi 
660, Mariano Acosta (CP 1723)Cel: 221 643-4291eduardots en amc.com.ar 
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mailmancabase.interdotnet.com.ar/pipermail/lista/attachments/20161105/ce1c7af7/attachment-0001.html>


Más información sobre la lista de distribución Lista