Hola muy buenas, actualmente estoy trabajando con Centos 5 server y estoy tratando de instalar unos certificados que me ha generado piensasolutions. He habilitado el https y demás y funciona pero el tema es que me han pasado ya el server.crt y el server.key.
La pregunta es la siguietne, tengo que hacer algo con esos archivos utilizando el openssl o teóricamente ya está todo generado y lo único que tengo que cambiar es esto en el archivo default-ssl
SSLCertificateFile /etc/httpd/conf/ssl.crt/example.com.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/example.com.key
He utilizado alguna vez https pero no con un certificado firmado.
Un saludo.
Aquí te van las lineas a añadir de ejemplo para tu fichero de configuración del host.
<VirtualHost IP:443> ServerName dominio.com ServerAlias www.dominio.com
DocumentRoot /var/www/vhosts/dominio.com/httpdocs/ CustomLog /var/www/vhosts/dominio.com/logs/access_ssl_log combined ErrorLog /var/www/vhosts/dominio.com/logs/error_ssl_log
<Directory /var/www/vhosts/dominio.com/httpdocs> Order allow,deny Allow from all AllowOverride All Options +FollowSymLinks </Directory>
AddDefaultCharset ISO-8859-1
# SSL Engine Switch: SSLEngine on SSLCertificateFile /etc/httpd/conf/ssl.crt/www.dominio.com.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/dominio.com.key
</VirtualHost>
El 11 de octubre de 2011 13:36, Maykel Franco Hernández < maykel@maykel.sytes.net> escribió:
Hola muy buenas, actualmente estoy trabajando con Centos 5 server y estoy tratando de instalar unos certificados que me ha generado piensasolutions. He habilitado el https y demás y funciona pero el tema es que me han pasado ya el server.crt y el server.key.
La pregunta es la siguietne, tengo que hacer algo con esos archivos utilizando el openssl o teóricamente ya está todo generado y lo único que tengo que cambiar es esto en el archivo default-ssl
SSLCertificateFile /etc/httpd/conf/ssl.crt/example.com.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/example.com.key
He utilizado alguna vez https pero no con un certificado firmado.
Un saludo.
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Gracias por contestar. Lo he hecho así y nada. Da error el apache. Una cosa, se tiene que llamar el nombre de la máquina igual que el nombre con el que se pide el certificado??
Una pregunta, con esos certificados generados que me han pasado el .key y el .crt en teoría ya firmados y demás...Tengo que hacer algo aparte de compartirlos para apache?? tengo que realizar alguna modificacióin con openssl...Ya nosé que más buscar.
On Tue, 11 Oct 2011 13:45:17 +0100, victor santana wrote:
Aquí te van las lineas a añadir de ejemplo para tu fichero de
configuración
del host.
ServerName dominio.com ServerAlias
www.dominio.com [3]
DocumentRoot
/var/www/vhosts/dominio.com/httpdocs/
CustomLog
/var/www/vhosts/dominio.com/logs/access_ssl_log combined
ErrorLog
/var/www/vhosts/dominio.com/logs/error_ssl_log
Order allow,deny
Allow from all
AllowOverride All Options +FollowSymLinks
AddDefaultCharset ISO-8859-1
# SSL Engine Switch: SSLEngine on
SSLCertificateFile /etc/httpd/conf/ssl.crt/www.dominio.com.crt [4]
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/dominio.com.key
El 11
de octubre de 2011 13:36, Maykel Franco Hernández <
maykel@maykel.sytes.net [5]> escribió:
Hola muy buenas,
actualmente estoy trabajando con Centos 5 server y estoy tratando de instalar unos certificados que me ha generado piensasolutions. He habilitado el https y demás y funciona pero el tema es que me han pasado ya el server.crt y el server.key. La pregunta es la siguietne, tengo que hacer algo con esos archivos utilizando el openssl o teóricamente ya está todo generado y lo único que tengo que cambiar es esto en el archivo default-ssl SSLCertificateFile /etc/httpd/conf/ssl.crt/example.com.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/example.com.key He utilizado alguna vez https pero no con un certificado firmado. Un saludo. _______________________________________________ CentOS-es mailing list CentOS-es@centos.org [1] http://lists.centos.org/mailman/listinfo/centos-es [2]
--
_______________________ REPARACIONONLINE GARANTIA PARA SU PC ******************************** _______________________________________________ CentOS-es mailing list CentOS-es@centos.org [6] http://lists.centos.org/mailman/listinfo/centos-es [7]
Links: ------ [1] mailto:CentOS-es@centos.org [2] http://lists.centos.org/mailman/listinfo/centos-es [3] http://www.dominio.com [4] http://www.dominio.com.crt [5] mailto:maykel@maykel.sytes.net [6] mailto:CentOS-es@centos.org [7] http://lists.centos.org/mailman/listinfo/centos-es
- ¿Que mensaje de error da el apache?
- Los certificados deben ir en el fichero de configuración del dominio en cuestión, es decir si has pedido el certificado generado para www.dominioA.com no puedes ponerlo en el fichero apache de configuración de www.dominioB.com
-
El 11 de octubre de 2011 15:03, Maykel Franco Hernández < maykel@maykel.sytes.net> escribió:
Gracias por contestar. Lo he hecho así y nada. Da error el apache. Una cosa, se tiene que llamar el nombre de la máquina igual que el nombre con el que se pide el certificado??
Una pregunta, con esos certificados generados que me han pasado el .key y el .crt en teoría ya firmados y demás...Tengo que hacer algo aparte de compartirlos para apache?? tengo que realizar alguna modificacióin con openssl...Ya nosé que más buscar.
On Tue, 11 Oct 2011 13:45:17 +0100, victor santana wrote:
Aquí te van las lineas a añadir de ejemplo para tu fichero de
configuración
del host.
ServerName dominio.com ServerAlias
www.dominio.com [3]
DocumentRoot
/var/www/vhosts/dominio.com/httpdocs/
CustomLog
/var/www/vhosts/dominio.com/logs/access_ssl_log combined
ErrorLog
/var/www/vhosts/dominio.com/logs/error_ssl_log
Order allow,deny
Allow from all
AllowOverride All Options +FollowSymLinks
AddDefaultCharset ISO-8859-1
# SSL Engine Switch: SSLEngine on
SSLCertificateFile /etc/httpd/conf/ssl.crt/www.dominio.com.crt [4]
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/dominio.com.key
El 11
de octubre de 2011 13:36, Maykel Franco Hernández <
maykel@maykel.sytes.net [5]> escribió:
Hola muy buenas,
actualmente estoy trabajando con Centos 5 server y estoy tratando de instalar unos certificados que me ha generado piensasolutions. He habilitado el https y demás y funciona pero el tema es que me han pasado ya el server.crt y el server.key. La pregunta es la siguietne, tengo que hacer algo con esos archivos utilizando el openssl o teóricamente ya está todo generado y lo único que tengo que cambiar es esto en el archivo default-ssl SSLCertificateFile /etc/httpd/conf/ssl.crt/example.com.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/example.com.key He utilizado alguna vez https pero no con un certificado firmado. Un saludo. _______________________________________________ CentOS-es mailing list CentOS-es@centos.org [1] http://lists.centos.org/mailman/listinfo/centos-es [2]
--
_______________________ REPARACIONONLINE GARANTIA PARA SU PC
_______________________________________________ CentOS-es mailing list CentOS-es@centos.org [6] http://lists.centos.org/mailman/listinfo/centos-es [7]
Links:
[1] mailto:CentOS-es@centos.org [2] http://lists.centos.org/mailman/listinfo/centos-es [3] http://www.dominio.com [4] http://www.dominio.com.crt [5] mailto:maykel@maykel.sytes.net [6] mailto:CentOS-es@centos.org [7] http://lists.centos.org/mailman/listinfo/centos-es _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Hola gente, tenemos un servidor con centos 5 y en el log secure veo intentos de acceso por ssh muy seguramente un script (checando la IP google dice que es alguien de beijing).
Primero agregue la ip a hosts.deny pero luego me di cuenta que la ip cambio y siguio cambiando, entonces no veo el caso de estar agregando las ip al hosts.deny
Luego cerre el acceso por ssh a root que bueno gloogeando me tope que es una buena practica de seguridad, asi como tambien limitar el numero de intentos el tiempo para poner la contraseña y ahi de ratos veo en el log intentos de acceso por ahi, pero pues por ahi ya no podra entrar.
¿Alguna otra recomendacio que me puedan dar para evitar esto?
Denyhosts es un rpm que te puede ayudar
denyhost + APF + FAIL2BAN
Sls
El 11 de octubre de 2011 10:54, Lic. Domingo Varela Yahuitl. < domingov@linuxsc.net> escribió:
Denyhosts es un rpm que te puede ayudar
Enviado desde mi teléfono Android con K-9 Mail. Disculpa mi brevedad
"Jesús Rivas" jesus@evangelizacion.org.mx escribió:
Hola gente, tenemos un servidor con centos 5 y en el log secure veo intentos de acceso por ssh muy seguramente un script (checando la IP google dice que es alguien de beijing).
Primero agregue la ip a hosts.deny pero luego me di cuenta que la ip cambio y siguio cambiando, entonces no veo el caso de estar agregando las ip al hosts.deny
Luego cerre el acceso por ssh a root que bueno gloogeando me tope que es una buena practica de seguridad, asi como tambien limitar el numero de intentos el tiempo para poner la contraseña y ahi de ratos veo en el log intentos de acceso por ahi, pero pues por ahi ya no podra entrar.
¿Alguna otra recomendacio que me puedan dar para evitar esto? _____________________________________________
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
fail2ban
Es una maravilla para estos casos.
----- Mensaje original ----- De: "Jesús Rivas" jesus@evangelizacion.org.mx Para: centos-es@centos.org Enviado: martes, 11 de octubre de 2011 17:53 Asunto: [CentOS-es] Intento de Hackeo
Hola gente, tenemos un servidor con centos 5 y en el log secure veo intentos de acceso por ssh muy seguramente un script (checando la IP google dice que es alguien de beijing).
Primero agregue la ip a hosts.deny pero luego me di cuenta que la ip cambio y siguio cambiando, entonces no veo el caso de estar agregando las ip al hosts.deny
Luego cerre el acceso por ssh a root que bueno gloogeando me tope que es una buena practica de seguridad, asi como tambien limitar el numero de intentos el tiempo para poner la contraseña y ahi de ratos veo en el log intentos de acceso por ahi, pero pues por ahi ya no podra entrar.
¿Alguna otra recomendacio que me puedan dar para evitar esto? _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Saludos Salvador Guzman Salman PSL Vigo, Galicia, España +34 986.21.30.27 +34 679-Salman Correo @Salman.ES Informaciones @Salman.ES para listas de correo http://Salman.EU/
Excelente, muchas gracias por las aportaciones ya me puse a leer.
El 11/10/2011 11:03, Salvador Guzman - Salman PSL escribió:
fail2ban
Es una maravilla para estos casos.
----- Mensaje original ----- De: "Jesús Rivas"jesus@evangelizacion.org.mx Para:centos-es@centos.org Enviado: martes, 11 de octubre de 2011 17:53 Asunto: [CentOS-es] Intento de Hackeo
Hola gente, tenemos un servidor con centos 5 y en el log secure veo intentos de acceso por ssh muy seguramente un script (checando la IP google dice que es alguien de beijing).
Primero agregue la ip a hosts.deny pero luego me di cuenta que la ip cambio y siguio cambiando, entonces no veo el caso de estar agregando las ip al hosts.deny
Luego cerre el acceso por ssh a root que bueno gloogeando me tope que es una buena practica de seguridad, asi como tambien limitar el numero de intentos el tiempo para poner la contraseña y ahi de ratos veo en el log intentos de acceso por ahi, pero pues por ahi ya no podra entrar.
¿Alguna otra recomendacio que me puedan dar para evitar esto? _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Saludos Salvador Guzman Salman PSL Vigo, Galicia, España +34 986.21.30.27 +34 679-Salman Correo @Salman.ES Informaciones @Salman.ES para listas de correo http://Salman.EU/ _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
cambia el puerto de ssh
César D. Cruz Arrunátegui
----- Mensaje original ----- De: "Jesús Rivas" jesus@evangelizacion.org.mx Para: centos-es@centos.org Enviados: Martes, 11 de Octubre 2011 10:53:18 GMT -05:00 Colombia Asunto: [CentOS-es] Intento de Hackeo
Hola gente, tenemos un servidor con centos 5 y en el log secure veo intentos de acceso por ssh muy seguramente un script (checando la IP google dice que es alguien de beijing).
Primero agregue la ip a hosts.deny pero luego me di cuenta que la ip cambio y siguio cambiando, entonces no veo el caso de estar agregando las ip al hosts.deny
Luego cerre el acceso por ssh a root que bueno gloogeando me tope que es una buena practica de seguridad, asi como tambien limitar el numero de intentos el tiempo para poner la contraseña y ahi de ratos veo en el log intentos de acceso por ahi, pero pues por ahi ya no podra entrar.
¿Alguna otra recomendacio que me puedan dar para evitar esto? _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Creo que cambiando el puerto ssh no es una solucion, pues te dan un port scan y dan con los puertos abiertos y empiezan el ataque, si no es asi, pues no tengo problemas en cambiar el puerto.
Lo que comentas de quitar el acceso a root al ssh ya lo hice, asi como limitar el numero de intentos y el tiempo para logearse.
Creo que no puedo moverle para que solo unas ip entren al servidor por ssh ya que tengo ip dinamicas para entrar al servidor, aunque si se puede agradeceria la aportacion.
El 12/10/2011 09:01, César CRUZ ARRUNATEGUI escribió:
cambia el puerto de ssh
César D. Cruz Arrunátegui
----- Mensaje original ----- De: "Jesús Rivas"jesus@evangelizacion.org.mx Para: centos-es@centos.org Enviados: Martes, 11 de Octubre 2011 10:53:18 GMT -05:00 Colombia Asunto: [CentOS-es] Intento de Hackeo
Hola gente, tenemos un servidor con centos 5 y en el log secure veo intentos de acceso por ssh muy seguramente un script (checando la IP google dice que es alguien de beijing).
Primero agregue la ip a hosts.deny pero luego me di cuenta que la ip cambio y siguio cambiando, entonces no veo el caso de estar agregando las ip al hosts.deny
Luego cerre el acceso por ssh a root que bueno gloogeando me tope que es una buena practica de seguridad, asi como tambien limitar el numero de intentos el tiempo para poner la contraseña y ahi de ratos veo en el log intentos de acceso por ahi, pero pues por ahi ya no podra entrar.
¿Alguna otra recomendacio que me puedan dar para evitar esto? _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
El 13/10/11 10:21, Jesús Rivas escribió:
Creo que cambiando el puerto ssh no es una solucion, pues te dan un port scan y dan con los puertos abiertos y empiezan el ataque, si no es asi, pues no tengo problemas en cambiar el puerto.
Lo que comentas de quitar el acceso a root al ssh ya lo hice, asi como limitar el numero de intentos y el tiempo para logearse.
Creo que no puedo moverle para que solo unas ip entren al servidor por ssh ya que tengo ip dinamicas para entrar al servidor, aunque si se puede agradeceria la aportacion.
El 12/10/2011 09:01, César CRUZ ARRUNATEGUI escribió:
cambia el puerto de ssh
César D. Cruz Arrunátegui
----- Mensaje original ----- De: "Jesús Rivas"jesus@evangelizacion.org.mx Para: centos-es@centos.org Enviados: Martes, 11 de Octubre 2011 10:53:18 GMT -05:00 Colombia Asunto: [CentOS-es] Intento de Hackeo
Hola gente, tenemos un servidor con centos 5 y en el log secure veo intentos de acceso por ssh muy seguramente un script (checando la IP google dice que es alguien de beijing).
Primero agregue la ip a hosts.deny pero luego me di cuenta que la ip cambio y siguio cambiando, entonces no veo el caso de estar agregando las ip al hosts.deny
Luego cerre el acceso por ssh a root que bueno gloogeando me tope que es una buena practica de seguridad, asi como tambien limitar el numero de intentos el tiempo para poner la contraseña y ahi de ratos veo en el log intentos de acceso por ahi, pero pues por ahi ya no podra entrar.
¿Alguna otra recomendacio que me puedan dar para evitar esto? _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
cuando te refieres a IP dinamicas, tu ISP no te da cualquier IP, sino algun IP de los bloques que le fueron asignados, lo que puedes hacer es averiguar los rangos IP de tu proveedor, y solo permites esos IP, con eso limitas bastante las IP que puedan acceder a tu SSH.
Yo.
Estimados: Para mi la mejor manera de solucionar esto es ponerse paranoico y generar "una clave de scaneo de apertura de puerto" el ejemplo seria el siguiente consutar el puerto 34 luego el puerto 70 , luego el puerto 72 y leugo puerto 73 , con esta secuencia de escaneo se abriria el puerto 22 por 5 segundos y luego se cierra. (bloqueando conexiones Nuevas, y solo dejar pasar conexiones establecidas).
/sbin/iptables -N INTO-PHASE2 /sbin/iptables -A INTO-PHASE2 -m recent --name PHASE1 --remove /sbin/iptables -A INTO-PHASE2 -m recent --name PHASE2 --set /sbin/iptables -A INTO-PHASE2 -j LOG --log-prefix "INTO PHASE2: "
/sbin/iptables -N INTO-PHASE3 /sbin/iptables -A INTO-PHASE3 -m recent --name PHASE2 --remove /sbin/iptables -A INTO-PHASE3 -m recent --name PHASE3 --set /sbin/iptables -A INTO-PHASE3 -j LOG --log-prefix "INTO PHASE3: "
/sbin/iptables -N INTO-PHASE4 /sbin/iptables -A INTO-PHASE4 -m recent --name PHASE3 --remove /sbin/iptables -A INTO-PHASE4 -m recent --name PHASE4 --set /sbin/iptables -A INTO-PHASE4 -j LOG --log-prefix "INTO PHASE4: "
/sbin/iptables -A INPUT -m recent --update --name PHASE1
/sbin/iptables -A INPUT -p tcp --dport 34 -m recent --set --name PHASE1 /sbin/iptables -A INPUT -p tcp --dport 70 -m recent --rcheck --name PHASE1 -j INTO-PHASE2 /sbin/iptables -A INPUT -p tcp --dport 72 -m recent --rcheck --name PHASE2 -j INTO-PHASE3 /sbin/iptables -A INPUT -p tcp --dport 73 -m recent --rcheck --name PHASE3 -j INTO-PHASE4
iptables -A INPUT -p tcp --dport 22 -m recent --rcheck --seconds 5 --name PHASE4 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j DROP
2011/10/13 Yoinier Hernandez Nieves ynieves@lt.datazucar.cu
El 13/10/11 10:21, Jesús Rivas escribió:
Creo que cambiando el puerto ssh no es una solucion, pues te dan un port scan y dan con los puertos abiertos y empiezan el ataque, si no es asi, pues no tengo problemas en cambiar el puerto.
Lo que comentas de quitar el acceso a root al ssh ya lo hice, asi como limitar el numero de intentos y el tiempo para logearse.
Creo que no puedo moverle para que solo unas ip entren al servidor por ssh ya que tengo ip dinamicas para entrar al servidor, aunque si se puede agradeceria la aportacion.
El 12/10/2011 09:01, César CRUZ ARRUNATEGUI escribió:
cambia el puerto de ssh
César D. Cruz Arrunátegui
----- Mensaje original ----- De: "Jesús Rivas"jesus@evangelizacion.org.mx Para: centos-es@centos.org Enviados: Martes, 11 de Octubre 2011 10:53:18 GMT -05:00 Colombia Asunto: [CentOS-es] Intento de Hackeo
Hola gente, tenemos un servidor con centos 5 y en el log secure veo intentos de acceso por ssh muy seguramente un script (checando la IP google dice que es alguien de beijing).
Primero agregue la ip a hosts.deny pero luego me di cuenta que la ip cambio y siguio cambiando, entonces no veo el caso de estar agregando las ip al hosts.deny
Luego cerre el acceso por ssh a root que bueno gloogeando me tope que es una buena practica de seguridad, asi como tambien limitar el numero de intentos el tiempo para poner la contraseña y ahi de ratos veo en el log intentos de acceso por ahi, pero pues por ahi ya no podra entrar.
¿Alguna otra recomendacio que me puedan dar para evitar esto? _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
cuando te refieres a IP dinamicas, tu ISP no te da cualquier IP, sino algun IP de los bloques que le fueron asignados, lo que puedes hacer es averiguar los rangos IP de tu proveedor, y solo permites esos IP, con eso limitas bastante las IP que puedan acceder a tu SSH.
Yo.
Yoinier Hernández Nieves. Administrador de Redes. División ZETI Nodo Provincial Datazucar Las Tunas.
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
El jue, 13-10-2011 a las 12:28 -0300, juan sabino escribió:
Estimados: Para mi la mejor manera de solucionar esto es ponerse paranoico y generar "una clave de scaneo de apertura de puerto" el ejemplo seria el siguiente consutar el puerto 34 luego el puerto 70 , luego el puerto 72 y leugo puerto 73 , con esta secuencia de escaneo se abriria el puerto 22 por 5 segundos y luego se cierra. (bloqueando conexiones Nuevas, y solo dejar pasar conexiones establecidas).
port knocking, buenísimo. Hay un paquete llamado knockd si mal no recuerdo. saludos epe
/sbin/iptables -N INTO-PHASE2 /sbin/iptables -A INTO-PHASE2 -m recent --name PHASE1 --remove /sbin/iptables -A INTO-PHASE2 -m recent --name PHASE2 --set /sbin/iptables -A INTO-PHASE2 -j LOG --log-prefix "INTO PHASE2: "
/sbin/iptables -N INTO-PHASE3 /sbin/iptables -A INTO-PHASE3 -m recent --name PHASE2 --remove /sbin/iptables -A INTO-PHASE3 -m recent --name PHASE3 --set /sbin/iptables -A INTO-PHASE3 -j LOG --log-prefix "INTO PHASE3: "
/sbin/iptables -N INTO-PHASE4 /sbin/iptables -A INTO-PHASE4 -m recent --name PHASE3 --remove /sbin/iptables -A INTO-PHASE4 -m recent --name PHASE4 --set /sbin/iptables -A INTO-PHASE4 -j LOG --log-prefix "INTO PHASE4: "
/sbin/iptables -A INPUT -m recent --update --name PHASE1
/sbin/iptables -A INPUT -p tcp --dport 34 -m recent --set --name PHASE1 /sbin/iptables -A INPUT -p tcp --dport 70 -m recent --rcheck --name PHASE1 -j INTO-PHASE2 /sbin/iptables -A INPUT -p tcp --dport 72 -m recent --rcheck --name PHASE2 -j INTO-PHASE3 /sbin/iptables -A INPUT -p tcp --dport 73 -m recent --rcheck --name PHASE3 -j INTO-PHASE4
iptables -A INPUT -p tcp --dport 22 -m recent --rcheck --seconds 5 --name PHASE4 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j DROP
2011/10/13 Yoinier Hernandez Nieves ynieves@lt.datazucar.cu
El 13/10/11 10:21, Jesús Rivas escribió:
Creo que cambiando el puerto ssh no es una solucion, pues te dan un port scan y dan con los puertos abiertos y empiezan el ataque, si no es asi, pues no tengo problemas en cambiar el puerto.
Lo que comentas de quitar el acceso a root al ssh ya lo hice, asi como limitar el numero de intentos y el tiempo para logearse.
Creo que no puedo moverle para que solo unas ip entren al servidor por ssh ya que tengo ip dinamicas para entrar al servidor, aunque si se puede agradeceria la aportacion.
El 12/10/2011 09:01, César CRUZ ARRUNATEGUI escribió:
cambia el puerto de ssh
César D. Cruz Arrunátegui
----- Mensaje original ----- De: "Jesús Rivas"jesus@evangelizacion.org.mx Para: centos-es@centos.org Enviados: Martes, 11 de Octubre 2011 10:53:18 GMT -05:00 Colombia Asunto: [CentOS-es] Intento de Hackeo
Hola gente, tenemos un servidor con centos 5 y en el log secure veo intentos de acceso por ssh muy seguramente un script (checando la IP google dice que es alguien de beijing).
Primero agregue la ip a hosts.deny pero luego me di cuenta que la ip cambio y siguio cambiando, entonces no veo el caso de estar agregando las ip al hosts.deny
Luego cerre el acceso por ssh a root que bueno gloogeando me tope que es una buena practica de seguridad, asi como tambien limitar el numero de intentos el tiempo para poner la contraseña y ahi de ratos veo en el log intentos de acceso por ahi, pero pues por ahi ya no podra entrar.
¿Alguna otra recomendacio que me puedan dar para evitar esto? _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
cuando te refieres a IP dinamicas, tu ISP no te da cualquier IP, sino algun IP de los bloques que le fueron asignados, lo que puedes hacer es averiguar los rangos IP de tu proveedor, y solo permites esos IP, con eso limitas bastante las IP que puedan acceder a tu SSH.
Yo.
Yoinier Hernández Nieves. Administrador de Redes. División ZETI Nodo Provincial Datazucar Las Tunas.
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Buen punto, deja ver eso
El 13/10/2011 09:31, Yoinier Hernandez Nieves escribió:
El 13/10/11 10:21, Jesús Rivas escribió:
Creo que cambiando el puerto ssh no es una solucion, pues te dan un port scan y dan con los puertos abiertos y empiezan el ataque, si no es asi, pues no tengo problemas en cambiar el puerto.
Lo que comentas de quitar el acceso a root al ssh ya lo hice, asi como limitar el numero de intentos y el tiempo para logearse.
Creo que no puedo moverle para que solo unas ip entren al servidor por ssh ya que tengo ip dinamicas para entrar al servidor, aunque si se puede agradeceria la aportacion.
El 12/10/2011 09:01, César CRUZ ARRUNATEGUI escribió:
cambia el puerto de ssh
César D. Cruz Arrunátegui
----- Mensaje original ----- De: "Jesús Rivas"jesus@evangelizacion.org.mx Para: centos-es@centos.org Enviados: Martes, 11 de Octubre 2011 10:53:18 GMT -05:00 Colombia Asunto: [CentOS-es] Intento de Hackeo
Hola gente, tenemos un servidor con centos 5 y en el log secure veo intentos de acceso por ssh muy seguramente un script (checando la IP google dice que es alguien de beijing).
Primero agregue la ip a hosts.deny pero luego me di cuenta que la ip cambio y siguio cambiando, entonces no veo el caso de estar agregando las ip al hosts.deny
Luego cerre el acceso por ssh a root que bueno gloogeando me tope que es una buena practica de seguridad, asi como tambien limitar el numero de intentos el tiempo para poner la contraseña y ahi de ratos veo en el log intentos de acceso por ahi, pero pues por ahi ya no podra entrar.
¿Alguna otra recomendacio que me puedan dar para evitar esto? _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
cuando te refieres a IP dinamicas, tu ISP no te da cualquier IP, sino algun IP de los bloques que le fueron asignados, lo que puedes hacer es averiguar los rangos IP de tu proveedor, y solo permites esos IP, con eso limitas bastante las IP que puedan acceder a tu SSH.
Yo.
O mejor cierra todos los puertos y usa una VPN.
-----Mensaje original----- De: centos-es-bounces@centos.org [mailto:centos-es-bounces@centos.org] En nombre de Yoinier Hernandez Nieves Enviado el: jueves, 13 de octubre de 2011 09:31 a.m. Para: centos-es@centos.org; jesus@evangelizacion.org.mx Asunto: Re: [CentOS-es] Intento de Hackeo
El 13/10/11 10:21, Jesús Rivas escribió:
Creo que cambiando el puerto ssh no es una solucion, pues te dan un port scan y dan con los puertos abiertos y empiezan el ataque, si no es asi, pues no tengo problemas en cambiar el puerto.
Lo que comentas de quitar el acceso a root al ssh ya lo hice, asi como limitar el numero de intentos y el tiempo para logearse.
Creo que no puedo moverle para que solo unas ip entren al servidor por ssh ya que tengo ip dinamicas para entrar al servidor, aunque si se puede agradeceria la aportacion.
El 12/10/2011 09:01, César CRUZ ARRUNATEGUI escribió:
cambia el puerto de ssh
César D. Cruz Arrunátegui
----- Mensaje original ----- De: "Jesús Rivas"jesus@evangelizacion.org.mx Para: centos-es@centos.org Enviados: Martes, 11 de Octubre 2011 10:53:18 GMT -05:00 Colombia Asunto: [CentOS-es] Intento de Hackeo
Hola gente, tenemos un servidor con centos 5 y en el log secure veo intentos de acceso por ssh muy seguramente un script (checando la IP google dice que es alguien de beijing).
Primero agregue la ip a hosts.deny pero luego me di cuenta que la ip cambio y siguio cambiando, entonces no veo el caso de estar agregando las ip al hosts.deny
Luego cerre el acceso por ssh a root que bueno gloogeando me tope que es una buena practica de seguridad, asi como tambien limitar el numero de intentos el tiempo para poner la contraseña y ahi de ratos veo en el log intentos de acceso por ahi, pero pues por ahi ya no podra
entrar.
¿Alguna otra recomendacio que me puedan dar para evitar esto? _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
cuando te refieres a IP dinamicas, tu ISP no te da cualquier IP, sino algun IP de los bloques que le fueron asignados, lo que puedes hacer es averiguar los rangos IP de tu proveedor, y solo permites esos IP, con eso limitas bastante las IP que puedan acceder a tu SSH.
Yo. -- Yoinier Hernández Nieves. Administrador de Redes. División ZETI Nodo Provincial Datazucar Las Tunas.
_______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Saludos.
Para proteger el SSH hay muchas recomendaciones distintas y cada persona generalmente da la que mejor le ha funcionado (yo daré la mía también).
Huelga decir que los ataques de diccionario (fuerza bruta), no suelen ser muy eficientes y el mayor daño que causan radica en el ancho de banda y los recursos que consumen. Si se tiene una buena clave y el acceso es solo de tipo administrativo (entra solamente el administrador), la posibilidad de que den con la clave de acceso es remota.
Algo un poco distinto ocurre cuando tenemos usuarios normales entrado por SSH donde la clave muchas veces se vuelve 123456 (asignada incluso por el mismo administrador). Aquí, un ataque de diccionario se empieza a tornar peligroso (entre más peces tenga el lago, más probable es pescar uno).
Con estos dos ambientes (SSH de acceso administrativo y SSH para acceso remoto de usuarios), lo que yo recomendaría es lo siguiente:
-------------------------------------------- SSH de acceso administrativo -------------------------------------------- Condiciones: (a) Solo se accede por SSH al servidor para administrarlo y no hay usuarios normales con acceso por SSH. (b) Existe un usuario sin privilegios en el sistema (p. ej. jesusadmin) que usa el administrador para acceder remotamente . (c) El login del usuario administrativo no aparece en ninguno de los diccionarios de nombres de usuario que se bajan de Internet (vaya cerrando desde aquí la ventana de exposición).
Acciones: 1) crear los grupos usesu y usessh
2) Se hacen miembros del grupo usesu al usuario root y al usuario administrativo.
3) Se hace miembro del grupo usessh al usuario administrativo.
2) Limitar el uso del comando su: únicamente al usuario de acceso administrativo (p. ej. jesusadmin) y root puede hacer su. Esto se hace editando /etc/pam.d/su y poniendo:
auth required pam_wheel.so group=usesu
3) Se activan/cambian las siguientes opciones del servicio SSH para configurar el ingreso por llave DSA: Protocol 2 # importante la version 1 se considera insegura LoginGraceTime 20s #se reduce el tiempo de espera. Malo cuando el canal de acceso no es bueno y toca aumentar el tiempo PermitRootLogin no # no puede iniciar sesión el root StrictModes yes MaxAuthTries 3 # solo puede probar 3 veces RSAAuthentication no # autenticación por llave RSA (insegura) se desactiva PubkeyAuthentication yes # aquí esta la magia PasswordAuthentication no # aquí se acaba con la efectividad de los ataques de diccionario, aunque no se limita el consumo de recursos GSSAPIAuthentication no # si no se usa se apaga AllowGroups usessh # solo se permite el acceso a los miembros del grupo del sistema usessh
4) Crear una llave pública y privada para SSH del tipo DSA con el comando ssh-keygen -t dsa.
5) La llave publica se deja en la cuenta del usuario administrador en ~/.ssh/authorized_keys. El directorio ~/.ssh debe tener permisos 700 y el archivo authorized_keys permisos 400 y pertenecer al usuario y grupo del usuario administrativo. Se protege el archivo de manipulación y modificación con el comando chattr +i authorized_keys
6) La llave privada se conserva protegida con un passphrase y no debe estar en ningún servidor. Solamente debe estar en el equipo desde el cual accedemos o en una memoria USB. SIEMPRE debe estar protegida con un passphrase. La llave privada es 'lo que tenemos' y el passphrase 'lo que sabemos' en la parte de la autenticación para poder autenticarnos en el servidor. Ya no se pide clave para ingresar.
7) Protegerse del scan de puertos y del consumo de recursos del ataque de diccionario de SSH habilitando el Port knocking para SSH.
Si el port knocking no es posible, activar fail2ban. No detiene el ataque de diccionario pero limita enormemente su efectividad. Si se está realmente paranoico: fail2ban + cambio de puerto para el servicio SSH.
El cambio de puerto no lo recomiendo, prefiero el port knocking que hace algo parecido, pero también funciona. La seguridad a través de la oscuridad funciona (¿acaso ustedes ven a los ladrones con un cartel grande que dice "soy ladrón"?. Ellos usan la (in)seguridad a través de la oscuridad para hacer sus fechorías, así que tampoco deberíamos andar diciendo en Internet "Mi servidor tiene SSH, por favor atáquenme").
OPCIONAL: - Dado que ya no se usan claves en SSH cada uno decide si permite el acceso a root por SSH o no. Si lo quiere hacer, realizar las siguientes acciones:
I) Se hace miembro del grupo usessh al usuario root. II) Se cambia la opción "PermitRootLogin no" del servicio de SSH a "PermitRootLogin without-password" III) Se ejecuta el paso 5 para el usuario root.
-------------------------------------------- SSH con acceso a usuarios -------------------------------------------- Condiciones: (a) Se accede por SSH al servidor para administrarlo y también hay usuarios normales con acceso por SSH. (b) Existe un usuario sin privilegios en el sistema (p. ej. jesusadmin) que usa el administrador para acceder remotamente . (c) El login del usuario administrativo no aparece en ninguno de los diccionarios de nombres de usuario que se bajan de Internet (vaya cerrando desde aquí la ventana de exposición).
Acciones:
1) crear los grupos usesu y usessh
2) Se hacen miembros del grupo su al usuario root y al usuario administrativo.
3) Se hace miembro del grupo usessh al usuario administrativo y a todos los usuarios que ingresen por SSH al servidor.
2) Limitar el uso del comando su: únicamente al usuario de acceso administrativo (p. ej. jesusadmin) y root puede hacer su. Esto se hace editando /etc/pam.d/su y poniendo:
auth required pam_wheel.so group=usesu
Opcional: usar también sudo y asegurarlo.
3) Se activan/cambia las siguientes opciones del servicio SSH para configurar el ingreso por llave DSA: Protocol 2 # importante LoginGraceTime 30s #se reduce el tiempo de espera PermitRootLogin no # no puede iniciar sesión el root StrictModes yes MaxAuthTries 3 # solo puede probar 3 veces RSAAuthentication no # autenticación por llave RSA (insegura) se desactiva PubkeyAuthentication yes # aquí esta la magia PasswordAuthentication yes # no hay de otra a menos que abramos un curso de autenticación por llave para SSH en la empresa GSSAPIAuthentication no # si no se usa se apaga AllowGroups usessh # solo se permite el acceso a los miembros del grupo del sistema usessh
4) Activar y configurar fail2ban
5) Implementar una política de claves que obligue al cambio periódico de las mismas cada 3 meses o menos, que verifique que tengan una longitud mínima de 8 ó más caracteres y se verifiquen contra un diccionario de frases regionalizado.
OPCIONAL: - activar el acceso por llave para el usuario administrativo y para el root.
PARANOIA TOTAL: - habilite el port knocking y enséñele a los usuarios a usarlo o cree scripts de acceso en Windows, Linux y MAC para que los usuarios puedan acceder (esto va para muy bien para aquellos que tienen alma de pedagogos).
PARANOIA ABSOLUTA: - Todos los usuarios usan port knocking y se autentican con llave
MIS RESPETOS Y ADMIRACIÓN (por favor de ser posible, envíeme el procedimiento de configuración): - Use kerberos contra un AD para autenticar los usuarios, con una divertida política de claves y fail2ban.
Hasta la próxima: Carlos A. Martínez
2011/10/13 Jesús Rivas jesus@evangelizacion.org.mx
Creo que cambiando el puerto ssh no es una solucion, pues te dan un port scan y dan con los puertos abiertos y empiezan el ataque, si no es asi, pues no tengo problemas en cambiar el puerto.
Lo que comentas de quitar el acceso a root al ssh ya lo hice, asi como limitar el numero de intentos y el tiempo para logearse.
Creo que no puedo moverle para que solo unas ip entren al servidor por ssh ya que tengo ip dinamicas para entrar al servidor, aunque si se puede agradeceria la aportacion.
El 12/10/2011 09:01, César CRUZ ARRUNATEGUI escribió:
cambia el puerto de ssh
César D. Cruz Arrunátegui
----- Mensaje original ----- De: "Jesús Rivas"jesus@evangelizacion.org.mx Para: centos-es@centos.org Enviados: Martes, 11 de Octubre 2011 10:53:18 GMT -05:00 Colombia Asunto: [CentOS-es] Intento de Hackeo
Hola gente, tenemos un servidor con centos 5 y en el log secure veo intentos de acceso por ssh muy seguramente un script (checando la IP google dice que es alguien de beijing).
Primero agregue la ip a hosts.deny pero luego me di cuenta que la ip cambio y siguio cambiando, entonces no veo el caso de estar agregando las ip al hosts.deny
Luego cerre el acceso por ssh a root que bueno gloogeando me tope que es una buena practica de seguridad, asi como tambien limitar el numero de intentos el tiempo para poner la contraseña y ahi de ratos veo en el log intentos de acceso por ahi, pero pues por ahi ya no podra entrar.
¿Alguna otra recomendacio que me puedan dar para evitar esto? _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
-- Saludos!!!
Jesus Alonso Rivas Sistemas
Evangelización Activa Comunicación Digital al Servicio del Evangelio www.evangelizacion.org.mx
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Otra buena opción es solo habilitar el acceso a través de una llave publica Mensaje enviado desde mi terminal BlackBerry® de Claro
-----Original Message----- From: Carlos Martinez camarti@gmail.com Sender: centos-es-bounces@centos.org Date: Thu, 13 Oct 2011 10:47:50 To: centos-es@centos.org; jesus@evangelizacion.org.mx Reply-To: centos-es@centos.org Subject: Re: [CentOS-es] Intento de Hackeo
Saludos.
Para proteger el SSH hay muchas recomendaciones distintas y cada persona generalmente da la que mejor le ha funcionado (yo daré la mía también).
Huelga decir que los ataques de diccionario (fuerza bruta), no suelen ser muy eficientes y el mayor daño que causan radica en el ancho de banda y los recursos que consumen. Si se tiene una buena clave y el acceso es solo de tipo administrativo (entra solamente el administrador), la posibilidad de que den con la clave de acceso es remota.
Algo un poco distinto ocurre cuando tenemos usuarios normales entrado por SSH donde la clave muchas veces se vuelve 123456 (asignada incluso por el mismo administrador). Aquí, un ataque de diccionario se empieza a tornar peligroso (entre más peces tenga el lago, más probable es pescar uno).
Con estos dos ambientes (SSH de acceso administrativo y SSH para acceso remoto de usuarios), lo que yo recomendaría es lo siguiente:
-------------------------------------------- SSH de acceso administrativo -------------------------------------------- Condiciones: (a) Solo se accede por SSH al servidor para administrarlo y no hay usuarios normales con acceso por SSH. (b) Existe un usuario sin privilegios en el sistema (p. ej. jesusadmin) que usa el administrador para acceder remotamente . (c) El login del usuario administrativo no aparece en ninguno de los diccionarios de nombres de usuario que se bajan de Internet (vaya cerrando desde aquí la ventana de exposición).
Acciones: 1) crear los grupos usesu y usessh
2) Se hacen miembros del grupo usesu al usuario root y al usuario administrativo.
3) Se hace miembro del grupo usessh al usuario administrativo.
2) Limitar el uso del comando su: únicamente al usuario de acceso administrativo (p. ej. jesusadmin) y root puede hacer su. Esto se hace editando /etc/pam.d/su y poniendo:
auth required pam_wheel.so group=usesu
3) Se activan/cambian las siguientes opciones del servicio SSH para configurar el ingreso por llave DSA: Protocol 2 # importante la version 1 se considera insegura LoginGraceTime 20s #se reduce el tiempo de espera. Malo cuando el canal de acceso no es bueno y toca aumentar el tiempo PermitRootLogin no # no puede iniciar sesión el root StrictModes yes MaxAuthTries 3 # solo puede probar 3 veces RSAAuthentication no # autenticación por llave RSA (insegura) se desactiva PubkeyAuthentication yes # aquí esta la magia PasswordAuthentication no # aquí se acaba con la efectividad de los ataques de diccionario, aunque no se limita el consumo de recursos GSSAPIAuthentication no # si no se usa se apaga AllowGroups usessh # solo se permite el acceso a los miembros del grupo del sistema usessh
4) Crear una llave pública y privada para SSH del tipo DSA con el comando ssh-keygen -t dsa.
5) La llave publica se deja en la cuenta del usuario administrador en ~/.ssh/authorized_keys. El directorio ~/.ssh debe tener permisos 700 y el archivo authorized_keys permisos 400 y pertenecer al usuario y grupo del usuario administrativo. Se protege el archivo de manipulación y modificación con el comando chattr +i authorized_keys
6) La llave privada se conserva protegida con un passphrase y no debe estar en ningún servidor. Solamente debe estar en el equipo desde el cual accedemos o en una memoria USB. SIEMPRE debe estar protegida con un passphrase. La llave privada es 'lo que tenemos' y el passphrase 'lo que sabemos' en la parte de la autenticación para poder autenticarnos en el servidor. Ya no se pide clave para ingresar.
7) Protegerse del scan de puertos y del consumo de recursos del ataque de diccionario de SSH habilitando el Port knocking para SSH.
Si el port knocking no es posible, activar fail2ban. No detiene el ataque de diccionario pero limita enormemente su efectividad. Si se está realmente paranoico: fail2ban + cambio de puerto para el servicio SSH.
El cambio de puerto no lo recomiendo, prefiero el port knocking que hace algo parecido, pero también funciona. La seguridad a través de la oscuridad funciona (¿acaso ustedes ven a los ladrones con un cartel grande que dice "soy ladrón"?. Ellos usan la (in)seguridad a través de la oscuridad para hacer sus fechorías, así que tampoco deberíamos andar diciendo en Internet "Mi servidor tiene SSH, por favor atáquenme").
OPCIONAL: - Dado que ya no se usan claves en SSH cada uno decide si permite el acceso a root por SSH o no. Si lo quiere hacer, realizar las siguientes acciones:
I) Se hace miembro del grupo usessh al usuario root. II) Se cambia la opción "PermitRootLogin no" del servicio de SSH a "PermitRootLogin without-password" III) Se ejecuta el paso 5 para el usuario root.
-------------------------------------------- SSH con acceso a usuarios -------------------------------------------- Condiciones: (a) Se accede por SSH al servidor para administrarlo y también hay usuarios normales con acceso por SSH. (b) Existe un usuario sin privilegios en el sistema (p. ej. jesusadmin) que usa el administrador para acceder remotamente . (c) El login del usuario administrativo no aparece en ninguno de los diccionarios de nombres de usuario que se bajan de Internet (vaya cerrando desde aquí la ventana de exposición).
Acciones:
1) crear los grupos usesu y usessh
2) Se hacen miembros del grupo su al usuario root y al usuario administrativo.
3) Se hace miembro del grupo usessh al usuario administrativo y a todos los usuarios que ingresen por SSH al servidor.
2) Limitar el uso del comando su: únicamente al usuario de acceso administrativo (p. ej. jesusadmin) y root puede hacer su. Esto se hace editando /etc/pam.d/su y poniendo:
auth required pam_wheel.so group=usesu
Opcional: usar también sudo y asegurarlo.
3) Se activan/cambia las siguientes opciones del servicio SSH para configurar el ingreso por llave DSA: Protocol 2 # importante LoginGraceTime 30s #se reduce el tiempo de espera PermitRootLogin no # no puede iniciar sesión el root StrictModes yes MaxAuthTries 3 # solo puede probar 3 veces RSAAuthentication no # autenticación por llave RSA (insegura) se desactiva PubkeyAuthentication yes # aquí esta la magia PasswordAuthentication yes # no hay de otra a menos que abramos un curso de autenticación por llave para SSH en la empresa GSSAPIAuthentication no # si no se usa se apaga AllowGroups usessh # solo se permite el acceso a los miembros del grupo del sistema usessh
4) Activar y configurar fail2ban
5) Implementar una política de claves que obligue al cambio periódico de las mismas cada 3 meses o menos, que verifique que tengan una longitud mínima de 8 ó más caracteres y se verifiquen contra un diccionario de frases regionalizado.
OPCIONAL: - activar el acceso por llave para el usuario administrativo y para el root.
PARANOIA TOTAL: - habilite el port knocking y enséñele a los usuarios a usarlo o cree scripts de acceso en Windows, Linux y MAC para que los usuarios puedan acceder (esto va para muy bien para aquellos que tienen alma de pedagogos).
PARANOIA ABSOLUTA: - Todos los usuarios usan port knocking y se autentican con llave
MIS RESPETOS Y ADMIRACIÓN (por favor de ser posible, envíeme el procedimiento de configuración): - Use kerberos contra un AD para autenticar los usuarios, con una divertida política de claves y fail2ban.
Hasta la próxima: Carlos A. Martínez
2011/10/13 Jesús Rivas jesus@evangelizacion.org.mx
Creo que cambiando el puerto ssh no es una solucion, pues te dan un port scan y dan con los puertos abiertos y empiezan el ataque, si no es asi, pues no tengo problemas en cambiar el puerto.
Lo que comentas de quitar el acceso a root al ssh ya lo hice, asi como limitar el numero de intentos y el tiempo para logearse.
Creo que no puedo moverle para que solo unas ip entren al servidor por ssh ya que tengo ip dinamicas para entrar al servidor, aunque si se puede agradeceria la aportacion.
El 12/10/2011 09:01, César CRUZ ARRUNATEGUI escribió:
cambia el puerto de ssh
César D. Cruz Arrunátegui
----- Mensaje original ----- De: "Jesús Rivas"jesus@evangelizacion.org.mx Para: centos-es@centos.org Enviados: Martes, 11 de Octubre 2011 10:53:18 GMT -05:00 Colombia Asunto: [CentOS-es] Intento de Hackeo
Hola gente, tenemos un servidor con centos 5 y en el log secure veo intentos de acceso por ssh muy seguramente un script (checando la IP google dice que es alguien de beijing).
Primero agregue la ip a hosts.deny pero luego me di cuenta que la ip cambio y siguio cambiando, entonces no veo el caso de estar agregando las ip al hosts.deny
Luego cerre el acceso por ssh a root que bueno gloogeando me tope que es una buena practica de seguridad, asi como tambien limitar el numero de intentos el tiempo para poner la contraseña y ahi de ratos veo en el log intentos de acceso por ahi, pero pues por ahi ya no podra entrar.
¿Alguna otra recomendacio que me puedan dar para evitar esto? _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
-- Saludos!!!
Jesus Alonso Rivas Sistemas
Evangelización Activa Comunicación Digital al Servicio del Evangelio www.evangelizacion.org.mx
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
_______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Muchas gracias carlos
El 13/10/2011 10:47, Carlos Martinez escribió:
Saludos.
Para proteger el SSH hay muchas recomendaciones distintas y cada persona generalmente da la que mejor le ha funcionado (yo daré la mía también).
Huelga decir que los ataques de diccionario (fuerza bruta), no suelen ser muy eficientes y el mayor daño que causan radica en el ancho de banda y los recursos que consumen. Si se tiene una buena clave y el acceso es solo de tipo administrativo (entra solamente el administrador), la posibilidad de que den con la clave de acceso es remota.
Algo un poco distinto ocurre cuando tenemos usuarios normales entrado por SSH donde la clave muchas veces se vuelve 123456 (asignada incluso por el mismo administrador). Aquí, un ataque de diccionario se empieza a tornar peligroso (entre más peces tenga el lago, más probable es pescar uno).
Con estos dos ambientes (SSH de acceso administrativo y SSH para acceso remoto de usuarios), lo que yo recomendaría es lo siguiente:
SSH de acceso administrativo
Condiciones: (a) Solo se accede por SSH al servidor para administrarlo y no hay usuarios normales con acceso por SSH. (b) Existe un usuario sin privilegios en el sistema (p. ej. jesusadmin) que usa el administrador para acceder remotamente . (c) El login del usuario administrativo no aparece en ninguno de los diccionarios de nombres de usuario que se bajan de Internet (vaya cerrando desde aquí la ventana de exposición).
Acciones:
crear los grupos usesu y usessh
Se hacen miembros del grupo usesu al usuario root y al usuario
administrativo.
Se hace miembro del grupo usessh al usuario administrativo.
Limitar el uso del comando su: únicamente al usuario de acceso
administrativo (p. ej. jesusadmin) y root puede hacer su. Esto se hace editando /etc/pam.d/su y poniendo:
auth required pam_wheel.so group=usesu
- Se activan/cambian las siguientes opciones del servicio SSH para
configurar el ingreso por llave DSA: Protocol 2 # importante la version 1 se considera insegura LoginGraceTime 20s #se reduce el tiempo de espera. Malo cuando el canal de acceso no es bueno y toca aumentar el tiempo PermitRootLogin no # no puede iniciar sesión el root StrictModes yes MaxAuthTries 3 # solo puede probar 3 veces RSAAuthentication no # autenticación por llave RSA (insegura) se desactiva PubkeyAuthentication yes # aquí esta la magia PasswordAuthentication no # aquí se acaba con la efectividad de los ataques de diccionario, aunque no se limita el consumo de recursos GSSAPIAuthentication no # si no se usa se apaga AllowGroups usessh # solo se permite el acceso a los miembros del grupo del sistema usessh
- Crear una llave pública y privada para SSH del tipo DSA con el
comando ssh-keygen -t dsa.
- La llave publica se deja en la cuenta del usuario administrador en
~/.ssh/authorized_keys. El directorio ~/.ssh debe tener permisos 700 y el archivo authorized_keys permisos 400 y pertenecer al usuario y grupo del usuario administrativo. Se protege el archivo de manipulación y modificación con el comando chattr +i authorized_keys
- La llave privada se conserva protegida con un passphrase y no debe
estar en ningún servidor. Solamente debe estar en el equipo desde el cual accedemos o en una memoria USB. SIEMPRE debe estar protegida con un passphrase. La llave privada es 'lo que tenemos' y el passphrase 'lo que sabemos' en la parte de la autenticación para poder autenticarnos en el servidor. Ya no se pide clave para ingresar.
- Protegerse del scan de puertos y del consumo de recursos del ataque
de diccionario de SSH habilitando el Port knocking para SSH.
Si el port knocking no es posible, activar fail2ban. No detiene el ataque de diccionario pero limita enormemente su efectividad. Si se está realmente paranoico: fail2ban + cambio de puerto para el servicio SSH.
El cambio de puerto no lo recomiendo, prefiero el port knocking que hace algo parecido, pero también funciona. La seguridad a través de la oscuridad funciona (¿acaso ustedes ven a los ladrones con un cartel grande que dice "soy ladrón"?. Ellos usan la (in)seguridad a través de la oscuridad para hacer sus fechorías, así que tampoco deberíamos andar diciendo en Internet "Mi servidor tiene SSH, por favor atáquenme").
OPCIONAL:
- Dado que ya no se usan claves en SSH cada uno decide si permite el
acceso a root por SSH o no. Si lo quiere hacer, realizar las siguientes acciones:
I) Se hace miembro del grupo usessh al usuario root. II) Se cambia la opción "PermitRootLogin no" del servicio de SSH a"PermitRootLogin without-password" III) Se ejecuta el paso 5 para el usuario root.
SSH con acceso a usuarios
Condiciones: (a) Se accede por SSH al servidor para administrarlo y también hay usuarios normales con acceso por SSH. (b) Existe un usuario sin privilegios en el sistema (p. ej. jesusadmin) que usa el administrador para acceder remotamente . (c) El login del usuario administrativo no aparece en ninguno de los diccionarios de nombres de usuario que se bajan de Internet (vaya cerrando desde aquí la ventana de exposición).
Acciones:
crear los grupos usesu y usessh
Se hacen miembros del grupo su al usuario root y al usuario administrativo.
Se hace miembro del grupo usessh al usuario administrativo y a
todos los usuarios que ingresen por SSH al servidor.
- Limitar el uso del comando su: únicamente al usuario de acceso
administrativo (p. ej. jesusadmin) y root puede hacer su. Esto se hace editando /etc/pam.d/su y poniendo:
auth required pam_wheel.so group=usesu Opcional: usar también sudo y asegurarlo.
- Se activan/cambia las siguientes opciones del servicio SSH para
configurar el ingreso por llave DSA: Protocol 2 # importante LoginGraceTime 30s #se reduce el tiempo de espera PermitRootLogin no # no puede iniciar sesión el root StrictModes yes MaxAuthTries 3 # solo puede probar 3 veces RSAAuthentication no # autenticación por llave RSA (insegura) se desactiva PubkeyAuthentication yes # aquí esta la magia PasswordAuthentication yes # no hay de otra a menos que abramos un curso de autenticación por llave para SSH en la empresa GSSAPIAuthentication no # si no se usa se apaga AllowGroups usessh # solo se permite el acceso a los miembros del grupo del sistema usessh
Activar y configurar fail2ban
Implementar una política de claves que obligue al cambio periódico
de las mismas cada 3 meses o menos, que verifique que tengan una longitud mínima de 8 ó más caracteres y se verifiquen contra un diccionario de frases regionalizado.
OPCIONAL:
- activar el acceso por llave para el usuario administrativo y para el root.
PARANOIA TOTAL:
- habilite el port knocking y enséñele a los usuarios a usarlo o cree
scripts de acceso en Windows, Linux y MAC para que los usuarios puedan acceder (esto va para muy bien para aquellos que tienen alma de pedagogos).
PARANOIA ABSOLUTA:
- Todos los usuarios usan port knocking y se autentican con llave
MIS RESPETOS Y ADMIRACIÓN (por favor de ser posible, envíeme el procedimiento de configuración):
- Use kerberos contra un AD para autenticar los usuarios, con una
divertida política de claves y fail2ban.
Hasta la próxima: Carlos A. Martínez
2011/10/13 Jesús Rivasjesus@evangelizacion.org.mx
Creo que cambiando el puerto ssh no es una solucion, pues te dan un port scan y dan con los puertos abiertos y empiezan el ataque, si no es asi, pues no tengo problemas en cambiar el puerto.
Lo que comentas de quitar el acceso a root al ssh ya lo hice, asi como limitar el numero de intentos y el tiempo para logearse.
Creo que no puedo moverle para que solo unas ip entren al servidor por ssh ya que tengo ip dinamicas para entrar al servidor, aunque si se puede agradeceria la aportacion.
El 12/10/2011 09:01, César CRUZ ARRUNATEGUI escribió:
cambia el puerto de ssh
César D. Cruz Arrunátegui
----- Mensaje original ----- De: "Jesús Rivas"jesus@evangelizacion.org.mx Para: centos-es@centos.org Enviados: Martes, 11 de Octubre 2011 10:53:18 GMT -05:00 Colombia Asunto: [CentOS-es] Intento de Hackeo
Hola gente, tenemos un servidor con centos 5 y en el log secure veo intentos de acceso por ssh muy seguramente un script (checando la IP google dice que es alguien de beijing).
Primero agregue la ip a hosts.deny pero luego me di cuenta que la ip cambio y siguio cambiando, entonces no veo el caso de estar agregando las ip al hosts.deny
Luego cerre el acceso por ssh a root que bueno gloogeando me tope que es una buena practica de seguridad, asi como tambien limitar el numero de intentos el tiempo para poner la contraseña y ahi de ratos veo en el log intentos de acceso por ahi, pero pues por ahi ya no podra entrar.
¿Alguna otra recomendacio que me puedan dar para evitar esto? _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
-- Saludos!!!
Jesus Alonso Rivas Sistemas
Evangelización Activa Comunicación Digital al Servicio del Evangelio www.evangelizacion.org.mx
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Umm vale eso es otra cosa. Yo he utilizado https pero siempre sin certificado firmado, es decir, generandolo con openssl y demás. Imagino que tampoco hace falta que el host se llame igual, simplemente le creo un dominio virtual en apache. Yo utilizo en cuestión el default-ssl, es que ahora estamos implementandolo en una máquina virtual con ubuntu 10.04 lts pero después me toca implementarlo en un Centos 5.6 por eso lo he comentado en este foro.
Gracias por tu ayuda, de verdad.
On Tue, 11 Oct 2011 15:22:35 +0100, victor santana wrote:
- ¿Que mensaje de
error da el apache?
- Los certificados deben ir en el fichero de
configuración del dominio en
cuestión, es decir si has pedido el
certificado generado para
www.dominioA.com [13] no puedes ponerlo en
el fichero apache de configuración de
www.dominioB.com [14]
El 11 de octubre de 2011 15:03, Maykel Franco Hernández <
maykel@maykel.sytes.net [15]> escribió:
Gracias por contestar. Lo
he hecho así y nada. Da error el apache. Una cosa, se tiene que llamar el nombre de la máquina igual que el nombre con el que se pide el certificado?? Una pregunta, con esos certificados generados que me han pasado el .key y el .crt en teoría ya firmados y demás...Tengo que hacer algo aparte de compartirlos para apache?? tengo que realizar alguna modificacióin con openssl...Ya nosé que más buscar. On Tue, 11 Oct 2011 13:45:17 +0100, victor santana wrote:
Aquí te van las lineas a
añadir de ejemplo para tu fichero de
configuración
del host.
ServerName dominio.com ServerAlias
www.dominio.com [2][3]
DocumentR
der-left:#10
d; margin-left:5px;
width:100%">CustomLog /var/www/vhosts/dominio.com/logs/access_ssl_log combined Al
ll Options +FollowSymLinks AddDefaultCharset ISO-8859-1
www.dominio.com.crt[4]SSLCertificateKeyFile /etc/httpd/conf/ssl.key/dominio.com.key uote> de octubre de 2011 13:36, Maykel F
cute;ndez escribió: Hola muy buenas, actualmente estoy
trabajando con Centos 5 server y estoy tratando de instalar unos certificados que me ha generado piensasolutions. He habilitado el https y demás y funciona pero el tema es que me
vos u
openssl o
teóricamente ya está todo generado y lo único que tengo que cambiar es esto en el archivo default-ssl SSLCertificateFile /etc/httpd/conf/ssl.crt/example.com.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/example.com.key He utiliz
CentOS-es mailing list CentOS-es@centos.org [1] [1]
s">http://lists.centos.org/mailman/listinfo/centos-es%5B2] -- _______________________ REPARACIONONLINE GARANTIA PARA SU PC ******************************** _______________________________________________ CentOS-es mailing list CentOS-es@centos.org [4] [6] http://lists.centos.org/mailman/listinfo/centos-es [5] [7] Links: ------ [1] mailto:CentOS-es@centos.org [6] [2] http://lists.centos.org/mailman/listinfo/centos-es [7] [3] http://www.dominio.com [8] [4] http://www.dominio.com.crt [9] [5] mailto:maykel@maykel.sytes.net [10] [6] mailto:CentOS-es@cento
st
s _______________________________________________ CentOS-es
mailing list CentOS-es@centos.org [11] http://lists.centos.org/mailman/listinfo/centos-es [12]
--
_______________________ REPARACIONONLINE GARANTIA PARA SU PC ******************************** _______________________________________________ CentOS-es mailing list CentOS-es@centos.org [16] http://lists.centos.org/mailman/listinfo/centos-es [17]
Links: ------ [1] mailto:CentOS-es@centos.org [2] http://www.dominio.com [3] mailto:maykel@maykel.sytes.net [4] mailto:CentOS-es@centos.org [5] http://lists.centos.org/mailman/listinfo/centos-es [6] mailto:CentOS-es@centos.org [7] http://lists.centos.org/mailman/listinfo/centos-es [8] http://www.dominio.com [9] http://www.dominio.com.crt [10] mailto:maykel@maykel.sytes.net [11] mailto:CentOS-es@centos.org [12] http://lists.centos.org/mailman/listinfo/centos-es [13] http://www.dominioA.com [14] http://www.dominioB.com [15] mailto:maykel@maykel.sytes.net [16] mailto:CentOS-es@centos.org [17] http://lists.centos.org/mailman/listinfo/centos-es
El nombre del dominio del certificado tiene que coincidir con el del dominio de la web. Algunas organizaciones lo que hacen es tener su propia CA, consiguen el certificado firmado por una CA y con ese certficado firman los certificados de sus subdominios.
Saludos,
Miguel
________________________________ De: victor santana reparaciononline@gmail.com Para: centos-es@centos.org Enviado: martes 11 de octubre de 2011 16:22 Asunto: Re: [CentOS-es] Instalar certificado firmado en apache
- ¿Que mensaje de error da el apache?
- Los certificados deben ir en el fichero de configuración del dominio en cuestión, es decir si has pedido el certificado generado para www.dominioA.com no puedes ponerlo en el fichero apache de configuración de www.dominioB.com
-
El 11 de octubre de 2011 15:03, Maykel Franco Hernández < maykel@maykel.sytes.net> escribió:
Gracias por contestar. Lo he hecho así y nada. Da error el apache. Una cosa, se tiene que llamar el nombre de la máquina igual que el nombre con el que se pide el certificado??
Una pregunta, con esos certificados generados que me han pasado el .key y el .crt en teoría ya firmados y demás...Tengo que hacer algo aparte de compartirlos para apache?? tengo que realizar alguna modificacióin con openssl...Ya nosé que más buscar.
On Tue, 11 Oct 2011 13:45:17 +0100, victor santana wrote:
Aquí te van las lineas a añadir de ejemplo para tu fichero de
configuración
del host.
ServerName dominio.com ServerAlias
www.dominio.com [3]
DocumentRoot
/var/www/vhosts/dominio.com/httpdocs/
CustomLog
/var/www/vhosts/dominio.com/logs/access_ssl_log combined
ErrorLog
/var/www/vhosts/dominio.com/logs/error_ssl_log
Order allow,deny
Allow from all
AllowOverride All Options +FollowSymLinks
AddDefaultCharset ISO-8859-1
# SSL Engine Switch: SSLEngine on
SSLCertificateFile /etc/httpd/conf/ssl.crt/www.dominio.com.crt [4]
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/dominio.com.key
El 11
de octubre de 2011 13:36, Maykel Franco Hernández <
maykel@maykel.sytes.net [5]> escribió:
Hola muy buenas,
actualmente estoy trabajando con Centos 5 server y estoy tratando de instalar unos certificados que me ha generado piensasolutions. He habilitado el https y demás y funciona pero el tema es que me han pasado ya el server.crt y el server.key. La pregunta es la siguietne, tengo que hacer algo con esos archivos utilizando el openssl o teóricamente ya está todo generado y lo único que tengo que cambiar es esto en el archivo default-ssl SSLCertificateFile /etc/httpd/conf/ssl.crt/example.com.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/example.com.key He utilizado alguna vez https pero no con un certificado firmado. Un saludo. _______________________________________________ CentOS-es mailing list CentOS-es@centos.org [1] http://lists.centos.org/mailman/listinfo/centos-es [2]
--
_______________________ REPARACIONONLINE GARANTIA PARA SU PC
_______________________________________________ CentOS-es mailing list CentOS-es@centos.org [6] http://lists.centos.org/mailman/listinfo/centos-es [7]
Links:
[1] mailto:CentOS-es@centos.org [2] http://lists.centos.org/mailman/listinfo/centos-es [3] http://www.dominio.com [4] http://www.dominio.com.crt [5] mailto:maykel@maykel.sytes.net [6] mailto:CentOS-es@centos.org [7] http://lists.centos.org/mailman/listinfo/centos-es _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Gracias a todos por vuestra ayuda. Me voy a crear un dominio virtual https y comento resultados.
Un saludo.
On Wed, 12 Oct 2011 08:34:19 +0100 (BST), Miguel Gonzalez wrote:
El nombre del dominio
del certificado tiene que coincidir con el del dominio de la web. Algunas organizaciones lo que hacen es tener su propia CA, consiguen el certificado firmado por una CA y con ese certficado firman los certificados de sus subdominios.
Saludos,
Miguel
________________________________
De: victor santana Para:
centos-es@centos.org [14]
Enviado: martes 11 de octubre de 2011
16:22
Asunto: Re: [CentOS-es] Instalar certificado firmado en apache
¿Que mensaje de error da el apache?
Los certificados deben
ir en el fichero de configuración del dominio en
cuestión, es decir si
has pedido el certificado generado para
www.dominioA.com [15] no
puedes ponerlo en el fichero apache de configuración de
www.dominioB.com [16]
El 11 de octubre de 2011 15:03, Maykel
Franco Hernández <
maykel@maykel.sytes.net [17]> escribió:
Gracias por contestar. Lo he hecho así y nada. Da error el apache. Una cosa, se tiene que llamar el nombre de la máquina igual que el nombre con el que se pide el certificado?? Una pregunta, con esos certificados generados que me han pasado el .key y el .crt en teoría ya firmados y demás...Tengo que hacer algo aparte de compartirlos para apache?? tengo que realizar alguna modificacióin con openssl...Ya nosé que más buscar. On Tue, 11 Oct 2011 13:45:17 +0100, victor santana wrote:
Aquí
te van las lineas a añadir de ejemplo para tu fichero de
configuración
del host. ServerName dominio.com ServerAlias
www.dominio.com [2][3] DocumentR
der-left:#10
d;
margin-left:5px; width:100%">CustomLog /var/www/vhosts/dominio.com/logs/access_ssl_log combined Al
ll
Options +FollowSymLinks AddDefaultCharset ISO-8859-1 www.dominio.com.crt[4]SSLCertificateKeyFile /etc/httpd/conf/ssl.key/dominio.com.key uote> de octubre de 2011 13:36, Maykel F
cute;ndez escribió: Hola muy buenas, actualmente estoy
trabajando con Centos 5 server y estoy tratando de instalar unos certificados que me ha generado piensasolutions. He habilitado el https y demás y funciona pero el tema es que me
vos u
openssl o
teóricamente ya está todo generado y lo único que tengo que cambiar es esto en el archivo default-ssl SSLCertificateFile /etc/httpd/conf/ssl.crt/example.com.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/example.com.key He utiliz
CentOS-es mailing list CentOS-es@centos.org [1] [1]
s">http://lists.centos.org/mailman/listinfo/centos-es%5B2] -- _______________________ REPARACIONONLINE GARANTIA PARA SU PC ******************************** _______________________________________________ CentOS-es mailing list CentOS-es@centos.org [4] [6] http://lists.centos.org/mailman/listinfo/centos-es [5] [7] Links: ------ [1] mailto:CentOS-es@centos.org [6] [2] http://lists.centos.org/mailman/listinfo/centos-es [7] [3] http://www.dominio.com [8] [4] http://www.dominio.com.crt [9] [5] mailto:maykel@maykel.sytes.net [10] [6] mailto:CentOS-es@cento
st
s _______________________________________________ CentOS-es
mailing list CentOS-es@centos.org [11] http://lists.centos.org/mailman/listinfo/centos-es [12]
--
_______________________ REPARACIONONLINE GARANTIA PARA SU PC ******************************** _______________________________________________ CentOS-es mailing list CentOS-es@centos.org [18] http://lists.centos.org/mailman/listinfo/centos-es [19] _______________________________________________ CentOS-es mailing list CentOS-es@centos.org [20] http://lists.centos.org/mailman/listinfo/centos-es [21]
Links: ------ [1] mailto:CentOS-es@centos.org [2] http://www.dominio.com [3] mailto:maykel@maykel.sytes.net [4] mailto:CentOS-es@centos.org [5] http://lists.centos.org/mailman/listinfo/centos-es [6] mailto:CentOS-es@centos.org [7] http://lists.centos.org/mailman/listinfo/centos-es [8] http://www.dominio.com [9] http://www.dominio.com.crt [10] mailto:maykel@maykel.sytes.net [11] mailto:CentOS-es@centos.org [12] http://lists.centos.org/mailman/listinfo/centos-es [13] mailto:reparaciononline@gmail.com [14] mailto:centos-es@centos.org [15] http://www.dominioA.com [16] http://www.dominioB.com [17] mailto:maykel@maykel.sytes.net [18] mailto:CentOS-es@centos.org [19] http://lists.centos.org/mailman/listinfo/centos-es [20] mailto:CentOS-es@centos.org [21] http://lists.centos.org/mailman/listinfo/centos-es
He generado un dominio virtual https para el apache y he configurado la ruta de los certificados y demás. Ahora no suelta el error pero si pincho en el favicon me aparece esto:
Propietario: Este sitio web no proporciona información sobre su dueño.
Verificado por: No especificado
Luego si pincho en ver certificado, ya me aparece para quien ha sido emitido, quien lo ha emitido...etc, etc. Estaría bien así?? Porque me dice que eso del propietario y lo de verificado??
Gracias un saludo.
On Thu, 13 Oct 2011 08:55:17 +0200, Maykel Franco Hernández wrote:
Gracias a todos por vuestra ayuda. Me voy a crear
un dominio
virtual https y comento resultados.
Un saludo.
On Wed, 12 Oct 2011
08:34:19 +0100 (BST), Miguel Gonzalez wrote:
El nombre del dominio
del certificado tiene que coincidir con el
del dominio de la web.
Algunas organizaciones lo que hacen es tener su
propia CA, consiguen el
certificado firmado por una CA y con ese
certficado firman los
certificados de sus subdominios.
Saludos,
Miguel
certificado firmado en
apache
quote type="cite" style="padding-left:5px; border-left:#1010ff
2px solid; margin-left:5px; width:100%">- ¿Que mensaje de error da el apache
lid; margin-left:5px; width:100%">cuestión, es decir si
has pedido el certificado generado> width:100%">www.dominioA.com
[1] [
quote>
puedes ponerlo en el fichero apache de
configuración de
www.dominioB
eft:5px; border-left:#1010ff
2px solid; margin-left:5px; width:100%">maykel@maykel.sytes.net [5][17]> escribió:
Graci> de la máquina igual que el nombre con el que se
pide
o?? Una pregunta, con esos certificados generados que me han
pasado el .key y el .crt en teoría ya firmados y demás...Tengo que hacer algo aparte de compartirlos para apache?? tengo que realizar
7
+0100, victor santana wrote:
lid; margin-left:5px; width:100%"> te van
las lineas a añadir de ejempl
hero deconfiguración del host.
ServerName dominio.com ServerAlias www.dominio.com [6][2][3] DocumentR der-left:#10 d;
margin-left:5px; width:100%">CustomLog
/var/www/vhosts/dom> #1010ff 2px solid; margin-left:5px; width:100%">
ll
Options +FollowSymLinks AddDefaultCharset
ISO-8859-1
o.com.crt[4]SSLCertificateKeyFile">www.dominio.com.crt[4]SSLCertificateKeyFile/etc/httpd/conf/ssl.key/dominio.com.key uote> de octubre de 2011 13:36, Maykel F cute;ndez escribió: Hola muy buenas, actualmente estoy
trabajando con Centos 5 server y estoy
tratando de instalar unos
certificados que me ha generado
piensasolutions. He habilitado el https
y demás y funciona pero el
tema es que me
t:5px; width:100%"> vos u openssl o
teóricamente
ya está todo generado y lo único que tengo que cambiar es
esto en el
archivo default-ssl SSLCertificateFile
/etc/htt>>
le="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%"> ______
CentOS-es mailing list CentOS-es@centos.org
[7][1] [1]s">http://lists.centos.org/mailman/listinfo/centos-es%5B2] [8] --
_______________________ REPARACIONONLINE GARANTIA PARA SU PC
********************************
___________> centos.org [4] [6]
http://lists.centos.org/mailman/listinfo/centos-es [2] [5] [7] Links: ------ [1] mailto:
centos.org">CentOS-es@centos.org [6] [2]
http://lists.centos.org/mailman/listinfo/centos-es [9] [7] [3] http://www.dominio.com [10] [8] [4] http://www.dominio.com.crt [11] [9] [5] mailto:maykel@maykel.sytes.net [12][10] [6] mailto:CentOS-es@centost
s _______________________________________________ CentOS-es
mailing list CentOS-es@ [11]
http://lists.centos.org/mailman/listinfo/centos-es [13][12] --
_______________________ REPARACIONONLINE GARANTIA PARA SU PC
********************************
_______________________________________________ CentOS-es mailing list
CentOS-es@centos.org [14] [2] http://www.dominio.com [15] [3] mailto:maykel@maykel.sytes.net [16] [4] mailto:CentOS-es@centos.org [17] [5] http://lists.centos.org/mailman/listinfo/centos-es [18] [6] mailto:CentOS-es@centos.org [19] [7] http://lists.centos.org/mailman/listinfo/centos-es [20] [8] http://www.dominio.com [21] [9] http://www.dominio.com.crt [22] [10] mailto:maykel@maykel.sytes.net [23] [11] mailto:CentOS-es@centos.org [24] [12] http://lists.centos.org/mailman/listinfo/centos-es [25] [13] mailto:reparaciononline@gmail.com [26] [14] mailto:centos-es@centos.org [27] [15] http://www.dominioA.com [28] [16
ytes.net">maykel@maykel.sytes.net [18] mailto:CentOS-es@centos.org [4] [19] htt
tos.org/mailman/listinfo/centos-es [20]
mailto:CentOS-es@centos.org [29] [21] http://lists.centos.org/mailman/listinfo/centos-es [30] _______________________________________________ CentOS-es mailing list CentOS-es@centos.org [31]
Links: ------ [1] http://www.dominioA.com [2] http://lists.centos.org/mailman/listinfo/centos-es [3] mailto:CentOS-es@centos.org [4] mailto:CentOS-es@centos.org [5] mailto:maykel@maykel.sytes.net [6] http://www.dominio.com [7] mailto:CentOS-es@centos.org [8] http://lists.centos.org/mailman/listinfo/centos-es%5B2] [9] http://lists.centos.org/mailman/listinfo/centos-es [10] http://www.dominio.com [11] http://www.dominio.com.crt [12] mailto:maykel@maykel.sytes.net [13] http://lists.centos.org/mailman/listinfo/centos-es [14] mailto:CentOS->tp://lists.centos.org/mailman/listinfo/centos-es[19]_______________________________________________CentOS-esmailinglistCentOS-es@centos.org[3][20] </div>ts.centos.org/mailman/listinfo/centos-es</a>[21]Links:------[1]mailto:<ahref= [15] http://www.dominio.com [16] mailto:maykel@maykel.sytes.net [17] mailto:CentOS-es@centos.org [18] http://lists.centos.org/mailman/listinfo/centos-es [19] mailto:CentOS-es@centos.org [20] http://lists.centos.org/mailman/listinfo/centos-es [21] http://www.dominio.com [22] http://www.dominio.com.crt [23] mailto:maykel@maykel.sytes.net [24] mailto:CentOS-es@centos.org [25] http://lists.centos.org/mailman/listinfo/centos-es [26] mailto:reparaciononline@gmail.com [27] mailto:centos-es@centos.org [28] http://www.dominioA.com [29] mailto:CentOS-es@centos.org [30] http://lists.centos.org/mailman/listinfo/centos-es [31] mailto:CentOS-es@centos.org
¿Puedes poner el dominio para leer la información pública del certificado?
El 13 de octubre de 2011 08:55, Maykel Franco Hernández < maykel@maykel.sytes.net> escribió:
He generado un dominio virtual https para el apache y he configurado la ruta de los certificados y demás. Ahora no suelta el error pero si pincho en el favicon me aparece esto:
Propietario: Este sitio web no proporciona información sobre su dueño.
Verificado por: No especificado
Luego si pincho en ver certificado, ya me aparece para quien ha sido emitido, quien lo ha emitido...etc, etc. Estaría bien así?? Porque me dice que eso del propietario y lo de verificado??
Gracias un saludo.
On Thu, 13 Oct 2011 08:55:17 +0200, Maykel Franco Hernández wrote:
Gracias a todos por vuestra ayuda. Me voy a crear
un dominio
virtual https y comento resultados.
Un saludo.
On Wed, 12 Oct 2011
08:34:19 +0100 (BST), Miguel Gonzalez wrote:
El nombre del dominio
del certificado tiene que coincidir con el
del dominio de la web.
Algunas organizaciones lo que hacen es tener su
propia CA, consiguen el
certificado firmado por una CA y con ese
certficado firman los
certificados de sus subdominios.
Saludos,
Miguel
certificado firmado en
apache
quote type="cite" style="padding-left:5px; border-left:#1010ff
2px solid; margin-left:5px; width:100%">- ¿Que mensaje de error da el apache
lid; margin-left:5px; width:100%">cuestión, es decir si
has pedido el certificado generado> width:100%">www.dominioA.com
[1] [
quote>
puedes ponerlo en el fichero apache de
configuración de
www.dominioB
eft:5px; border-left:#1010ff
2px solid; margin-left:5px; width:100%">maykel@maykel.sytes.net [5][17]> escribió:
Graci> de la máquina igual que el nombre con el que se
pide
o?? Una pregunta, con esos certificados generados que me han
pasado el .key y el .crt en teoría ya firmados y demás...Tengo que hacer algo aparte de compartirlos para apache?? tengo que realizar
7
+0100, victor santana wrote:
lid; margin-left:5px; width:100%"> te van
las lineas a añadir de ejempl
hero deconfiguración del host.
ServerName dominio.com ServerAlias www.dominio.com [6][2][3] DocumentR der-left:#10 d;
margin-left:5px; width:100%">CustomLog
/var/www/vhosts/dom> #1010ff 2px solid; margin-left:5px; width:100%">
ll
Options +FollowSymLinks AddDefaultCharset
ISO-8859-1
o.com.crt[4]SSLCertificateKeyFile">www.dominio.com.crt[4]SSLCertificateKeyFile/etc/httpd/conf/ssl.key/dominio.com.key uote> de octubre de 2011 13:36, Maykel F cute;ndez escribió: Hola muy buenas, actualmente estoy
trabajando con Centos 5 server y estoy
tratando de instalar unos
certificados que me ha generado
piensasolutions. He habilitado el https
y demás y funciona pero el
tema es que me
t:5px; width:100%"> vos u openssl o
teóricamente
ya está todo generado y lo único que tengo que cambiar es
esto en el
archivo default-ssl SSLCertificateFile
/etc/htt>>
le="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%"> ______
CentOS-es mailing list CentOS-es@centos.org
[7][1] [1]s">http://lists.centos.org/mailman/listinfo/centos-es%5B2] [8]
_______________________ REPARACIONONLINE GARANTIA PARA SU PC
___________> centos.org [4] [6]
http://lists.centos.org/mailman/listinfo/centos-es [2] [5] [7] Links: ------ [1] mailto:
centos.org">CentOS-es@centos.org [6] [2]
http://lists.centos.org/mailman/listinfo/centos-es [9] [7] [3] http://www.dominio.com [10] [8] [4] http://www.dominio.com.crt [11] [9] [5] mailto:maykel@maykel.sytes.net [12][10] [6] mailto:CentOS-es@centost
s _______________________________________________ CentOS-es
mailing list CentOS-es@ [11]
http://lists.centos.org/mailman/listinfo/centos-es [13][12] --
_______________________ REPARACIONONLINE GARANTIA PARA SU PC
_______________________________________________ CentOS-es mailing list
CentOS-es@centos.org [14] [2] http://www.dominio.com [15] [3] mailto:maykel@maykel.sytes.net [16] [4] mailto:CentOS-es@centos.org [17] [5] http://lists.centos.org/mailman/listinfo/centos-es [18] [6] mailto:CentOS-es@centos.org [19] [7] http://lists.centos.org/mailman/listinfo/centos-es [20] [8] http://www.dominio.com [21] [9] http://www.dominio.com.crt [22] [10] mailto:maykel@maykel.sytes.net [23] [11] mailto:CentOS-es@centos.org [24] [12] http://lists.centos.org/mailman/listinfo/centos-es [25] [13] mailto:reparaciononline@gmail.com [26] [14] mailto:centos-es@centos.org [27] [15] http://www.dominioA.com [28] [16
ytes.net">maykel@maykel.sytes.net [18] mailto:CentOS-es@centos.org [4] [19] htt
tos.org/mailman/listinfo/centos-es [20]
mailto:CentOS-es@centos.org [29] [21] http://lists.centos.org/mailman/listinfo/centos-es [30] _______________________________________________ CentOS-es mailing list CentOS-es@centos.org [31]
Links:
[1] http://www.dominioA.com [2] http://lists.centos.org/mailman/listinfo/centos-es [3] mailto:CentOS-es@centos.org [4] mailto:CentOS-es@centos.org [5] mailto:maykel@maykel.sytes.net [6] http://www.dominio.com [7] mailto:CentOS-es@centos.org [8] http://lists.centos.org/mailman/listinfo/centos-es%5B2] [9] http://lists.centos.org/mailman/listinfo/centos-es [10] http://www.dominio.com [11] http://www.dominio.com.crt [12] mailto:maykel@maykel.sytes.net [13] http://lists.centos.org/mailman/listinfo/centos-es [14] mailto:CentOS->tp:// lists.centos.org/mailman/listinfo/centos-es[19]_______________________________________________CentOS-esmailinglistCentOS-es@centos.org[3][20]
</div>ts.centos.org/mailman/listinfo/centos-es </a>[21]Links:------[1]mailto:<ahref= [15] http://www.dominio.com [16] mailto:maykel@maykel.sytes.net [17] mailto:CentOS-es@centos.org [18] http://lists.centos.org/mailman/listinfo/centos-es [19] mailto:CentOS-es@centos.org [20] http://lists.centos.org/mailman/listinfo/centos-es [21] http://www.dominio.com [22] http://www.dominio.com.crt [23] mailto:maykel@maykel.sytes.net [24] mailto:CentOS-es@centos.org [25] http://lists.centos.org/mailman/listinfo/centos-es [26] mailto:reparaciononline@gmail.com [27] mailto:centos-es@centos.org [28] http://www.dominioA.com [29] mailto:CentOS-es@centos.org [30] http://lists.centos.org/mailman/listinfo/centos-es [31] mailto:CentOS-es@centos.org _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Hola miguel, respecto a lo que has comentado de certificar nuestros propios subdominios, yo tengo un certificado de www.dominio.com y tengo otro servidro web https, quiero redireccionar el dominio por ejemplo mail.dominio.com a otro servidro web que está en otra parte. La pregunta es, podría realizar de alguna forma un certificado para mail.dominio.com?
Un saludo, gracias.
On Wed, 12 Oct 2011 08:34:19 +0100 (BST), Miguel Gonzalez wrote:
El nombre del dominio del
certificado tiene que coincidir con el del dominio de la web. Algunas organizaciones lo que hacen es tener su propia CA, consiguen el certificado firmado por una CA y con ese certficado firman los certificados de sus subdominios.
Saludos,
Miguel
________________________________
De: victor santana Para:
centos-es@centos.org [14]
Enviado: martes 11 de octubre de 2011
16:22
Asunto: Re: [CentOS-es] Instalar certificado firmado en apache
¿Que mensaje de error da el apache?
Los certificados deben
ir en el fichero de configuración del dominio en
cuestión, es decir si
has pedido el certificado generado para
www.dominioA.com [15] no
puedes ponerlo en el fichero apache de configuración de
www.dominioB.com [16]
El 11 de octubre de 2011 15:03, Maykel
Franco Hernández <
maykel@maykel.sytes.net [17]> escribió:
Gracias por contestar. Lo he hecho así y nada. Da error el apache. Una cosa, se tiene que llamar el nombre de la máquina igual que el nombre con el que se pide el certificado?? Una pregunta, con esos certificados generados que me han pasado el .key y el .crt en teoría ya firmados y demás...Tengo que hacer algo aparte de compartirlos para apache?? tengo que realizar alguna modificacióin con openssl...Ya nosé que más buscar. On Tue, 11 Oct 2011 13:45:17 +0100, victor santana wrote:
Aquí
te van las lineas a añadir de ejemplo para tu fichero de
configuración
del host. ServerName dominio.com ServerAlias
www.dominio.com [2][3] DocumentR
der-left:#10
d;
margin-left:5px; width:100%">CustomLog /var/www/vhosts/dominio.com/logs/access_ssl_log combined Al
ll
Options +FollowSymLinks AddDefaultCharset ISO-8859-1 www.dominio.com.crt[4]SSLCertificateKeyFile /etc/httpd/conf/ssl.key/dominio.com.key uote> de octubre de 2011 13:36, Maykel F
cute;ndez escribió: Hola muy buenas, actualmente estoy
trabajando con Centos 5 server y estoy tratando de instalar unos certificados que me ha generado piensasolutions. He habilitado el https y demás y funciona pero el tema es que me
vos u
openssl o
teóricamente ya está todo generado y lo único que tengo que cambiar es esto en el archivo default-ssl SSLCertificateFile /etc/httpd/conf/ssl.crt/example.com.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/example.com.key He utiliz
CentOS-es mailing list CentOS-es@centos.org [1] [1]
s">http://lists.centos.org/mailman/listinfo/centos-es%5B2] -- _______________________ REPARACIONONLINE GARANTIA PARA SU PC ******************************** _______________________________________________ CentOS-es mailing list CentOS-es@centos.org [4] [6] http://lists.centos.org/mailman/listinfo/centos-es [5] [7] Links: ------ [1] mailto:CentOS-es@centos.org [6] [2] http://lists.centos.org/mailman/listinfo/centos-es [7] [3] http://www.dominio.com [8] [4] http://www.dominio.com.crt [9] [5] mailto:maykel@maykel.sytes.net [10] [6] mailto:CentOS-es@cento
st
s _______________________________________________ CentOS-es
mailing list CentOS-es@centos.org [11] http://lists.centos.org/mailman/listinfo/centos-es [12]
--
_______________________ REPARACIONONLINE GARANTIA PARA SU PC ******************************** _______________________________________________ CentOS-es mailing list CentOS-es@centos.org [18] http://lists.centos.org/mailman/listinfo/centos-es [19] _______________________________________________ CentOS-es mailing list CentOS-es@centos.org [20] http://lists.centos.org/mailman/listinfo/centos-es [21]
Links: ------ [1] mailto:CentOS-es@centos.org [2] http://www.dominio.com [3] mailto:maykel@maykel.sytes.net [4] mailto:CentOS-es@centos.org [5] http://lists.centos.org/mailman/listinfo/centos-es [6] mailto:CentOS-es@centos.org [7] http://lists.centos.org/mailman/listinfo/centos-es [8] http://www.dominio.com [9] http://www.dominio.com.crt [10] mailto:maykel@maykel.sytes.net [11] mailto:CentOS-es@centos.org [12] http://lists.centos.org/mailman/listinfo/centos-es [13] mailto:reparaciononline@gmail.com [14] mailto:centos-es@centos.org [15] http://www.dominioA.com [16] http://www.dominioB.com [17] mailto:maykel@maykel.sytes.net [18] mailto:CentOS-es@centos.org [19] http://lists.centos.org/mailman/listinfo/centos-es [20] mailto:CentOS-es@centos.org [21] http://lists.centos.org/mailman/listinfo/centos-es
-
Anthony Mogrovejo -
Carlos Martinez -
cmartinez＠servicomecuador.com -
César CRUZ ARRUNATEGUI -
Ernesto Pérez Estévez -
Javier Aquino H. -
Jesús Rivas -
juan sabino -
Lic. Domingo Varela Yahuitl. -
Maykel Franco Hernández -
Miguel Gonzalez -
Salvador Guzman - Salman PSL -
victor santana -
Yoinier Hernandez Nieves