domingo, 29 de mayo de 2005

Configuracion Linux Dell D600

lspci:

0000:00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 03)
0000:00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 03)
0000:00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
0000:00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01)
0000:00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01)
0000:00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI Controller (rev 01)
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81)
0000:00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01)
0000:00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 01)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
0000:00:1f.6 Modem: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000 M9] (rev 02)
0000:02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705M Gigabit Ethernet (rev 01)
0000:02:01.0 CardBus bridge: O2 Micro, Inc. OZ711EC1 SmartCardBus Controller (rev 20)
0000:02:01.1 CardBus bridge: O2 Micro, Inc. OZ711EC1 SmartCardBus Controller (rev 20)


Archivo de configuracion:
/usr/src/linux/.config
/etc/modules/
XF86Config-4.fglrx.conf (/etc/X11/XF86Config)
XF86Config-4.drm.agpgart.conf (/etc/X11/XF86Config)
/etc/lilo.conf

Notas:
* Framebuffer y aceleracion con fglrx no son compatibles (al pasar de X al
framebuffer y volver a las X se cuelgan)
* Hace falta en ambos modos agpgart y intel_agp cargados en el kernel
* El driver de fglrx se baja de la web y de ATI y hay que compilarlo
* Usar glxgears y glxinfo para comprobar la aceleracion

Cambiar el Banner del SSH en Debian

Comandos necesarios para cambiar el "banner" de ssh. Lo que se muestra cuando
alguien hace un telnet al puerto del servicio.
(No confundir con la directiva "Banner" del archivo de configuracion de sshd,
que muestra un msg de bienvenida/aviso cuando alguien conecta usando un cliente
de ssh).

mkdir /tmp/openssh; cd /tmp/openssh
apt-get source ssh
cd directorio-ssh
sed -e 's,SSH_VERSION :=.*,SSH_VERSION := OpenSSH_3,'<debian/rules>debian/rules.tmp
mv debian/rules.tmp debian/rules
chmod +x debian/rules
dpkg-buildpackage -b -us -uc
cd ..
dpkg -i ssh...deb

martes, 24 de mayo de 2005

screen dentro de screen (screen into screen)

Para poder tener un "screen" dentro de otro, y no liar
las teclas de ctrl-A-a en el cambio de ventanas, es posible
iniciar uno de los screen con una combinacion distinta:

screen -e\^Ee

De esta forma, el screen arrancado con esos parametros, usara
control-E-e en vez del control-A-a que es el definido por defecto.

viernes, 20 de mayo de 2005

SNMP Pen-test

Herramientas para auditar SNMP

ADMsnmp
onesixtyone
pysnmp
snmp-python
snmpbrute-fixedup
SNscan-Foundstone
NetScanTools Pro

De un thread de pen-test

lunes, 16 de mayo de 2005

Guia rapida de tunneling IP sobre DNS

+---------------------------------------------------------------+
| Guia rapida de tunneling IP sobre DNS Alejandro Ramos |
| 29/Mar/2005 v0.2 aramosf@unsec.net |
+---------------------------------------------------------------+


/ 1.- Introduccion /
+--------------------+

El proposito de esta guia es crear un tunel IP sobre el protocolo DNS
para conseguir salir a Internet en un entorno donde al unico servicio que
podemos acceder es un DNS que nos resuelve direcciones de Internet.

Muy practico para redes wireless en las que te permiten asociarte pero solo
te dan salida una vez te has autentificado via HTTP, previo pago. Como por
ejemplo en aeropuertos y hoteles. Estos sitios suelen tener un DNS que
resuelve dominios de Internet, requisito indispensable.

El siguiente texto va a mostar un ejemplo practico de una de estas confi-
guraciones.

El funcionamiento es sencillo, se desarrolla un servidor DNS que responde
a determinadas peticiones encapsulando en Base32 (si se realizan peticiones
mediante CNAME) o en Base 64 (si son registros TXT). El cliente sera capaz de
desencapsular la codificacion de la peticion y generar el paquete correcto.


En la actualidad existen dos aplicaciones que nos permiten realizar un
tunel atraves de DNS: nstx (http://nstx.dereference.de/nstx/) y ozymandns
(http://www.doxpara.com/). Se muestra una lista comparativa:

Ventajas de ozymandns:
* Esta escrito en perl, por lo que se puede portar a cualquier sistema
que soporte este interprete.
* Es sencillo y rapido de configurar.
Inconvenientes de ozymandns:
* Solo permite realizar un SSH o hay que realizar un tunel ssh posterior.
* El software es beta e inestable.

Ventajas de nstx:
* Permite usar cualquier tipo de servicio.
* Software antiguo y mas comprobado.
* Existen paquetes para algunas distribuciones (debian sid).
Inconvenientes de nstx:
* Tanto servidor como cliente tiene que ser linux.
* Se necesita crear un tunel con tun/tap.


Ademas de estas aplicaciones existen otras que nos permiten enviar
y recibir ficheros por DNS o usarlo para encapsular VoIP.



OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO
J J
O Ambos sistemas no usan autenticacion, alguien que conozca la O
J configuracion que se ha realizado en su sistema podria usar J
O el tunel DNS. O
J J
OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO-OJO


/ 2.- Requisitos /
+------------------+

Partimos de la premisa de que tenemos un conocimiento basico de como funciona
un servidor DNS y cuales son sus tipos de registros; A, NS, TXT...

Una configuracion tipo, en la que nuestros dispositivos van marcados entre
asteriscos podria ser la siguiente:


[*PC cliente*] ~~ wireless ~~ [ AP ]
|
[ switch ]-----[ server DNS (con acceso) ]
|
[ router ]
|
/\/\/\/\/\
[*server DNS*]-------|Internet|-----[*server tunel*]
\/\/\/\/\/

Por lo que seria necesario:
- Cliente desde el que realizar el tunel.
- Servidor DNS que podamos administrar y en el que tengamos un dominio.
- Servidor tunel, donde correra la aplicacion servidor.
- Acceso como cliente a un servidor DNS


En el ejemplo que se usara a lo largo del texto se usaran los siguientes
datos:
- Server DNS (con acceso): 10.1.2.2, sera el DNS al que tengamos acceso
como cliente y que ha de ser capaz de resolver nuestro dominio.
- Server tunel: este sistema es nuestro y en el instalaremos la parte
que sirve peticiones, es necesario que un DNS pueda preguntarle y para ello
necesita el 53/udp abierto a Internet.
- Server DNS: es indistinta la IP.


/ 3.- Configuracion DNS /
+-------------------------+

Si se tiene claro el concepto de recursividad en DNS y como funciona
no tendria por que encontrar ninguna dificultad a la hora de configurar
el dominio para poder realizar el tunel.

En el ejemplo se va a utilizar el dominio 'digitalsec.net' como referencia.

Editamos el fichero de zona de digitalsec.net, en este caso (fedora core 3
con named enjaulado): /var/named/chroot/var/named/db.digitalsec.net, y se
a?aden los siguientes registros:

t.digitalsec.net. IN NS tun.digitalsec.net.
tun IN A 65.73.147.191

Con estos dos registros lo que se esta haciendo es enviar al sistema
tun.digitalsec.net (65.73.147.191) todas las peticiones que cuelgen de
t.digitalsec.net. Es decir, si alguien pregunta por 'foo.t.digitalsec.net' el
servidor DNS que esta escuchando en t.digitalsec.net (65.73.147.191) sera el
encargado de resolver esas peticiones.

En 65.73.147.191 es donde ha estar el servidor de tunel DNS.

Esta configuracion es comun para nstx y ozymandns. Las pruebas que se han
realizado han sido con bind y todo ha funcionado correctamente, por lo que he
visto en el paquete de debian, con djbdns hace falta parchear para el caso de
nstx. Asi que si no se desean complicaciones adicionales, lo mas sencillo es
usar bind.



/ 4.- Configuracion ozymandns /
+--------------------------------+

Se obtiene el software de su url oficial: http://www.doxpara.com/, en la
actualidad la ultima version es: http://www.doxpara.com/ozymandns_src_0.1.tgz.
Para que ozymandns funcione son necesarios una serie de modulos CPAN,
se puede encontrar informacion detallada de como instalarlos en la direccion:
http://www.cpan.org/modules/INSTALL.html. Muchas distribuciones tienen
algunos de estos modulos como paquetes, por lo que no seria necesario insta-
larlos manualmente y compilarlos.

Los scripts necesarios para hacer funcionar el tunel son: nomde.pl (servidor)
y droute.pl (cliente), las demas aplicaciones incluidas en el tarball son para
otros propositos.

Una vez que se haya terminado de instalar todo lo necesario al ejecutar
los scripts en perl, no ha de existir ningun problema y ha de mostrar la ayuda:

# perl nomde.pl
nomde 0.1: Experimental DNS Server
Component of: OzymanDNS Dan Kaminsky(dan@doxpara.com)
Usage: nomde -l 10.0.1.11 servername.foo.com
Options: -i [ip address]: IP address to host for all A requests
-f [filename] : Filename to host in TXT records [b64]
-p [name] : Name/IP to return for reverse lookups[ptr]
-L [name:host:port]: Forward function to address, port
(Default: sshdns:127.0.0.1:22)


Hay que tener en cuenta que esta aplicacion es una beta y tiene algunos
fallos; la ayuda no se corresponde con las opciones reales y en el caso
concreto del "nomde.pl", el parametro -L no funciona como se espera. Este punto
se vera mas adelante cuando se configure el servidor.

- PARTE SERVIDOR - :

Este es el servicio que se ejecutara en el servidor del tunel, exactamente
en la direccion tun.digitalsec.net (65.73.147.191).

El siguiente comando dejaria lista esta parte:

# ./nomde.pl -i 127.0.0.1 t.digitalsec.net
creating TCP socket...done.
creating UDP socket...done.
waiting for connections...

Esto, por defecto permite hacer un ssh a 127.0.0.1 (es decir, al servidor que
realiza el tunel o tun.digitalsec.net) al puerto 22, esto es teoricamente
modificable con la opcion "-L", pero por un bug no funciona y si se desea que
el SSH se haga contra otra IP y puerto, habra que modificarlo en el codigo
fuente:

Con cambiar la linea 32 de nomde.pl:
"Localforward"=> \$opts{forward}
por la siguiente:
"Localforward=s"=> \$opts{forward}

Tendremos solucionado el problema.

Este comando nos permitira hacer un SSH al puerto 2222 de 82.165.25.126

# ./nomde.pl -i 127.0.0.1 -L sshdns:82.165.25.126:2222 t.digitalsec.net
creating TCP socket...done.
creating UDP socket...done.
waiting for connections...

Por otro fallo el script se "cae" de vez en cuando, para que se vuelva a
ejecutar cada vez que falle, se puede utilizar alguna solucion temporal como
la siguiente:

# while true; do ./nomde.pl -i 127.0.0.1 t.digitalsec.net; done


- PARTE CLIENTE - :

Seguiremos los mismos pasos que en el servidor para instalar los modulos
CPAN necesarios para que la ejecucion del script "droute.pl" no de ningun
problema.

# ssh -p2222 -o ProxyCommand="droute.pl sshdns.t.digitalsec.net" \
aramosf@82.165.25.126

Con esto se realizara un SSH al sistema que se le especifico anteriormente en
el servidor con la opcion -L. Notese que se ha a?adido "sshdns" delante de
t.digitalsec.net. Otra apreciacion es que el usuario y direccion IP solo seran
utilizados a la hora de comprobar si existe llave privada o si el sistema remoto
es un "know host". Si se desea cambiar la direccion destino del SSH ha de ser
en el servidor de tunel (nomde.pl) con la opcion -L.


El script droute.pl si se desea ejecutar en windows, se puede hacer mediante
el perl y el ssh de cygwin, usando los modulos de CPAN. Aunque es posible que
funcionei tambien bajo el perl de ActiveState y con otro cliente de SSH que
soporte la opcion una opcion como "ProxyCommand" del cliente openssh.



/ 5.- Configuracion nstx /
+--------------------------+

Para que nstx funcione es requisito tener compilado el kernel de los
sistemas linux con soporte para ethertap/tun. Tanto cliente como servidor.

Device Drivers --->
Networking support --->
Universal TUN/TAP device driver support


Hay veces que es necesario crear el dispositivo a mano:

# mkdir /dev/net
# mknod /dev/net/tun c 10 200


NOTA: La configuracion de tun0 tanto en servidor como en cliente se realiza
DESPUES de arrancar las aplicaciones.


- PARTE SERVIDOR - :

Se instalara como en el caso de ozymandns en tun.digitalsec.net
(65.73.147.191). Descargar el software desde: http://nstx.dereference.de/nstx/.
La ultima version en la actualidad es: nstx-1.1-beta6.tgz

Como ya se explico anteriormente, es posible que existe un paquete
con los binarios necesarios. En el caso de debian sid, el paquete se llama
"nstx", y con instalarlo con el comando "apt-get install nstx" seria suficiente,
solo habria que proceder a configurarlo en el fichero: /etc/default/nstx.

Una vez descomprimido y compilado:

# tar -zxvf nstx-1.1-beta6.tgz
# cd nstx-1.1-beta6
# make

Se tendran los binarios necesarios para la ejecucion en la parte del servidor,
que sera ejecutado con la opcion para que cambie el UID del usuario a nobody y
deje el servicio en background:

# ./nstxd -u nobody -D t.digitalsec.net
Opening tun/tap-device... using device tun0
Please configure this device appropriately (IP, routes, etc.)
Opening nameserver-socket... listening on 53/UDP

Cargar el modulo de TUN:

# modprobe -a tun

Por ultimo, se configura el interfaz con una IP interna (la que se desee):

# ifconfig tun0 172.26.0.2 netmask 255.255.255.0


- PARTE CLIENTE - :

Realizar el mismo proceso de descarga y compilacion del tarball nstx para
la parte del cliente.

Cargar el modulo de TUN:

# modprobe -a tun

Lanzar el cliente apuntando a t.digitalsec.net y al DNS al que tengamos
acceso como cliente en el ejemplo, 10.1.2.2:

# ./nxstcd t.digitalsec.net 10.1.2.2

Finalmente, configurar el dispositivo tun0 con un interfaz en la misma red
que el servidor:

# ifconfig tun0 172.26.0.1 netmask 255.255.255.0

Con esto ya deberia de existir conectividad con nuestro cliente y la ip del
servidor remoto: 172.26.0.2


/ 6.- Contramedidas /
+--------------------+
Una de las posibles opciones para evitar peticiones CNAME es usando iptables
en el router/firewall con una regla similar a esta:

# iptables -t filter -A INPUT -p udp --dport 53 \
-m string --string "CNAME" -j DROP

Para utilizar "string" en iptables, es necesario aplicar el corresponidente
parche de "patch-o-matic". El problema de utilizar este metodo es la bajada de
rendimientto del sistema, y el gran numero de paquetes que se descartan que son
falsos positivos, ademas, implementar el mismo filtro para TXT resultaria una red
con excesivos paquetes eliminados.

Una alternativa es utilizar un servidor de DNS que no acepte peticiones de la
clase TXT ni CNAME, o que compruebe el tamanyo de la respuestas para localizar
posibles peticiones empaquetadas.

El siguiente ejemplo muestra un script bastante simple en perl que realiza
esta funcion.

--------------------------------------------------------------------------------

#!/usr/bin/perl
# Mon May 16 00:00:44 CEST 2005
# Last version at: http://www.unsec.net
#
# proxy-dns, check lengh of respones and deny TXT records
#
# BUGS: All Net::DNS bugs -> SLOW!
#



use Net::DNS::Nameserver;
use Net::DNS::Resolver;
use Net::DNS;
use Getopt::Long;
use POSIX qw(strftime);
use strict;

my ($daemon, $log, $verbose, $ns, $help, $length);


my $length = 100;
my $log = "/dev/stdout";
GetOptions(
"daemon" => \$daemon,
"log=s" => \$log,
"ns=s" => \$ns,
"length=s" => \$length,
"verbose" => \$verbose,
"help" => \$help);


if(defined($help)) {
print STDERR <<"EOD";
Syntax: $0 [--daemon] [--log ] [--verbose] [--ns ] [--help]
Options:
--daemon : run script as daemon
--log : log all querys to (default: STDOUT)
--ns : use instead /etc/resolv.conf
--length : use of maximum length of reply (default: 100)
--verbose : verbose output
--help : this help
EOD
exit 1;
}



if (defined($daemon)) {
defined(my $pid = fork) or die "Error: $!";
exit if $pid;
}


open LOG, ">>$log";
print LOG scalar(localtime) . " [$0] Starting service\n";
sub reply_handler {
my ($qname, $qclass, $qtype, $peerhost) = @_;
my ($rcode, @ans, @auth, @add, $ret, $r1, $r2);
my $res = Net::DNS::Resolver->new;
$res->nameservers("$ns") if defined $ns;
my $query = $res->query($qname, $qtype);
if ($query) {
foreach my $rr ($query->answer) {
next unless $rr->type eq "$qtype";
$ret = $rr->address if $qtype eq "A";
$ret = $rr->ptrdname if $qtype eq "PTR";
$ret = $rr->nsdname if $qtype eq "NS";
if ($qtype eq "MX") {
$ret = $rr->preference . " " . $rr->exchange;
}

if (($qtype ne "TXT") || length($ret) gt $length) {
my ($ttl, $rdata) = (3600, "$ret");
push @ans, Net::DNS::RR->new("$qname $ttl $qclass $qtype $rdata");
print LOG scalar(localtime) . " [$0] $qname -> $qclass $qtype " .
"from: $peerhost reply: $rdata\n";
$rcode = "NOERROR";
} else {
print LOG scalar(localtime) . " [$0] $qname -> $qclass $qtype " .
"from: $peerhost reply: REFUSED(".length($ret).")\n";
$rcode = "REFUSED";
}
}
} else {
print LOG scalar(localtime) . " [$0] $qname -> $qclass $qtype " .
"from: $peerhost reply: NO ANSWER\n";
$rcode = "NOTAUTH";
}
return ($rcode, \@ans, \@auth, \@add, { aa => 1 });
}

my $ns = Net::DNS::Nameserver->new(
LocalPort => 53,
ReplyHandler => \&reply_handler,
Verbose => $verbose,
) || die "couldn't create nameserver\n";

$ns->main_loop;

close LOG;
--------------------------------------------------------------------------------


/ 7.- Referencias /
+------------------+

http://www.doxpara.com/Black_Ops_DNS_BH.ppt
http://www.aripollak.com/wiki/Main/SSHOverDNS
http://slashdot.org/articles/00/09/10/2230242.shtml



/ 8.- Control de cambios /
+-------------------------+


lun may 16 00:53:54 CEST 2005
+ Añadido punto de contramedidas.
+ Version en ingles.
+ Añadido control de cambios.

Obtener lista de usuarios de un Windows a traves de SAMBA

Se utiliza la herramienta 'rpcclient' de samba 3, es mucho mas
completa la que tiene el fork de samba samba-tng, pero por
no andar instalandola...

Una manera sencilla de hacerlo es:

---- cut here ----
for rid in `rpcclient -I -W \
-c "enumdomusers" | sed -e 's,.*\[\(.*\)\],\1,'`;
do
rpcclient -I $IP -W \
-c "queryuser $rid" | awk '/User Name/ {print $4}'
done
---- cut here ----
Nota: tener en cuenta que si no tenemos acceso al IPC$ como anonimo
tendremos que autenticarnos usando -U en el comando rpcclient

Para simular lo que hace cerberus nbtdump.exe en linux (ver usuarios sin
contraseña o con user=pass), a modo guarro, se podria usar lo siguiente:


----- cut here ----
IP=$1
USER=$2
PASS=$3

NMBLOOKUP=`nmblookup -A $IP 2>/dev/null`
if [ `echo -e "$NMBLOOKUP"|wc -l` -lt 5 ]; then
echo "Netbios not found"
exit 1
fi

SISTEMA=`echo "$NMBLOOKUP"| awk '// { print $1 }'`
WORKGROUP=`echo "$NMBLOOKUP"| awk '// { print $1 }'`

for rid in `rpcclient -I $IP -W $WORKGROUP $SISTEMA \
-U$USER%$PASS -c "enumdomusers" | \
sed -e 's,.*\[\(.*\)\],\1,'`;
do
u="$u\n"`rpcclient -I $IP -W $WORKGROUP $SISTEMA -U$USER%$PASS \
-c "queryuser $rid" | awk '/User Name/ {print $4}'`
done
if [ $(echo -e "$u" | grep -E "[:alpha:]" | wc -l) -gt 0 ]; then
echo -e "Lista de usuarios:\n------------------$u"
else
echo -e "Lista de usuarios:\n------------------\nSin acceso"
fi

for user in `echo -e "$u"`; do
n=`smbclient -L //$SISTEMA -I $IP -W $SISTEMA -U$user%$user 2>&1`
if [ `echo -e "$n"|grep -E "ACCESS_DENIED|NT_STATUS_LOGON_FAILURE" | \
wc -l` -eq 0 ]; then
r="$r\n$user/$user"
fi
n=`smbclient -L //$SISTEMA -I $IP -W $SISTEMA -N -U$user 2>&1`
if [ `echo -e "$n"|grep -E "ACCESS_DENIED|NT_STATUS_LOGON_FAILURE" | \
wc -l` -eq 0 ]; then
r="$r\n$user/$user"
fi
n=`smbclient -L //$SISTEMA -I $IP -W $SISTEMA -N -U$user 2>&1`
if [ `echo -e "$n"|grep -E "ACCESS_DENIED|NT_STATUS_LOGON_FAILURE" | \
wc -l` -eq 0 ]; then
r="$r\n$user contraseña en blanco"
fi

done

if [ $(echo -e "$r" | grep -E "[:alpha:]" | wc -l) -gt 0 ]; then
echo -e "Accesos:\n---------$r"
fi
----- cut here ----

TODO: mirar de modificar el rpcclient par hacer esto

SpammAssasin + Postfix install

Para instalar sin procmail:
The following assumes you are wanting to use SpamAssassin directly and without
the use of Amavisd.
To get Postfix piping all mail recieved into SpamAssassin for tagging and
sending on to the recipient follow these steps.


As root, create a file at /usr/bin called "postfixfilter", it should contain
the following:
#!/bin/bash
/usr/bin/spamc | /usr/sbin/sendmail -i "$@"
exit $?
Make it executable with "chmod 755 /usr/bin/postfixfilter".
Create a user called "spamfilter" with a home directory and shell.
Make spamfilter the owner of postfixfilter "chown spamfilter
/usr/bin/postfixfilter".
Edit the Services and Interfaces to non-Postfix software sections as follows:
Under the Services section locate the smtp line like this one:
smtp inet n - n - - smtpd

Directly below it CREATE this line, making sure to add the whitespace before
the -o:
-o content_filter=spamfilter:

Under the Interfaces to non-Postfix software section CREATE the following two
lines, making sure to add the whitespace before the flags:
spamfilter unix - n n - - pipe
flags=Rq user=spamfilter argv=/usr/bin/postfixfilter -f ${sender} -- ${recipient}
Use "postfix reload" to make Postfix use the changes. Send a test spam message
to yourself from an outside source and verify that its working.

miércoles, 11 de mayo de 2005

Toolbar para IE

Toolbar para Internet Explorer de microsoft.


http://www.microsoft.com/downloads/details.aspx?familyid=[...]


Esta bastante currada...

sábado, 7 de mayo de 2005

Usar el xinetd para redirigir un puerto (redirect xinetd port)

Se edita un nuevo servicio en por ejemplo el archivo: /etc/xinet.d/redirect

service [PUERTO LOCAL]
{
disable = no
bind = [NUESTRA IP LOCAL]
flags = REUSE
socket_type = stream
wait = no
user = root
redirect = [HOST REMOTO] [PORT REMOTO]
log_on_failure += USERID
}