VPSs y mas.

Mostrando entradas con la etiqueta seguridad. Mostrar todas las entradas
Mostrando entradas con la etiqueta seguridad. Mostrar todas las entradas

jueves, 23 de marzo de 2017

BGP: Filtrar por tamaño de la red en BGP, he ahí el dilema

Introducción
 El equipo de I+D del área técnica y WARP redactaron en conjunto el presente artículo basado en algunos incidentes gestionados por el centro de respuestas de LACNIC.
 En el mundo de BGP existen decenas de maneras para filtrar prefijos. El objetivo del presente post mostrar una serie de recomendaciones para tener una red más estable, no perder conectividad con ciertos destino y reducir el número de quejas en nuestro NOC.


Situación identificada
  Muchos ISPs no pueden recibir la full routing table de BGP (para el dia de hoy consta de ~610.000 prefijos IPv4) en sus enrutadores.
  Lo anterior puede deberse a diversas razones:
  • El enrutador no posee suficiente RAM para aprender todos los prefijos (además recordar que es posible que el router tenga varias sesiones BGP)
  • Por ahorro de CPU
  • Porque el upstream provider a su vez no entrega toda la tabla de enrutamiento
  • Por simplicidad y sencillez


 Entendiendo la situación e independientemente de la razón que sea, el enrutador no aprende toda la tabla de enrutamiento.


Problema
  No aprender toda la tabla de enrutamiento puede traer algunos inconvenientes parciales pero que al final trae problemas de conectividad, quejas de los usuarios, inconvenientes de acceso a ciertos sitios, entre otros.


¿Por qué?
  Imaginemos la siguiente situación:
  1. Tengo un router (propiedad de EXAMPLE) en Internet que solo aprende la tabla parcial de enrutamiento
  2. El router propiedad de EXAMPLE quedó configurado solo para aprender redes “más grandes” que /21. Es decir, aprende redes /20, /19, /18, etc.  (evidentemente estamos hablando de IPv4)
  3. Debido a la configuración establecida en el punto “b”, el router no aprenderá prefijos de tamaño /21, /22, /23 ni /24
  4. Mientras tanto en otra parte del mundo, le acaban de secuestrar su red /21 a la empresa ACME (planteamos el caso como un secuestro pero podría ser una mala configuración)
  5. ACME decide realizar anuncios más específicos de su red original /21, es decir, anuncia 8 redes /24
  6. Por causa de los filtros configurados por EXAMPLE, nunca verá dichos anuncios /24 de ACME
  7. EXAMPLE seguirá aprendiendo la red /21 del secuestrador de la red. Lo que puede ocasionar que el tráfico hacia ACME puede ser potencialmente secuestrado (repito, se entiende que esta situación es potencial, no necesariamente el tráfico irá hacia el atacante)


Diagrama:
  El siguiente diagrama representa la hipótesis planteada en el punto anterior de manera gráfica para facilitar su comprensión.
Articulo BPG.png

Recomendación
 Realizaremos la siguiente recomendación en base a algunas experiencias vividas, teniendo en cuenta que solo aplican al caso de cuando no se pueda aprender/recibir la tabla completa de BGP:
  1. No filtrar permitiendo redes menos específicas. Es conveniente aprender redes más chicas, es decir: /24, /23, /22.
  2. Filtrar por AS_PATH de profundidad.
  3. Crear los ROAs respectivos a los prefijos (RPKI).


Algunos ejemplos (Cisco like)
1)  Solo queremos aprender redes entre /22 y /24 (hay otras maneras de hacer esto):

router bgp 65002
neighbor 10.0.0.1 remote-as 65001
neighbor 10.0.0.1 route-map FILTRO-IN in
!
ip prefix-list REDESCHICAS seq 5 permit 0.0.0.0/0 ge 22 le 24
!
route-map FILTRO-IN permit 10
match ip address prefix-list REDESCHICAS
!


2) Solo queremos aprender dos AS de profundidad (hay otras maneras de hacer esto):


router bgp 65001
neighbor 10.0.0.2 remote-as 65002
neighbor 10.0.0.2 route-map ASFILTER-IN in
!
ip as-path access-list 5 permit ^[0-9]+_$
ip as-path access-list 5 permit ^[0-9]+ [0-9]+_$
!
route-map ASFILTER-IN permit 10
match as-path 5
!


Mas información



Autores
- Dario Gomez
- Alejandro Acosta (@ITandNetworking)

sábado, 28 de noviembre de 2015

Carta de Lacnic Labs a Papa Noel

Querido Papá Noel, alias Santa Claus,

  Quiero comenzar esta carta dándote un gran saludo,  ojalá también pudiese darte un fuerte abrazo. Hace mucho que no te escribía, siento una felicidad interna indescriptible e inesperada.
  Quizás te extrañe un poco que vuelva a aparecer luego de tantos años, dicen que nunca es tarde, te aseguro que el cariño es el mismo, perdón, hoy en día es mayor, he aprendido a comprenderte y admirar tu trabajo, mis felicitaciones a tú persona!! :-)
  Antes de continuar no puedo omitir indicarte que todo el año me he portado muy bien, he hecho mis tareas cabalmente, ayudo al prójimo, he intento ser parte de la solución y no del problema. Claro, tú lo sabes todo pero quería decírtelo para prevenir, alguna se te debe escapar.
  Ahora bien, vamos al grano, se que tienes mucho trabajo y sobre todo en estas fechas, tu tiempo es valioso así que no voy a extenderme mucho.
  Te escribo no por mí, desde chico me enseñaron a pedir para los demás, en esta ocasión voy a pedir por alrededor de 600 millones de latinoamericanos, suena mucho pero créeme que solo hay que enfocarse en una pequeña cúpula de personas.., el resto viene solo.
  ¿Qué voy a pedir para toda esta gente?…, cosas más sencillas que lo que parecen, me han dicho que no sabes mucho de tecnología y por ello voy a explicarte muy breve cada regalito.., ahh, tampoco voy a pedir mucho, me han enseñado a máximo tres regalos y sin garantía de que se cumpla…., pienso que mis padres repetían lo que tu le decías a ellos.
  Quiero para esta navidad o durante el 2016:

- Un Internet más seguro… Santa, puedes creer que existen muchas tecnologías de seguridad y aún no las implementan!, muchas gratis y sencillas, bueno Santa, esta no puede faltar. Pls!
- Mejores interconexiones… con esto quiero decir más IXPs, más conexiones entre ISPs y diferentes entidades. Esto trae ahorre de costos, mejor rendimiento, mayor uptime de servicios, facilidad de troubleshooting y muchas cosas más. Es una práctica mundialmente aplaudida y comprobada y aún hay gente que no esta convencida. ¿Me ayudas?
- Y por último…, más IPv6 en la región!. ¿Puedes creer que el promedio aún es ligeramente mayor al 1% en LAC?.., estamos hablando de un protocolo que va a ayudar a los países a ser más productivos, a mejorar la calidad de vida de la gente, a disminuir la rata de falla en las aplicaciones y aún así mucha gente no da el paso a implementarlo. ¿Cuento contigo?


  En estos tiempos tan difíciles de gusanos, backdoors, rootkits, troyanos, secuestro de redes e información creo que mi solicitud no es una cosa loca, se que no es fácil pero entre todos podemos :-)   Ahh, no debemos olvidar el otro casi 50% de la población que aun no cuenta con Internet, afortunadamente este indicador se mueve a favor de mí deseo pero me encantaría que fuese más rápido, no por mí, sino por ellos.

  Antes de finalizar la carta no quiero despedirme sin enviarle saludos a la señora Santa y a los renos -en especial a Rodolfo!!-, quienes han hecho pasar horas de infinita alegría a millones de niños.  Espero todos tengan su tablet y su conexión a Internet con IPv6, sino me avisas y vemos si podemos conectarte en el Polo Norte…, creo que no lo cubre Lacnic pero te extendemos nuestro apoyo.

  Recibe un gran saludo, ojalá pases por mí casa  y en vez de dejarte unas galletas  y leche, te daré un modem Wifi 802.11ac y un SSD.

Un fuerte abrazo con mucho amor

Lacnic Labs

miércoles, 27 de mayo de 2015

Sinopsis FLIP6 Lima Peru 18-22 de Mayo 2015

Buenas dias a todos(as),


 Una vez más para mi es un honor realizar este resumen. En esta
oportunidad me corresponde sobre el Decimotercer Foro Latinoamericano de
IPv6 (FLIP6) llevado a cabo durante el evento de Lacnic 23 en Lima -
Perú entre los días 18 al 22 de Mayo del presente año.

 Todos los eventos son especiales, cada uno tiene su propia magia, sin
embargo esta oportunidad venía acompañado de un contexto adicional por
ser mi último año como moderador del foro.

 En Lima, FLIP6 tuvo una duración de 6 horas divididas en tres días
consecutivos. Para el evento hubo más de 450 personas en sitio y
aproximadamente 100 personas haciendo seguimiento vía Webcasting. Para
el momento que se escriben estas líneas parte de las presentaciones se
encuentran en youtube.com ([1]) y en el sitio guindadas en la web de
Lacnic ([2]).

 Hablando del evento per sé: contamos con los siguientes expositores más
un panel (la agenda puede ser conseguida también en [2]):


Expositores:

- John Correa

 John Correa estaba exponiendo por primera vez durante FLIP6, su tema
fue "Asegurando servicios IPv6 en Linux". El tópico indiscutiblemente es
considerado un tema muy importante en estos tiempo donde las
implementaciones de IPv6 se están llevando a cabo a un ritmo acelerado.
Desde FLIP6 además de incentivar el protocolo lo queremos promover de
manera segura.


- Panel: Fabricantes e IPv6

 El Panel fue una iniciativa de Lacnic que vino como resultado de las
encuestas realizadas en eventos previos donde los asistentes
manifestaban que sería buena idea contar con los propios fabricantes
hablando directamente de su soporte de IPv6 en sus productos.

 El Panel estuvo compuesto por los siguientes panelistas:

 - Tomás Lynch, Ericsson
 - Hugo Peña - Alcatel-Lucent
 - Wardner Maia, Mikrotik
 - Enrique Dávila, Cisco


 Al final esta presentación fue muy exitosa, en lo personal tuve muy
buen feedback y siempre escuchar del propio vendor hablar de su soporte
IPv6 es muy beneficioso.


- John Brzozowski - KeyNote

 Como es costumbre, dentro del FLIP6 contamos con la presencia de un
Keynote, en esta oportunidad le correspondió a un amigo de la casa: John
Brzozowski. Durante su presentación cubrió diferentes temas relevantes a
IPv6: Desde estadísticas, novedades en Comcast, importancia de IPv6
entre otros. Este tipo de exposiciones esperemos apoyen a la difusión
del protocolo a lo largo y ancho de nuestra región.


- Jordi Palet - 464XLAT

 Jordi, viejo amigo de la casa, expuso sobre una interesante tecnología
la cual ha tenido mucha  adopción y probablemente se masifique más su
implementación en un corto tiempo. Su presentación trató sobre el
mecanismo de transición 464XLAT. Esperamos haya sido educativo y le
sirva de puente a muchos para implementar IPv6 en sus redes


- Gregorio Manzano - Iniciativa comunitaria para despliegue del
protocolo IPv6 en Venezuela

 Esta presentación trató sobre como un grupo de lideres en Internet en
Venezuela llevaron a cabo la formación de un grupo para promover IPv6 en
su país. Gregorió abarcó desde sus inicios hasta la entrega de un
documento al gobierno de Venezuela. Felicitamos esta iniciativo y ojalá
existan más en la región.


- Kathleen Moriarty - IETF CodeMatch

 Por primera vez en FLIP6 tuvimos a Kathleen Moriarty quien trabaja muy
de cerca con ISOC y la IETF. Nos expuso sobre una excelente iniciativa
llamada CodeMatch donde se busca acercar a las universidades de la
región a la IETF. Kathleen explicó en que consiste y como convertirse en
parte de esta interesante iniciativa. Deseamos ver muchas universidades
de la región involucradas en este tipo de proyectos.


- Fernando Gont - Avances recientes en seguridad de IPv6 y Evaluaciones
de seguridad y resolución de problemas con el IPv6 Toolkit v2.0 de SI6

 Fernando, otro amigo de la casa, tuvo la oportunidad de realizar dos
exposiciones durante FLIP6, ambas muy relaciones a seguridad de red.
Expuso de una manera muy pedagógica basado en ejemplos de como utilizar
IPv6 Toolkit y adicionalmente indicó temas muy importantes de seguridad
en el mundo de IPv6. Una vez para nuestro foro no es solo fomentar IPv6
sino promoverlo dentro de un contexto de implementación segura y basado
en mejores prácticas. Esperamos que con este tipo de charlas educar al
asistentes y fortalecer las redes en la región.


- Enrique Davila - Operar en forma segura redes IPv6

 Enrique Dávila, exponía por primera vez en FLIP6, explicó de una manera
práctica diversas tareas que pueden llevar a cabo los administradores de
redes para operar de mejor manera una red IPv6. Indicó diversos consejos
y prevenciones que pueden tomarse en cuenta con el objetivo de aumentar
la seguridad de una red IPv6. Estamos seguro que esta junto a otras
exposiciones llevadas a cabo durante el FLIP6 permitirán al asistente en
incrementar la seguridad de sus redes.


- Gianpietro Lavado - Segment-Routing in IPv6

  Gianpietro expuso sobre un tema muy novedoso llamado Segment-Routing,
específicamente lo enfocó al área de IPv6. Indicó sus ventajas y
posibles implementaciones que existirán en el futuro cercano. Desde
FLIP6 nos encantan este tipo de temas porque nos permiten estar
enterados en lo que acontece en el marco de la IETF y a su vez
prepararnos mejor para lo que viene en el mundo de enrutamiento en un
futuro no muy lejano


- Mariela Rocha - Informe Portal IPv6

 Mariela Rocha (ex-moderadora de FLIP6*)* nos acompañó en esta
oportunidad para indicarnos avances que existen en el portal IPv6 de
Lacnic [3]. Nos explicó diferentes aspectos y noticias que se guindan en
el mismo, contenido nuevo que tiene y como participar en el mismo. Nos
recordó que el portal es de la comunidad y cada uno de nosotros puede
ser participe del mismo. Ójala esta exposición incentive al asistente a
engranarse con el portal IPv6.


Miscelaneos.

 En este oportunidad el moderador también hizo algunos anuncios:


- Se presentó la canción IPv6 [4]  (favor escucharla y recordar colocar
los subtítulos)

- Se presentó una animación llamada: "La triste historia de un ISP sin
IPv6" [5]

- El actual moderador anunció próximas elecciones para Junio 2015
indicando su intención de no postularse para las mismas. De igual manera
enfáticamente indicó que este cargo ha sido muy enriquecedor dentro de
su vida profesional.


Reciban todos un fuerte abrazo y como siempre quedando a sus ordenes.



Att.

Alejandro Acosta

Moderador
FLIP6 2015



[1] https://www.youtube.com/playlist?list=PLU6Q4ZhHN2Q6Iw4rb9paNKIwYGhEMLCZK

[2] http://www.lacnic.net/en/web/eventos/lacnic23-foro-flip6

[3] http://portalipv6.lacnic.net

[4] https://www.youtube.com/watch?v=99Qw9cfpyEg
Créditos a:
Antonio Esguerra: Head Engineer
Michae Schulze: Co-producer
Eidan Molina: Co-producer. Composer.
Music and Lyrics by Eidan Molina
Agrupacion de producción: Fifth Floor Studios
Idea: Alejandro Acosta

[5] https://www.youtube.com/watch?v=BswW2uVHoX0*
Créditos a:

Guion: Alejandro Acosta,
Producido en: Universidad de
Guadalajara Coordinacion General de Tecnologia de Informacion, Animacion
y Diseno: Marco Sierra,

Voz:**Dolores Hernandez - Red Radio Universidad de Guadalajara,
Grabacion: Mauricio Urbina - Red Radio

Universidad de Guadalajara, Edicion: de Sonido Marco Sierra, Tema
Musical: "Children" Matti Paalanen.

miércoles, 6 de mayo de 2015

Demostracion de Secuestro de Prefijos - RPKI - BGP (parte 2/2)


En este segundo video se muestra como manipular Quagga para que tome decisiones en base al estado del prefijo RPKI. Continuacion de: https://blog.acostasite.com/2015/05/demostracion-de-secuestro-de-prefijos.html

martes, 5 de mayo de 2015

Demostracion de Secuestro de Prefijos - RPKI - BGP (parte 1/2)


El video muestra un ejemplo de como ocurre un secuestro de un prefijo de red en Internet y a su vez muestra como RPKI ayudaría a prevenir esta situación

martes, 9 de diciembre de 2014

Python Script: Probably useless but functional IPv6 Network scanner

Below is the code of what is probably useless but a functional IPv6 host scanner written in Python using threading.

To perform a regular (brute force) network scans in an IPv6 Network is almost impossible and it can take over 5.000 years to finish.

This project was purely academic and I just wanted to learn about threading in Python.

This software is not recommended for general usage.....

This  script  will call the OS to actually perform the ping

This software receives two parameters:
a) Prefix to scan in the format 2001:db8::/64 (subnet, not host)
b) Number of simultaneous processes it can run (MAXPINGS)

One more time it was purely academic stuff but hopefully it can make your day

Finally, AFAIK nmap does not yet support IPv6 network scan.

The code was written in python3:

--- cut here ---

#!/usr/bin/python3

import threading
import sys
import ipaddress
import subprocess
import time

CURRENTPINGS=0 # Number of simultaneous ping at a time

def DOPING6(IPv6ADDRESS):
  global MAXPINGS, CURRENTPINGS
  CURRENTPINGS+=1
  CMD="ping6 -c 3 "+str(IPv6ADDRESS) + " 2> /dev/null > /dev/null"
  return_code = subprocess.call(CMD, shell=True)
  if return_code == 0:  #If ping was succesful
    print (IPv6ADDRESS," is alive")

  CURRENTPINGS-=1

def main():
  global MAXPINGS, CURRENTPINGS
  if len(sys.argv) != 3: #Validate how many parameters we are receiving
    print("  Not enough or too many parameter")
    print("  Usage: ./scanipv6.py IPv6Prefix/lenght MAXPINGS")
    print("  Example: ./scanipv6.py 2001:db8::/64 20")
    print("  Prefix lenght can be between 64-128")
    print("  MAXPINGS corresponds to how many pings will be running at the same time")
    exit()

  SUBNET,MASK=sys.argv[1].split("/")
  MAXPINGS=int(sys.argv[2])

  for addr in ipaddress.IPv6Network(sys.argv[1]):  #Let's loop for each address in the Block
    ping_thread=threading.Thread(target=DOPING6,args=(addr,))

    while CURRENTPINGS >= MAXPINGS: # With this while we make it possible to run max simultaneous pings
      time.sleep(1)  # Let's wait one second before proceeding
      #print ("Interrumping...., CURRENTPINGS > MAXPINGS") #Uncomment this line just for debugging

    ping_thread.start()

main()

lunes, 10 de febrero de 2014

Configurando Quagga para manipular prefijos (Local Preference) utilizando RPKI

Objetivo:
   En el siguiente mini laboratorio configuraremos Quagga para manipular prefijos BGP y asignar Local Preference segun el estado RPKI (valid, invalid, Not Found).
 
Escenario:
- R1 publica un prefijo con un AS que no le corresponde (segun ROA)
- R2 publica el mismo prefijo que R1 pero desde un AS que si es valido
- R2 publica un prefijo sin ROA.
- En este escenario el validador y el router Quagga estan en el mismo equipo

Diagrama del laboratorio:




Requisitos:
- Quagga con soporte para RPKI
- RPKI Validator de RIPE NCC
- Un prefijo que sepamos que se tiene ROA valido. En nuestro caso utilizamos el prefijo 200.85.64.0 que sabiamos que tiene un ROA que indica que debe ser publicado por el AS 7908
- Ejecutar el validador de RIPE NCC antes de ejecutar Quagga


Configuraciones de todos los equipos

Conf-Quagga-RPKI-Mini-LAB.txt

hostname RPKI-RTR
password test
!
router bgp 65000
 bgp router-id 10.0.0.10
 bgp bestpath prefix-validate allow-invalid
 neighbor 10.0.0.1 remote-as 65001
 neighbor 10.0.0.1 route-map rpki in
 neighbor 10.0.0.2 remote-as 7908
 neighbor 10.0.0.2 route-map rpki in
 neighbor 10.0.0.3 remote-as 65003
 neighbor 10.0.0.3 route-map rpki in
!
route-map rpki permit 10
 match rpki invalid
 set local-preference 10
!
route-map rpki permit 20
 match rpki valid
 set local-preference 30
!
route-map rpki permit 30
 match rpki notfound
 set local-preference 20
!        
line vty
!
enable-rpki
  rpki polling_period 1000
  rpki timeout -1216757171
!
  rpki group 1
    rpki cache 127.0.0.1 8282
! 

R1.cfg

!

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
enable password test
!
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
!
ip cef
ip audit po max-events 100
!
!
!
!
ip tcp synwait-time 5
! 
!
!
!
interface Ethernet0
 ip address 10.0.0.1 255.255.255.0
 half-duplex
!
interface FastEthernet0
 no ip address
 shutdown
 speed auto
!
router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 network 200.85.64.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 200.85.64.0 255.255.255.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 password test
 login
!
end

R2.cfg

!
!
!
!
hostname R2
!
no ip domain lookup
no ip icmp rate-limit unreachable
ip tcp synwait 5
!
!
interface Ethernet0
 ip address 10.0.0.2 255.255.255.0
 half-duplex
!
!
router bgp 7908
 no synchronization
 bgp log-neighbor-changes
 network 200.85.64.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 200.85.64.0 255.255.255.0 Null0
no ip http server
!
line con 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
line aux 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
!
!
end

R3.cfg

!

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R3
!
boot-start-marker
boot-end-marker
!
!
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
!
ip cef
ip audit po max-events 100
!
!
!
!
ip tcp synwait-time 5
! 
!
!
!
interface Ethernet0
 ip address 10.0.0.3 255.255.255.0
 half-duplex
!
interface FastEthernet0
 no ip address
 shutdown
 speed auto
!
router bgp 65003
 no synchronization
 bgp log-neighbor-changes
 network 192.168.0.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 192.168.0.0 255.255.255.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 login
!
end



Salida final en Quagga:
(Notese los flags N, I, V) (Notese los local preference)

RPKI-RTR# sh ip bgp
BGP table version is 0, local router ID is 10.0.0.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
N*> 192.168.0.0      10.0.0.3                 0     20      0 65003 i
I*  200.85.64.0      10.0.0.1                 0     10      0 65001 i
V*>                  10.0.0.2                 0     30      0 7908 i

Total number of prefixes 2




jueves, 27 de diciembre de 2012

Que hacer cuando falla "clear line N" en Cisco

Caso:
  Al realizar un "clear line" en Cisco para desconectar una sesión Telnet o SSH sencillamente sigue apareciendo el usuario.

Ejemplo:


IMP#sh user
    Line       User       Host(s)              Idle       Location
   2 vty 0     aacosta    idle                 00:00:01 a.b.c.d
*  4 vty 2     pepe idle                 00:00:00 xx.yy.zz.dd

Queremos sacar a pepe del equipo y realizamos:
 IMP#clear line vty 2


y sigue apareciendo:


IMP#who
    Line       User       Host(s)              Idle       Location
   2 vty 0     aacosta    idle                 00:00:39 a.b.c.d
*  4 vty 2     pepe    idle                 00:00:00 xx.yy.zz.dd


Procedimiento y solución:
Hay dos manera de hacerlo:

a) Manera rápida y 99% seguro que funciona (y menos probabilidades de error de dañar otra cosa). En vez de utilizar "clear line vty" utilizaremos "clear tcp line":

Así (nuevamente para desconectar a pepe):

IMP#clear tcp line 2
[confirm]
 [OK]

b) Manera más drástica:

Buscamos las conexiones TCP que tenga el router en ese momento. Para ello utilizamos el comando "show tcp brief". Filtramos el puerto 23 (Telnet) o 22 (SSH) según sea el caso. Por ejemplo:

IMP#show tcp brief | i \.23_
63820270  n.n.n.n.23        a.b.c.d.56691     ESTAB
637E1AC0  x.x.x.x.23             xx.yy.zz.dd.39431   ESTAB

  El valor del lado izquiero es la dirección dentro del TCB (TCP Block), esto es precisamente la conexión TCP que estaremos eliminando. 
  El comando es el siguiente:

IMP#clear tcp tcb 637E1AC0

  NOTA: Favor estar seguros antes de eliminar la sesión TCP, recuerden que el router puede tener conexiones HTTP, BGP y otras importantes.

Suerte, espero haya sido útil,

sábado, 1 de enero de 2011

Deshabilitar IPtables en Ubuntu

Situacion:
IPtables y UFW estan dando dolores de cabeza.
Deseo permitir todo el trafico con IPtables

Solucion:
Ejecuta los siguientes comandos como root:

iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -L -n

Suerte, espero haya sido util,

lunes, 27 de septiembre de 2010

Ejemplos de manipulacion de port forwarding utilizando NAT en routers Cisco

Situacion:
Tengo una granja de servidores (ejemplo Web, Mail y SSH) y tengo solo una direccion publica en mi router de borde.

Escenario:
{Internet} --- {RTR con IP publica} ------- {Granja de Servidores}

IP Publica: 11.12.13.14
Mail Server: 192.168.1.5
Web Server: 192.168.1.4
SSH: 192.168.1.6

IP WAN: 11.12.13.14/30
IP LAN: 192.168.1.1/24

Solucion:
La solucion es configurar en el router Cisco NAT de tal manera de que al momento de recibir un paquete TCP al puerto destino correspondiente sepa a donde enviarlo.
En este sentido, es necesario que el router re-envie los paquetes (port forwarding) de la siguiente manera:

Paquetes destinados al IP 11.12.13.14 al puerto destino 25 lo envie al Mail Server (192.168.1.5)
Paquetes destinados al IP 11.12.13.14 al puerto destino 80 lo envie al Web Server (192.168.1.4)
Paquetes destinados al IP 11.12.13.14 al puerto destino 22 lo envie al SSH Server (192.168.1.6)

Procedimiento:
La configuracion del router seria la siguiente:

! ESTA ES LA INTERFAZ QUE DA HACIA LA GRANJA DE SERVIDORES
interface FastEthernet0
description Mi granja de servidores
ip address 192.168.1.1 255.255.255.0
ip nat inside
!
! ESTA ES LA INTERFAZ QUE DA HACIA INTERNET
interface Serial0
description Hacia Internet
ip address 11.12.13.14 255.255.255.252
ip nat outside
!
!En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 80 lo envie al !servidor web
ip nat inside source static tcp 192.168.1.4 80 11.12.13.14 80 extendable

!En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 25 lo envie al !servidor mail
ip nat inside source static tcp 192.168.1.5 25 11.12.13.14 25 extendable

!En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 22 lo envie al !servidor ssh
ip nat inside source static tcp 192.168.1.4 22 11.12.13.14 22 extendable

Tips
Un dato muy interesante que es que se puede manipular el puerto. Por ejemplo, supongamos que tenemos un servidor web "escondido" podemos manejarlo con un puerto diferente al 80. Digamos que queremos que la gente desde Internet acceda a nuestro servidor Web utilizando el puerto 61234 podemos hacer lo siguiente:

!El usuario desde Internet debe acceder a http://11.12.13.14:61234
ip nat inside source static tcp 192.168.1.4 80 11.12.13.14 61234 extendable

Lo anterior es muy util para escoder servicios, ahorrar direcciones IP y darle seguridad a la red.


Espero haya sido de tu utilidad,

Suerte!

domingo, 19 de julio de 2009

Proteccion de hotlink con Apache

Problema:
Poseer un website con contenido de imagenes u otro tipo de media y que existan otros website que hagan referencia a tu contenido. El punto mas negativo de esta situacion es que estas gastando TU ANCHO de banda, memoria y recursos de tu servidor. Al problema anterior se le conoce como Hotlinking.

Solucion:
En el caso de Apache (existen soluciones similares en IIS) la solucion es utilizar el archivo .htaccess con un codigo que veremos mas abajo. Existen dos soluciones: a) bloquear la solicitud HTTP si el HTTP_REFERER no contiene el contenido que deseamos b) Devolver una imagen pre-configurada. En el siguiente articulo nos enfocaremos en devolver un codigo de error que es mi opcion preferida debido a que de esta manera gastamos menos CPU y ahorramos de verdad ancho de banda

Requerimientos:
Servidor Apache con el modulo Rewrite (mod_rewrite).


Procedimiento:
Colocar el siguiente codigo en el archivo .htaccess

RewriteEngine on
RewriteCond %{HTTP_REFERER} .
RewriteCond %{HTTP_REFERER} !^http://(www\\.)?tumujer\\.com [NC]
RewriteRule \\.(gif|jpe?g)$ - [NC,F]


Explicacion codigo anterior:

RewriteEngine on

Este comando comienza el modulo rewrite, necesario para poder trabajar con los comandos rewrite


RewriteCond %{HTTP_REFERER} .
Con este comando permitimos HTTP_REFERERs en blanco. Esto es muy util porque alguien puede escrbir directamente el URL en el navegador, su navegador puede estar configurado para no enviar el referrer y/o incluso existen Firewalls capa 7 que eliminan el HTTP_REFERER de la solicitud HTTP


RewriteCond %{HTTP_REFERER} !^http://(www\\.)?tumujer\\.com [NC]

Esta linea hace match con aquellas solicitudes que vengan del dominio tumujer.com, incluso, no es necesario que lleve el www en el referer. El doble back-slash luego del dominio es para crear un caracter de escape y que el punto en .com se comporte realmente como un punto.

Importante: Para permitir dominios adicionales solo duplica esta linea cambiando el dominio.

RewriteRule \\.(gif|jpe?g)$ - [NC,F]
Esta linea indica que tipo de archivos seran permitidos desde el dominio especificado en la linea anterior. Para permitir nuevos tipos de archivos solo agrega nuevos pipes seguidos por el tipo de archivo (por ejemplo png, bmps, etc).


Eso es todo,

Suerte.

viernes, 10 de julio de 2009

Como activar las licencias dentro de un firewall Juniper

Objetivo:
Activar las diferentes licencias adquiridad (por ejemplo Antivirus) dentro de una caja Juniper SSG5

Problema:
Luego de que recibí la caja no tenía la menor idea de como activar el Antivirus (AV) dentro del mismo

Procedimiento:
Procedí a abrir un ticket dentro del website de Juniper indicando mi problema

Solución:
* Conectar la caja a Internet y con navegación
* Asegurarse que el firewall pueda navegar. Recomiendo entrar a la caja por ssh y/o telnet y hacer un ping a yahoo.com o google.com
* Colocar fecha y hora de la caja (MUY importante)
* Posteriormente hay dos maneras de actualizar las licencias: Web y CLI

Vía Web:
Ir a: Configuration>update>screen OS/keys y hacer click en retrieve subscriptions

Vía CLI:
cst-1->exec license-key update
o
cst-1->exec license-key .

Luego la caja se conectará a lo que Juniper llama el Entitlement Server y traerá las licencias compradas y registradas dentro del Website de Juniper.

Eso es todo,

miércoles, 8 de julio de 2009

Firewall bueno, gratuito y configurable en Windows

Necesidad:
Quitar el acceso a Internet a 100 localidades y solo permitir DNS y FTP. De ser posible gratuito.
En cada localidad solo existe un PC conectado a Internet y dicho PC puede estar conectado de muchas maneras diferentes: Ethernet, Wireless; GSM, EVDO, UMTS, etc, etc.
Por ello, el firewall a utilizar debe de ser capaz de implementar las políticas en TODAS las interfaces del PC

Solución:

Luego de buscar mucho por Internet, incluso probar varios diferentes Firewall logré conseguir: WIPFW
Wipfw lo definen como un Firewall sencillo y eficiente para el mundo del sistema operativo Windows.

En fin, no voy a entrar en detalles de donde bajarlo y como instalarlo. Voy a indicar el procedimiento que seguí para unicamente permitir FTP Y DNS.

Procedimiento:

1) Luego de tener el software instalado en: c:\wipfw procedí a modificar el archivo: wipfw.conf y lo dejé de la siguiente manera:

# First flush the firewall rules
-f flush

# Localhost rules
add 100 allow all from any to any via lo*

# Mis politicas

add 101 allow tcp from me to any 53 out
add 102 allow udp from me to any 53 out
add 103 deny tcp from me to any 1863 out
add 104 allow tcp from me to any 20 out
add 105 allow tcp from me to any 21 out


# Prevent any traffic to 127.0.0.1, common in localhost spoofing
add 110 deny log all from any to 127.0.0.0/8 in
add 110 deny log all from 127.0.0.0/8 to any in

# Bloquear TODO el resto del tráfico. No quiero que naveguen y nada
add 115 deny log all from any to any out

add check-state
add pass all from me to any out keep-state
add count log ip from any to any

2) Posteriormente ejecutas el archivo: install.cmd ubicado en c:\wipfw

3) En caso de necesitar deshabilitar el firewall debes ejecutar: c:\wipfw\uninstall.cmd

Suerte!.

viernes, 5 de junio de 2009

Tips de Seguridad para Linux

A la hora de instalar un Servidor en Linux, el paso del tiempo me ha dado ciertas experiencia a la hora de ajustar politicas de seguridad. Muchas de ellas van a ayudar a que nuestro servidor se encuentre mas seguro.

A continuacion, comparto varias de las politicas que siempre mantengo en mente a la hora de configurar un servidor.

Siempre despues de instalar un servidor, aprovecho para hacer estos cambios.

1) Con el comando chkconfig, elimino los siguientes daemons:
ppp, bind9 ( a menos que sea un servidor DNS), lwresd, portmap, exim4, netatalk, samba, fam, nfs-common, atd, apache2.

E inclusive, sino son necesarios, los elimino

2) Me aseguro de que el siguiente parametro este en el archivo /etc/security/limits.conf

* hard core 0

3) Asegurarse tambien de que las siguientes lineas esten en el archivo /etc/pam.d/login

session required /lib/security/pam_limits.so

4) Comento la siguiente linea en el archivo /etc/inittab

ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

ejm:

#ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

5) Las claves deben de expirar cada 90 dias, esto se hace editando el siguiente parametro en /etc/logins.def

MASS_MAX_DAYS 90

6) Elimino las siguientes cuentas (/etc/passwd, /etc/shadow)

games, lp, news, uucp, proxy, irc, gnats, list


7)Cambio el shell por defecto de los siguientes usuarios a /bin/false
bin, daemon, mail, nobody, sync, sys

8) Elimino cualquier informacion que contengan los archivos

/etc/issue
/etc/issue.net

9)Todo los ejecutables que tenga el setuid y setgid, por defecto, ninguno puede ser escrito por el grupo "others"

find / -perm -4000 -exec ls -l {} \;
find / -perm -2000 -exec ls -l {} \;

Ejm
-rwsr-xr-x 1 root root 31640 2008-11-22 11:01 /usr/bin/passwd
||



9) Modifico el parametro a continuacion en el archivo /etc/login.defs:

LOGIN_RETRIES 3

( crear el archivo /var/log/faillog para grabar todo los intentos de acceso)

10) Editamos el archivo /etc/pam.d/common-password y nos aseguramos de que la opcion min=8 este en la configuracion de pam_unix


Estos tips van a ayudar de cierta manera a asegurar el servidor, mas adelante, colocare unas herramientas que van a ayudarnos a realizar tareas sobre el sistema y verificar la integridad del mismo.