EJEMPLO DE CONFIGURACION

 Esta pequeña guía se hace teniendo en cuenta que el router de acceso del centro es un router JUNIPER. En caso contrario, las configuraciones no tendrían por que ser iguales.


SISTEMA

 En esta parte de la jerarquía se configuran parámetros generales como dominios a los que pertenece el equipo, host name del router, servidores DNS y de TACACS/RADIUS. 
 También se define el orden de autenticación y los usuarios con los permisos que se les quieran otorgar. Obligatoriamente hay que introducir una clave de root. 

system {
    domain-name xxxx.xx;
    domain-search [ xxxx.xx ];
    time-zone Europe/Madrid;
    dump-on-panic;  (sirve para generar un fichero de core cuando se produce un crash)
    authentication-order [ tacplus password ];
    root-authentication {
        encrypted-password "xxxx”
    }
    name-server {
        x.x.x.x
    }
    tacplus-server {
        x.x.x.x secret "xxxx”
    }


    login{
	class operador {
	            idle-timeout 60;
            	    permissions [ admin firewall interface network routing secret security snmp system trace view ];
	            allow-commands "request support information";
	            deny-commands set;
        	}
	class root {
     		    idle-timeout 1440;
    		    permissions all;
		}
	user noc {          
		    class root;
		    authentication {
		        encrypted-password "xxxxxxx"; ## SECRET-DATA
 	            }               
		}                   
	user ops {          
		    class operador;
		    authentication {
		        encrypted-password "xxxxxxxx"; ## SECRET-DATA
		    }               
		}                   
    }

     services {
        ssh {
            protocol-version v2;
            connection-limit 10;
            rate-limit 10;
        }
        telnet {
            connection-limit 2;
            rate-limit 5;
      }

En esta sección se podrían configurar también el servidor de syslog y de ntp con sus parámetros correspondientes, y si queremos guardar periódicamente las configuraciones del equipo en una máquina:

archival {
    configuration {
        transfer-interval 2880; <<<<<<<< aquí transferimos cada cierto tiempo, el que se especifica en el intervalo
	transfer-on-commit; <<<<<< aquí transferimos cada vez que se modifica la configuración
        archive-sites {
            "ftp://usuario:password@maquina/directorio";
        }
    }
}

CONECTIVIDAD

 Habrían dos configuraciones típicas para los interfaces, una cuando son SONET/SDH y otra cuando son GigaEthernet. 

 - Interfaz SONET/SDH

	description "-- XXXX  --";
	mtu 9192;                         (1)
	clocking external;	          (2)
	encapsulation cisco-hdlc;	  (3)
	sonet-options {			  (4)
    		fcs 32;
    		payload-scrambler;
		}
	unit 0 {
	family inet {
		no-redirects;
		address 130.206.x.x/30;
		}
	}

	....

	chassis {
		fpc x {
	    		pic x {
				framing sdh;              (5)
	    			}
			}
		}

     
     (1) Si se quieren configurar Jumbo frames (9000 bytes) habría que poner esta MTU que incluye las cabeceras 
     (2) Para configurar line timing en un interfaz, preferible al loop timing
     (3) Se usa esta encapsulación para interfaces E1, E3, SONET/SDH, T1 y T3.
     (4) FCS (Frame checksum) por defecto está en 16 bits pero conviene ponerlo a 32 bits puesto que aumenta una verificación más fiable. 
     La opción payload-scrambler es recomendable para aumentar la estabilidad en el enlace puesto que asegura la integridad de los datos. 
     (5) Hay que configurar a nivel de chasis la pic correspondiente para que sea SDH, que es el estandard a nivel europeo. Por defecto viene configurado como SONET. 

 - Interfaz GE

	description "-- XXXX --";
	vlan-tagging;                    (1)
	mtu 9192;
	unit 0 {			 (2)
	     vlan-id 254;		 (3)
             family inet {		 
		no-redirects;		 (4)
		address 130.206.x.x/30;
		}
	family iso;
	}


     (1) Habilitando esta opción se pueden enviar y recibir tramas con 802.1Q VLAN tags
     (2) Unidad lógica por defecto del interfaz
     (3) Sirve para marcar un identificador de nivel 2 a una interfaz lógica
     (4) Por defecto se envían los mensajes ICMP redirects y conviene quitarlos ya que no es una manera muy eficiente de actualizar información y además puede provocar ataques de DoS. 


CONTROL DE ACCESO

Hay varios filtros que habría que poner para evitar ataques a servicios y a la red y para tener control sobre las direcciones desde las que podemos acceder. 
Estos filtros se aplican a nivel interfaz y según de que interfaz se esté tratando se ajusta a uno u otro. A continuación se definen a nivel genérico y la recomendación de interfaz al que se debería aplicar:

 - Filtro aplicado a interfaces de acceso

	· Se deberían configurar dos filtros, uno de entrada y otro de salida en la interfaz que conecta con el centro o red local.

       firewall {
         filter ENTRADA {
     
	· El filtro antispoofing tira todo el tráfico excepto el que se permita desde las direcciones que definas en la prefix list correspondiente:
      
           term Filtro-Antispoofing {
              from {
                 source-prefix-list {
                     defecto;
                 }
               }
	   then discard;
            }
	 
	 · Los bogons son rangos de IPs públicos de Internet que no están asignados o delegados por la IANA, pero que hay que filtrarlos porque pueden ser usados para usos ilegítimos. Se puede obtener una lista actualizada en la página de la IANA:
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

En la página de Team Cymru se encuentra información más detallada, además del listado formateado para usar en filtros de equipos Cisco y Juniper:
http://www.team-cymru.org/Services/Bogons/

            term Filtro-Bogons {
                from {
                   prefix-list {
                      rangos-BOGONS;
                   }
                }
		then discard;
             }
         
	 · Se filtran estos puertos por vulnerabilidades típicas de sistemas Windows, en ambos casos por ataques de acceso remoto:

             term Filtro-Windows {
                 from {
                    destination-port [ 137-139 445 ];
                 }
		 then discard;
              }

	 · Este término es para limitar el tráfico sobre estos puertos que utilizan aplicaciones P2P:

             term Limitador-Puertos {
                 from {
                   port [ 1214 2234 4112 4661-4665 5534 6346 6699 ];
                 }
		 then discard;
              }

	 · Se filtran los paquetes ICMP para evitar ataques de DoS. Se acompaña de prefix-list para definir los extremos bajo un entorno controlado desde los que se puede hacer uso, acompañado de policers para limitar los paquetes ICMP grandes (el policer se define a nivel de firewall):

              term Limitador-ICMP {
                 from {
                    protocol icmp;
                 }
		 then {
		    policer 128Kbps;
        	    accept;
		 }
              }

	     policer 128Kbps {
    		if-exceeding {
       			 bandwidth-limit 128k;
       			 burst-size-limit 8k;
    		}
   	     then discard;
	     }

	 · Permitimos el resto del tráfico:

	     term Resto {
		then accept;
	     }
	}

	 · Como filtro de salida podemos configurar si nos interesa unos 'policer' que limiten cierto tráfico de salida, como el P2P o el ICMP, y permitir el resto.


 - Filtro aplicado a la Routing Engine 

	 · Este filtro se aplica en la interfaz de loopback y afecta al tráfico dirigido al propio equipo.

	 · Para el acceso a la gestión del equipo hay que controlar los puertos predefinidos de telnet y ssh. Igualmente hay un puerto predefinido para la conexión con los servidores DNS, el 	sistema de autenticación TACACS o RADIUS, FTP, NTP y SNMP. 
	 · Si queremos habilitar tráfico multicast debemos permitir tráfico desde/hacia la dirección 224.0.0.13 u otros vecinos pim, lo mismo que se hace recomendable filtrar los peerings BGP.
	 · Y en general cualquier servicio adicional que queramos activar en el equipo probablemente necesite ser permitido en este filtro.
	
	term TELNET-Permitido {
    	      from {
        		source-prefix-list {
      		     		direcciones_acceso_permitidas;
        		}
        		protocol tcp;
        		port telnet;
    	      }
    	then accept;
	}

	term SSH-Permitido {
    	      from {
        		source-prefix-list {
		     		direcciones_acceso_permitidas;
        		}
        		protocol tcp;
	            port ssh;
    	      }
    	then accept;
	}
	
	term DNS-Permitido {
	    from {
	        source-prefix-list {
	            servidores_dns_permitidos;
	        }
	        protocol udp;
	        port domain;
	    }
	    then accept;
	}

	term TACACS-Permitido {
	    from {
	        source-prefix-list {
	            servidores_tacacs_permitidos;
	        }
	        protocol tcp;
	        source-port tacacs;
	    }
	    then accept;
	}
	term FTP-Permitido {
	    from {
	        source-address {
            		servidores_ftp_permitidos;
	        }
	        source-port [ ftp ftp-data ];
	    }
	    then accept;
	}

	term ICMP-Permitido {
	    from {
	        prefix-list {
	            direcciones_icmp_permitidas;
	        }
	        protocol icmp;
	    }
	    then accept;
	}

	term NTP-Permitido {
	    from {
	        source-prefix-list {
	            servidores_ntp_permitidos;
	        }
	        protocol udp;
	        port ntp;
	    }
	    then accept;
	}

	term PIM-Permitido {
	    from {
	        prefix-list {
	            direcciones_mcast_permitidas;
	        }
	        protocol pim;
	    }
	    then accept;
	}

	term BGP-Permitido {
	    from {
	        source-prefix-list {
	            vecinos_bgp;
	        }
	        protocol tcp;
	    }
	    then accept;
	}	

	term SNMP-Permitido {
	    from {
	        source-prefix-list {
	            servidores_snmp_permitidos;
	        }
	        protocol udp;
	        destination-port snmp;
	    }
	    then accept;
	}

	term RESTO {
	    then {	
	        discard;
	    }
	}