Spotlight es una de las mejores cosas que tiene OSX y la verdad es que tiene sus trucos y opciones que espero ir colocando aquí, de momento dejo este truco que no conocía:

• Buscar frases exactas:
  Si queremos buscar alguna frase exacta o algo exacto debemos poner el texto entre comillas (”). Por ejemplo:

  "Glenn Miller"

• Buscar por tipo:
  Si queremos buscar algo por tipo o simplemente por extensión podemos introducir en la búsqueda lo siguiente: clase:tipo donde tipo es el tipo de aplicación o extensión que queremos buscar. Por ejemplo si quiero buscar libros o información de Cisco en formato CHM podemos usar:

  clase:chm cisco

• Buscar por fecha:
  Si queremos buscar algo que se ha creado en una fecha concreta podemos usar creado:dd/mm/aa. Si queremos buscar algo que hemos modificado podemos usar: modificado:dd/mm/aa. También podemos usar comparadores al más puro estilo programación por ejemplo fichero modificados antes o en la fecha colocando <= antes de la fecha, modificado:<=dd/mm/aa. Por ejemplo para buscar ficheros MP3 creados el 10 de Junio de 2008 podemos usar:

  creado:10/06/08 mp3

• Búsquedas booleanas:
  También podemos usar operadores booleanos AND, OR, NOT y el signo menos - (que significa AND NOT “y no”). Por ejemplo buscar todos lo que que contenta “lucas y lukas”:

  lucas AND lukas

Por supuesto podemos combinar algunos o todas las opciones de búsqueda para poder realizar búsquedas más exactas. Algunos ejemplos:

• viaje -francia
  busca ítems que contengan la palabra “viaje” pero no “francia“, de modo que los resultados puedan incluir fotografías de un viaje a Alemania pero no a Francia
• Clase:mensajes fecha:29/06/07-25/07/07 NOT fecha:14/07/07
  busca mensajes de correo electrónico fechados entre el 29/06/07 y el 25/07/07, pero excluye los que tengan fecha del 14/07/07
• Clase:música de:”glenn miller”
  busca música de Glenn Miller pero no de Glenn Ford

En Leopard se añadió la fantástica utilidad llamada QuickLook que al principio no le pillaba el gustillo pero que poco a poco se ha hecho imprescindible y ahora se me hace necesario tener soportados ciertos formatos que ya de por si ya están soportados por QuickLook pero que por tener otra extensión no los muestra, por ejemplo los ficheros .nfo y .diz entre otros que son simples ficheros de texto.

Voy a explicar como hacer posible ver los ficheros .nfo y .diz vía QuickLook:

1. Como son ficheros de texto y se visualizan con TextEdit.app, haremos una copia por si acaso
2. Ahora mostramos su contenido pulsando el botón derecho del ratón (o Control+Clik) y en el menú contextual pinchamos en “Mostrar el contenido del paquete”
3. dentro de la carpeta “Contents” tenemos un fichero llamado info.plist que tenemos que editar, se puede hacer con “Property List Editor” pero es bastante engorroso así que es mejor con un editor que muestre el XML en plano como BBEDIT, Dashboard (incluido en Xcode) o cualquier otro.
4. nos vamos al final del fichero y justo antes de:

   --- pegar aquí ---
   </dict>
   </plist>

5. Pegamos este bloque:

   <key>UTExportedTypeDeclarations</key>
   	  <array>
   	    <dict>
   	      <key>UTTypeConformsTo</key>
   	      <array>
   	        <string>public.text</string>
   	        <string>public.plain-text</string>
   	      </array>
   	      <key>UTTypeDescription</key>
   	      <string>NFO information file</string>
   	      <key>UTTypeIdentifier</key>
   	      <string>com.macromates.textmate</string>
   	      <key>UTTypeTagSpecification</key>
   	      <dict>
   	        <key>com.apple.ostype</key>
   	        <string>TEXT</string>
   	        <key>public.filename-extension</key>
   	        <array>
   	          <string>nfo</string>
   	          <string>diz</string>
   	        </array>
   	      </dict>
   	    </dict>
   	  </array>

Si queremos añadir más extensiones a parte de .nfo y .diz que sean ficheros de texto podemos añadir tantas líneas como extensiones queramos añadir justo debajo de:

<string>nfo</string>
<string>diz</string>

Ahora para que todo esto funciona solo hay que hacer es abrir un terminal y ejecutar lo siguiente:

touch /Applications/TextEdit.app

Y ya podemos ver ficheros .nfo y .diz desde el QuickLook pulsando la barra espaciadora.

Esto mismo se puede aplicar a otros tipo de ficheros y programas.

Los que trabajamos en servidores remotos muchas veces necesitamos tener copia de cierto contenido del servidor remoto en uno local, hay muchas formas de hacerlo pero una simple y con un solo paso es hacer un TAR remoto vía SSH de la siguiente forma:

ssh usuario@servidor "cd /destino && tar cvz * --exclude=loquesea*" > copia.$( date +%y-%m-%d ).tgz

vamos a explicar que es cada cosa y que se puede cambiar, quitar y/o añadir:

• usuario@servidor -> es evidente el usuario y el nombre o IP del servidor remoto
• cd /destino -> es por si queremos ir a un directorio antes de hacer el TAR, es opcional y se puede quitar.
• --exclude=loquesea* -> no hace copia de “loquesea*” por si hay ficheros o directorios que no queremos hacer copia, se pueden añadir más de un “–exclude” o quitarlo es opcional.
• copia.$( date +%y-%m-%d ).tgz -> genera un fichero llamado copia.AAAA-MM-DD.tgz, aqui se puede poner lo que se quiera, quitar la fecha, añadir la hora o poner un simple nombre.
• También podemos añadir más opciones al TAR o quitar la v de verbose

En mi primer artículo sobre ossec he mostrado los pasos para hacer una instalación básica y completamente estándar de ossec. En este artículo vamos a ver lo que hay por debajo del software.

Ossec usa tres componentes: un detector de rootkits, una herramienta para revisar la integridad del sistema, y el analizador de logs. Todas ellas se configuran en el fichero ossec.conf.

Este fichero de configuración tiene una estructura muy clara, en formato xml, en el que se definen varios bloques.

En este artículo sólo voy a dar algunas ideas básicas sobre el formato con el que se definen las reglas que describen los eventos detectables en los logs.

Tanto el chequeo de integridad como el detector de rootkits se configuran de una forma muy similar, así que lo dejaré para que quien quiera se pelee con ello.

En ossec.conf se definen los logs que se quieren monitorizar dentro de secciones “localfile”. Un ejemplo:

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
  </localfile>

En este caso se dice que queremos vigilar auth.log, del tipo syslog. Existen varios formatos definidos, como apache o snort-full, por citar dos ejemplos. Syslog se usa en los casos en los que se loguea un único evento por linea. Sort-full, por poner otro ejemplo, está adaptado al tipo de log que deja snort cuando usa el formato de salida full.

Una vez definidos los formatos, empezamos a hablar de reglas. El primer paso es que ossec detecte qué tipo de entrada de log es. Para esto se usan los decoders (decoder.xml) Veamos un ejemplo.

<decoder name="sshd">
<program_name>^sshd</program_name>
</decoder>

Este decoder “se activa” cuando la entrada de log es generada por el programa sshd (sshd[5493] en el siguiente ejemplo):

Feb  3 19:22:33 server sshd[5493]: Accepted publickey for prueba from 192.168.10.2 port 50560 ssh2

Pero, a pesar de la importancia de esta sencilla regla (después veremos por qué), necesitamos extender el decoder para que sea útil.

<decoder name="ssh-failed">
<parent>sshd</parent>
<prematch>^Failed \S+ </prematch>
  <regex offset="after_prematch">^for (\S+) from (\S+) port \d+ \w+$</regex>

  <order>user, srcip</order>
</decoder>

Gracias a la primera y simple regla “sshd” nos aseguramos que ossec sólo va a analizar la entrada de log contra esta segunda regla, mucho más compleja, si dicho log está relacionado con ssh. Esto es una gran mejora en el rendimiento del sistema.

Sin entrar en explicaciones detalladas, esta regla se cumple con este tipo de log:

Jul 26 22:06:10 server sshd[3727]: Failed password for prueba from 192.168.10.2 port 50519 ssh2

Y además crea dos “variables”; una con el usuario que ha intentado conectarse y otra con la IP origen.

Teniendo estos datos ya podemos empezar con las reglas “de verdad”. Veamos algo del fichero sshd_rules.xml

  <rule id="5700" level="0" noalert="1">
    <decoded_as>sshd</decoded_as>

    <description>SSHD messages grouped.</description>
  </rule>

<rule id="5716" level="5">
    <if_sid>5700</if_sid>
    <match>^Failed|^error: PAM: Authentication</match>

    <description>SSHD authentication failed.</description>
    <group>authentication_failed,</group>
  </rule>

De manera similar a los decoders, se define una primera regla básica para ssh, que ayudará a ossec en no tener que analizar reglas de apache (por ejemplo) en logs de ssh.

La segunda regla (5716) generará una alerta de nivel 5 cuando haya un intento de login erróneo.

Pero también se pueden crear reglas compuestas que activarán alertas de mayor nivel si hay x intentos fallidos desde una misma IP

  <rule id="5720" level="10" frequency="6">
    <if_matched_sid>5716</if_matched_sid>
    <same_source_ip />
    <description>Multiple SSHD authentication failures.</description>

    <group>authentication_failures,</group>
  </rule>

Gracias al formato xml es muy sencillo añadir nuevas reglas. También se pueden enviar correos con las alertas a cuentas de correo diferentes en base, por ejemplo, al agente que ha generado la alerta o al nivel de la misma.

En el tercer y último artículo de la serie vamos a integrar ossec con psad.

En el mundo del software libre hay multitud de proyectos que, debido a su calidad, han terminado siendo comprados por empresas para ser usados como parte de sus soluciones comerciales. Dos ejemplos son sguil y ossec.

En la próxima serie de dos artículos voy a comentar muy por encima lo principal de ossec.

Ossec es un proyecto relacionado con la seguridad informática, y particularmente con lo que se suele llamar HIDS. Dicho de otra forma, y simplificando mucho, se trata de una aplicación que monitoriza una máquina, y que detecta las anomalías que puedan producirse en el sistema. Para hacer esto usa sobre todo una herramienta para la detección de rootkits, otra para revisar la integridad de ficheros y ejecutables del sistema, y por último un potente sistema para analizar logs.

En cuanto a la arquitectura del sistema, usa básicamente un modelo de servidor/agentes, con lo que tendremos una máquina (servidor) encargada de recibir y actuar en base a la información que reciba de los agentes que, en definitiva, son las máquinas que están siendo monitorizadas. La forma de actuar del servidor es, por una parte, enviando notificaciones, y por otro lado, si así se configura, generando reglas firewall que se ejecutarán en los propios agentes.

Este primer artículo sólo va a describir la instalación de ossec. Dejamos para artículos posteriores la configuración.

La instalación de ossec es muy sencilla. Es suficiente con ejecutar el típico install.sh del fichero de instalación que se puede descargar desde la web.

sh install.sh

Una vez seleccionamos el idioma de instalación empieza el tema.

1- What kind of installation do you want (server, agent, local or help)? server
  - Server installation chosen.
2- Setting up the installation environment.
  - Choose where to install the OSSEC HIDS [/var/ossec]:  /usr/local/ossec-1.6
     - Installation will be made at  /usr/local/ossec-1.6 .
3- Configuring the OSSEC HIDS.
  3.1- Do you want e-mail notification? (y/n) [y]:
   - What's your e-mail address? zzz@yyyyyyy.net
   - We found your SMTP server as: mail.yyyyyyy.net.
   - Do you want to use it? (y/n) [y]:
   --- Using SMTP server:  mail.yyyyyyy.net.
  3.2- Do you want to run the integrity check daemon? (y/n) [y]:
   - Running syscheck (integrity check daemon).
  3.3- Do you want to run the rootkit detection engine? (y/n) [y]:
   - Running rootcheck (rootkit detection).
  3.4- Active response allows you to execute a specific
       command based on the events received. For example,
       you can block an IP address or disable access for
       a specific user.
       More information at:
       http://www.ossec.net/en/manual.html#active-response
   - Do you want to enable active response? (y/n) [y]: n
     - Active response disabled.
  3.5- Do you want to enable remote syslog (port 514 udp)? (y/n) [y]:
   - Remote syslog enabled.
  3.6- Setting the configuration to analyze the following logs:
    -- /var/log/messages
    -- /var/log/auth.log
    -- /var/log/syslog
    -- /var/log/vsftpd.log
    -- /var/log/mail.info
    -- /var/log/dpkg.log
    -- /var/log/snort/alert (snort-full file)
    -- /var/log/apache2/error.log (apache log)
    -- /var/log/apache2/access.log (apache log)

   - If you want to monitor any other file, just change
     the ossec.conf and add a new localfile entry.
     Any questions about the configuration can be answered
     by visiting us online at http://www.ossec.net .

   --- Press ENTER to continue ---

A partir de aquí empieza a compilar los distintos componentes. He elegido una instalación para el servidor que recibirá los eventos, y he activado tanto la detección de rootkits como la revisión de integridad, pero he dejado sin activar la respuesta activa, que básicamente se trata de añadir entradas a hosts.deny y reglas de firewall.

El syslog remoto lo vamos a usar para recibir mensajes desde los agentes.

Por cierto, mientras escribía estas líneas el sistema se ha terminado de compilar:

 - System is Debian (Ubuntu or derivative).
 - Init script modified to start OSSEC HIDS during boot.
 - Configuration finished properly.
 - To start OSSEC HIDS:
                /usr/local/ossec-1.6/bin/ossec-control start
 - To stop OSSEC HIDS:
                /usr/local/ossec-1.6/bin/ossec-control stop
 - The configuration can be viewed or modified at /usr/local/ossec-1.6/etc/ossec.conf
     Thanks for using the OSSEC HIDS.
     If you have any question, suggestion or if you find any bug,
     contact us at contact@ossec.net or using our public maillist at
     ossec-list@ossec.net
     ( http://www.ossec.net/main/support/ ).
     More information can be found at http://www.ossec.net
 ---  Press ENTER to finish (maybe more information below). ---

A partir de aquí, por un lado tendremos que configurar ossec (ossec.conf), y después tendremos que ir añadiendo los agentes con la utilidad /usr/local/ossec-1.6/bin/manage_agents.

Vamos a arrancar el servidor y a añadir un par de agentes, uno en linux y otro en windows. Bueno, el agente windows no lo voy a documentar aquí. Tiene un instalador gráfico que se descarga desde la web, y los pasos son muy similares.

/usr/local/ossec-1.6/bin/ossec-control start
Starting OSSEC HIDS v1.6 (by Third Brigade, Inc.)...
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-remoted...
Started ossec-syscheckd...
Started ossec-monitord...
Completed.

# ps aux | grep osse
ossecm    5579  0.0  0.0   2076   528 ?        S    17:45   0:00 /usr/local/ossec-1.6/bin/ossec-maild
ossec     5587  0.0  0.1   2664  1312 ?        S    17:45   0:00 /usr/local/ossec-1.6/bin/ossec-analysisd
root      5591  0.0  0.0   1796   468 ?        S    17:45   0:00 /usr/local/ossec-1.6/bin/ossec-logcollector
root      5603  2.5  0.0   1944   512 ?        D    17:45   0:04 /usr/local/ossec-1.6/bin/ossec-syscheckd
ossec     5607  0.0  0.0   1980   480 ?        S    17:45   0:00 /usr/local/ossec-1.6/bin/ossec-monitord
ossecm    5610  0.0  0.0   2076   300 ?        S    17:45   0:00 /usr/local/ossec-1.6/bin/ossec-maild

# ./manage_agents
***********************************************
* OSSEC HIDS v1.6 Agent manager.  *
* The following options are available:  *
***********************************************
   (A)dd an agent (A).
   (E)xtract key for an agent (E).
   (L)ist already added agents (L).
   (R)emove an agent (R).
   (Q)uit.
Choose your action: A,E,L,R or Q: A

- Adding a new agent (use '\q' to return to the main menu).
  Please provide the following:
    * A name for the new agent: agente1
    * The IP Address of the new agent: 172.17.0.131
    * An ID for the new agent[001]:
Agent information:
    ID:001
    Name:agente1
    IP Address:172.17.0.131
Confirm adding it?(y/n): y
Agent added.

# ./manage_agents

***********************************************
* OSSEC HIDS v1.6 Agent manager.  *
* The following options are available:  *
***********************************************
   (A)dd an agent (A).
   (E)xtract key for an agent (E).
   (L)ist already added agents (L).
   (R)emove an agent (R).
   (Q)uit.
Choose your action: A,E,L,R or Q: E

Available agents:
   ID: 001, Name: agente1, IP: 172.17.0.131
Provide the ID of the agent to extract the key (or '\q' to quit): 001
Agent key information for '001' is:
XDAxIGZuMTMxIDE5Mi4xNjguMTXuMTMxIDZzY2IzZjg1Y2JmYjVmOaBhMWM0MWRkMTNjMWQ4OWY4MZMyMjkyYTRiOTk5YjJlZ4U5MjRm5zU0ZGE1N2I3NTk=

** Press ENTER to return to the main menu.

Y ya está. Ahora sólo queda instalar el agente en el servidor a monitorizar. La clave se usa para la comunicación agente/servidor.

# ./install.sh
...
1- What kind of installation do you want (server, agent, local or help)? agent
  - Agent(client) installation chosen.
2- Setting up the installation environment.
  - Choose where to install the OSSEC HIDS [/var/ossec]: /usr/local/ossec-1.6
    - Installation will be made at  /usr/local/ossec-1.6 .
3- Configuring the OSSEC HIDS.
  3.1- What's the IP Address of the OSSEC HIDS server?: 172.17.0.1
    - Adding Server IP 172.17.0.1
  3.2- Do you want to run the integrity check daemon? (y/n) [y]:
    - Running syscheck (integrity check daemon).
  3.3- Do you want to run the rootkit detection engine? (y/n) [y]:
    - Running rootcheck (rootkit detection).
  3.4 - Do you want to enable active response? (y/n) [y]: n
    - Active response disabled.
  3.5- Setting the configuration to analyze the following logs:
    -- /var/log/messages
    -- /var/log/auth.log
    -- /var/log/syslog
    -- /var/log/mail.info
    -- /var/log/dpkg.log
  - If you want to monitor any other file, just change
    the ossec.conf and add a new localfile entry.
    Any questions about the configuration can be answered
    by visiting us online at http://www.ossec.net .
--- Press ENTER to continue ---

Y ahora copiamos la clave pública que antes hemos sacado del servidor:

./bin/manage_agents

***********************************************
* OSSEC HIDS v1.6 Agent manager.  *
* The following options are available:  *
***********************************************
   (I)mport key from the server (I).
   (Q)uit.
Choose your action: I or Q: I
* Provide the Key generated by the server.
* The best approach is to cut and paste it.
*** OBS: Do not include spaces or new lines.
Paste it here (or '\q' to quit): XDAxIGZuMTMxIDE5Mi4xNjguMTXuMTMxIDZzY2IzZjg1Y2JmYjVmOaBhMWM0MWRkMTNjMWQ4OWY4MZMyMjkyYTRiOTk5YjJlZ4U5MjRm5zU0ZGE1N2I3NTk=
Agent information:
   ID:001
   Name:agente1
   IP Address:172.17.0.131
Confirm adding it?(y/n): y
Added.
** Press ENTER to return to the main menu.

Arrancamos el agente… y ya está.

/usr/local/ossec-1.6/bin/ossec-control start

Y no hay nada más que hacer para tener lo básico de ossec. Por supuesto, todo es muy configurable, y ampliable en base a lo que cada uno necesite.

Desde otra máquina, me intento conectar digamos que 10 veces usando ssh con usuarios invalidos….. sorpresa, recibo este correo.

OSSEC HIDS Notification.
2008 Sep 21 22:30:40

Received From: (agente1) 172.17.0.131->/var/log/auth.log
Rule: 5712 fired (level 10) -> "SSHD brute force trying to get access to the system."
Portion of the log(s):

Sep 21 19:06:32 fn131 sshd[5990]: Invalid user aaaaab from 172.17.0.2
Sep 21 19:06:26 fn131 sshd[5986]: Failed password for invalid user aaaaa from 172.17.0.2 port 39010 ssh2
Sep 21 19:06:23 fn131 sshd[5986]: Failed password for invalid user aaaaa from 172.17.0.2 port 39010 ssh2
Sep 21 19:06:21 fn131 sshd[5986]: Failed none for invalid user aaaaa from 172.17.0.2 port 39010 ssh2
Sep 21 19:06:21 fn131 sshd[5986]: Invalid user aaaaa from 172.17.0.2
Sep 21 19:06:09 fn131 sshd[5984]: Failed password for invalid user aaaah from 172.17.0.2 port 39009 ssh2
Sep 21 19:06:06 fn131 sshd[5984]: Failed none for invalid user aaaah from 172.17.0.2 port 39009 ssh2

Algunos ejemplos con distintos tipos de eventos:

OSSEC HIDS Notification.
2008 Oct 09 21:29:03

Received From: servidor->syscheck
Rule: 550 fired (level 7) -> "Integrity checksum changed."
Portion of the log(s):

Integrity checksum changed for: '/etc/dovecot/dovecot.conf'
Size changed from '45438' to '45460'
Old md5sum was: 'bd5c81584dad9725045ec0e52eb0c15c'
New md5sum is : '439061951cdeb975c21d37b4cc5f8649'
Old sha1sum was: '8d7ade9a74b9e8ff4d6758c14bdb070ccb15b198'
New sha1sum is : '8e7d34ba6328a1e5d38645972b369e700f7d05b2'
 --END OF NOTIFICATION

OSSEC HIDS Notification.
2008 Oct 07 18:29:00

Received From: servidor->/var/log/dpkg.log
Rule: 2902 fired (level 7) -> "New dpkg (Debian Package) installed."
Portion of the log(s):

2008-10-07 18:29:00 status installed unzip 5.52-12
 --END OF NOTIFICATION

OSSEC HIDS Notification.
2008 Oct 05 17:42:23

Received From: agente1->/var/log/messages
Rule: 5104 fired (level 8 ) -> "Interface entered in promiscuous(sniffing) mode."
Portion of the log(s):

Oct  5 17:42:21 nurn kernel: device lo entered promiscuous mode
 --END OF NOTIFICATION

En el próximo artículo veremos un poco sobre la configuración de todas estas reglas.

Este artículo fue publicado en la revista Linux+ Julio/Agosto 2007 (Nº 34) (Web de la revista) y que amablemente me han cedido y dado permiso para publicarlo. El artículo está escrito por Alberto Permuy Leal.

---

La implementación de un proxy en la red del cliente es un paso inicial y que, con frecuencia, viene a solucionar muchos problemas de seguridad y saturación de comunicaciones, siendo habitual la existencia de organizaciones que han estado incrementando previamente sus comunicaciones contratadas con un ISP sin saber muy bien porqué, lo único que saben es que los anchos de banda se acaban agotando, los problemas de virus y ataques persisten y las comunicaciones siempre se quedan cortas.
Por ello, una primera tarea puede ser la de instalar un proxy, con el fin de solucionar un primer problema. Como veremos en estas páginas, SQUID, como otros, nos permitirá comenzar a organizar los dos ámbitos de las comunicaciones de la PYME, el tramo Internet, optimizando el mismo y la demanda que la red realiza sobre las comunicaciones, y el tramo de los usuarios, comenzando a organizar el uso que dan los mismos a la red, aplicando asimismo soluciones de optimización caché, que redundan de manera palpable en el rendimiento de las comunicaciones.
Ésta es una de las razones por las cuales optamos por este tipo de implantaciones como primer paso, dado que la instalación de un servicio proxy es imperceptible para los usuarios, desde su punto de vista, pero redunda en resultados claros para la organización, abriendo ese camino de confianza tan importante para abordar nuevos proyectos y soluciones en el cliente.
Por lo tanto, vamos a describir de un modo detallado las características de una de las soluciones proxy que hay en el mercado: Squid. Entre sus características principales, podemos destacar la facilidad de configuración, su fiabilidad y los excelentes resultados que ofrece una vez está operativo.
Por otra parte, Squid nos abre las puertas, posteriormente, a introducir a la PYME en cuestiones que hasta el momento le eran ajenas, tales como el control del uso de la red y el análisis del rendimiento de la misma, que nos permitirá, con la información que nos ofrece Squid, planificar mejoras en dicha red y solucionar errores en el diseño de la misma.
Squid es un software proxy, diseñado originalmente para plataformas Unix-Like, liberado bajo licencia GPL, que permite desde la aceleración de la navegación, hasta caché DNS, soportando multitud de protocolos,aunque en realidad se utiliza principalmente para HTTP y FTP.
El término proxy hace referencia a un programa o dispositivo que realiza una acción en representación de otro. La finalidad más habitual es la del servidor proxy, que sirve para permitir el acceso a Internet a todos los equipos de una organización cuando sólo se puede disponer de un único equipo conectado, esto es, una única dirección IP.
Squid posee las siguientes características:

• Proxy y Caché de HTTP, FTP, y otras URLs,
• Proxy para SSL,
• Jerarquías de Caché,
• ICP, HTCP, CARP, Caché Digests,
• Caché transparente,
• WCCP (Squid v2.3 y superior),
• Control de acceso,
• Aceleración de servidores HTTP,
• SNMP,
• Caché de resolución DNS.

Squid puede ejecutarse en plataformas:

• Linux,
• FreeBSD,
• OpenBSD,
• NetBSD,
• BSDI,
• Mac OS X,
• OSF and Digital Unix,
• IRIX,
• SunOS/Solaris,
• NeXTStep,
• SCO Unix,
• AIX,
• HP-UX,
• Microsoft Windows NT/XP/2000/2003.

Actualmente (Enero 2007) la rama estable se encuentra en la versión 2.6.x. Entre los cambios más destacables en relación a versiones anteriores destacamos:

• Mejoras en la autentificación con Kerberos,
• Cambios adicionales en el manejo de ACLs con SSL,
• Soporte WCCPv2,
• Cifrado SSL con OpenSSL,
• Implementación Cygwin que permite a Squid correr bajo plataformas Microsoft.

Instalación

La instalación de Squid en una distribución Debian GNU/Linux o derivados (Ubuntu, Kubuntu, Knoppix, etc.) es muy sencilla. Desde consola y como root actualizaremos repositorios, y posteriormente instalaremos
Squid:

[root@satriani] apt-get
update && apt-get
install squid

Antes de comenzar con la edición del fichero de configuración documentaremos las redes o subredes desde las que Squid aceptará peticiones así como las interfaces de red de la máquina:

• La primera interfaz de red es eth0 con dirección IP 192.168.0.254/24 conectada a la VLAN2,
• La segunda interfaz de red es eth1 con dirección IP 192.168.60.253/27 conectada a la VLAN4 para la salida a Internet.

Con el comando ifconfig, comprobaremos que este direccionamiento está correctamente configurado en el servidor.

[root@satriani]
ifconfig | more

En la mayoría de las distribuciones, y partiendo de una instalación de paquetes precompilados
(.rpm o .deb por ejemplo), el fichero de configuración de Squid se halla en /etc/squid/squid.conf. Este fichero consta de multitud de parámetros; aunque en este artículo nos centraremos en las opciones
indispensables y más interesantes para conseguir un óptimo funcionamiento.
En caso de no poder localizar squid.conf, con las herramientas find y whereis intentaremos localizarlos, y en caso contrario, crearemos el fichero.
Localizando el fichero con find:

[root@satriani] find / -name squid.conf

Localizando el fichero con whereis:

[root@satriani] whereis squid.conf
squid: /etc/squid/squid.conf

Antes de nada, haremos un backup de nuestro fichero actual de configuración de Squid y lo enviaremos por email. Realmente no es necesario, pero es una buena práctica a la hora de modificar ficheros que puedan afectar a la estabilidad del sistema:

[root@satriani]cp /etc/squid/squid.conf /etc/squid/squid.conf.bak
[root@satriani]mail -s BackupSquidConf myuser@mydomain.com < /etc/squid/squid.conf

Llegados a este punto, dividiremos en dos partes el fichero de configuración squid.conf : Configuración Global y ACLs, con el fin de aclarar la comprensión del mismo.

Configuración Global

• visible_hostname: Nombre visible de nuestro servidor proxy,
• http_port: Puerto TCP en el que escucha el servicio,
• cache_mem: Tamaño de la memoria caché,
• cache_dir: Directorio de la caché,
• cache_access_log: Fichero de almacenamiento de logs,
• cache_mgr: Administrador de la caché,
• coredump_dir: Directorio para los volcados de memoria,
• maximum_object_size: Tamaño máximo de los objetos de la caché,
• half_closed_clients: Cierre de conexiones a clientes con sockets abiertos que no envían datos,
• ftp_user: Dirección de correo para FTP anónimos.

Con nuestro editor de texto favorito (nano en este artículo), editaremos o crearemos (recomendado) el fichero squid.conf, aplicando los parámetros descritos en el punto anterior acorde con el ejemplo que se muestra a continuación (ver Listado 1).

Listado 1. Squid.conf Parte 1, definición de parámetros globales
[root@satriani] nano /etc/squid/squid.conf
Squid.conf Parte 1, Configuración Global
-----------------------------------------------------
#
#Fichero de Configuración Squid 2.6.x
#Localización: /etc/squid/squid.conf
#
#Última modificación : 07/02/07
#
visible_hostname proxy.mydomain.com
http_port 3128 transparent
#
#
#Parámetros de la cache
cache_mem 32 MB
cache_dir ufs /tmp 1024 32 256
cache_mgr myuser@mydomain.com
coredump_dir /var/spool/squid/cache
acl manager proto cache_object
maximum_object_size 32768 KB
cache_access_log /var/log/squid/access.log
#
#
#Parámetros varios
half_closed_clients off
ftp_user anonymous@nospam.com

ACLs

Un ACL es una definición de control de acceso, que en Squid se especifica mediante el parámetro acl según la siguiente sintaxis:

acl nombre_acl tipo_acl descripción
...
acl nombre_acl tipo_acl
"fichero_de_descripciones" ...

Cuando usamos un “fichero_de_descripciones“, cada descripción se corresponde con una línea del fichero, como podemos ver en el siguiente ejemplo:

acl denywords url_regex "/etc/squid/denywords"
http_access deny denywords

Es necesario apuntar que antes de reiniciar el servicio, el fichero /etc/squid/denywords debe existir; en caso contrario no se podrá iniciar el servicio. Es recomendable añadir por lo menos una cadena de texto, para eliminar un posible mensaje Warning al iniciar el servicio.
Las Listas de Control de Acceso (ACL) en Squid proporcionan seguridad adicional, limitando o permitiendo tráfico. Implementando ACLs podremos, entre otras opciones filtrar tráfico por:

• IP o Subred de origen,
• Dominio o Subdominio de destino,
• Contenido del site,
• Extensión del archivo o archivos descargados,
• Navegador utilizado,
• Filtrado por MAC,
• Filtrado por horario.

Listado 2. Squid.conf Parte 2, definición de ACLs
acl all src 0.0.0.0/0.0.0.0
acl localhost src 127.0.0.1/255.255.255.255
acl lan src 192.168.0.0/255.255.255.0
acl denywords url_regex "/etc/squid/denywords"
acl denydomains dstdom_regex "/etc/squid/denydomains"

A continuación describiremos el proceso para aplicar las ACLs a nuestra implementación. Definiremos las redes / subredes en las que trabajaremos. En este caso son tres redes:

• 127.0.0.1/255.255.255.255 : Loopback, el propio Squid debe poder conectarse por la interfaz de loopback(lo).
• 192.168.0.0/255.255.255.0: LAN en la que Squid escucha por el puerto 3128(http_port).
• 0.0.0.0/0.0.0.0: Definición global de todas las redes.

Listado 3. Squid.conf Parte 3, aplicación de ACLs
http_access allow localhost
http_access allow manager localhost
http_access deny denywords
http_access deny denydomains
http_access allow lan
http_access allow mantenimiento
http_access deny CONNECT !SSL_Ports
http_access deny CONNECT !Safe_Ports
http_access deny all

Definiremos las restricciones a aplicar en los hábitos de navegación:

• Restricción a dominios determinados, por ejemplo midominio.com,
• Restricción a sitios cuyo contenido contenga la cadena micadena,
• Restricción de conexiones que no tengan como origen las redes de las interfaces loopback y eth0 (en este ejemplo),
• Restricción de conexiones que intenten acceder a puertos que no se hayan definido previamente en las ACLs SSL_ports Safe_ports,
• Restricción total al resto de conexiones que no coincidan con los patrones definidos en las ACLs.

Llegados a este punto, tenemos prácticamente configurado Squid. Antes de iniciar el servicio, necesitamos crear la estructura del directorio swap de Squid, iniciar el servicio y verificar el funcionamiento. Para ello, como de costumbre, desde el terminal y como root (Listado 4).

Listado 4. Arrancando Squid
[root@satriani] squid -z
2007/02/07 15:10:18 | Creating Swap Directories
[root@satriani] /etc/init.d/squid start
Starting Squid HTTP Proxy: squid
[root@satriani] telnet 192.168.0.254 3128
Trying 192.168.10.254 3128 . . .
Connected to proxy.mylan.com (192.168.0.254)
Escape character is '^]'.
get http://www.gnu.org

Uno de los puntos a tener en cuenta a la hora de configurar un servidor proxy son los ficheros log. Éstos suelen aumentar de tamaño, como es lógico, a medida que nuestro proxy va sirviendo páginas. Para evitar futuros problemas, es necesario configurar la herramienta logrotate, para que la rotación de logs se realice semanalmente (Listado 5).

Listado 5. Rotando logs
[root@satriani] nano /etc/
logrotate.d/squid
/var/log/squid/access.log {
weekly
rotate 5
copytruncate
compress
notifempty
missingok
}

Configuración Proxy Navegadores

En párrafos posteriores, configuraremos Iptables, para dotar a nuestro servidor proxy, de las funciones de proxy transparente. Para que los navegadores de los clientes envíen las peticiones a nuestro servidor, debemos configurar los navegadores para que salgan a Internet por el proxy.
Configuración para Mozilla Firefox 2.0.x:
Herramientas/Opciones/Avanzado/Red/Configuración.
Configuración para Internet Explorer 6.0.x:
Herramientas/Opciones de Internet/Conexiones/Configuración LAN.
Configuración para Links 0.99.x: Configuración/Opciones de Red.
Se han obviado en la implementación del proxy, la instalación de filtros adicionales, que facilitan las restricciones y las configuraciones de las ACLs, como pueden ser los archiconocidos DansGuardian o Squid Guard. Una de las opciones más interesantes de Squid, es que, en binomio con Iptables, podemos configurar el mismo servidor proxy como gateway para la salida a Internet, liberando al administrador de red, de la tediosa labor de configurar puesto a puesto los navegadores y demás aplicaciones.
La instalación y configuración de estos paquetes, así como la configuración de Squid en modo transparente es relativamente sencilla, y los resultados son realmente espectaculares, pero como habrá podido observar el lector, se escapan al enfoque inicial de este artículo.
Monitorizando accesos: SARG
Con Squid funcionando, filtrando resultados y acelerando en la medida de lo posible los accesos a Internet, la monitorización de accesos desde Shell al fichero access.log, se vuelve una tarea tediosa y complicada. Existen multitud de paquetes que resuelven con más o menos soltura esta tarea, entre ellos destacamos:

• Calamaris,
• Webalizer,
• Squidalyser,
• SARG.

Cualquier opción es altamente recomendable, pero por flexibilidad, sencillez y robustez, utilizaremos SARG. Acrónimo de Squid Análisis Report Generador, SARG es una aplicación escrita en C por Pedro Orso, que genera reportes en HTML a partir del fichero access. log generado por Squid, soportando ficheros log de: Squid, Microsoft ISA Server y Novell Border Manager.
Entre otros detalles muestra información acerca de :

• Usuarios: Distinguiendo IP origen o Nombre de Usuario,
• Archivos descargados,
• Sites visitados,
• Sites denegados,
• Top Sites: Sites más visitados,
• Errores de autentificación.

La versión más actual (Enero 2007) es la 2.2.3.1, pudiendo ser descargada en formato tar.gz o en paquetes binarios para: Debian, Fedora-RedHat, SuSE, Slackware, OpenBSD, MacOS…etc.
Como se indica en el párrafo anterior, SARG genera reportes en formato HTML, con lo cual nos vemos prácticamente obligados* a instalar un servidor web en nuestra máquina, por ejemplo Apache (http://www.apache. org), disponible para casi la totalidad de distribuciones GNU/Linux. Por razones de seguridad y privacidad, a la hora de generar los reportes, se recomienda instalar el módulo mod_auth, para restringir el acceso al servidor web.
La instalación, vía apt, yum o rpm, como viene siendo habitual es muy sencilla. Para la instalación desde una versión en tar.gz, describiremos los pasos:
Desempaquetamos y descomprimimos el fichero sarg-x.x.x.tar.gz:

[root@satriani] tar zxvf sarg-x.x.x.tar.gz
[root@satriani] ./configure
configure options:
enable-bindir= Directorio dónde se instalará el binario de sarg; por defecto : /usr/bin
enable-sysconfdir – Directorio de configuración; por defecto : /usr/local/sarg
nable-htmldir – Directorio del servidor web donde se generarán los reportes; default: /var/www/html
enable-mandir - where the sarg man page will be saved; default: /usr/local/man/man1
make
make install

En el directorio /usr/local/sarg o en el directorio especificado en –sysconfigdir, editaremos el fichero sarg.conf y haremos las modificaciones oportunas.
Podemos enviar los reportes a otra máquina vía SMB,NFS…etc.
El fichero sarg.conf almacena la configuración de SARG, y se localiza en el directorio especificado en –enable-sysconfdir, y la sintaxis es como en el Listado 6.

Listado 6. Ejemplo sarg.conf
Ejemplo fichero sarg.conf
# Slovak
# Spanish
# Turkish
#
language Spanish
# TAG: access_log file
# Where is the access.log file
# sarg -l file
#
access_log /var/log/squid/
access.log
# TAG: graphs yes|no
# Use graphics where is possible.
# graph_days_bytes_bar_color blue|g
reen|yellow|orange|brown|red
#
graphs yes
graph_days_bytes_bar_color red

Pese a ser un fichero de configuración aparentemente sencillo, en realidad nos encontramos con infinidad de posibilidades y combinaciones a la hora de trabajar con SARG.
Para hacer nuestra primera prueba, desde Shell y como root simplemente:

[root@satriani] sarg

Si no hemos tenido ningún Warning, abriendo un navegador podremos ver los resultados (Figuras 4, 5, 6).
Necesitamos añadir una tarea cron para ejecutar SARG por lo menos una vez al día, para ello, con nuestro editor de textos favoritos editamos /etc/crontab y añadimos:

0 20 * * * root /usr/bin/sarg

Iptables

El proyecto Iptables, también conocido como Netfilter, comenzó en 1998 encabezado por Michael Neuling y Rusty Russell, autor también del proyecto antecesor a iptables: ipchains.
Iptables es la herramienta principal de cortafuegos para GNU/Linux en las series del Kernel 2.4 en adelante. En relación a ipchains las principales novedades son: mejor aprovechamiento de los recursos del sistema, la integración de las reglas de filtrado, NAT y manipulación.
Para instalar Iptables en nuestra/s máquinas, podemos descargar iptables de www. netfilter.org, compilarlo e instalarlo. En prácticamente cualquier distribución actual el kernel está precompilado e iptables instalado por defecto.
Iptables para su funcionamiento utiliza tres tablas: nat, magle, y filter, donde cada una tiene definidas unas reglas o chains.Cada una de estas reglas se compone de una lista de reglas de filtrado sobre el paquete mediante un par condición/acción. El paquete IP pasará secuencialmente por cada una de estas reglas hasta encajar en alguna de las reglas definidas. En caso contrario, se aplicará la acción por defecto asociada a esa regla.
Veamos un ejemplo de construcción de regla de iptables (man iptables):

iptables { -A | --append | -D | --delete } cadena especificación-de-regla [ opciones ]
/sbin/iptables –A INPUT –i eth0 –p tcp –dport 80 –j DROP

En la regla anterior, añadimos (-A) a la tabla filter (INPUT) una regla que deniega (DROP) todo el tráfico web entrante (-p tcp –dport 80) por la interfaz eth0 ( -i eth0).
Enmascarando Interfaces: Proxy transparente
Es necesario recordar que iptables no deja de ser un shell script, y que si no salvamos las reglas, con el reinicio de la máquina, éstas se perderán. Para ello, disponemos del comando iptables-save. En este ejemplo, de integración de Iptables con Squid, no utilizaremos iptables-save, sino que crearemos un shell script, que ejecutaremos cada vez que reiniciemos la máquina. Así, podremos comentar y analizar de un modo mucho más flexible el conjunto de reglas a aplicar.
Comenzaremos creando el fichero que almacenará las reglas de iptables. Como es habitual, en el terminal y como root:

[root@satriani] touch /etc/init.d/firewall
[root@satriani] chmod 700 /etc/init.d/firewall
[root@satriani] update-rc.d firewall defaults

Hemos creado el fichero /etc/init.d/firewall, modificado permisos (rxw- - - - - - ) para que solamente root pueda ejecutarlo, y a continuación con el comando update-rc.d conseguimos que se ejecute en todos los runlevels.
Retomemos la configuración de Squid. Tenemos corriendo el servicio de Proxy Caché, en el puerto TCP 3128. Supuestamente hemos llevado a cabo la tediosa labor de configurar todas y cada una de las aplicaciones en las máquinas de nuestra LAN que queremos que salgan a Internet a través de este servicio. Evidentemente este supuesto es inviable cuando el número de máquinas y aplicaciones de las que hablamos es considerable. Para ello, iptables es capaz de simular un router, actuando como puerta de enlace para las máquinas de su LAN, por medio del enmascaramiento IP o masquerading.

Llegados a este punto, iptables llama a la puerta de nuestra máquina pidiendo ser configurado. Como hemos comentado, iptables es capaz de modificar los paquetes IP, acorde a unas reglas predefinidas. Para ello añadiremos reglas en la tabla mangle, utilizando la cadena PREROUTING; es decir, redireccionaremos todas la peticiones al puerto 80 hacia el 3128:

iptables –t nat –A PREROUTING –s 192.168.0.0/0 –p tcp –dport 80 –j DNAT –to-destination 192.168.0.1:3182

Ejecutando este script, eliminando la configuración proxy en las aplicaciones configuradas en las máquinas de nuestra LAN y modificando el gateway de éstas por las IP de la interfaz enmascarada, hemos configurado un proxy transparente.
Como habrán podido observar nuestros avispados lectores, la política por defecto es ACCEPT, con lo cual nuestra máquina acepta todo el tráfico sin restricciones ni filtrado de ningún tipo, dejándola expuesta ante cualquier ataque. Así mismo, tampoco se ha mencionando las conexiones por SSL a través del proxy transparente. La razón es muy sencilla: los paquetes viajan cifrados entre el servidor web y el navegador del cliente, impidiendo que Squid pueda escuchar y procesar correctamente las peticiones https. Recordemos que el proxy se encuentra entre el webserver y el navegador del cliente. Entre las recomendaciones sugeridas para aumentar el blindaje de nuestra máquina se encuentran:

• Cambiar política por defecto a DROP. Es un paso complejo, pero muy recomendable al tratarse de una máquina expuesta a Internet. Antes de implementar esta solución, instale y configure una máquina a efectos de testing. El establecimiento de DROP por defecto, requiere conocimientos mínimos de la pila de protocolos TCP/IP, para po der manejar con soltura las reglas de iptables.
• Añadir regla que permita hacer forward a peticiones SSL. Como hemos comentado, Squid en modo transparente no puede procesar peticiones HTTPS, con lo cual será necesario permitir el acceso a través de Iptables

  iptables -A INPUT -i eth0 -p tcp -s 192.168.0.0/24 –dport 443 -j ACCEPT.

En caso de encontrar problemas a la hora de identificar los puertos utilizados en las conexiones SSL, aplicaciones como Ethereal o Iptraff, pueden ayudarnos.
Logear reglas. Iptables permite logear reglas con la directiva LOG, lo cual nos permitirá comprobar si ha habido algún intento de acceso no deseado a nuestra máquina:

iptables –A INPUT –i eth0 –p tcp –dport 22 –j LOG –logprefix=”ACCESO-SSH”

Por defecto, el fichero log donde iptables almacena los log es /var/log/messages. A medida que este fichero va aumentando, acceder a una línea concreta, puede resultar una tarea ardua y difícil. Para ello existen herramientas que permiten su legibilidad, como por ejemplo Wflogs, que convierte entradas en formato HTML.
IDS. Implementar un Sistema de Detección de Intrusos nunca está demás. Recomendamos encarecidamente Snort. La finalidad de este artículo es mostrar al lector las posibilidades globales de Squid e Iptables. Es responsabilidad de cada usuario o Administrador, proteger y blindar sus sistemas. Implementando Squid e Iptables tendrá parte del camino recorrido, el resto… está en sus manos.

Listado 7. Script de configuración iptables
#!/bin/bash
#
#
#
#Borrado de reglas previas
iptables –F
iptables –X
iptables –Z
iptables –t nat –F
#
#
#Política por defecto
iptables –P INPUT ACCEPT
iptables –P OUTPUT ACCEPT
iptables –P FORWARD ACCEPT
iptables –t nat -P PREROUTING ACCEPT
iptables –t nat –P POSTROUTING ACCEPT
#
#
#Permitimos que los paquetes puedan ser "forwardeados"
iptables –A FORWARD –p tcp –s 192.168.0.0/24 –j ACCEPT
#
#Redireccionamos el tráfico web hacia el proxy
iptables –t nat –A PREROUTING –s 192.168.0.0/24 –p tcp –dport 80
–j DNAT –to-destination 192.168.0.1:3128
#Enmascaramos la interfaz eth0
iptables –t nat –A POSTROUTING –s 192.168.0.0/24 –o eth0 –j MASQUERADE
#
#Habilitamos bit de forward. ¡Muy importante!
echo 1 > /proc/sys/net/ipv4/ip_forward

Consideraciones finales

Controlar el acceso y acelerar la navegación a los sitios visitados en Internet es una solución viable y contrastada para optimizar el acceso y el ancho de banda de una PYME. Mediante la instalación de una solución proxy gestionar la conexión a Internet desde un sólo punto, permitiendo una conexión segura, habilitando y denegando la conexión a ciertos puertos o protocolos es posible, fiable, y económico.
Implementando Sistemas Operativos Libres (Linux,*BDSs ..etc), independientemente del ahorro de costes en licencias, dotamos a las implementaciones de un nivel de seguridad y robustez añadido, que difícilmente podremos encontrar en otros Sistemas Operativos.
Squid, como software de servidor proxy, en su versión 2.6, ha alcanzado su madurez, tanto es así, que grandes corporaciones e incluso ISPs optan por su implementación bajo plataformas *NIX. Iptables va camino de convertirse en un hito en sistemas GNU/Linux con Kernel 2.4 - 2.6. Mientras tanto y a la espera de la release 2.7 de Squid… seguiremos haciendo web-caching.

Enlaces de la red:

• Squid: http://www.squid-cache.org/
• Dansguardian: http://www.dansguardian.org/
• SquidGuard: http://squidguard.shalla.de/
• Calamaris: http://calamaris.cord.de/
• Sarg: http://sarg.sourceforge.net/
• Netfilter: http://www.netfilter.org
• Wflogs: http://www.wallfire.org/wflogs/

Ese fichero de configuración que casi siempre nos olvidamos de él y que a penas dedicamos unos minutos de nuestro tiempo y puede ayudarnos mucho. Voy a explicar sus opciones.

• nameserver IP
  Una IP de un servidor de dominios o DNS donde se hacen las consultas de DNS, es decir, a que DNS se va a consultar cuando necesitemos traducir un nombre de dominio en una IP. Se pueden poner más de una directiva y se usaran una detrás cuando falle la anterior. También depende de que opciones se hayan puesto, ver más abajo.
• search lista_de_dominios
  Lista_de_dominios pueden ser hasta 6 dominios diferentes con un máximo de 256 en total y se utilizan para poder usar nombres cortos de dominio sin tener que añadir el dominio completo. Por ejemplo si trabajamos en una universidad y todos los dispositivos tienen 2 tipos de dominios dispositivo.campus.a.uni.edu o dispositivo.campus.b.uni.edu podrmos agregar una lista search campus.a.uni.edu campus.b.uni.edu y ahora podemos usar solo el nombre del dispositivo al cual se le añadirá el dominio automáticamente.
• options lista_de_opciones
  donde lista de opciones puede ser:
  • timeout:n
    indica el numero de segundo que debe esperar por la respuesta y si no da un timeout. Por defecto son 5 segundos.
  • attempts:n
    Número de intentos que debe hacer al DNS antes de dar error a la aplicación, por defecto 2.
  • rotate
    lo que hace es un round robin con todos los servidores de nombre que se han indicado con nameserver en vez se siempre consultar el primero. Esto es útil para no cargar siempre a un mismo DNS y poder repartir la carga de las consultas.
  • ndots:n
    Indica el número de puntos (.) que deben aparecer en el dominio a consultar antes de añadir un dominio indicado por search. Por defecto es 1 punto (.), lo que significa que cualquier dominio con al menos un punto se consulta al DNS antes de añadir un dominio indicado por search. Por ejemplo si queremos poder indicar dispositivo.campus_a y que añada siempre un dominio indicado por search deberemos poner ndots:2 para que al menos haya 2 puntos (.) para consultar al DNS.

Hay alguna opción más pero las más interesantes y útiles están aquí explicadas. Como siempre mira el manual de resolv.conf o en algún libro de Bind.

Con la utilidad “Perfil de Sistema” (o System Profiler en inglés) podemos ver toda la información de nuestro sistema de una forma ordenada por temas y muy visual, pero los que solemos hacer scripts y necesitamos información del sistema esta utilidad no es de poca o nula ayuda. Sin embargo hay un comando (system_profiler) de shell que hace lo mismo pero lo devuelve en texto (por defecto) o en XML ambos muy fáciles de parsear en un script.

La ayuda y parámetros de system_profiler de es la siguiente:

system_profiler [-listDataTypes]
system_profiler [-xml] [-detailLevel n]
system_profiler [-xml] [dataType1 ... dataTypeN]

• -detailLevel n
  especifica el nivel de detalle que mostrará
  mini = muestra poca información (no contiene información identificativa o personal)
  basic = información básica de red y hardware
  full = toda la información disponible.
• -listDataTypes
  Lista todos los tipos de datos (datatypes) para luego mostrar información de ese tipo.
• -xml
  Genera salida en XML en vez de texto plano. Si se redirige la salida (vía pipe “|”) a un fichero con extensión “.spx”  el fichero se puede abrir desde la utilidad “Perfil de Sistema” (System Profiler en inglés).

Si no se usa ningún parámetro lista TODA la información del sistema al estilo de la utilidad “Perfil de Sistema”, aunque si se usa el parámetro “-detailLevel full” la cantidad de información puede ser abrumadora.

A nivel de script con ejecutar el comando a secas o en toda caso con el parámetro “-xml” para obtener el resultado en XML será más que suficiente y en todo caso para limitar la cantidad de salida o limitar a un tipo de datos concretos añadir el parámetro “datatype” con el tipo de datos que necesitamos.
Un ejemplo de salida de un tipo concreto, donde se muestra el tipo de tarjeta gráfica y monitor que tengo:

$ system_profiler  SPDisplaysDataType
Graphics/Displays:

    ATI Radeon HD 2600 XT:

      Chipset Model: ATI Radeon HD 2600
      Type: Display
      Bus: PCIe
      Slot: Slot-1
      PCIe Lane Width: x16
      VRAM (Total): 256 MB
      Vendor: ATI (0x1002)
      Device ID: 0x9588
      Revision ID: 0x0000
      ROM Revision: 113-B1480A-252
      EFI Driver Version: 01.00.252
      Displays:
        DELL 2407WFP:
          Resolution: 1920 x 1200 @ 60 Hz
          Depth: 32-bit Color
          Core Image: Hardware Accelerated
          Main Display: Yes
          Mirror: Off
          Online: Yes
          Quartz Extreme: Supported
          Rotation: Supported
        Display Connector:
          Status: No display connected

Bash tiene un gran soporte de comparadores de todo tipo que nos permiten hacer comparaciones en los bucles y crear condiciones de todo tipo:

Comparación de enteros (números)

• -eq
  es igual a

  if [ "$a" -eq "$b" ]

• -ne
  no es igual a / distinto

  if [ "$a" -ne "$b" ]

• -gt
  es mayor que

  if [ "$a" -gt "$b" ]

• -ge
  es mayor que o igual a

  if [ "$a" -ge "$b" ]

• -lt
  es menor que

  if [ "$a" -lt "$b" ]

• -le
  es menor que o igual a

  if [ "$a" -le "$b" ]

• <
  es menor que (dentro de doble paréntesis)

  (("$a" < "$b"))

• <=
  es menor que o igual a (dentro de doble paréntesis)

  (("$a" <= "$b"))

• >
  es mayor que (dentro de doble paréntesis)

  (("$a" > "$b"))

• >=
  es mayor que o igual a (dentro de doble paréntesis)

  (("$a" >= "$b"))

Comparación de cadenas

• =
  es igual a

  if [ "$a" = "$b" ]

• ==
  es igual a

  if [ "$a" == "$b" ]

Nota: Aunque es un sinónimo de = el operador == se comporta diferente cuando se usa dentro de corchetes dobles que simples, por ejemplo:

[[ $a == z* ]]   # Verdadero si $a empieza con una "z" (expresión regular coincide).
[[ $a == "z*" ]] # Verdadero si $a es igual a z* (coincide literalmente).

[ $a == z* ]     # Ocurre división de palabras.
[ "$a" == "z*" ] # Verdadero si $a es igual a z* (coincide literalmente).

• !=
  no es igual a / Distinto

  if [ "$a" != "$b" ]

  NOTA: este operador usa coincidencia de patrón dentro de doble corchete.

• <
  es menor que (en orden alfabético ASCII)

  if [[ "$a" < "$b" ]]
  if [ "$a" \< "$b" ]

  Nota: el operador “<” necesita ser escapado dentro de corchetes.

• >
  es mayor que (en orden alfabético ASCII)

  if [[ "$a" > "$b" ]]
  if [ "$a" \> "$b" ]

  Nota: el operador “>” necesita ser escapado dentro de corchetes.

• -z
  La cadena está vacía (nulll), tiene longitud cero.

  cadena=''   # Variable de longitud cero (null)
  if [ -z "$String" ]
  then
  echo "\$String está vacía."
  else
  echo "\$String no está vacía."
  fi

• -n
  cadena no está vacía (contiene algo)
  nota: El operador -n exige que la cadena esté entre comillas entre paréntesis. Aunque el uso son comillas puede funcionar es altamente recomendable usar comillas.

Comparaciones lógicas

• -a
  Y lógico (and)

  exp1 -a exp2

  devuelve verdadero si ambas exp1 y exp2 son verdaderas.

• -o
  O lógico (or)

  exp1 -o exp2

  devuelve verdadero si alguna de las expresiones exp1 y exp2 son verdaderas.

Éstos últimos operadores son similares a los operadores de Bash && (and) y || (or) cuando se usan con doble corchete:

[[ condition1 && condition2 ]]

El secure mode es un modo en el que es a la vez muy potente y peligroso ya que tenemos acceso TOTAL a todo el sistema como root y sin que sepamos la contraseña ni de un usuario ni la del propio root. Por lo tanto es conveniente que por una parte no dejemos a nadie desconocido nuestro MAC ni hagamos cosas sin saber en este modo porque podemos corromper nuestro sistema y dejarlo inservible.

Para entrar en este modo hacemos lo siquiente:

1. Encendemos o reinciamos el MAC
2. En cuanto arranque pulsamos y mantenemos pulsadas las tecla command+s (manzana+s o ⌘+s)
3. Veremos como arranca en modo texto y terminará mostrandonos el prompt #

Una vez que estemos en el modo seguro (o más bien diría yo inseguro si no sabes lo que haces) podemos hacer cosas interesantes (sin las comillas):

• “/sbin/fsck -y” esto hace un chequeo del disco de sistema de arranque. -y hace que no nos pregunte nada y asume YES (SI) a todas las preguntas.
• /sbin/mount -wu /” por defecto el sistema está en modo solo lectura y con esto pasamos a modo lectura/escritura con lo cual podemos modificar ficheros.
• passwd usuario” cambiamos la contraseña de un usuario del sistema incluida la de root (en alguna ocasión podemos necesitar pasarnos a root, usando su -, aunque es aconsejable usar el comando sudo).
• /sbin/SystemStarter” esto inicializa los servicios de red, que es necesario para obtener acceso a NetInfo.
• En caso de que tengamos problemas con el login o simplemente la ventana de login no aparezca, es muy probable que nuestro directorio NETINFO esté corrupto, podemos borrar y que el sistema cree uno nuevo. ATENCIÓN: esto borra todos los datos del usuario y hay que crearlos desde cero, también necesitamos que root tenga una contraseña y conocerla claro:
  • 10.4

    rm -Rf /var/db/netinfo

  • 10.5

    rm -Rf /var/db/dslocal
    rm /var/db/.AppleSetupDone

Para salir del secure mode podemos usar una de estas tres opciones:

1. exit - Continua el proceso de arranque. En caso de que hayamos hecho modificaciones importantres y/o ejecutado SystemStarter o arrando algún demonio es más seguro reiniciar.
2. reboot - Reinicia el ordenador.
3. shutdown -h now - Apaga el ordenador.