ff-multiconverter, multimedia, audio, video, linux, ubuntu ubuntu kylin, china, releases, linux terminal, ubuntu, linux, comandos, shell conky, gadgets, ubuntu, linux SpeedTest-Cli, velocidad, red, consola, terminal tag foto 6 pinta, grafica, linux, ubuntu djl, juegos, yum, synaptic, paquetes ubuntu, releases, canonical psensor, ubuntu, linux, sistema, monitor
Mostrando las entradas con la etiqueta Linux. Mostrar todas las entradas

Linux lanza una tarjeta de crédito con Visa para financiarse

ubuntu_visa Un porcentaje de cada compra irá destinado a financiar a la comunidad de programadores.

La Fundación Linux, la organización que mantiene el desarrollo del sistema operativo libre en todo el mundo, acaba de lanzar una de las iniciativas más curiosas que se recuerdan en el mundo de la informática: una tarjeta de crédito que destinará parte de las ganancias a financiar el desarrollo y el mantenimiento de programas de uso libre.

La iniciativa está desarrollada con Visa y el banco estadounidense UMB, ubicado en Kansas City, y de momento no permite ser solicitada por ciudadanos extranjeros.

La Fundación Linux, que en la práctica es una ONG, recibirá 50 dólares (35 euros) por cada alta de usuario aprobada y un pequeño porcentaje por cada compra que se haga con ella. La cuota anual es gratuita y permite financiar compras a crédito.

Además hay un programa de puntos por compras, que incluyen billetes de avión, y otros beneficios habituales en las tarjetas de crédito estadounidenses, además de protección antirrobo.

Extensa comunidad de programadores
La Fundación Linux, creada en el 2007, mantiene el núcleo del sistema operativo creado por Linus Torvald y los desarrollos de los programas basados en código abierto de programadores y compañías como Fujitsu, Hitachi, HP, IBM, Intel, NEC, Novell y Oracle, a los que contribuyen programadores de todo el mundo, la mayoría de forma desinteresada.

Guia de Seguridad del Administrador de Linux (GSAL): Acceso a los ficheros del servidor WWW

Acceso a los ficheros del servidor WWW

En algún momento habrá que acceder a los ficheros del servidor para actualizarlos. Hacer un logging y utilizar un editor de texto como el emacs no suele ser una sabia decisión a largo plazo, si valoras tu tiempo. Hay varios paquetes de autoría de HTML que pueden acceder al website vía FTP o compartición de ficheros de Windows.

FTP

Este es el método clásico de garantizar acceso a los usuarios a los servidores ftp, las preocupaciones habituales incluyen que los usuarios puedan verse sus
ficheros entre sí, que vean ficheros del sistema que no deberían, etcétera.

Hacer un chroot de las sesiones de los usuarios resolverá la mayoría de estos problemas, sin embargo el principal problema que existe con el FTP es que cifrar el nombre de usuario y la contraseña no suele ser posible debido al hecho de que la mayoría de la gente está utilizando clientes FTP de Windows.

Recomendaría el ProFTPD antes que el WU-FTPD para una aplicación de este tipo,
el ProFTPD tiene mejores controles de acceso.

Acceso Samba

El Samba es bastante útil para compartir directorios www con clientes Windows, se pueden mantener los nombres de usuarios y contraseñas separados del sistema (utilizando smbpasswd en vez del passwd del sistema) y el cifrado de logins no es ningún problema. Simplemente hay que hacer los directorios compartidos no visibles, y utilizar la directiva "valid users" para restringir qué usuarios pueden ver los datos compartidos. Por ejemplo:

[www-example]

path = /www/www.example.org/

valid users = example

read only = No

browseable = No

configurará un directorio compartido bastante seguro del directorio "/www/www.example.org/" al que sólo podrá acceder el usuario "example".

Acceso Frontpage

El FrontPage es uno de los programas más famosos para edición de HTML entre los usuarios de Windows (qué caramba, incluso yo lo utilizo). Puede comunicarse directamente con los servidores WWW y descargar / subir ficheros de un sitio (llamado el "sitio Frontpage") si el servidor soporta extensiones FrontPage. Las extensiones FrontPage se encuentran disponibles para diferentes plataformas

UNIX, gratuitamente, en Ready To Run Software: http://www.rtr.com En el pasado, las extensiones FrontPage de RTR para UNIX han sido un tanto desastrosas. Sin embargo existen alternativas comerciales, una es el Instant ASP, disponible en:
http://www.halcyonsoft.com

RearSite

El RearSite es un programa cgi que proporciona a los usuarios acceso a sus directorios vía un navegador normal. Se puede conseguir en:
http://listes.cru.fr/rs/fd

Fast Webpage Exchanger

El Fast Webpage Exchanger mantiene sincronizados los ficheros utilizando un interesante fichero de configuración en el que se especifica todo. Se puede descargar desde: http://www.enjoy.ne.jp/~gm/program/iew_en.html

SMTP

Simple Mail Transfer Protocol (SMTP), es uno de los servicios más importantes que proporciona Internet. Ahora casi todas las compañías tienen o dependen del correo, y por extensión todos los servidores SMTP. Se encuentran disponibles muchos paquetes SMTP, siendo el más viejo y el más probado el Sendmail (ahora con soporte comercial, etc.), y hay dos nuevos contendientes, Postfix y Qmail, ambos dos escritos desde cero teniendo en cuenta la seguridad. Filtrar con el
cortafuegos el SMTP no tiene pérdida, se ejecuta en el puerto 25, tcp:

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 25

ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 25

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 25

o bien con ipchains:

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 25

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 25

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 25

Sendmail

Sendmail es otro de esos servicios con los que la mayoría de nosotros hemos tenido relaciones. Odiamos administrarlo y nos encantaría reemplazarlo (en realidad he empezado a eliminar el Sendmail de las máquinas que administro y lo estoy reemplazando con el Postfix).

Sendmail se ha ganado por sí mismo una muy mala reputación en cuanto a seguridad, sin embargo es difícil echarle la culpa al software cuando te encuentras con sistemas ejecutando versiones antiguas del sendmail. La raíz del problema (si se me permite el mal juego de palabras) es que casi todo el mundo ejecuta el sendmail como root (y algo así como el 70% del correo de Internet se maneja mediante máquinas con Sendmail, de modo que hay un montón de ellas), de
forma que tan pronto se encuentra un bug, encontrar un sistema que explotar no es tan difícil. Las últimas versiones de sendmail han sido bastante buenas, sin hacks del root, etc, y con las nuevas características anti spam finalmente ha alcanzado la mayoría de edad. Más información en Sendmail y su código fuente está disponible en:

http://www.sendmail.org/

Hacer un chroot del sendmail es una buena opción, pero lleva demasiado trabajo, y puesto que se ejecuta como root, algo bastante discutible en cuanto a su efectividad (puesto que el root se puede escapar de una cárcel chroot).

Personalmente pienso que es mejor invertir el esfuerzo en cambiarse a Postfix o a Qmail.

Mantener actualizado el sendmail es relativamente simple, recomendaría como mínimo la versión 8.9.3 (la serie 8.9 tiene más características anti-spam, la 8.8.x tiene la mayoría de estas características, suponiendo que se ha configurado correctamente el sendmail.cf). La mayoría de las distribuciones vienen con la 8.8.x, aunque las versiones más recientes suelen venir con la
8.9.x. Se puede conseguir el código fuente desde ftp://ftp.sendmail.org/, pero compilar el sendmail no es algo para el débil de corazón o para aquellos que no tengan un montón de tiempo para dedicárselo.

Sendmail sólo tiene que estar accesible desde el mundo exterior si se está utilizando para recibir correo de otras máquinas y repartirlo localmente. Si sólo se quiere ejecutar sendmail de forma que funcione el reparto local (p. ej., una estación de trabajo autónoma, un servidor de prueba u otros) y que se pueda enviar con facilidad el correo a otras máquinas, simplemente filtra con
el cortafuegos el sendmail, o mejor, no lo ejecutes en modo demonio (en el cual escucha conexiones). Sendmail se puede ejecutar en la cola de refresco de un nodo, donde simplemente se "despierta" cada cierto tiempo y procesa el correo local, ya sea distribuyéndolo localmente o enviándolo a través de la red. Para configurar la ejecución del Sendmail en modo cola:

edita el script de inicio del Sendmail y cambia la línea que contiene:

sendmail –bd –q1h

por:

sendmail –q1h

Ten en cuenta que: si utilizas el sistema para enviar mucho correo quizás prefieras disminuir el tiempo de refresco, quizás "-q15m" (refrescar la cola cada 15 minutos), ahora el correo saliente y el correo interno del sistema se comportarán bien, lo cual a menos que se ejecute un servidor de correo, es perfecto.

Ahora vienen todas esas maravillosas características anti-spam del sendmail.
Los ficheros de configuración del Sendmail consisten en (se aplica al Sendmail 8.9.x):

/etc/sendmail.cf

El fichero de configuración principal, también dice dónde se encuentran el resto de ficheros de configuración.

/etc/mail/

Se puede definir la localización de los ficheros de configuración en sendmail.cf, generalmente la gente los coloca en /etc/ o en /etc/mail (lo cual
lo lía menos).

access

La base de datos de la lista de accesos, permite rechazar el correo proveniente de ciertas fuentes (IP o dominio), y controlar con facilidad las transmisiones.
Mi fichero de acceso es así:

* RELAY

spam.com REJECT

lo que quiere decir que a 10.0.0.* (los hosts de mi red interna) se les permite
utilizar el servidor de correo para enviar correo donde quieran, y el correo de
*.spam.com se rechaza. Hay listas en línea de spammers conocidos, generalmente
suele tener entre 5-10.000 entradas, lo cual puede afectar seriamente el
rendimiento del sendmail (pues cada conexión se comprueba contra esta lista),
por otra parte, tener una máquina sendmail para enviar spam es incluso peor.

aliases

El fichero de alias, te permite controlar el reparto del correo local al
sistema, es útil para hacer una copia de seguridad del correo entrante de un
usuario a un spool por separado. La mayoría del software de servidores de
listas utiliza este fichero para enviar el correo que recibe a los programas
que realmente procesan las listas. Recuerda ejecutar el comando "newaliases"
después de editar este fichero, y después reiniciar el sendmail.

domaintable

la tabla de dominios (añadir dominios) que se maneja, útil para hacer hosting
virtual.

majordomo

fichero de configuración de majordomo, personalmente recomendaría SmartList a
Majordomo.

sendmail.cw

fichero que contiene nombres de hosts de los que se recibe correo, útil si se
alberga más de un dominio.

sendmail.hf

situación del fichero de ayuda (telnet al puerto 25 y escribir "HELP")

virtusertable

Tabla de usuario virtual, mapea usuarios entrantes, p. ej., mapear
ventas@ejemplo.org a john@ejemplo.org

Sendmail 8.9.x (y versiones anteriores) en realidad no tienen soporte para
hacer un log de todo el correo de una forma agradable (un requisito
indispensable por muchas compañías por motivos legales). Esta es una de las
características sobre las que se trabaja en la versión de Sendmail 8.10.x.
Hasta entonces, hay dos formas de hacer log del correo, la primera es algo
agraciada, y registra un log de los correos entrantes a usuarios según cada
usuario. El segundo método no es agraciado, e implica un simple log de todas
las transacciones SMTP a un fichero, habría que escribir algún tipo de
procesador (probablemente en perl) para que el log fuese útil.

El correo (o las conexiones SMTP para ser más precisos) primero se filtra con el fichero access, y es aquí donde se pueden RECHAZAR correos de ciertos dominios/IP's, y TRANSMITIR correo de ciertos hosts (p. ej. tu red interna de máquinas windows). Cualquier dominio local para el que se hospeda el correo tendrá que ir al sendmail.cw. Suponiendo que el correo cumple con las reglas y va a la cola para reparto local, el siguiente fichero que se comprueba en virtusertable, que es una lista de direcciones de correo mapeadas al nombre de la cuenta/otra dirección de correo. p.ej.:

seifried@seifried.org alias-seifried

listuser@seifried.org usuariolista

@seifried.org correos-estropeados

La última regla es para evitar que reboten los correos estropeados, y que en lugar de eso se envíen a un buzón. Después se comprueba el fichero de alias, si se encuentra una entrada se hace lo que dice, y si no, se intenta entregar el correo a un buzón de un usuario local, mi entrada seifried del fichero de alias
es:

alias-seifried: seifried, "/var/backup-spool/seifried"

De esta forma mi correo se reparte a mi buzón normal, y a un buzón de copia de seguridad (por si acaso he borrado un correo que no quisiera), o en el peor de los casos, Microsoft Outlook decide cascar un día y cargarse mis buzones. Esto también sería útil en empresas, puesto que ahora se tiene una copia de seguridad de todo el correo entrante según cada usuario, y se les puede
permitir ( o no) acceder al fichero que contiene el correo en la copia de seguridad.

Una advertencia, cuando se esté usando una regla general para un dominio ( p. ej. @seifried.org) hay que crear un alias para CADA cuenta, y para las listas de correo. Si no, cuando se examina la lista y no se encuentra una entrada específica (para, digamos, lista-correo@seifried.org) lo enviará al buzón especificado por la regla general. Ya sólo por este motivo no se debería
utilizar una regla general.

El segundo método es muy simple, sencillamente se arranca el sendmail con la opción –x y se especifica un fichero para hacer un log de todas las transacciones. Este fichero crecerá con enorme rapidez, NO recomendaría utilizar este método para hacer log del correo, al menos que sea absolutamente necesario.

Qmail

Qmail (al igual que Postfix) fue creado como una respuesta directa a los fallos percibidos en Sendmail. Qmail es GPL con una cláusula sin distribución binaria que obliga a instalarlo desde el código fuente. Muy poco del código del Qmail se ejecuta como root, y es muy modular comparado con el sendmail (el cual es un trozo de código monolítico). Se puede descargar de: http://www.qmail.org/

Postfix

El Postfix es un agente de transferencia de correo (MTA) orientado a la seguridad, velocidad, y facilidad de configuración, cosas en las que Sendmail suele fallar por lo general. Recomendaría encarecidamente reemplazar el Sendmail por el Postfix. La única parte de Postfix que se ejecuta como root es un programa de control maestro, llamado "master", que llama a otros programas
para procesar el correo a la cola ("pickup"), un programa para gestionar la cola, espera conexiones entrantes, repartos de correo retrasados, etc.

("qmgr"), un programa que en realidad envía y recibe el correo ("smtpd") etc.
Cada parte de Postfix está muy bien pensada, y generalmente hace una o dos tareas, muy bien. Por ejemplo, en lugar del modelo de sendmail, donde el correo simplemente se volcaba a /var/spool/mqueue, en Postfix existe un directorio accesible por el mundo llamado "maildrop" el cual se comprueba mediante "pickup", el cual alimenta los datos a "cleanup", el cual mueve el correo (si está correctamente formateado, etc.) a un directorio seguro de cola para el
procesado real.

Los ficheros primarios de configuración están en /etc/postfix, y existen varios ficheros primarios de configuración que es necesario tener:

master.cf

Controla el comportamiento de varios programas de "ayuda", están hechos chroot, el máximo número de procesos que pueden ejecutar, etcétera. Probablemente sea mejor dejar las configuraciones por defecto en la mayoría de los servidores de correo, a menos que se necesite ajustar algo por altas cargas o asegurar el servidor (p. ej. haciéndolo chroot).

main.cf

Este fichero está muy próximo al sendmail.cf (en cuanto a propósito, en cuanto al diseño es bastante diferente). Está bien comentado y configura todas las variables principales, y las situaciones y formato de diferentes ficheros que contienen información tal como los mapeos a usuarios virtuales e información relativa.

He aquí una lista de variables y localización de ficheros que se suele tener que configurar, el fichero /etc/postfix/main.cf por lo general suele estar comentado densamente. Ten en cuenta que los siguientes ejemplos de entradas main.cf no son un main.cf completo.

# ¿cuál es el nombre de la máquina?

myhostname = correo.ejemplo.org

# ¿cuál es el nombre de dominio?

mydomain = ejemplo.org

# ¿cómo etiqueto el "from" del correo?

myorigin = $mydomain

# ¿en qué interfaces lo ejecuto? Por lo general, en todas.

inet_interfaces = all

# un fichero que contiene una lista de nombres de hosts y nombres de

# dominio cualificados desde los cuales recibo correo,

# generalmenteestán listados así:

# mydestination = localhost, $myhostname, etc

# pero prefiero mantener el listado en un fichero.

mydestination = /etc/postfix/mydestination

# mapa de nombres de usuarios entrantes. "man 5 virtual"

virtual_maps = hash:/etc/postfix/virtual

# mapeo de alias (como /etc/aliases en sendmail), "man 5 aliases"

alias_maps = hash:/etc/postfix/aliases

# base de datos de alias, se pueden tener diferentes configuraciones.

# "man 5 aliases"

alias_database = hash:/etc/postfix/aliases

# dónde repartir el correo, formato Mailbox o Maildir

# (el tradicional /var/spool/mail).

home_mailbox = Maildir/

# dónde guardar el correo, generalmente en /var/spool/mail/ pero se

# puede cambiar con facilidad

mail_spool_directory = /var/spool/mail

# ¿qué comando utilizamos para repartir el correo? /usr/bin/procmail

# es el comando por defecto, pero yo utilizo scanmail que es el sello

# del software antivirus AMaViS

mailbox_command = /usr/sbin/scanmails

# para quién retransmito el correo, de nuevo se pueden listarlos o

# guardarlos en un fichero (uno por línea).

relay_domains = /etc/postfix/relaydomains

# lista de redes locales (por defecto se retransmite el correo de

# estos hosts).

mynetworks = 10.0.0.0/24, 127.0.0.0/8

# ¿qué se le muestra a la gente que conecte al puerto 25? Por defecto

# muestra el número de versión, lo cual yo no hago.

smtpd_banner = $myhostname ESMTP $mail_name

En términos generales, cualquier fichero que simplemente liste un elemento por línea (como /etc/postfix/mydestination o /etc/postfix/relaydomains) se suelen almacenar como simple texto llano. Los ficheros que contienen mapeados (p. ej. alias, donde se tienen entradas como "root: cualquierusuario") deberían transformarse en ficheros hash de base de datos por velocidad (se puede especificar el tipo de fichero como hash, dbm, etc.).

Al igual que la mayoría de productos de IBM, Postfix tiene una licencia bastante curiosa, pero parece que la mayoría es código abierto y libre. Postfix se encuentra disponible en: http://www.postfix.org/. Se pueden conseguir los rpm's de postfix en: ftp://contrib.Redhat.com/, y aparentemente SuSE ahora viene con Postfix.

Sendmail Pro

Sendmail Pro es una versión comercial de Sendmail con soporte, y se encuentra disponible en: http://www.sendmail.com/. No me ha sido posible conseguir una demo o encontrar a alguien que lo utilice, de modo que no estoy seguro al 100% de lo cercano que se encuentra al Sendmail "original", aunque la compañía me ha dicho que utiliza el mismo código de base.

Zmailer

Zmailer es un gestor de correo GPL disponible en: http://www.zmailer.org/.
Tiene ganchos criptográficos y por lo general parece bien construido.

DMail

DMail es un servidor de correo comercial, y no es código abierto. Se puede descargar una versión de prueba de: http://netwinsite.com/dmail_first.htm

nullmailer

El nullmailer envía correo a hosts inteligentes (relays) de forma que la máquina local no tenga que ejecutar ningún software de servidor. Está en:
http://em.ca/~bruceg/nullmailer/.

MasqMail

El MasqMail manda el correo a una cola mientras está offline y después lo envía cuando conectas a tu ISP. Se puede configurar para múltiples ISP's, con dirección de respuesta, etc. Se puede descargar en:
http://merlin.uni-sw.gwdg.de/~okurth/masqmail/

Dynamic Relay Authorization Control

El Dynamic Relay Authorization Control (DRAC) se une a tu servidor POP/IMAP para garantizar temporalmente acceso de reenvío SMTP a los hosts que se han autentificado con éxito y recogen correo (asumiendo que estos hosts enviarán correo, y no van a abusar de este privilegio. Se puede conseguir en:
http://mail.cc.umanitoba.ca/drac/index.html.

POP

WU IMAPD (popd original)

POP e IMAP están relacionados pero son muy diferentes, de modo que los he separado aparte. POP significa "Protocolo de Oficina de Correos, Post Office Protocol" y simplemente te permite listar mensajes, recibirlos y borrarlos. Existen muchos servidores POP disponibles para Linux, el original que viene con la mayoría de las distribuciones suele ser adecuado para la mayoría de los
usuarios. Los problemas principales con POP son similares a los de muchos otros protocolos; los nombres de usuarios y sus contraseñas se transmiten en texto claro, haciendo de ello un buen objetivo para un sniffer de paquetes. El POP se puede "SSLificar", sin embargo no todos los clientes de correo soportan POP seguro mediante SSL. La mayoría de los servidores POP vienen configurados para utilizar TCP_WRAPPERS, que es un método excelente de restringir el acceso. Para más información, ver anteriormente la sección sobre TCP_WRAPPERS. POP se ejecuta como root (ya que tiene que acceder a buzones) y en el pasado se han detectado varios ataques de root a varios servidores POP. POP se ejecuta en el puerto 109 y 110 (aunque el 109 está obsoleto), utilizando el protocolo tcp. El servidor IMAPD de la Universidad de Washington también viene con un servidor POP y en general se trata del servidor POP standard que viene con la mayoría de distribuciones Linux. Se puede conseguir de: http://www.washington.edu/imap/.

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 110

ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 110

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 110

o

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 110

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 110

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 110

Cyrus

Cyrus en un servidor imap (también soporta pop y kpop) dirigido a entornos "cerrados". Es decir, que los usuarios no tendrán ningún acceso al servidor de correo más que mediante los protocolos imap o pop. Esto le permite a Cyrus almacenar el correo de forma más segura, y permite una gestión más sencilla en instalaciones más grandes. Cyrus no tiene licencia GNU, pero es relativamente "libre", y está disponible en: http://andrew2.andrew.cmu.edu/cyrus/imapd/.
También existe un conjunto de herramientas añadidas a Cyrus disponible en:
ftp://ftp.hr.vc-graz.ac.at/cyrus-tools/.

IDS POP

IDS (No apesta, "It Doesn't Suck") POP es un reemplazo más ligero del popd dirigido a instalaciones más pequeñas. Es GPL y se encuentra disponible en:
http://www.nodomainname.net/software/ids-pop/.

Qpopper

Qpopper es freeware, está producido por Qualcomm (los autores de Eudora). No lo recomendaría (el código fuente no está disponible). Se puede conseguir de:
http://eudora.qualcomm.com/freeware/qpop.html.

IMAPD

WU IMAPD (imapd original)

IMAP es un POP con esteroides. Permite mantener con facilidad múltiples cuentas, permitir a múltiples personas acceso a una cuenta, dejar correo en el servidor, simplemente descargar los encabezados, o los cuerpos sin attachments, etc. IMAP es ideal para cualquiera o con serias necesidades de correo. Los servidores POP e IMAP que traen la mayoría de las distribuciones (empaquetados en un único paquete llamado imapd, por extraño que parezca) cubren la mayoría
de las necesidades.

IMAP también se ejecuta como root, aunque imapd suele tener el privilegio del usuario que está accediendo, y no se puede configurar con facilidad para que se ejecute como usuario no-root, puesto que tienen buzones abiertos (y en el caso de IMAP, crea carpetas, ficheros, etc. en el directorio personal del usuario), de modo que no se pueden quitar los privilegios tan pronto como alguien quisiera. Ni se puede hacer chroot con facilidad (IMAP necesita tener acceso a
/var/spool/mail, e IMAP necesita acceder al directorio personal del usuario).

La mejor política es tener el software actualizado. Y si es posible, filtrar pop e imapd con el cortafuegos, lo cual funciona bien no hay nadie de gira que necesite recoger su correo vía Internet. El IMAP de la Universidad de Washington (WU) se encuentra disponible en: http://www.washington.edu/imap/.

IMAP se ejecuta en el puerto 143 y la mayoría de los servidores IMAPD soportan
TCP_WRAPPERS, lo cual le hace relativamente sencillo de bloquear.

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 143

ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 143

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 143

o

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 143

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 143

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 143


Si te ha gustado el artículo inscribete al feed clicando en la imagen más abajo para tenerte siempre actualizado sobre los nuevos contenidos del blog:

Pruebas de ejecución de Java en Windows Vista y Ubuntu han demostrado una vez más que Vista llegó tarde

Si te preguntas en que sistema operativo se ejecuta de manera más eficiente Java, entonces la respuesta tal vez te produzca un fuerte shock. Unas pruebas de ejecución de Java en Windows Vista y Ubuntu han demostrado una vez más que Vista llegó tarde…

Los tests fueron ejecutados en un Dell Inspiron 1525, con un procesador Intel Core 2 Duo T5800, con 3 GB de DDR2, un HDD Hitachi de 250 GB, gráfica integrada de Intel 965 y una resolución de pantalla de 1280 x 800.

Los sistemas operativos enfrentados: Windows Vista Home Premium SP1 vs Ubuntu 8.10. Vista utiliza Java 1.6.0_07, mientras que Ubuntu usa Java 1.6.0_10. Ambas versiones de Java fueran las publicadas más recientemente para cada uno de los sistemas operativos en el momento de la realización de los tests.

Los tests incluyen Sunflow Rendering System, Bork File Encrypter, Java SciMark, y Java 2D Microbenchmark. Todos los tests corren el mismo Java byte-code compilado en ambos sistemas.

La primera prueba fue el Sunflow Rendering System. A pesar del gran uso de la CPU, ambos sistemas quedaron a la par.

En el test de Fast Fourier Transform (FFT) la máquina con Ubuntu 8.19 superó significativamente a la que usaba Vista, ejecutándose cerca de un 30 por ciento más rápido.

Successive Over Relaxation (SOR) con Java SciMark también corrió más rápido en Ubuntu, igual que la prueba anterior, llegando al 33 por ciento más que bajo Windows Vista.

El SciMark composite performance test mostró una vez más la clara ventaja de Java en Ubuntu, alcanzando cifras un 50 por ciento superiores en comparación con Windows Vista.

Estas pruebas no cubren todos los aspectos de Java, pero dejan bastante claro que, al menos Ubuntu 8.10 ejecuta Java con más eficacia que Windows Vista en la misma máquina.

Si te ha gustado el artículo inscribete al feed clicando en la imagen más abajo para tenerte siempre actualizado sobre los nuevos contenidos del blog:

El SNMP se diseñó para permitir que sistemas heterogéneos y equivalentes hablasen entre sí

El SNMP (Protocolo Simple de Gestión de Red, Simple Network Management Protocol) se diseñó para permitir que sistemas heterogéneos y equivalentes hablasen entre sí, generasen informes y permitiesen modificaciones de sus configuraciones sobre una red TCP-IP.

Por ejemplo, un dispositivo SNMP (como un router Cisco) se puede monitorizar/configurar desde un cliente SNMP, y se pueden escribir con sencillez scripts, para, digamos, alertarte si los paquetes denegados/segundo suben por encima de 20.

Por desgracia, SNMP no trae seguridad incluida. El SNMPv1 se propuso originalmente en el RFC 1157 (Mayo de 1990) y la sección 8 (Consideraciones de Seguridad) dice: "En esta memoria no se discuten asuntos de seguridad". Creo que eso lo resume todo. En 1992/1993, salió el SNMPv2, y contenía consideraciones de seguridad, sin embargo éstas se eliminaron más tarde cuando demostraron ser totalmente rompibles. De modo que hoy hemos acabado con un SNMPv2 sin seguridad.
Actualmente, la única forma de proteger los dispositivos SNMP consiste en configurar el nombre de la comunidad por algo difícil de adivinar (pero es muy fácil hacer un sniffing del cable y encontrar el nombre), y filtrar con el cortafuegos el SNMP de modo que sólo los hosts que necesiten hablar entre sí puedan hacerlo (lo cual te deja abierto al spoofing). Los ataques al nombre de la comunidad mediante fuerza bruta son fáciles de llevar a cabo, y suelen ser efectivos, y existen varios métodos para monitorizar específicamente las transmisiones SNMP y reventar por completo una comunidad SNMP, es un mundo peligroso el que existe por ahí fuera.

Estos riesgos se pueden mitigar ligeramente dada la utilidad que tiene el SNMP, puesto que si está soportado e implementado de forma correcta, puede hacer significativamente más sencilla la administración de la red. Casi en cada
implementación de SNMP, el nombre por defecto de la comunidad es "public" (en cuanto a Linux, NT, etc), hay que cambiarlo, por algo más oscuro (el nombre de la empresa es una mala idea). Una vez que alguien ha conseguido el nombre de la comunidad, puede llevar a cabo un "snmpwalk" y entrar en la red. El SNMP se ejecuta sobre UDP en los puertos 161 y 162; hay que bloquear esto en todas las entradas a la red (la backbone, el pool de acceso telefónico, etc.). Si un
segmento de la red no tiene habilitados dispositivos SNMP o una consola SNMP, habría que bloquear el SNMP hacia y desde esa red. Esta es la única línea de defensa en cuanto a SNMP.

Por añadidura, el uso de IPSec (u otro software VPN) puede reducir considerablemente el riesgo de sniffing. Los RFC's del SNMPv3 se centran con intensidad en la seguridad (específicamente el RFC 2274, Ene 1998) de modo que queda algo de esperanza en el futuro. Si se están comprando productos SNMP, asegúrate de que soportan SNMPv3, pues sólo así tendrás oportunidades reales de seguridad.

Con el cu-snmpd no existen problemas específicos per-se, aparte de los problemas generales del SNMP anteriormente cubiertos. Las herramientas y utilidades cu-snmp sólo soportan SNMPv1 y SNMPv2, de modo que recuerda tener
cuidado al utilizarlas sobre redes no fiables, puesto que la principal línea de seguridad (el nombre de la comunidad) quedará expuesta a que lo vea cualquiera.

ipfwadm –I –a accept –P udp –S 10.0.0.0/8 –D 0.0.0.0/0 161:162

ipfwadm –I –a accept –P udp –S un.host.fiable –D 0.0.0.0/0 161:162

ipfwadm –I –a deny –P udp –S 0.0.0.0/0 –D 0.0.0.0/0 161:162

ipchains –A input –p udp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 161:162

ipchains –A input –p udp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 161:162

ipchains –A input –p udp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 161:162

Finger

El Finger es una de esas cosas que la mayoría de los administradores deshabilitan e ignoran. Es una herramienta útil según la ocasión, pero si se quiere permitir que otros administradores se hagan una idea de cuál de tus usuarios está intentando reventar el sistema, utiliza identd. El Finger revela demasiada información, y es la herramienta favorita para pruebas niciales, y recopilación de datos sobre los objetivos. Existen otro tipo de ataques DOS, la mayoría consistentes en el envío de cientos de peticiones de finger y en ciertas configuraciones simplemente en observar el murmullo del servidor. Por
favor, no ejecutes el finger. Muchas distribuciones vienen con él habilitado, pero citando el inetd.conf de Red Hat:

# Finger, systat y netstat proporcionan información que puede ser

# valiosa para potenciales "revienta sistemas". Muchos sitios eligen

# deshabilitar alguno de estos servicios para mejorar la seguridad.

Si todavía se tiene la sensación de que es absolutamente imprescindible utilizarlo, ejecútalo con –u para denegar las peticiones de tipo finger @host que sólo se utilizan para reunir información para futuros ataques. Deshabilita finger, de veras. Recientemente Fingerd también ha sido la causa de unos pocos ataques severos de denegación de servicio, especialmente si se ejecuta el NIS con grandes mapas, NO, repito NO ejecutes fingerd. El finger se ejecuta en el
puerto 79, y el cfinger se ejecuta en el puerto 2003, ambos utilizan tcp.

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 79

ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 79

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 79

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 79

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 79

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 79

Cfingerd

Cfingerd (fingerd configurable) es un buen reemplazo del fingerd original, se construyó teniendo en cuenta la seguridad, normalmente se ejecuta como usuario no-root, y los usuarios lo pueden configurar con facilidad de modo que no se
les pueda hacer un finger. Cfingerd se encuentra disponible en:

http://ftp.bitgate.com/cfingerd/

PFinger

El PFinger es parecido al Cfingerd en la forma en que supone un reemplazo seguro del fingerd original. Se puede conseguir en:
http://www.xelia.ch/unix/pfinger/

Identd

El servicio identd se utiliza para mapear usuarios/procesos a puertos en uso.
Por ejemplo, la mayoría de los servidores irc intentan averiguar quién se está conectando a ellos haciendo una petición identd, lo cual consiste básicamente en preguntarle al servidor identd desde el ordenador cliente qué información

tiene sobre un número de puerto, y la respuesta puede varias desde ninguna (si nadie está utilizando ese puerto en particular) a un nombre de usuario, un nombre de grupo, un id de proceso y otra información interesante. La configuración por defecto de la mayoría de las distribuciones es que el identd está activado (es elegante ejecutarlo, los servidores de irc y las versiones más recientes de sendmail comprueban las respuestas de identd), y sólo distribuirán el nombre de usuario. El uso principal del identd es permitir a los sistemas remotos algún tipo de forma de seguir la pista de los usuarios que se están conectando a sus servidores, irc, telnet, correo, u otros, por propósitos de autentificación (no es una buena idea, ya que es muy fácil de falsear). La universidad local de Edmonton requiere que se ejecute el identd si se quiere hacer un telnet a cualquiera de los servidores de shell, principalmente de forma que puedan seguir con rapidez la pista de las cuentas comprometidas.

Ejecutar el identd en tu máquina ayudará a otros administradores a la hora de hacer el seguimiento de problemas, puesto que no sólo consiguen la dirección IP y la hora del problema, sino que utilizando identd pueden averiguar el nombre del usuario. Esta forma es una espada de doble filo, mientras que proporciona información útil para seguir a usuarios maliciosos (definitivamente la gente a la que se quiere mantener alejada de los servidores) también se puede utilizar para conseguir información de los usuarios del sistema, lo cual dé como resultado que sus cuentas sean comprometidas. Ejecutar identd en los servidores sólo tiene sentido si están albergando cuentas de shell.

Identd soporta bastantes características, y se puede configurar con sencillez para que se ejecute como usuario no-root. Dependiendo de las políticas de seguridad, se puede querer o no dar mucha información, o se puede querer informar lo máximo posible. Simplemente activa la opción en inetd.conf, después en in.identd (las configuraciones por defecto son –l –e –o).

-p port

-a address

Se puede utilizar para especificar a qué puerto y en qué dirección se enlaza (en el caso de una máquina con IP's en forma de alias, o a múltiples interfaces), generalmente sólo es útil si se quiere que conecten máquinas internas, puesto que a las máquinas externas probablemente no les sea posible imaginarse a qué puerto se cambió.

-u uid

-g gid

Se utilizan para configurar el usuario y el grupo bajo el que el identd tendrá privilegios después de conectar al puerto, lo cual da como resultado el ser menos susceptible de comprometer la seguridad del sistema. En cuanto al manejo de la cantidad de información que proporciona:

-o

Especifica que identd no devuelva el tipo de sistema operativo, decir Copyright © 1999, Kurt Seifried, José Antonio Revilla

simplemente "UNKNOWN" es una muy buena opción.

-n

Hará que identd devuelva números de usuarios (p.ej. su UID) y no el nombre de usuario, lo cual todavía les proporciona suficiente información para ti y para seguir la pista del usuario con facilidad, sin proporcionar valiosas pistas a posibles atacantes.

-N

Permite a los usuarios hacer crear un fichero ~/.noident , lo cual forzará que el identd devuelva "HIDDEN-USER" en lugar de información. Esto les permite a los usuarios la opción de tener un cierto grado de privacidad, pero un usuario malicioso lo utilizará para evadir la identificación.

-F format

Te permite especificar mucha más información que la standard, cualquier cosa desde el nombre y número del usuario hasta el PID real, nombre de comando, ¡y los argumentos dados! Esto sólo lo recomendaría para uso interno, puesto que es
mucha información que los atacantes encontrarían útil.

En general, recomendaría utilizar el identd en servidores con cuentas de usuario shell, o si no deshabilitarlo, principalmente debido al número de ataques de denegación de servicio a los que es susceptible. Ejecutar identd le hará la vida mucho más fácil a otros usuarios a la hora de seguir pistas provenientes de tu sitio, algunas con mejoras de seguridad (no lo aseguro todavía pues aún no he podido comprobarlo):

http://insecurity.net/ - El identd seguro de Paul, escrito en Perl

http://www.ojnk.un/~odin/ - ojnk identd

http://www.tildeslash.org/nullidentd.html - null identd

http://www.ajk.tele.fi/~too/sw/ - identd falso

http://p8ur.op.het.net/midentd/ - midentd

http://www.nyct.net/~defile/programs/ident2/ - ident2

Identd se ejecuta en el puerto 113 utilizando tcp, y por lo general sólo se necesitará si que quiere hacer IRC (muchas redes irc requieren una respuesta identd), o ser amable con los sistemas ejecutando demonios (tales como tcp_wrapped telnet, o sendmail) que hagan revisiones identd en las conexiones.

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 113

ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 113

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 113

o

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 113

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 113

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 113

NTPD

El NTP (Protocolo de Red de Tiempo, Network Time Protocol) es bastante simple en cuanto a su misión, mantiene sincronizados los relojes de los ordenadores. ¿Y qué? Intenta comparar ficheros de log desde 3 servidores separados si sus
relojes están fuera de sincronismo por unos cuantos minutos. El NTP funciona simplemente mediante un cliente que se conecta a un servidor de tiempo, averiguando el retraso entre ellos (en una red de área local podría ser de sólo
1-2ms, a través de internet puede ser de varios cientos de ms), y después pregunta la hora y configura el reloj propio. Además, los servidores se pueden colocar en "cluster" para mantenerse sincronizados entre ellos, las posibilidades de que 3 o más servidores pierdan la pista de la hora que es (también llamado "deriva", "drift" ) es relativamente baja.
Habitualmente, la señal de tiempo se suele generar por un reloj atómico o una señal GPS, medida por un ordenador, estos son los servidores "stratum 1", más abajo se indican servidores de tiempo "stratum 2" que se encuentran generalmente abiertos al público, una compañía podría mantener sus propios servidores de tiempo "stratum 3" si es lo suficientemente necesario, etcétera.

Los datos que intercambia el NTP por supuesto que no son sensibles, es una señal de tiempo, sin embargo, si a un atacante le fuese posible interferirla, podrían ocurrir todo tipo de cosas desagradables: los ficheros de log se podrían volver inutilizables, las cuentas podrían expirar antes de tiempo, los trabajos del cron que hacen la copia de seguridad del servidor se podrían ejecutar en hora punta causando retrasos, etc. De modo que es una buena idea ejecutar tu propio servidor de tiempo y configurar el ajuste máximo que harán a sólo unos pocos segundos (en cualquier caso, tampoco deberían derivar mucho más). Si se es realmente paranoico, o se tiene un gran número de clientes, habría que considerar comprar una unidad de tiempo GPS.

Vienen de todo tipo de formas y tamaños, desde un rack de 1Unidad que se enchufa directamente a la LAN hasta tarjetas ISA o PCI que se conectan en un servidor y tienen una antena. Es una buena idea filtrar con el cortafuegos el servidor de tiempo, puesto que podrían darse ataques de negación de servicio en detrimento de la red. Además de esto, si es posible, utilizar el cifrado disponible en ntpd, basada en DES, suele ser suficiente para desalentar a la mayoría de atacantes. El NTP se encuentra disponible en: http://www.eecis.udel.edu/~ntp/. Generalmente, ntpd o xntpd no suelen traer páginas de manual (genial, eh?) pero se puede encontrar documentación en /usr/doc/ntp-xxx/, o en:

http://www.eecis.udel.edu/~ntp/ntp_spool/html/index.htm.

NTP se ejecuta en el
puerto 123 utilizando udp y tcp, de modo que filtrarlo con el cortafuegos es relativamente sencillo:

ipfwadm –I –a accept –P udp –S 10.0.0.0/8 –D 0.0.0.0/0 123

ipfwadm –I –a accept –P udp –S un.host.fiable –D 0.0.0.0/0 123

ipfwadm –I –a deny –P udp –S 0.0.0.0/0 –D 0.0.0.0/0 123

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 123

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 123

o

ipchains –A input –p udp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 123

ipchains –A input –p udp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 123

ipchains –A input –p udp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 123

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 123

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 123

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/123

CVS
CVS permite trabajar juntos a múltiples desarrolladores en proyectos con enorme cantidad de código fuente, y mantiene una gran base de código en alguna parte de forma limpia. Los mecanismos internos de seguridad del CVS son bastante
simples por sí mismos; de hecho, si alguien dijera que son débiles, le tendría que dar la razón. La autentificación del CVS se suele conseguir a través de la red, utilizando pserver, los nombres de usuario se envían en texto claro, y las contraseñas tienen un hash trivial (en realidad no existe seguridad).

Para evitar esto, se cuenta con varias opciones buenas. En un entorno Unix, probablemente el método más simple sea utilizar SSH para pasar las conexiones por un túnel entre las máquinas clientes y el servidor. "Tim el PierdeTiempo" (Tim Hemel) ha escrito una excelente página ocupándose de esto, disponible en:

http://cuba.xs4all.nl/~tim/scvs/. Una aproximación algo más complicada (pero a la larga mejor en cuanto a grandes instalaciones) es "kerberizar" el servidor CVS y los clientes.

Las redes grandes (especialmente en entornos universitarios) ya han establecido una infraestructura con Kerberos. Detalles en la "kerberización" del CVS disponibles en: http://www.cyclic.com/cyclic-pages/security.html. Aparte de que
recomendaría encarecidamente filtrar con el cortafuegos el CVS, a menos que se esté utilizando para cualquier tipo de propósito público (como un proyecto de código abierto a través de Internet).

Otra herramienta que acaba de aparecer para asegurar CVS es "cvsd", un wrapper para pserver que hace chroot y/o suid el pserver al de un usuario no dañino.
cvsd se encuentra disponible en: http://cblack.mokey.com/cvsd/ en formato rpm y en tarball fuente.

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 2401

ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 2401

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 2401

o

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 2401

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 2401

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 2401


rsync

El rsync es un método extremadamente eficiente para hacer mirroring de ficheros, ya sea de ficheros de código desde un árbol CVS, un sitio web, o incluso este documento. rsync mantiene los permisos de ficheros, enlaces, hora de los ficheros y más. Además de esto, soporta modo anónimo (lo cual por cierto, utilizo para hacer el mirroring de este documento) lo cual hace la vida muy sencilla en lo concerniente.

El programa rsync puede actuar por sí mismo como cliente (se ejecuta desde una línea de comandos o un script) y como servidor (generalmente se ejecuta desde inetd.conf). El programa en sí es bastante seguro: no requiere privilegios de root para ejecutarse como cliente ni como servidor (aunque se puede hacer si se quiere) y se puede hacer chroot a sí mismo en el directorio raíz o cualquiera que esté siendo hecho mirror (sin embargo esto requiere privilegios de root y puede ser más peligroso de lo que merezca la pena).
También se puede mapear el id del usuario y el id del grupo con acceso al sistema (por defecto, es nobody para la mayoría de los paquetes de rsync precompilados y probablemente sea la mejor elección). En modo no-anónimo, rsync soporta nombres de usuarios y contraseñas que se cifran fuertemente utilizando MD4 de 128 bit. La página del manual "man rsyncd.conf" cubre claramente la configuración de un servidor rsync y lo hace relativamente seguro. El fichero de configuración por defecto es /etc/rsyncd.conf. Tiene una sección global y sección modular (básicamente cada directorio compartido es un módulo):

ejemplo de rsyncd.conf

motd file = /etc/rsync.motd # Especifica fichero a mostrar

etcmax connections = 5 # número máximo de conexiones, para evitar saturación

[pub-ftp]

comment = public ftp area # comentario simple

path = /home/ftp/pub # path al directorio exportado

read only = yes # hacerlo de sólo lectura, para directorios exportados

chroot = yes # chroot a /home/ftp/pub

uid = nobody # configurar explícitamente el UID

gid = nobody # configurar explícitamente el GID

[asuntos-secretos]

comment = mis asuntos secretos

path = /home/user/secretos # path a mis secretos

list = no # ocultar este módulo cuando pidan una lista

secrets file = /etc/rsync.users # fichero de contraseñas

auth users = me, bob, santa # lista de usuarios a los que se permite ver mis
secretos

hosts allow = 1.1.1.1, 2.2.2.2 # lista de hosts permitidos

Como se puede ver, el rsync es bastante configurable, y generalmente es
bastante seguro, excepción hecha de que las transiciones de ficheros no van
cifradas de ninguna forma. Si se necesita seguridad, sugeriría utilizar el SSH
para abrir una conexión mediante un túnel, o alguna solución VPN como
FreeS/WAN. Igualmente asegúrate de estar ejecutando rsync 2.3.x o una versión
más alta, ya que se encontró un compromiso de root en la 2.2.x. Rsync se
encuentra disponible en: http://rsync.samba.org/. Rsync se ejecuta en el puerto
873, tcp.

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 873

ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 873

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 873

o

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 873

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 873

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 873