jueves, 9 de enero de 2014

Cómo enviar los logs de un switch juniper a un servidor syslog

Nos conectamos por ssh o telnet al switch Juniper escribimoscliconfigure Y despues introducimos el comando: set system syslog host IP_SERVIDOR_SYSLOG any info  o a través de la configuración web syslog {
        user * {
            any emergency;
        }
        host IP_SERVIDOR_SYSLOG {
            any info;
        }
        time-format millisecond;
    }

Bibliografía:

http://www.juniper.net/techpubs/en_US/junos10.4/topics/reference/configuration-statement/syslog-edit-system.html

Syntax

syslog {archive {files number;size maximum-file-size;start-time "YYYY-MM-DD.hh:mm";transfer-interval minutes;(world-readable | no-world-readable);}console {facility severity;}file filename {facility severity;explicit-priority;match "regular-expression";archive {files number;size maximum-file-size;start-time "YYYY-MM-DD.hh:mm";transfer-interval minutes;(world-readable | no-world-readable);}structured-data {brief;}}host (hostname | other-routing-engine | scc-master) {facility severity;explicit-priority;facility-override facility;log-prefix string;match "regular-expression";}source-address source-address;time-format (millisecond | year | year millisecond);user (username | *) {facility severity;match "regular-expression";}}

viernes, 3 de enero de 2014

Cómo recolectar logs de Cisco con rsyslog en Red Hat / CentOS

Normalmente ya viene instalado en nuestro sistema Red Hat o Centos el demonio rsyslogd, pero viene configurado para recivir logs locales del propio servidor, no está preparado para recibir logs de otros equipos.

Deshabilitar SElinux? cat /etc/selinux/config
Deshabilitar Firewall? system-config-firewall-tui

Asi que vamos a configurar el servicio para recibir logs desde otros dispositivos de red (en nuestro caso switches y routers cisco).

Editamos el archivo /etc/rsyslog.conf

#Hay que descomentar algunas líneas para que el servidor 
#reciba logs de otro equipos.

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514


# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514


#Añadimos el nuevo archivo de log dedicado a los dispositivos CISCO
local6.emerg;local6.alert;local6.crit;local6.err;local6.warning;local6.notice;local6.info;local6.debug  /var/log/cisco


Reiniciamos el servicio
/etc/init.d/rsyslog restart
 
En los dispositivos Cisco introducimos los siguientes comandos. (Revisar si teneis alguna ACL que os impida llegar al servidor de logs)

conf t
logging count
logging queue-limit 1000
logging rate-limit 60
logging trap notifications
logging origin-id hostname
logging facility local6
logging IP_del_servidor_rsyslog
end



En el servidor de logs para ver los logs ejecutar:
tail -f /var/log/cisco
Jan  3 09:20:39 192.168.1.1 156: RTR-0: 000157: Jan  3 09:20:43.738 GMT: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/18, changed state to up
 

Como se puede acumular mucho log vamos a rotar los logs (durante 12 meses realizando un log por mes). si el log es menos de 1k no se rotará.
Creamos un archivo llamado /etc/logrotate.d/cisco y ponemos la siguiente configuración.
 
/var/log/cisco {
        mothly
        create 0644 root root
        rotate 12
        missingok
        notifempty
        size 1k
}

 

Para forzar la compresion de los logs rotados, editamos /etc/logrotate.conf y descomentamos:
# uncomment this if you want your log files compressed
compress


Para forzar la ejecución de la rotacion de los logs ejecutamos:
logrotate -vf  /etc/logrotate.conf

[root@syslogsrv]# ls -lh /var/log/cisco*
-rw-r--r--. 1 root root   0 ene  3 17:46 /var/log/cisco
-rw-r--r--. 1 root root 526 ene  3 17:46 /var/log/cisco-20140103.gz

martes, 12 de noviembre de 2013

VTP: Cisco VLAN Trunk Protocol

El protocolo VTP se utiliza para propagar la base de datos de VLANs por los switches.

Se establecen uno o dos switches como server (mantienen la bbdd de VLANs) y el resto como client (reciven actualizaciones de la bbdd de vlans).

Existe un modo transparent para los switches que dejarán pasar las actualizaciones VTP pero no actulalizarán su bbdd vlan propia.

El en equipo que hace de servidor
Switch(config)#vtp version 2
Switch(config)#vtp mode server
Device mode already VTP SERVER.
Switch(config)#vtp domain vtp1
Changing VTP domain name from NULL to vtp1
Switch(config)#vtp password vtp1
Setting device VLAN database password to vtp1



En los equipos que hacen de clientes
Switch2(config)#vtp version 2
Switch2(config)#vtp mode client
Device mode already VTP SERVER.
Switch2(config)#vtp domain vtp1
Changing VTP domain name from NULL to vtp1
Switch2(config)#vtp password vtp1
Setting device VLAN database password to vtp1


los comandos show:
show vtp status
show vtp domain
show vtp counters
show vlan brief


Bibliografía
http://www.cisco.com/en/US/tech/tk389/tk689/technologies_configuration_example09186a0080890607.shtml

Enlaces entre Antenas Cisco Aironet

Con una única vlan
configure terminal
interface dot11radio0.1
    encapsulation dot1q 1 native
    bridge group 1

interface fastEthernet0.1
    encapsulation dot1q 1 native
    bridge group 1

interface dot11radio0
    ssid SSID_modo_TRUNK
    vlan 1
    infrastructure-ssid

end
write memory

Con 4 vlans ID 1, ID 10, ID 20,  ID 30


configure terminal

interface Dot11Radio0.1
    encapsulation dot1Q 1 native

interface FastEthernet0.1
    encapsulation dot1Q 1 native

interface Dot11Radio0.10
    encapsulation dot1Q 10

interface FastEthernet0.10
    encapsulation dot1Q 10

interface Dot11Radio0.20
    encapsulation dot1Q 20

interface FastEthernet0.20
    encapsulation dot1Q 20

interface Dot11Radio0.30
    encapsulation dot1Q 30

interface FastEthernet0.30
    encapsulation dot1Q 30

interface Dot11Radio0
    ssid SSID_modo_TRUNK
    vlan 1
    infrastructure-ssid

end
write memory


Bibliografía:

jueves, 7 de noviembre de 2013

Nagios - not could be due to Performed to fork () error 'Resource temporarily unavailable'

El otro día me paso que hice una instalación desde cero de Nagios en RHEL 6.4 y al principio no me dí cuenta pero luego me fije que todos los servicios que usaban check_snmp fallaban dando el siguiente error:
Could not open pipe

Revisando el log de Nagios (nagios.log) se veía lo siguiente:
Warning: The check of service 'uptime' on host 'router1' not could be due to Performed  to fork () error 'Resource temporarily unavailable'. The check will be rescheduled.

Buscando un poquito en google encontré en la web comercial de Nagios.
http://support.nagios.com/wiki/index.php/Nagios_XI:FAQs leí que estos errores suelen ser debidos a límites impuestos al usuario en /etc/security/limits.conf
Para verificar los limites actuales podemos ejecutar:
ulimit -a En la web de Nagios nos recomiendan poner los siguientes valores:
* hard memlock 128 #locked memory
* soft memlock 128
* soft nofile 4096 #open files
* hard nofile 4096
* hard nproc 4096  #max user processes
* soft nproc 4096
* hard stack 20480 #stack size
* soft stack 20480

para aplicar los cambios tendremos que reiniciar.
Para verificar los límites después de reiniciar ejecutar:
ulimit -a
Para mejorar aún más el rendimiento de nuestro Nagios podemos deshabilitar el interprete perl embebido, configurando estas 2 variables en nuestro archivo de configuración nagios.cfg.
 enable_embedded_perl=0
 use_embedded_perl_implicitly=0 
Bibligrafía
http://support.nagios.com/wiki/index.php/Nagios_XI:FAQs

jueves, 10 de octubre de 2013

Liberar memoria cache y swap en Linux

#limpia_mem.sh
#Este script se puede programar por las noches con CRON
#para que al dia siguiente el equipo este fresco como una rosa
#
#Script para liberar memoria de forma segura en Linux
#
#!/bin/bash

echo "Comprobando como esta la memoria antes de hacer nada"
free -m

echo “Vaciando la memoria cache y swap“;

echo "Primero deshabilitamos la Swap"
swapoff -a

echo "Liberando de la cache las pagecache, dentries e inodes"
sync;sysctl -w vm.drop_caches=3;sync

echo "Por ultimo habilitamos la Swap"
swapon -a


echo "Comprobando la memoria despues de hacer los deberes XD"
free -m



Despues de ejecutar el script veremos algo parecido a esto:

[root@correo scripts]# ./limpia_mem.sh
Comprobando como esta la memoria antes de hacer nada
             total       used       free     shared    buffers     cached
Mem:          7983       7867        116          0        788       5200
-/+ buffers/cache:       1878       6105
Swap:         2047          0       2047
.Vaciando la memoria cache y swap.
Primero deshabilitamos la Swap
Liberando de la cache las pagecache, dentries e inodes
vm.drop_caches = 3
Por ultimo habilitamos la Swap
Comprobando la memoria despues de hacer los deberes XD
             total       used       free     shared    buffers     cached
Mem:          7983       1405       6577          0          0         78
-/+ buffers/cache:       1326       6657
Swap:         2047          0       2047

 

lunes, 8 de julio de 2013

Archivos de windows a excluir del escaneo en tiempo real de Trend Micro OfficeScan

Los archivos de bases de datos y los archivos cifrados normalmente no deberían de ser escaneados por el antivirus en tiempo real puesto que ganamos en rendimiento del equipo y no deberían representar una amenaza.

En la siguiente web http://esupport.trendmicro.com/solution/en-us/1059770.aspx Trend Micro nos propone una lista de archivos utilizados en sistemas Microsoft que no deberían ser escaneados por su producto OfficeScan.

Para configurar estas excepciones debemos entrar en la consola web de gestión de OfficeScan.


Equipos en red -> Administración de clientes




 

















Seleccionamos el grupo de equipos o unidad organizativa del dominio (OU) que nos interese y vamos a:
Configuración -> Configuración de la exploración -> Parámetros de escaneo en tiempo real.

Por ejemplo en los controladores de dominio habría que excluir los siguientes archivos.

Microsoft Active Directory Domain Controller
  • DRIVE:\WINNT\SYSVOL
  • DRIVE:\WINNT\NTDS
  • DRIVE:\WINNT\ntfrs
  • DRIVE:\WINNT\system32\dhcp
  • DRIVE:\WINNT\system32\dns

Resumen de listado de directorios a excluir:
C:\inetpub\logs\
C:\Program Files\Call Manager
C:\Program Files\Call Manager Attendant
C:\Program Files\Call Manager Serviceability
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions
C:\Program Files\Common Files\Microsoft Shared\Web Service Extensions
C:\Program Files\Common Files\Microsoft Shared\Web Storage System
C:\Program Files\Microsoft ISA Server\ISALogs
C:\Program Files\Microsoft Office Servers
C:\Program Files\Microsoft Operations Manager 2005
C:\Program Files\Microsoft SQL Server\MSSQL$MSFW\Dat
C:\Program Files\Microsoft SQL Server\MSSQL.X\OLAP\Data
C:\Program Files\Microsoft SQL Server\MSSQL\Data
C:\Program Files\SharePoint Portal Server
C:\Users\Default\AppData\Local\Temp
C:\Users\ServiceAccount\AppData\Local\Temp
C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files
C:\WINDOWS\system32\LogFiles
C:\Windows\Syswow64\LogFiles
C:\Windows\Temp\Frontpagetempdir
C:\Windows\Temp\WebTempDir
C:\WINNT\NTDS
C:\WINNT\ntfrs
C:\WINNT\system32\dhcp
C:\WINNT\system32\dns
C:\WINNT\system32\IIS Temporary Compressed Files
C:\WINNT\system32\InetSrv
C:\WINNT\system32\LogFiles
C:\WINNT\SYSVOL
M:\
Q:\

Resumen de extensiones de archivo a excluir:
*.appstate
*.bak
*.dat
*.ldf
*.log
*.mdf
*.ndf
*.pf
*.pol
*.pst
*.tm
*.tmp
*.vmdk
*.vmem
*.zc


Bibliografía:
http://esupport.trendmicro.com/solution/en-us/1059770.aspx

lunes, 3 de junio de 2013

Como habilitar y des-habilitar las notificaciones de Nagios.

A veces interesa que durante cierto tiempo que Nagios no nos cuente  las caídas que detecta. Por ejemplo cuando reiniciamos Nagios puede darse el caso que durante un rato lleguen un montón de correos de UP y de DOWN.

A continuación e muestra una imagen en la que se muestran los menús de la web de Nagios para habilitar o des-habilitar las notificaciones.

La web de la imagen es Nagios modificado con el tema nuvola.


jueves, 2 de mayo de 2013

Consultas al directorio activo con los comandos DSQUERY, DSGET y DSMOD

Listado de todas las OUs del dominio
dsquery ou domainroot

Usuarios están inactivos en el directorio activo desde hace 26 semanas (6 meses)
dsquery user -inactive 26 -limit 0

Usuarios están deshabilitados en el directorio activo
dsquery user -disabled

Direcciones email de los usuario
dsquery user –samid * | dsget user -email

PCs inactivos en el directorio activo desde hace 26 semanas (6 meses)
dsquery computer -inactive 26 -limit 0

Deshabilitar un PC en el directorio activo
dsmod computer PC12 -disabled yes

Deshabilitar PCs que llevan inactivos 26 semanas(6 meses)
dsquery computer -inactive 26 | dsmod computer -disabled yes

Listado de todos los PCs
dsquery computer -name * | dsget computer -samid

Listado de todos los PCs con sistema operativo Windows Server
dsquery * domainroot -filter “(&(objectCategory=computer)(operatingSystem=Windows Server*))” | dsget computer - Windowsamid


jueves, 11 de abril de 2013

Registro SOA de una zona DNS


Un registro SOA (Start Of Authority) lo tiene definido toda zona dns y tiene la siguiente estructura:

@ IN SOA nameserver. email. serial refresh retry expire min-ttl
ó
@ IN SOA nameserver. email. (
         serial
         refresh
         retry
         expire
         min-ttl
)

Parametros generales:
  • nameserver - Es el servidor donde se crea el fichero de la zona DNS.
  • email - Es el correo electrónico del administrador del fichero que define la zona. Ojo! nunca se pone una @ sino que se sustituye por un punto.
  • serial - Es el numero de revision del archivo. Hay que incrementar el numero cada vez que modificamos el fichero para que se propaguen los cambios a los demás servidores DNS.
Parámetros que afectan a las transferencias entre DNS primario y secundario:
  • refresh - Es el tiempo (en segundos) que espera un DNS secundario antes de volver a preguntar si hay cambios en el registro SOA. El DNS secundario revisa el Serial number del registro SOA, en caso que sea diferente al que ya tiene solicitará una transferencia de la zona al dns primario.
  • retry - Es el tiempo (en segundos) que el DNS secundario esperará para volver a solicitar la transferencia en caso que haya fallado con anterioridad. Normalmente suele ser menor que el "Refresh time".
  • expire - Es el tiempo (en segundos) que un DNS secundario esperará a que se complete una transferencia correcta con su DNS primario, en caso de no llegar la transferencia correcta en dicho tiempo el DNS secundario no responderá a las peticiones de dicha zona. Pasado este tiempo se considera que los registros son obsoletos.
Parámetros que afectan a los DNS cache
  • min-ttl - Es el tiempo mínimo que deben mantener vivos los registros de esta zona el resto de servidores DNS (cache o no autoritativos).

En el siguiente ejemplo se muestra el registro SOA de una zona:
 
@ IN SOA  ns1.example.com.  dnsmaster.example.com. (
    1      ; serial       esta zona sólo se ha modificado una vez

    3600   ; refresh [1h] los DNS secundarios se actualizaran
           ;              cada hora.

    600    ; retry [10m]  si una transferencia de zona falla se
           ;              intentara actualizar cada 10 min.

    86400  ; expire [1d]  Si no se realiza con exito ninguna
           ;              transferencia de zona a los DNS
           ;              secundarios en un día los DNS
           ;              secundarios no contestarán a dicha
           ;              zona.

    3600 ) ; min TTL [1h] Si las modificaciones de un registro se 
           ;              propagan a los DNS cache de internet en 
           ;              1 hora.

Bibliografía: