Seguridad en Servidor - Aspectos a tener en cuenta

[mlumbreras]

Revisando por casualidad una web que se ha anunciado en esta comunidad he visto que ha sido hackeada (http://bahiahosting.com/).

¿Qué aspectos básicos de seguridad debemos tener en cuenta cuando configuramos nuestro servidor?

[f.villalba]

Lo más básico es desabilitar los servicios que no vayas a usar en el init.d (contra menos servicios menos puertas traseras tendras) (netbios, avahi daemon etc...)

Dejar solo los puertos que vayas a utilizar abiertos en el firewall iptables y los otros cerrarlos.

Configurar sudoers con visudo para asignar usuarios. (no utilizar root por default)

Configurar las llaves de acceso pública y privada

Asegurar SSH y protejerlo de diccionario de ataques

Utilizar FTP encriptado

Asegurar sysctl.conf para evitar ataques de red

Esto es lo más básico.


Por supuesto tener todo el sistema y servicios actualizadas a últimas versiones estables. Esto tambien incluye CMS. y no usar la versión de Joomla 1.5 que veo que usan en muchos sitios. :-)

[mlumbreras]

Gracias por el aporte, Ferran :aprueba:

A trabajar en ello :afirmar:

[f.villalba]

Esto puede servirte:
https://docs.google.com/viewer?a=v&pid=sites&srcid=dmF6cXVlem5hbmluaS5jb20uYXJ8c3lzYWRtaW58Z3g6 MjEwZWY1ODEwMmJmOTM1Zg

[mlumbreras]

Muchísimas gracias por el enlace! Me viene genial! Gracias de nuevo!

[mlumbreras]

Ferran, me da hasta vergüenza hacer esta pregunta, pero... ¿cómo puedo saber qué paquetes de los que tengo instalados en mi servidor no se están utilizando para poder eliminarlos? Cuando lanzo 'rpm -qa' me aparecen una burrada de paquetes.

[f.villalba]

Ferran, me da hasta vergüenza hacer esta pregunta, pero... ¿cómo puedo saber qué paquetes de los que tengo instalados en mi servidor no se están utilizando para poder eliminarlos? Cuando lanzo 'rpm -qa' me aparecen una burrada de paquetes.

Tienes que ver los que estas usando y mirar sus dependencias. O eso creo.

Salu2.

[mlumbreras]

Me he instalado Webmin, a ver si me ayuda un poquito con eso y con los servicios de init.d, que tengo también una barbaridad...

[f.villalba]

Ferran, me da hasta vergüenza hacer esta pregunta, pero... ¿cómo puedo saber qué paquetes de los que tengo instalados en mi servidor no se están utilizando para poder eliminarlos? Cuando lanzo 'rpm -qa' me aparecen una burrada de paquetes.

Lo acabo de aprender. En Debian/Ubuntu dpkg (herramienta escrita en C de bajo nivel) con al argumento/parametro -l y te muestra todos los paquetes instalados en el S.O.

dpkg -l para listar los paquetes instalados en el sistema (debian o ubuntu)

Para ver que dependencias usa con el argumento o parametro -s:

Ejemplo:

dpkg -l (lista paquetes instalados en el S.O.)

***@equipo-***-*****:~$ dpkg -s vino
Package: vino
Status: install ok installed
Priority: optional
Section: gnome
Installed-Size: 2476
Maintainer: Ubuntu Desktop Team <[email protected]>
Architecture: i386
Version: 2.26.1-0ubuntu1
Depends: libavahi-client3 (>= 0.6.16), libavahi-common3 (>= 0.6.16), libavahi-glib1 (>= 0.6.16), libc6 (>= 2.4), libdbus-1-3 (>= 1.0.2), libdbus-glib-1-2 (>= 0.78), libgconf2-4 (>= 2.13.5), libgcrypt11 (>= 1.4.0), libglade2-0 (>= 1:2.6.1), libglib2.0-0 (>= 2.17.0), libgnome2-0 (>= 2.17.3), libgnomeui-0 (>= 2.22.0), libgnutls26 (>= 2.4.0-0), libgtk2.0-0 (>= 2.16.0), libjpeg62, libnotify1 (>= 0.4.4), libnotify1-gtk2.10, libpango1.0-0 (>= 1.14.0), libsoup2.4-1 (>= 2.25.4), libunique-1.0-0 (>= 1.0.0), libx11-6, libxdamage1 (>= 1:1.1), libxext6, libxfixes3 (>= 1:4.0.1), libxtst6, zlib1g (>= 1:1.1.4), gconf2 (>= 2.10.1-2)
Suggests: vinagre, gnome-user-guide | gnome2-user-guide (>= 2.8.1)
Conffiles:
/etc/xdg/autostart/vino-server.desktop ad3c9bd99608c9a748af7429a1ab6f7f
Description: VNC server for GNOME
VNC is a protocol that allows remote display of a user's desktop. This
package provides a VNC server that integrates with GNOME, allowing you
to export your running desktop to another computer for remote use or
diagnosis.
Original-Maintainer:

[f.villalba]

Esto de las dependencias es parecido a las herencias de CSS (Cascading Style Sheets) que hasta que no le pillas el truco te subes por las paredes. Jeje.

[f.villalba]

o más concreto le metes una tubería y con el comando grep:

dpkg -s vino | grep Depends

Depends: libavahi-client3 (>= 0.6.16), libavahi-common3 (>= 0.6.16), libavahi-glib1 (>= 0.6.16), libc6 (>= 2.4), libdbus-1-3 (>= 1.0.2), libdbus-glib-1-2 (>= 0.78), libgconf2-4 (>= 2.13.5), libgcrypt11 (>= 1.4.0), libglade2-0 (>= 1:2.6.1), libglib2.0-0 (>= 2.17.0), libgnome2-0 (>= 2.17.3), libgnomeui-0 (>= 2.22.0), libgnutls26 (>= 2.4.0-0), libgtk2.0-0 (>= 2.16.0), libjpeg62, libnotify1 (>= 0.4.4), libnotify1-gtk2.10, libpango1.0-0 (>= 1.14.0), libsoup2.4-1 (>= 2.25.4), libunique-1.0-0 (>= 1.0.0), libx11-6, libxdamage1 (>= 1:1.1), libxext6, libxfixes3 (>= 1:4.0.1), libxtst6, zlib1g (>= 1:1.1.4), gconf2 (>= 2.10.1-2)

[mlumbreras]

genial! :aprueba:

[IPSecureNetwork]

Antes que nada disculpas por llegar tarde a este hilo recien lo veo y me ha parecido interesante poder colaborar en lo que pueda y para quien le sirva.

Antes que nada hay que tener en cuenta que la seguridad en servidores y la aplicación de esta, siempre va de la mano de la utilidad que se le vaya a dar a un servidor.

Generalmente y por lo que este foro indica vamos a hacer referencia a lo que el negocio del Webhosting y servicios de internet asociados se puedan ofrecer desde nuestros servidores.

Ahora bién. el primer paso es entender que servicio vamos a brindar y cual sera el acceso de nuestros clientes a nuestro servidor.
Por ejemplo: no es lo mismo brindar shared webhosting que solo un servidor de streaming o un game server que un servidor de cuentas Shell.

el proceso de securizar nuestros servidores es comunmente llamado Hardening ( podran encontrar en google cientos de miles de sitios que explican distintos niveles de hardening de servidores ).

Ahora volviendo a lo que nos interesa vamos a tomar 2 ejemplos clasicos que son el Webhosting y el Shell provisioning.

Para ambos casos un factor importante a tomar en cuenta es que tipo de sistema operativo a utilizar y su distribución.

los mas conocidos por ser gratuitos, configurables, seguros y estables son FreeBSD y GNU/Linux , cada uno con sus particularidades ( pros y contras en cuanto a seguridad refieren ).

Ahora bien una vez que hemos decidido que el sistema operativo nos queda ver en que forma brindaremos nuestros servicios a los clientes y de que manera accederan a nuestro servidor.


P.D.: Disculpen si hay faltan algunas letras en las palabras , el teclado inalambrico se esta quedando sin baterias lol
Algo importante a tener en cuenta por que a partir de ello es que securizaremos luego lo mejor posible para que ni alguien externo pueda meterse donde no debe y .. algo no menor .. que alguien que si tiene acceso no pueda realizar nada que no le este permitido y poder limitar sus acciones simplemente a las que al servicio demande y nada mas.

Imaginando que hemos decidido un panel bastante popular como lo puede ser Cpanel, y que hemos decidido brindar shared hosting. pues bien .. debemos tener en cuenta que todo servicio expuesto a la nube ( internet ) es un factor de riesto sin importar cuanto hagamos, no existe el riesgo "0" y lo que trataremos de hacer es minimizar los puntos en los cuales expongamos nuestro equipamiento, red y los datos de nuestros clientes.

como comenzamos la tarea:

De cara al factor de riesgo remoto:

Tal y como ha dicho nuestro querido colega Ferran ver que todos los servicios que no seran utilizados y sobre todo aquellos que abran puertos ( TCP o UDP ) sean solo los que necesitamos..esto no indica que con esto se acabaran los problemas sino que simplemente minimizaremos el factor de riesgo externo.

Como dato adicional es interesante que sepan que son los servicios mas necesarios e indispensables los que poseen el mayor numero de fallas de seguridad detectadas Ej. DNS ( Bind ) Webserver ( Apache ) Base de datos (My Sql), etc.

Ok, imaginemos que ya hemos reducido nuestros servicios al maximo y que solo tenemos corriendo lo que necesitaremos para brindar hosting con su panel base de datos, webserver, dns, etc.

Que nos significa esto? pues que no solo hemos definido los servicios a utilizar sino que hemos fijado los puertos que nuestro servidor tendra abiertos.

Estos datos seran fundamentales dado que una de las consideradas buenas practicas para todo servicio que este expuesto a una red publica es contar con un Firewall. ( Tanto linux como FreeBSD incluyen unos muy buenos firewalls = IPTABLES Y IPFW ) muchas veces son estos firewalls los que definen que distribución elegiremos.. pero bueno es algo filosofico que podremos tratar en otro hilo.. je

Ahora ya tenemos nuestro Sistema Operativo con nuestro Firewall incluido y lo que deberemos hacer es tomar los datos que conocemos a la perfección ( los puertos de nuestros servicios ) y crear las reglas pertinentes para que solo estos puertos de nuestros servicios sean los que puedan ser accedidos en nuestro servidor y por los que nuestro servidor se comunicara con el resto de la red.

* Obviamente las reglas en los firewalls pueden hacerse tan complejas como se quieran y generar forwards y miles de cosas mas pero es algo que dejaremos para otra oportunidad ya que trataremos de que esto sea algo basico pero si .. pueden hacerse maravillas :P

Ok ya tenemos nuestro servidor con nuestras reglas corriendo y que mas podemos hacer?

Pues bien tener puertos cerrados y servicios corriendo no nos garantizan mucho ahora debemos ver la forma en como proteger a los servicios en si.

Algo que ha dicho Ferran es muy cierto.. se debe tratar de tener actualizado antes fallas criticas de seguridad, es importante estar informado constantemente a sitios donde informan este tipo de cosas ( los hay y muchos ) estar suscripto a este tipo de sitios les ayudara a no llevarse sorpresas en el futuro.

una buena forma de prevenir y asegurar nuestros servicios es instalar un IPS ( Intrussion Prevention System) o IDPS ( Intrussion Detection and Prevention System ).. pero que es esto ??? pues son appliances que monitorean la actividad en la red detectando actividades sospechosas y maliciosas.

Muchos Datacenters los Ofrecen como parte de su servicio de red para nuestros servidores lo que es algo muy bueno si apuntamos a un nivel de seguridad alto.

En caso de que no tengamos dinero para adquirir esto tambien estan siempre nuestras queridas alternativas Free y que pueden instalarse en nuestros servidores.

Un IDS muy conocido es Snort ( buscar en google ) el cual analizará el trafico entrante y saliente de nuestra interfaz de red buscando patrones maliciosos que coincidan con todo su set de reglas que si estan bien actualizadas a diario pueden ser muy muy efectivas al momento de protegernos de aquellos que quieran sacar provecho de nuestro servidor sin permiso.

Bueno .. ya tenemos nuestro server protegido por un firewall y un IDS de red.. ahora como sigue la cosa? pues ... a realizar un poco de hardening sobre cada servicio que brindaremos..despues de todo la seguridad nunca sobra.

Tomemos un ejemplo:
DNS
Mysql
Apache

Siempre debemos tener en cuenta que cada servicio corra con un usuario propio... con esto lograremos que si alguien compromete un servicio el mismo no tenga los privilegios del usuario que administra el mismo por lo tanto reduciremos el impacto de la falla de seguridad. ( lo se lo se .. lo ideal es encapsular con chroot etc pero vamos.. esto debe ser basic no? je )

un consejo que podemos dar sobre apache es que bueno .. al ser nuestro servicio mas importante para el cliente en cierta forma es uno de los que mas debemos cuidar por lo tanto habrá que tener muy en cuenta todo lo que el apache mismo pueda brindar al atacante.

Ej: configurar correctamente el php.ini para que no permita ejecución de comandos o permita generar un phpshell etc.
( leer info en google hay mucha )

Otra forma de cuidarnos de esto es poner un IDS en la capa del webserver el cual tenga reglas actualizadas de todas aquellas practicas maliciosas que salen dia a dia. este ids se llama Mod_Security y hay mucha info en la net dando vuelta que recomendaria que lean. es un modulo muy bueno y configurable. diria casi indispensable a la hora de dar servicios web. sobretodo por que pueden prevenr los tan conocidos RFI.

con estos pasos minimos reduciremos bastante el factor de riesgo externo pero creanme siempre hay que informarse de lo ultimo por que nunca se sabe que puede salir y afectarte.

( creo que mas de uno se acordara del bug de apache ( el range attack ) que daba denegación de servicio y por 2 semanas no tenia parche je )

en fin.

Que nos resta ahora?

La seguridad interna de nuestro servidor, que queremos decir con esto? pues que la seguridad no solo se mide de cara a internet sino que muchos usuarios y clientes pueden comprometer nuestros servidores ( el 40% de los problemas de seguridad en los proveedores de red son de factor interno )

Aqui algunos tips para nuestra seguridad interna:

Establecer politicas de passwords para los usuarios y lockeo de las mismas a X cantidad de intentos fallidos ( esto evitara que por un usuario con una password facil nuestro servidor quede expuesto y tambien los password crackers por fuerza bruta )

Pam.d puede ayudarnos con esto y no solo para politicas de passwords.

( recomendaria leer sobre pam.d ya que es una excelente herramienta de seguridad para utilizar y esta disponible en nuestros Linux y FreeBSD )

utilizar rookitshunters a diario : estos programas verifican que nuestros archivos de sistema no se hayan modificado y detectaran si alguien posee ficheros maliciosos en nuestro sistema ). ej. rkhunter

verificar que la umask de nuestros usuarios sea 022 .. lo que garantizara que solo la gente con el ID correspondiente pueda leer ficheros y manipularlos .. sobre todo los de nuestro sistema.

modificar el port SSH a un port alto superior a 1024.
utilizar un usuario de administración diferente de root y restringir el logueo de root al sistema por SSH: osea crear un usuario que pueda escalar privilegios y evitar que root pueda loguearse desde /etc/ssh/sshd_config ( rootlogin no )

utilizar las bondades del /etc/pam.d/limits.conf para limitar los recursos que consumiran nuestros usuarios dentro de nuestro sistema.. esto evitara fork bombs etc.

pues bien...

se que este tema del hardening es muy largo y lo que he dicho aqui es muy pequeño comparado con todo lo que debemos hacer a diario

pero bueno es un buen inicio.

luego veremos otras miles de cosas que se pueden hacer ..con sus firewalls .. IDS.. hardening interno. etc.

pero bueno je me canse de escribir por hoy.

[neocomp]

Lo mejor es instalar un buen firewall, csf es genial sobre todo si se integra con WHM ... si revisan la primera opción Check Server Security hace un diagnóstico de más de 130 medidas de seguridad e indica las medidas que se deben tomar para solucionar las que tienen un Warning :-D

Otra medida que al menos a mi me da mucha tranquilidad es cambiar el puerto de SSH y configurar en cPanel -> Host Access Control acceso al sshd solo al rango de IP's de mi ISP o a la IP que tengo en el minuto y bloqueo todas las demás.

cPanel tambien provee una buena herramienta para la mayoría de los ataques de hackeo habilitando cPHulk Brute Force Protection

Estas son 3 medidas básicas que siempre usamos ... de una lista bastante grande de medidas de hardening que siempre utilizamos :cool:

[f.villalba]

Me he instalado Webmin, a ver si me ayuda un poquito con eso y con los servicios de init.d, que tengo también una barbaridad...

Hola,

Para la posteridad ya que ahora mismo María (mlumbreras) ya es una sysadmin junior profesional y recorriendo camino para seguir creciendo más como profesional en este campo de la administración de sistemas como a todos los que nos gusta este mundillo.

Para los servicios en GNU/Linux he aquí varios comandos:

Listar demonios de servicios encendidos:
chkconfig --list

Cambiar los niveles de ejecución:
chkconfig --level (introducir los niveles por orden)

Desactivar los demonios de servicios:
chkconfig --del

Activar servicio
chkconfig httpd on --level (introducir niveles de ejecución)