[Lista ArNOG] Tráfico no valido en ITX
Jose Gaspoz
gaspozj en is.com.ar
Sab Nov 5 11:15:31 ART 2016
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 CABASE, 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 455
Top 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 Flows
2016-11-03 14:13:40.973 0.000 TCP 10.6.3.21:61083 <->
190.55.61.221:443 0 1 0 1003 1
2016-11-03 10:36:08.445 0.000 TCP 10.33.31.164:46510 <->
190.55.61.204:443 0 1 0 999 1
2016-11-03 11:46:07.408 0.000 TCP 192.168.0.4:35958 <->
181.47.248.88:80 0 1 0 603 1
2016-11-03 12:59:09.727 0.000 TCP 10.5.1.11:25971 <->
168.83.77.30:80 0 1 0 590 1
2016-11-03 06:02:32.451 0.000 TCP 10.1.1.81:443 <->
186.19.111.211:32964 0 1 0 393 1
2016-11-03 05:57:05.811 0.000 TCP 10.50.114.20:993 <->
186.18.173.54:62261 0 1 0 156 1
2016-11-03 15:59:48.333 0.000 UDP 10.19.193.204:43832 <->
186.23.58.52:50321 0 1 0 145 1
2016-11-03 11:56:51.840 0.000 UDP 10.19.193.204:43832 <->
181.46.106.174:18118 0 1 0 145 1
2016-11-03 06:39:45.140 0.000 UDP 10.3.152.2:35906 <->
255.255.255.255:5678 0 1 0 140 1
2016-11-03 08:24:56.444 0.000 TCP 172.19.15.47:50831 <->
186.18.65.49:16836 0 1 0 140 1
2016-11-03 12:45:38.058 0.000 TCP 10.1.219.250:38911 <->
181.44.74.138:443 0 1 0 129 1
2016-11-03 11:05:07.253 0.000 TCP 10.1.212.68:48728 <->
181.44.74.147:443 0 1 0 129 1
2016-11-03 15:31:37.815 0.000 TCP 10.1.212.2:55810 <->
181.44.74.163:443 0 1 0 129 1
2016-11-03 06:26:24.664 0.000 UDP 10.225.2.20:5678 <->
255.255.255.255:5678 0 1 0 127 1
2016-11-03 11:46:07.438 0.000 TCP 10.255.255.6:15250 <->
181.45.139.2:50186 0 1 0 108 1
2016-11-03 14:00:06.547 0.000 TCP 10.255.255.6:57865 <->
181.46.165.236:46582 0 1 0 108 1
2016-11-03 14:32:08.541 0.000 TCP 10.255.255.6:53342 <->
181.45.27.38:58732 0 1 0 108 1
2016-11-03 12:51:15.782 0.000 TCP 10.154.10.48:59850 <->
186.18.65.179:28579 0 1 0 108 1
2016-11-03 11:02:26.444 0.000 TCP 10.1.219.209:47448 <->
190.55.61.208:443 0 1 0 105 1
2016-11-03 13:23:10.777 0.000 UDP 192.168.10.57:63398 <->
186.23.224.163:57585 0 1 0 91 1
2016-11-03 09:07:02.552 0.000 TCP 172.30.1.4:143 <->
181.44.218.105:50508 0 1 0 85 1
2016-11-03 15:15:18.797 0.000 TCP 10.90.0.23:49694 <->
181.47.248.210:443 0 1 0 76 1
2016-11-03 10:46:34.385 0.000 UDP 192.168.244.50:60345 <->
200.115.192.89:53 0 1 0 75 1
2016-11-03 15:50:20.988 0.000 UDP 192.168.0.22:63176 <->
181.47.248.205:443 0 1 0 72 1
2016-11-03 10:59:50.265 0.000 UDP 192.168.85.100:30166 <->
190.55.61.210:443 0 1 0 67 1
2016-11-03 11:11:03.211 0.000 TCP 10.194.0.192:1236 <->
186.18.86.1:44487 0 1 0 64 1
2016-11-03 11:19:53.552 0.000 UDP 10.160.50.51:63530 <->
200.16.99.17:53 0 1 0 64 1
2016-11-03 12:26:03.474 0.000 TCP 172.17.255.250:49670 <->
186.19.62.108:17146 0 1 0 60 1
2016-11-03 08:38:05.822 0.000 UDP 192.168.244.50:55041 <->
200.115.192.30:53 0 1 0 60 1
2016-11-03 10:28:49.934 0.000 UDP 192.168.244.50:44206 <->
200.115.192.89:53 0 1 0 60 1
2016-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 list
Lista en arnog.com.ar
http://mailmancabase.interdotnet.com.ar/mailman/listinfo/lista
--
Eduardo Tealdi Saad
Administrador de Red
Cooperativa Mariano Acosta
Superi 660, Mariano Acosta (CP 1723)
Cel: 221 643-4291
eduardots 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/3e680cb1/attachment-0001.html>
Más información sobre la lista de distribución Lista