suPHP: Solucionar 500 Internal Server Error.

Acomodando los permisos de carpetas, dueño de archivos/carpetas y permisos de achivos, solucionamos todos los problemas que pueda traer suPHP a nuestra web:

Despues de internet suPHP corré:
find /home/*/public_html -type d -exec chmod 755 {} \;
Este comando arregla todos los permisos de carpetas.

find /home/*/public_html -name '*.php' -o -name '*.php[345]' -o -name '*.phtml'| xargs chmod -v 644
Este comando arregla todos los permisos de archivos
Por ultimo, pero no menos importante:

#!/bin/bash
cd /var/cpanel/users
for user in *
do
chown -R $user.$user /home/$user/public_html/*
done

Este script arregla todos los problemas de dueño de archivos.

SSHd: Config varias

En el archivo: /etc/ssh/sshd_config
Primero: cambiamos el puerto por seguridad:

Port xxxx
Listen xxx.xxx.xxx.xxx
TCPKeepAlive yes
UseDNS no
ClientAliveInterval 30
ClientAliveCountMax 100

y en /etc/ssh/ssh_config
Añadir:
ServerAliveInterval 60

 

 

Pure-FTPd: PassivePortRang para controlar los puertos utilizados por el demonio y firewalling

Es simple: no quiero que el demonio de FTP haga random en un puerto cualquiera para las conexiones pasivas (osea, las normales de cualquier cliente ftp)

nano /etc/pure-ftpd.conf

# Port range for passive connections replies. – for firewalling.

PassivePortRange 30000 35000

Extracto de Readme de CSF (ConfigServer Security & Firewall (csf))

13. A note about FTP Connection Issues
######################################

It is important when using an SPI firewall to ensure FTP client applications
are configured to use Passive (PASV) mode connections to the server.

On servers running Monolithic kernels (e.g. VPS Virtuozzo/OpenVZ and custom
built kernels) ip_conntrack and ip_conntrack_ftp iptables kernel modules may
not be available or fully functional. If this happens, FTP passive mode (PASV)
won't work. In such circumstances you will have to open a hole in your firewall
and configure the FTP server to use that same hole.

For example, with pure-ftpd you could add the port range 30000:35000 to TCP_IN
and add the following line to /etc/pure-ftpd.conf and then restart pure-ftpd:
PassivePortRange	30000 35000

For example, with proftpd you could add the port range 30000:35000 to TCP_IN
and add the following line to /etc/proftpd.conf and then restart proftpd:
PassivePorts	30000 35000

FTP over SSL/TLS will usually fail when using an SPI firewall. This is because
of the way the FTP protocol established a connection between client and server.
iptables fails to establish a related connection when using FTP over SSL
because the FTP control connection is encrypted and so cannot track the
relationship between the connection and the allocation of an ephemeral port.

If you need to use FTP over SSL, you will have to open up a passive port block
in both csf and your FTP server configuration (see above).

Perversely, this makes your firewall less secure, while trying to make FTP
connections more secure.

Ahora, desde el CSF, habilitamos el rango de puertos:
/etc/csf/csf.conf
TCP_IN = «22,21,20,30000:35000»

Solo es necesario en el IN … porque el OUT, el servidor usa el 21 y el 20.

Joya, con esto aseguramos el FTPd.

Amaro.

Cambiar de Kernel de OVH a CentOS original…

Los tipo de OVH cuando instalas CentOS te meten un kernel de ellos…
Esto complica un poco el tema de la seguridad (No permite instalar CSF que utiliza: xt_connlimit ) en el servidor y su estabilidad: prefiero utilizar el orishinal que ya conozco su buen funcionamiento.

uname -r
3.2.13-grsec-xxxx-grs-ipv6-64

Este es el kernel de ellos.. para cambiarlo:

yum install kernel

Vamos a ver, se creo en /boot:

initramfs-2.6.32-431.20.3.el6.x86_64.img
vmlinuz-2.6.32-431.20.3.el6.x86_64

Ejecutá esto en el terminal:
cd /boot/grub
cp grub.conf grub.conf.bak | echo ‘Backup del archivo de conf hecho’

Ahora, ATENCION:

root@master [~]# cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/md2 / ext3 errors=remount-ro 0 1
/dev/md3 /home ext3 defaults 1 2
/dev/sda4 swap swap defaults 0 0
/dev/sdb4 swap swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts defaults 0 0
root@master [~]

/dev/md2 —> es nuestro punto de montaje de /
entonces, a tener en cuenta. Vamos a modificar el grub.conf ahora….

nano /boot/grub/grub.conf

Tiene que quedar así:

default=0
timeout=5
title linux centos6_64
root (hd0,0)
kernel /boot/vmlinuz-2.6.32-431.20.3.el6.x86_64 root=/dev/md2
initrd /boot/initramfs-2.6.32-431.20.3.el6.x86_64.img

Listo… dale: shutdown -r now
Cuando reinicie….

root@master [~]# uname -r
2.6.32-431.20.3.el6.x86_64
root@master [~]#

Joya, tenemos el kernel original de CentOS, ready to ride.

Best Regards… Amaro

 

 

Wowza: RTMP/RTSP Authenticate Publich USERNAME and PASSWORD config

Bueno, la idea es que para emitir Streaming ya sea de video o audio por rtmp o rtsp se deba introducir user y password: para evitar que usen el Wowza libremente cualquiera que anda probando.

Primero que nada, con el Wowza 2.3.4 obvio, instalado y corriendo
se debe instalar el plugin MediaSecurity
MediaSecurity_2.0
Extraerlo y copiar los archivos:
-rwxr-xr-x  1 root root 2.5K Feb  3 00:09 wms-plugin-security-encryption.jar
-rwxr-xr-x  1 root root  24K Feb  3 00:09 wms-plugin-security.jar
dentro de /usr/local/WowzaMediaServer/lib
y darle permisos de ejecucion, lectura y escritura para el grupo y root:
chmod 0775 wms-plugin-*

Reiniciamos el Wowza: /etc/init.d/WowzaMediaServer restart

Joya, ahora tenemos activado el plugin para seguridad, nos vamos a /usr/local/WowzaMediaServer/conf/{applicacion}
En mi caso se llama «envivo»
(/usr/local/WowzaMediaServer/conf/envivo/)

Editamos el archivo Application.xml, dentro de este directorio.
En la seccion de <Module>, añadimos como último de los Module, lo siguiente:

<Module>
<Name>ModuleRTMPAuthenticate</Name>
<Description>ModuleRTMPAuthenticate</Description>
<Class>com.wowza.wms.plugin.security.ModuleRTMPAuthenticate</Class>
</Module>

Guardamos el archivo. Listo: ahora le dijimos que esa applicacion necesita authenticar para que se pueda publicar (hacer streaming)

Ahora donde definimos el usuario y password?
Aca: /usr/local/WowzaMediaServer/conf/publish.password

[root@skate conf]# pwd
/usr/local/WowzaMediaServer/conf
[root@skate conf]# cat publish.password
# Publish password file (format [username][space][password])
#username password
[root@skate conf]#

Listorti: ahora cuando intentemos conectarnos para emitir desde el Flash Media Encoder u otro programa para emitir rtmp, pedirá el user y password.

Alta data documentada. Saludos.

Adjunto PDF de MediaSecurity, el plugin para Wowza. aca: WowzaMediaServerMediaSecurity_UsersGuide

Evitar cambios en el fichero resolv.conf

A veces el archivo resolv.conf, es modificado al momento de tomar DHCP por una interface, para evitar que pase, siempre como root:

Simple, pero efectivo:
chattr +i /etc/resolv.conf

Si posteriormente necesitamos añadir o modificar alguno de los valores, podremos desbloquearlo simplemente con :
chattr -i /etc/resolv.conf

Saludos,

AmaRo

PPTPd Mikrotik Examples – Remote Access y Site-to-Site

Application Examples

Connecting Remote Client

The following example shows how to connect a computer to a remote office network over PPTP encrypted tunnel giving that computer an IP address from the same network as the remote office has (without need of bridging over EoIP tunnels)

Consider following setup

Pptp-rem-offoce.png

Office router is connected to internet through ether1. Workstations are connected to ether2. Laptop is connected to the internet and can reach Office router’s public IP (in our example it is 192.168.80.1).
First step is to create a user

[admin@RemoteOffice] /ppp secret> add name=Laptop service=pptp password=123
local-address=10.1.101.1 remote-address=10.1.101.100
[admin@RemoteOffice] /ppp secret> print detail
Flags: X - disabled
  0   name="Laptop" service=pptp caller-id="" password="123" profile=default
      local-address=10.1.101.1 remote-address=10.1.101.100 routes==""

[admin@RemoteOffice] /ppp secret>

Notice that pptp local address is the same as routers address on local interface and remote address is form the same range as local network (10.1.101.0/24).

Next step is to enable pptp server and pptp client on the laptop.

[admin@RemoteOffice] /interface pptp-server server> set enabled=yes
[admin@RemoteOffice] /interface pptp-server server> print
            enabled: yes
            max-mtu: 1460
            max-mru: 1460
               mrru: disabled
     authentication: mschap2
  keepalive-timeout: 30
    default-profile: default
[admin@RemoteOffice] /interface pptp-server server>

PPTP client from the laptop should connect to routers public IP which in our example is 192.168.80.1.
Please, consult the respective manual on how to set up a PPTP client with the software You are using.

At this point (when pptp client is successfully connected) if you will try to ping any workstation form the laptop, ping will time out, because Laptop is unable to get ARPs from workstations. Solution is to set up proxy-arp on local interface

[admin@RemoteOffice] /interface ethernet> set Office arp=proxy-arp
[admin@RemoteOffice] /interface ethernet> print
Flags: X - disabled, R - running
  #    NAME                 MTU   MAC-ADDRESS         ARP
  0  R ether1              1500  00:30:4F:0B:7B:C1 enabled
  1  R ether2              1500  00:30:4F:06:62:12 proxy-arp
[admin@RemoteOffice] interface ethernet>

After proxy-arp is enabled client can successfully reach all workstations in local network behind the router.

 

Site-to-Site PPTP

The following is an example of connecting two Intranets using PPTP tunnel over the Internet.

Consider following setup

Site-to-site-pptp-example.png

Office and Home routers are connected to internet through ether1, workstations and laptops are connected to ether2. Both local networks are routed through pptp client, thus they are not in the same broadcast domain. If both networks should be in the same broadcast domain then you need to use BCP and bridge pptp tunnel with local interface.

First step is to create a user

[admin@RemoteOffice] /ppp secret> add name=Home service=pptp password=123
local-address=172.16.1.1 remote-address=172.16.1.2 routes="10.1.202.0/24 172.16.1.2 1"
[admin@RemoteOffice] /ppp secret> print detail
Flags: X - disabled
  0   name="Home" service=pptp caller-id="" password="123" profile=default
      local-address=172.16.1.1 remote-address=172.16.1.2 routes=="10.1.202.0/24 172.16.1.2 1"

[admin@RemoteOffice] /ppp secret>

Notice that we set up pptp to add route whenever client connects. If this option is not set, then you will need static routing configuration on the server to route traffic between sites through pptp tunnel.

Next step is to enable pptp server on the office router and configure pptp client on the Home router.

[admin@RemoteOffice] /interface pptp-server server> set enabled=yes
[admin@RemoteOffice] /interface pptp-server server> print
            enabled: yes
            max-mtu: 1460
            max-mru: 1460
               mrru: disabled
     authentication: mschap2
  keepalive-timeout: 30
    default-profile: default
[admin@RemoteOffice] /interface pptp-server server>
[admin@Home] /interface pptp-client> add user=Home password=123 connect-to=192.168.80.1 disabled=no
[admin@Home] /interface pptp-client> print
Flags: X - disabled, R - running
 0    name="pptp-out1" max-mtu=1460 max-mru=1460 mrru=disabled connect-to=192.168.80.1 user="Home" 
       password="123" profile=default-encryption add-default-route=no dial-on-demand=no 
       allow=pap,chap,mschap1,mschap2
[admin@Home] /interface pptp-client>

Now we need to add route to reach local network behind Home router

[admin@RemoteOffice] /ip route> add dst-address=10.1.101.0/24 gateway=pptp-out1

Now after tunnel is established and routes are set, you should be able to ping remote network.

Fuente: http://wiki.mikrotik.com/wiki/Manual:Interface/PPTP

Saludos- AmaRo

Forzar la actualización de DDClient

Para forzar la actualizacion de un DynDNS en Linux;
despues de modificar el ddclient.conf:

TUSERVER:~# cat /etc/ddclient.conf
# Configuration file for ddclient
pid=/var/run/ddclient.pid
protocol=dyndns2
use=if, if=eth0
#use=if, if=ppp0
server=members.dyndns.org
login=TUUSER
password=TUPASSWORD
TUHOST.homelinux.com

Luego ejecutar: ddclient -force

Saludos.

AmaRo

Exim: Comandos que se necesitan saber.

Exim es un agente de transporte de correo (Mail Transport Agent, MTA) que puede ser utilizado en la mayoría de sistemas Unix, siendo una de las opciones más comunes, junto con Qmail o Postfix para servicio de correo servidores Unix.

Partiendo de la base de que conocemos el funcionamiento de Exim, los comandos básicos que un administrador de sistemas que utilice este MTA son:

Lista por pantalla los correos en cola:

exim -bp

Sacar por pantalla el nº de correos en cola:

exim -bpc

Muestra un resumen de los correos en cola (dominio, nº de correos, tiempo en cola y peso):

exim -bp | exiqsumm

Eliminar un correo en concreto:

exim -Mrm '<id correo>'

Congelar un correo:

exim -Mf '<id correo>'

Procesar un correo:

exim -M '<id correo>'

Eliminar todos los correos congelados:

exiqgrep -z -i | xargs exim -Mrm

Sacar por pantalla que está haciendo exim en este momento:

exiwhat

Hacer un traceroute a una dirección de correo:

exim -bt '<id correo>'

Ver las cabeceras de un correo:

exim -Mvh '<id correo>'

Ver el cuerpo de un correo:

exim -Mvb '<id correo>'

Ver los logs de un correo:

exim -Mvl '<id correo>'

Forzar cola de correo:

exim -qff

Buscar correos en cola de un determinado emisor:

exiqgrep -f [usuario]@dominio

Buscar correos en cola de un determinado receptor:

exiqgrep -r [usuario]@dominio

Respecto a estos dos últimos comandos, exigrep es un comando extremadamente útil, dispone de muchas otras opciones que pueden ser revisadas en su respectiva ayuda.

Eliminar la cola de correo completa (dos formas):

exim -bp | awk '/^ *[0-9]+[mhd]/{print "exim -Mrm " $3}' | sh
rm /var/spool/exim/input/*

Conociendo estos comandos (o teniendolos a mano) uno ya puede moverse con soltura en exim.

 

Fuente: http://rm-rf.es/exim-comandos-basicos/