Agcapa

programador web

Categoría: Linux (página 2 de 5)

Copiar archivos y carpetas en Linux

En Linux (Ubuntu) tenemos un administrador de archivos llamado “Nautilus” en donde podemos copiar, pegar y mover nuestros archivos y carpetas en nuestras carpetas de usuario. Lo que no puedes hacer es copiar en una carpeta del sistema, pero se puede copiar, pegar y mover si ejecutamos “Nautilus” como super usuario.

En modo gráfico

Para ejecutar “Nautilus” como super usuario en modo gráfico, solo abre una terminal y escribe lo siguiente:

sudo nautilus

En modo consola

Sintaxis: cp [carpeta|archivo origen a copiar] [carpeta destino a copiar]

Para copiar “UN SOLO ARCHIVO” a la memoria USB

sudo cp /home/ivan/Documentos/midocumento.doc /media/MEMORIA-USB

Copiar “UNA CARPETA” a una memoria USB

sudo cp -r /home/ivan/Documentos /media/MEMORIA-USB

Copiar “Archivos, carpetas y subcarpetas” sin crear la carpeta principal

sudo cp -r /home/ivan/Documentos/* /media/MEMORIA-USB

Nota que en este comando se ha colocado un asterisco (*) en la parte de origen a copiar.

Copiar “Archivos, carpetas y subcarpetas” sobrescribiendo archivos

sudo cp -rf /home/ivan/Documentos/* /media/MEMORIA-USB

Copiar “Archivos, carpetas y subcarpetas” preguntando si desea sobrescribir

sudo cp -ri /home/ivan/Documentos/* /media/MEMORIA-USB

How to install HTTP Request Module in CentOS 5.2

Hello everybody,

I have e-fax integration to be integrated in my application(a website which is build in PHP) where I need to install HTTP Request Module first , then should make a change in my php.ini file.

For that to happen I need to execute four steps. They are :

sudo yum install php-xml
sudo yum install php-devel
sudo pecl install pecl_http
sudo yum install php-pear-HTTP-Request

I am facing a problem in executing the 3rd step. The error what I am getting is
building in /var/tmp/pear-build-root/pecl_http-1.6.2
running: /temp/pecl_http/configure –with-http-curl-requests –with-http-zlib-compression=all –with-http-magic-mime=all –with-http-shared-deps
checking for egrep… grep -E
checking for a sed that does not truncate output… //bin/sed
checking for gcc… gcc
checking for C compiler default output file name… configure: error: C compiler cannot create executables
See `config.log’ for more details.
ERROR: `/temp/pecl_http/configure –with-http-curl-requests –with-http-zlib-compression=all –with-http-magic-mime=all –with-http-shared-deps’ failed

Cómo tener dos servidores web en maquinas diferentes, con una única IP

Hay veces que nos es necesario tener dos maquinas diferentes, que lleven instalado un servidor web cada una, bajo una única IP publica.
Pues bien, este truco explica como configurar un Apache, para que cuando reciba peticiones sobre el dominio que sirve otra maquina de nuestra misma red local, le redirija dichas peticiones.
Pagina1/1
Ya se sabe que esto no debería ser ningún problema con los Virtual Host de Apache, pues nuestro amigable servidor web, puede servir infinidad de dominios, sin necesidad de gastarnos el dinero en una segunda maquina.
Pero en ocasiones, no es necesario realizar este tipo de configuraciones en nuestra LAN, ya sea porque el jefe nos lo “aconseja”, porque hay desarrolladores que necesitan acceso desde fuera, a ese servidor web que están machacando o porque hay cierto producto propietario que necesita ir en un servidor Web determinado (por buscarle alguna explicación).
Esto mismo debieron de pensar los desarrolladores de Apache, pues utilizando algunas directivas que veremos enseguida, nos dan la posibilidad de utilizar otra maquina con un servidor web instalado, por detrás.
Pero empecemos de una vez el trabajo:

Indicaciones Previas:
Imaginemos para nuestro ejemplo que tenemos un servidor web Apache, directamente conectado a nuestro Router, modem, firewall, etc.. cuya ip de la LAN es 192.168.1.1 y cuya ip publica es 1.1.1.1. Esta maquina sirve el dominio www.dominio1.com. Imaginemos ahora que detrás de este Apache, en otra maquina diferente hay otro servidor web instalado (ya sea otro Apache, IIS, etc, etc…). Dicha maquina tiene una ip privada 192.168.1.2 y sirve el dominio www.dominio2.com

Paso 1: Configurar nuestro /etc/hosts
En el fichero /etc/hosts del primer servidor (el que tendrá instalado el Apache), tendremos que indicarle quien es en realidad ese dominio, de esta manera:

192.168.1.2	www.dominio2.com

Paso 2: Configuramos el Apache
Editamos el fichero httpd.conf (que en debian está en /etc/apache/httpd.conf y en redhat en /etc/httpd/conf/httpd.conf) y primero comprobamos que existe una linea similar a esta:

LoadModule proxy_module /usr/lib/apache/1.3/libproxy.so

Si esta comentada, descoméntala, si no esta siquiera, añadela a mano, pues este modulo suele venir incluido en el Apache que nos instala nuestra distribución preferida. Si compilas el Apache, acuerdate de incluir este modulo en la compilación.
Una vez añadimos esta linea, añadiremos un VirtualHost que haga referencia a www.dominio2.com:

# Si ponemos "*", nos evitamos el problema de tener ip dinámica
# que haga referencia a todas las ips de la maquina
NameVirtualHost *

<VirtualHost *>
ServerName www.dominio2.com
ProxyPass / http://www.dominio2.com/
ProxyPassReverse / http://www.dominio2.com/
</VirtualHost>

Y asunto terminado, ya podemos conectarnos desde fuera a nuestro segundo servidor web y visitar el dominio www.dominio2.com

Fail2ban el mejor baneador para SSH

Configuración

Una vez tenemos instalados todos los paquetes, procedemos a descargarnos la versión de fail2ban que queramos, tenemos disponibles, tanto los fuentes, como un paquete para distribuciones basadas en Debian (.deb) o para distribuciones basadas en Red Hat (.rpm)..

Y los instalamos..

Ya tenemos el fail2ban instalado en /usr/bin/fail2ban si todo ha ido bien, si hacemos un fail2ban -h deberíamos ver la ayuda, algo así como:

Fail2Ban v0.5.1 reads log file that contains password failure report
and bans the corresponding IP addresses using firewall rules.

-b start fail2ban in background.
-d start fail2ban in debug mode.
-c <FILE> read configuration file FILE.
-p <FILE> create PID lock in FILE.
-h display this help message.
-i <IP(s)> IP(s) to ignore.
-k kill a currently running Fail2Ban instance.
-r <VALUE> allow a max of VALUE password failure.
-t <TIME> ban IP for TIME seconds.
-v verbose. Use twice for greater effect.
-V print software version.

Todo genial, ya tenemos que localizar el fichero de configuración y adaptarlo a nuestras necesidades, con unos pequeños retoques estaremos listos..

El fichero en cuestión es el /etc/fail2ban.conf.example lo renombramos a .conf para poder trabajar sobre él..

mv /etc/fail2ban.conf.example /etc/fail2ban.conf

Ahora lo editamos con nuestro editor favorito y vamos recorriendo las lineas que tiene y cambiaremos las que más nos interesan:..

Bien, en este apartado, se nos da la posibilidad de correr fail2ban como daemon, cosa que nos interesa, por eso le decimos que “background=true”.

# Option: background.
# Notes.: start fail2ban as a daemon. Output is redirect to logfile..
# Values: [true | false] Default: false.
#.
background = true

¿Dónde van a estar los logs?.

Tenemos dos opciones, o bien decirle que use syslog, y que todo lo que haga vaya al /var/log/messages o bien que cree su propio fichero /var/log/fail2ban.log, podeis hacer lo que creais conveniente, a mi personalmente me gusta tenerlo todo bien ordenado, por eso le digo que tenga su propio fichero de logs..

# Option: logtargets.
# Notes.: log targets. Space separated list of logging targets..
# Values: STDERR SYSLOG file Default: /var/log/fail2ban.log.
#
logtargets = /var/log/fail2ban.log

¿Cuántos intentos vamos a dejar antes de banear la ip?.

Por defecto vienen 3, personalmente creo que es un buen número de intentos, ¿quién no se ha equivocado dos veces al meter el nombre de usuario o contraseña? Por tanto, lo dejamos tal cual viene..

 

# Option: maxretry.
# Notes.: number of retrys before IP gets banned..
# Values: NUM Default: 3.
#.
maxretry = 3

¿Cuánto tiempo vamos a banear a la ip que intenta atacarnos?.

Por defecto vienen 600 segundos, que son 10 minutos, a mi juicio es poco tiempo, ya que le baneamos, que sea por un tiempo razonable y se canse, así que yo he optado por poner 36000 que son 10 horas.

# Option: bantime.
# Notes.: number of seconds an IP will be banned..
# Values: NUM Default: 600.
#.
bantime = 36000

Esta opción es bastante interesante, nos permite hacer excepciones con quién baneamos..

Por ejemplo si conectamos siempre desde una ip o desde varias ips fijas y sabemos que somos nosotros y nadie más, podemos decirle que a estas ips no las ignore, pese a que tengamos un día torpón y fallemos más de 3 veces el login..

Podemos también ignorar a una red entera indicando su máscara..

Yo por mi parte le he dicho que no banee a nadie de mi red privada y a otras dos ips desde las que conecto, pero por seguridad no puedo listarlas aquí..

# Option: ignoreip.
# Notes.: space separated list of IP's to be ignored by fail2ban..
# You can use CIDR mask in order to specify a range..
# Example: ignoreip = 192.168.0.1/24 123.45.235.65.
# Values: IP Default: 192.168.0.0/24.
#.
ignoreip = 192.168.1.0/24

Con estas dos opciones podemos decirle a nuestro sistema de que nos informe cuando fail2ban es iniciado, por defecto no viene nada, yo por mi parte le he dicho que me mande un mail avisandome de que se ha puesto en funcionamiento..

# Option: cmdstart.
# Notes.: command executed once at the start of Fail2Ban.
# Values: CMD Default:.
#.
cmdstart = echo "Se ha iniciado fail2ban" | mail -s "Fail2ban" manuelATtodo-linux.com..

Con esta opción es igual,pero para que nos informe si se ha parado el servicio, he creido conveniente que me avise al correo igualmente..

# Option: cmdend.
# Notes.: command executed once at the end of Fail2Ban.
# Values: CMD Default:.
#.
cmdend =echo "Se ha detenido fail2ban" | mail -s "Fail2ban" manuelATtodo-linux.com<

Para esta opción debeis tener corriendo un servidor de correo en el mismo host que el fail2ban, en mi caso lo tengo, así que sacaré partido de él.

Quiero que me avise al correo cuando se banea alguna ip, así que activo esta opción.

[MAIL]

# Option: enabled.
# Notes.: enable mail notification when banning an IP address..
# Values: [true | false] Default: false.
#.
enabled = true

Ahora tenemos que meter los datos de nuestro servidor de correo, los que vienen por defecto están bien..

# Option: host.
# Notes.: host running the mail server..
# Values: STR Default: localhost.
#.
host = localhost

# Option: port.
# Notes.: port of the mail server..
# Values: INT Default: 25.
#.
port = 25

Ahora rellenamos dos campos muy sencillos, que serán, el remitente del correo y a quién debe enviarlo, este es mi caso:.

# Option: from.
# Notes.: e-mail address of the sender..
# Values: MAIL Default: fail2ban.
#.
from = fail2ban

# Option: to.
# Notes.: e-mail addresses of the receiver. Addresses are space.
# separated..
# Values: MAIL Default: root.
#.
to = manuelATtodo-linux.com

El asunto del correo lo definimos en:.

# Option: subject.
# Notes.: subject of the e-mail..
# Tags: <ip> IP address.
# <failures> number of failures.
# <failtime> unix timestamp of the last failure.
# Values: TEXT Default: [Fail2Ban] Banned <ip>.
#.
subject = [Fail2Ban] Se ha baneado a <ip>..

Y ahora el cuerpo del correo que nos será enviado:.

# Option: message.
# Notes.: message of the e-mail..
# Tags: <ip> IP address.
# <failures> number of failures.
# <failtime> unix timestamp of the last failure
# <br> new line.
# Values: TEXT Default: .
#.
message = La ip <ip> ha sido baneada por Fail2Ban despues de

<failures> intentos fallidos…

Ahora nos metemos ya en la configuración de los servicios por los que fail2ban velará en nuestro sistema, el primero es para todos aquellos que tengan un servidor web Apache corriendo en la máquina, como es mi caso, pues tendré que entrar a retocar algunos parámetros de este apartado…

Lo primero es indicarle que sí tiene que activarse para Apache, eso se lo decimos en aquí..

 

[Apache]

# Option: enabled.
# Notes.: enable monitoring for this section..
# Values: [true | false] Default: false.
#.
enabled = true

Ahora le decimos de dónde tiene que recoger la información, pues del access_log, se lo indicamos:.

# Option: logfile.
# Notes.: logfile to monitor..
# Values: FILE Default: /var/log/httpd/access_log.
#.
logfile = /var/log/httpd/access_log

Ahora vienen las dos opciones que comentamos antes, si queremos que al iniciar el fail2ban para Apache se nos notifique de alguna forma, como se comentó antes, no lo vamos a volver a decir…

Siguiente paso, ¿qué ha de hacer iptables para banear una ip? ¿y cuando tenga que quitarle el ban? Pues eso lo indicamos en estas dos secciones que podemos dejar por defecto..

# Option: fwban.
# Notes.: command executed when banning an IP. Take care that the
# command is executed with Fail2Ban user rights..
# Tags: <ip> IP address.
# <failures> number of failures.
# <failtime> unix timestamp of the last failure.
# <bantime> unix timestamp of the ban time.
# Values: CMD.
# Default: iptables -I INPUT 1 -i eth0 -s <ip> -j DROP.
#.
fwban = iptables -I INPUT -s <ip> -j DROP

# Option: fwunban.
# Notes.: command executed when unbanning an IP. Take care that the
# command is executed with Fail2Ban user rights..
# Tags: <ip> IP address.
# <bantime> unix timestamp of the ban time.
# <unbantime> unix timestamp of the unban time.
# Values: CMD.
# Default: iptables -D INPUT -i eth0 -s <ip> -j DROP.
#.
fwunban = iptables -D INPUT -s <ip> -j DROP

¿Cómo va a reconocer fail2ban que tiene que bannear a alguien? Pues porque encuentre las determinadas palabras en los logs, eso lo definimos en:(yo he añadido la de user notfound).

# Option: failregex.
# Notes.: regex to match the password failure messages in the logfile..
# Values: TEXT Default: authentication failure|user .* not found.
#.
failregex = authentication failure|user .* not found|*. User notfound.

Se acabó la cosa para Apache, ahora entramos en la sección de nuestro servidor Ssh.

Le decimos que queremos habilitar el fail2ban para ssh:

[SSH]

# Option: enabled
# Notes.: enable monitoring for this section.
# Values: [true | false] Default: true
#
enabled = true

Ahora debemos indicarle, al igual que hicimos con Apache, donde ha de recoger los datos en los que basarse para banear ips, en mi caso, los logs del sshd están en /var/log/secure poned vuestro PATH a los logs, ¡¡no el mio!!

# Option: logfile
# Notes.: logfile to monitor.
# Values: FILE Default: /var/log/secure
#
logfile = /var/log/secure

Ahora vienen las opciones para notificarnos (si queremos) cuando se inicialice fail2ban y cuando se acabe, no las comentamos.

Pasamos directamente a las ordenes que se le pasaran a iptables tanto para banerar como para desbanear ips, las podemos dejar por defecto.

# Option: fwbanrule
# Notes.: command executed when banning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: <ip> IP address
# <failures> number of failures
# <failtime> unix timestamp of the last failure
# <bantime> unix timestamp of the ban time
# Values: CMD
# Default: iptables -I INPUT 1 -i eth0 -s <ip> -j DROP
#
fwban = iptables -I INPUT -s <ip> -j DROP

# Option: fwunbanrule
# Notes.: command executed when unbanning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: <ip> IP address
# <bantime> unix timestamp of the ban time
# <unbantime> unix timestamp of the unban time
# Values: CMD
# Default: iptables -D INPUT -i eth0 -s <ip> -j DROP
#
fwunban = iptables -D INPUT -s <ip> -j DROP

Y ya, solo tenemos que fijarnos en las palabras clave que ha de buscar fail2ban en los logs para determinar cuando sí y cuando no se está intentando el login

# Option: failregex
# Notes.: regex to match the password failures messages in the logfile.
# Values: TEXT Default: Authentication failure|Failed password|Invalid user
#
failregex = Authentication failure|Failed password|Invalid user

Ya tenemos el fichero listo, lo guardamos y salimos.

Ahora solo debemos arracar el fail2ban como root y esperar los resultados, que no se harán esperar, vamos a hacer una prueba.

Me loggeo en una máquina cuya ip no está en la sección ignore y me pongo a fallar contra mi máquina:

(Protego las ips, por seguridad, no serán mostradas)

Vemos que el fail2ban está corriendo:

Spanish fail2ban1.jpg

Ahora desde la otra máquina intentamos conectar a nuestro pc, y fallamos tres veces la contraseña:

Spanish fail2ban2.jpg

Ahora tras esto intentamos conectar de nuevo al servidor, y ponemos las opciones -v -v -v para qué pasa en la conexión.

Y como vemos, no podemos conectar, estamos baneados:

Spanish fail2ban3.jpg

Ahora nos vamos a la máquina local, a ver qué nos dicen los logs de fail2ban

Nov 18 12:20:52 desastre python2.4: SSH: 80.59.XX.XX has 3 login failure(s). Banned.

Pues sí, hemos sido baneados.

Espero que os haya sido útil.

Arranque automático de Apache con clave privada cifrada con contraseña

Arranque automático de Apache con clave privada cifrada con contraseña

Cuando el servidor web se inicia trata de abrir la clave privada configurada. Si la llave privada está protegida con contraseña el servidor pide la contraseña por consola. Este proceso obliga a que haya una persona física arrancando el servidor e introduciendo la contraseña solicitada. Para que el servidor arranque sin solicitar la contraseña se debe configurar para que la obtenga por otros medios según se detalla a continuación:

  1. Editar el archivo de configuración de Apache (httpd.conf).
  2. Sustituir
    SSLPassPhraseDialog builtin

    por

    SSLPassPhraseDialog exec:<ServerRoot>/bin/clave.sh
  3. Crear el shell-script <ServerRoot>/bin/clave.sh que deberá contener:
    #!/bin/sh
    echo "PASSWORD"

    (Se puede generar el script en un solo comando:
    echo -e '#!/bin/sh\necho "PASSWORD"' > <ServerRoot>/bin/clave.sh)

Instalar mod_evasive en Apache para dificultar ataques DoS

Describiremos a continuación los pasos para la instalación y configuración de mod_evasive, un módulo para Apache desarrollado por Nuclear Elephant para prevenir ataques DoS. Antes que nada es preciso advertir que no se trata de una solución definitiva y que, incluso, bajo ataques importantes, no sirve de mucho. Pero es una buena forma de evitar ataques pequeños y mantener la salud de nuestro servidor.

¿Cómo funciona?

Básicamente lo que hace es mantener una tabla dinámica con las URIs accedidas por las distintas IPs de los clientes del Apache, y permite ejecutar algunas acciones cuando una misma IP solicita un mismo recurso (una misma URI o elementos de un mismo sitio) más de n veces en m segundos. La acción por default que ejecuta el mod_evasive es, una vez superado el máximo de requests por segundo permitidos, bloquear durante una cantidad de segundos al cliente (la IP) devolviendo un error 403 (Forbidden) a la petición HTTP. Pero lo interesante es que también permite ejecutar un comando de sistema al registrarse un intento de ataque, con lo cual se puede agregar una regla al iptables para bloquear la IP del cliente.

Instalación

La instalación es muy sencilla. Basta con descargar el tar, descomprimirlo, compilarlo con apxs y habilitarlo en el httpd.conf.

# cd /usr/src
# wget http://www.zdziarski.com/projects/mod_evasive/mod_evasive_1.10.1.tar.gz
# tar zxvf mod_evasive_1.10.1.tar.gz
# cd mod_evasive
# apxs -cia mod_evasive20.c # para Apache 1.3 el comando sería apxs -cia mod_evasive.c
# vi /etc/httpd/conf/httpd.conf # editamos la configuracion
# service httpd restart # reiniciamos el Apache

En el httpd.conf habría que agregar las siguientes líneas.

<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 300
</IfModule>

Opciones de configuración

A continuación transcribo la descripción de las distintas opciones de configuración tomada de esta excelente guía de Xombra Team.

  • DOSHashTableSize <valor> – Establece el número de nodos a almacenar para cada proceso de peticiones de la tabla hash (contenedor asociativo de recuperación de peticiones por medio de claves que agiliza las respuestas del servidor). Si aplicamos un número alto a este parámetro obtendremos un rendimiento mayor, ya que las iteraciones necesarias para obtener un registro de la tabla son menores. Por contra, y de forma evidente, aumenta el consumo de memoria necesario para el almacenamiento de una tabla mayor. Se hace necesario incrementar este parámetro si el servidor atiende un número abultado de peticiones, aunque puede no servir de nada si la memoria de la máquina es escasa.
  • DOSPageCount <valor> – Indica el valor del umbral para el número de peticiones de una misma página (o URI) dentro del intervalo definido en DOSPageInterval. Cuando el valor del parámetro es excedido, la IP del cliente se añade a la lista de bloqueos.
  • DOSSiteCount <valor> – Cuenta cuántas peticiones de cualquier tipo puede hacer un cliente dentro del intervalo definido en DOSSiteInterval. Si se excede dicho valor, el cliente queda añadido a la lista de bloqueos.
  • DOSPageInterval <valor> – El intervalo, en segundos, para el umbral de petición de páginas.
  • DOSSiteInterval <valor> – El intervalo, en segundos, para el umbral de petición de objetos de cualquier tipo.
  • DOSBlockingPeriod <valor> – Establece el tiempo, en segundos, que un cliente queda bloqueado una vez que ha sido añadido a la lista de bloqueos. Como ya se indicó unas líneas atrás, todo cliente bloqueado recibirá una respuesta del tipo 403 (Forbidden) a cualquier petición que realice durante este periodo.
  • DOSEmailNotify <e-mail> – Un e-mail será enviado a la dirección especificada cuando una dirección IP quede bloqueada. La configuración del proceso de envío se establece en el fichero mod_evasive.c de la forma /bin/mail -t %s, siendo %s el parámetro que queda configurado en este parámetro. Será necesario cambiar el proceso si usamos un método diferente de envío de e-mails y volver a compilar el módulo con apxs (por ejemplo, la opción t ha quedado obsoleta en las últimas versiones del comando).
  • DOSSystemCommand <comando> – El comando reflejado se ejecutará cuando una dirección IP quede bloqueada. Se hace muy útil en llamadas a herramientas de filtrado o firewalls. Usaremos %s para especificar la dirección IP implicada. Por ejemplo, podemos establecer su uso con iptables de la forma siguiente:
    DOSSystemCommand “/sbin/iptables –I INPUT –p tcp –dport 80 –s %s –j DROP”
  • DOSLogDir <ruta> – Establece una ruta para el directorio temporal. Por defecto, dicha ruta queda establecida en /tmp, lo cual puede originar algunos agujeros de seguridad si el sistema resulta violado.
  • DOSWhitelist <IP> – La dirección IP indicada como valor del parámetro no será tenida en cuenta por el módulo en ningún caso. Para cada dirección IP a excluir ha de añadirse una nueva línea con el parámetro. Por ejemplo, dejaremos fuera del chequeo del módulo a un posible bot que use los siguientes rangos de direcciones:
    DOSWhitelist 66.249.65.*
    DOSWhitelist 66.249.66.*

Probarlo

¿Y cómo sé si está funcionando? mod_evasive viene con un pequeño script en perl para probar el funcionamiento del módulo. Para eso vamos al directorio de mod_evasive y ejecutamos el script test.pl:

# cd /usr/src/mod_evasive
# perl test.pl
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden

Y si pusimos la directiva para bloquear la IP por iptables podemos verlo con:

# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP tcp --  anywhere tcp dpt:http

Como mostrar y vaciar la cola de postfix

Como mostrar y vaciar la cola de postfix

qshape deferred | head
Para ver todos loe email en cola

Tip rapidísimo de postfix.

Para mostrar que emails están en cola, osea, aun no se han enviado:

mailq

Para borrar un email de la cola:

postsuper -d queue_id

Para borrar todos esos emails de la cola:

postsuper -d ALL

Mas comandos:
 postsuper -d numero (eliminar el mensaje)
 postsuper -d ALL (eliminar todos los mensajes)
 postsuper -r Number (Encolar de nuevo el mensaje)
 postsuper -r ALL (Encolar de nuevo todos los mensajes)
 postqueue -p  (Mostrar la cola de correo por pantalla)
 postqueue -f  (Hacer un flush de la cola de correo, intentar enviar todos los correos)

Para saber cual es la cabecera de un mail:
 postcat -q Numero de la cabecera | more

suhosin download

If you are running Gentoo Linux or FreeBSD Suhosin is already within your ports system. Users of OpenSuSE Linux, Mandriva Linux or Debian Linux will find Suhosin packages in the distribution. You can install it by following the instructions in the installation manual.

If you are using suhosin to protect your PHP servers please consider donating a small amount of money to help with hosting and future development. You can donate here.

Suhosin Extension 0.9.33

suhosin development source at github
suhosin source – 0ce498a02a8281e4274ea8e390c2b487 – sig

Suhosin Patch 0.9.10

suhosin-patch-5.3.9 – c099b3d7eac95018ababd41ded7f3066 – sig
suhosin-patch-5.3.7 – 08582e502fed8221c6577042ca45ddb8 – sig
suhosin-patch-5.3.4 – 69683b97f1e8d8c7ad01eebcbb8a56fa – sig
suhosin-patch-5.3.3 – b66b27c43b1332400ef8982944c3b95b – sig

Suhosin Patch 0.9.9.1

suhosin-patch-5.3.2 – 4647b05330862d6a1fc4469245cc6ade – sig

Suhosin Patch 0.9.8

suhosin-patch-5.3.1 – bf75fe3a9bda8c7a041d86197d6da09a – sig
suhosin-patch-5.3.1 RC1 – c3ff0cb5fa728420d56f8ed139446647 – sig
suhosin-patch-5.3.0 – a23a3d54e177ac0ad30f78d928ba8177 – sig

Suhosin Patch 0.9.7

suhosin-patch-5.2.16 – d815fc99a0c25c21f5df28551fcbb001 – sig
suhosin-patch-5.2.14 – 84cf0142b8a3637b8784b5ee1e6cbc07 – sig
suhosin-patch-5.2.13 – 8188e119ce7abce98b8f004de46fbac5 – sig
suhosin-patch-5.2.12 – 40be1b05ad893a01778d7fb323dd8872 – sig
suhosin-patch-5.2.11 – 8f9de4d97fae6eba163cf3699509a260 – sig
suhosin-patch-5.2.10 – 41b475a469eef0eb0e7aa10a820f12b2 – sig
suhosin-patch-5.2.9 – f80dbcd2773a98da1dab0c73c3654895 – sig

Suhosin Patch 0.9.6

suhosin-patch-5.2.8 – d455c3dd5b652046dbac2951a58f64fa – sig
suhosin-patch-5.2.7 – d455c3dd5b652046dbac2951a58f64fa – sig
suhosin-patch-5.2.6 – f2ec986341a314c271259dbe4d940858 – sig
suhosin-patch-5.2.5 – a43f1a0ee9e7c41c4cb6890174f1f9d8 – sig
suhosin-patch-5.2.4 – 58b18d0db00bc52b004fc749190a958f – sig
suhosin-patch-5.2.3 – f217d04f9513222e48cea6588ac65b89 – sig
suhosin-patch-5.2.2 – 081fe08d584820a6ece1fe2e8629711f – sig
suhosin-patch-5.2.1 – 98cae8ee994df74e3ea1b25c955310e8 – sig
suhosin-patch-5.2.0 – 621ec57f10345cc58b29b189d89aecce – sig
suhosin-patch-5.1.6 – 40533ea76767dacbcc8e67522db8ef50 – sig
suhosin-patch-5.1.5 – c8cec5e765a0ada36c16aa7b32ea3c1e – sig
suhosin-patch-5.1.4 – c731f931faac5d5ee8a68c6172561ce0 – sig
suhosin-patch-5.0.5 – 21458573377820f081e7d050be05b1b6 – sig
suhosin-patch-4.4.9 – c4e88782b1572e0aee26e6b2124e6257 – sig
suhosin-patch-4.4.8 – 094162a3cc48bec95b29e02df4930a43 – sig
suhosin-patch-4.4.7 – 6aa5d3d240a568a21d671952e7d6be2c – sig
suhosin-patch-4.4.6 – da1c4d309b191bac78767cbf697d6c8d – sig
suhosin-patch-4.4.5 – acaa585bbc0117910e214d333ce448df – sig
suhosin-patch-4.4.4 – 26b7a0ad744e374aa43f1e0d56561ac5 – sig
suhosin-patch-4.4.3 – e9bb4be14b472fcbb14c65fdf81a3940 – sig
suhosin-patch-4.4.2 – f79cd1cf9c8f60112c45639c932496af – sig
suhosin-patch-4.3.11 – 15c103a6ec8dc8eea5cddcfd41a11cc8 – sig

Suhosin

Installation!

If you only want to install the suhosin extension you can skip directly to the Installing the Extension section. If you are unfamiliar with verifying downloaded files, we suggest that you also read the first 2 steps of the Preparation Phase.

In case you want to install Suhosin on a Gentoo or FreeBSD system you can skip directly to the sections.
Preparation

When you want to install PHP with the Suhosin-Patch you have to first perform some preparation steps.
Step 1: Installing the Hardened-PHP Project Signaturekey

You should first grab a copy of the Hardened-PHP Project’s Release Signaturekey and import it into your GNU Privacy Guard keychain. (For further information on the usage of gnupg please consult it’s manpage)

#> gpg –import < hardened-php-signature-key.asc gpg: /root/.gnupg/trustdb.gpg: trust-db erzeugt gpg: key 0A864AA1: public key "Hardened-PHP Signature Key" imported gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1 gpg: importiert: 1 Step 2: Downloading and verifying the necessary files It is now time to grab a copy of a fresh PHP tarball and the latest version of the Suhosin-Patch. Additionally you should get the digital signature (*.sig) files. You can grab all of this on our suhosin download page. As a first precaution you can check the MD5 hashs of the downloaded files against those you find on the download page. #> md5sum php-5.1.4.tar.bz2
66a806161d4a2d3b5153ebe4cd0f2e1c php-5.1.4.tar.bz2
#> md5sum suhosin-patch-5.1.4-0.9.0.patch.gz
ea9026495c4ce34a329fd0a87474f1ba suhosin-patch-5.1.4-0.9.0.patch.gz

When the MD5 hash values are valid you can check the digital signatures like this.

#> gpg php-5.1.4.tar.bz2.sig
gpg: Signature made Di 16 Mai 2006 23:39:04 CEST using DSA key ID 0A864AA1
gpg: Good signature from “Hardened-PHP Signature Key”
#> gpg suhosin-patch-5.1.4-0.9.0.patch.gz.sig
gpg: Signature made So 21 August 2006 20:02:53 CEST using DSA key ID 0A864AA1
gpg: Good signature from “Hardened-PHP Signature Key”

Step 3: Unpacking and Patching

You now have to unpack the PHP tarball, gunzip the patchfile and then apply the patch.

#> tar -xfj php-5.1.4.tar.bz2
#> gunzip suhosin-patch-5.1.4-0.9.0.patch.gz
#> cd php-5.1.4
#> patch -p 1 -i ../suhosin-patch-5.1.4-0.9.0.patch

If you prefer to have suhosin as builtin extension you can also download the suhosin extension source code and copy the src files into the ext/suhosin directory within your PHP source tree.
Installing on a Generic Linux/Unix

After having prepared the PHP source tree the next step is not much different from the usual installation of PHP. If you have copied the suhosin extension into the ext directory you also have to activate it.

#> [./buildconf – in case you want to compile suhosin statically]
#> ./configure –with-whatever-you-want [–enable-suhosin]
#> make
#> make test
#> make install

By executing make test you can verify, that PHP still works and does not break anything.

If you are upgrading from a previous installation of PHP you do not need to recompile all installed PHP modules and extensions unless you are upgrading to a PHP version that breaks binary compatibility. However recompiling the extensions after having installed PHP with the Suhosin-Patch can protect them from possible format string vulnerabilities, which was built into the header files.

After having recompiled and installed everything, have a look at the bundled php.ini files for examples how to use the new configuration directives. For a documentation of the new directives consult the Configuration section.

Binary extensions from for example Zend should continue flawlessly. If you encounter any problem contact us immediately.
Installing the Extension

Unlike the Hardening-Patch for PHP, nearly all of Suhosin´s features are within the extension. Therefore you might want to only install the extension and use a plain unpatched PHP. Depending on the system we might already offer binary packages. You can check our Suhosin Downloads page. In that case you only need to activate the extension inside your php.ini and maybe add Configuration directives if you are not satisfied by the default values.

Before you continue compiling the Suhosin-Extension you should verify the file integrity. Please check the preparation section of this guide. The next step is unpacking the extension tarball and performing the usual compilation steps for PHP extensions.

#> cd suhosin
#> phpize
#> ./configure
#> make
#> make install

This should install suhosin in the correct extension directory. The final step is adding a load directive to php.ini

extension=suhosin.so

and optionally add some Configuration directives in case you do not like the default values.
Special Instructions

Some distributions already come with Suhosin source or binary packages. Here is a small overview how to install Suhosin on this distributions.
Installing on Gentoo

Installing and using Suhosin on Gentoo is very easy. At the moment the Suhosin patches and extensions are only available in the external PHP Overlay, and not yet in the Portage tree, you can expect them to also be available in the main Portage tree during October 2006. Let’s install the PHP Overlay then:

#> emerge layman
#> layman -f
#> layman -a php-testing

Now let’s install PHP with the Suhosin patch and extension:

#> echo “dev-lang/php” >> /etc/portage/package.keywords
(unstable version needed)
#> USE=”suhosin” emerge =php-4* for PHP4, or =php-5* for PHP5
(NOTE: you cannot also have the “hardenedphp” USE flag enabled at the same time!)

That’s it, your PHP on Gentoo is now running with the Suhosin patch enabled, and the Suhosin extension was automatically installed (from the dev-php{4,5}/suhosin package).
Installing on FreeBSD

The Suhosin-Patch and the Suhosin extension are both within the FreeBSD ports. Therefore installing it on FreeBSD is very simple. The Suhosin-Patch is an option which you can choose when you install the lang/php4 or lang/php5 port. To install the patch just do

#> cd /usr/ports/lang/php5
#> make
… now select the menu item that says: Enable Suhosin Protection
#> make install

To install the extension just do

#> cd /usr/ports/security/php-suhosin
#> make
#> make install

After these simple steps Suhosin-Patch is successfully installed on your system.
Upgrading

Upgrading to a new PHP or new Suhosin-Patch version is quite identical to the normal installation process. This is like upgrading a normal PHP. That means, if the binary compatibility was broken between PHP versions you have to recompile all installed PHP modules/extension. Upgrading the Suhosin-Extension on the other hand is as simple as recompiling it (or using a binary), replacing the file and restarting your webserver.

Apache Tips: Disable the HTTP TRACE Method

Applies: apache 1.3.x / apache 2.0.x Required apache module: – Scope: global server configuration Type: security

Description: How to disable the HTTP TRACE method on recent apache versions.

Most vulnerability scanners (like the popular nessus, but commercial ones also) will complain (normally as a low thread or warning level) about TRACE method being enabled on the web server tested.

Normally you will have this enabled by default, but if you want to test if it is really enabled on your server you just have to telnet on the port your web server is running and request for ”TRACE / HTTP/1.0” if you get a positive reply it means TRACE is enabled on your system. The output of a server with TRACE enabled will look like:

telnet 127.0.0.1 80
Trying 127.0.0.1…
Connected to 127.0.0.1.
Escape character is ‘^]’.
TRACE / HTTP/1.0
Host: foo
Any text entered here will be echoed back in the response <- ENTER twice to finish HTTP/1.1 200 OK Date: Sat, 20 Oct 2007 20:39:36 GMT Server: Apache/2.2.6 (Debian) PHP/4.4.4-9 mod_ruby/1.2.6 Ruby/1.8.6(2007-06-07) Connection: close Content-Type: message/http TRACE / HTTP/1.0 Host: foo Any text entered here will be echoed back in the response Connection closed by foreign host. Traditionally experts will suggest to disable this using some rewrite rules like: RewriteEngine On RewriteCond %{REQUEST_METHOD} ^TRACE RewriteRule .* - [F] (this needs to be added somewhere in your main apache config file outside of any vhost or directory config). Still this has the disadvantage that you need to have mod_rewrite enabled on the server just to mention one. But for apache versions newer than 1.3.34 for the legacy branch, and 2.0.55 (or newer) for apache2 this can be done very easily because there is a new apache variable that controls if TRACE method is enabled or not: TraceEnable off

This needs to be added in the main server config and the default is enabled (on). TraceEnable off causes apache to return a 403 FORBIDDEN error to the client.

After setting this and reloading the apache config the same server as above shows:

telnet 127.0.0.1 80
Trying 127.0.0.1…
Connected to 127.0.0.1.
Escape character is ‘^]’.
TRACE / HTTP/1.0
Host: foo
testing… <- ENTER twice HTTP/1.1 403 Forbidden Date: Sat, 20 Oct 2007 20:38:31 GMT Server: Apache/2.2.6 (Debian) PHP/4.4.4-9 mod_ruby/1.2.6 Ruby/1.8.6(2007-06-07) Content-Length: 320 Connection: close Content-Type: text/html; charset=iso-8859-1

403 Forbidden

Forbidden

You don’t have permission to access /
on this server.


Apache/2.2.6 (Debian) PHP/4.4.4-9 mod_ruby/1.2.6 Ruby/1.8.6(2007-06-07) Server at foo Port 80


Connection closed by foreign host.

Antiguas entradas Recientes entradas

© 2019 Agcapa

Tema por Anders NorenArriba ↑

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR
Aviso de cookies