Durante el trabajo diario, en ocasiones, debemos realizar tareas que nos gustaría documentar como es debido.
En esta entrada vamos a ver como guardar toda una sesión de terminal Linux, de tal forma que podamos incluirla a posteriori en cualquier documentación.
El comando que vamos utilizar es:
script
Algunas veces debemos administrar aplicaciones PHP que para nuestra sorpresa han sido hackeadas, han sustituido la página de inicio, añadido código en la cabecera de la página, insertado código malicioso entre los ficheros de la aplicación (por ejemplo para enviar email spam), etc…
Dejo algunas imágenes:
Este tipo de ataques es más probable sufrirlos si nuestra aplicación es algo relativamente popular, WordPress, Joomla, Drupal, etc…
El plan de mejora de seguridad incluye los procesos:
Vamos por partes:
Cuando montamos sistemas Linux una de las reglas de oro es externalizar la configuración y los datos de la aplicación a otro volumen. Esto se puede hacer fácilmente por ejemplo montando /opt sobre otro disco y realizando las instalaciones sobre /opt.
Las instalaciones sobre otros volúmenes son sencillas siempre y cuando no recurramos al repositorio de la distribución que estemos usando, en este caso vamos a tener configuración y datos en unos cuantos sitios. En una situación así podemos hacer 2 cosas:
Esto puede parecer una trivialidad, pero he visto a mucha gente no tener nada claro como tener en una misma máquina, varios servidores de aplicaciones Java ejecutando sobre diferentes versiones.
Para comenzar por cuestiones de seguridad lo más recomendable es que por cada servidor de aplicaciones que tengamos en ejecución, el propietario de la instalación sea un usuario diferente, este mismo usuario es el que ejecuta el servidor de aplicaciones.
En resumidas cuentas, para cada usuario podemos configurar su entorno de ejecución por defecto, de tal forma que no es necesario tocar nada en los servidores de aplicaciones para indicar que Java debe usar.
Pongamos el ejemplo de que queremos ejecutar Tomcat 8, con Java 8 y Tomcat 6 con Java 1.5.
A modo de ampliación del post «Configuración firewall iptables Red Hat/CentOS 6, desde linea de comandos«, esta vez vamos a ver como asegurar las conexiones salientes de nuestro servidor.
El limitar las conexiones salientes puede parecer algo un tanto paranoico, pero en caso de un ataque tu máquina será utilizada para «saltar» a otras o enviar correos. Se que esto todavía puede sonar más paranoico todavía, pero son cosas que ocurren y son muy reales, quiero hacer un post más adelante tratando un caso real.
Vamos al lío, partimos de una situación inicial:
[root@oradb ~]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destinationVamos a realizar una instalación de Oracle 12c sobre CentOS 6 de 64 bits, la documentación oficial se puede encontrar en:
Quick Installation Guide 12c Release 1 (12.1) for Linux x86-64
Esta documentación es extensa, no demasiado clara y contiene información parcial para las instalaciones sobre RedHat 6 o CentOS 6, por tanto me he decidido a escribir esta guía.
Sólo vamos a tratar la instalación de los binarios, la creación de la base de datos ya lo trataremos en otro momento.
Para realizar la instalación cumpliendo los prerrequisitos, se ha utilizado una máquina con:
En lineas generarles, partiendo de una instalación nueva, lo que vamos a hacer es:
En ocasiones es muy útil obtener la instrucción DDL de un objeto de base de datos determinado.
Podemos por ejemplo recrear un usuario de un entorno a otro sin ni siquiera conocer la contraseña.
Las instrucciones DDL las podemos obtener llamando a la función:
DBMS_METADATA.GET_DDL (
object_type IN VARCHAR2,
name IN VARCHAR2,
schema IN VARCHAR2 DEFAULT NULL,
version IN VARCHAR2 DEFAULT 'COMPATIBLE',
model IN VARCHAR2 DEFAULT 'ORACLE',
transform IN VARCHAR2 DEFAULT 'DDL')
RETURN CLOB;Recientemente un cliente ha pedido una instalación securizada en en todo el cirtucito de información, es decir:
Usualmente lo que se hace el configurar Apache con SSL y la comunicación interna entre Apache y JBoss se realiza con el protocolo AJP, de esta forma:
El protocolo AJP tiene como ventaja frente al http, que es una comunicación binaria en lugar de texto, este reduce el ancho de banda necesario para transmitir la misma información (se estima que se reduce el ancho de banda necesario en un 25%).
Con cada versión o release de Oracle Database, se añaden nuevas funcionalidades y correcciones de bugs en el optimizador, esto en principio es bueno pero cualquier modificación de código puede incluir nuevos bugs.
Cuando actualizamos de una versión de Oracle a otra superior es posible que algunas consultas funcionen realmente mal, esto se puede solucionar con un workaround del tipo (si hemos migrado a 11gr2 desde 10.2.0.4 por ejemplo):
ALTER session SET optimizer_features_enabled='10.2.0.4';o para hacerlo permanente:
En tablas donde hay cambios constantemente como un mantenimiento más de la BD, hay que reconstruir los índices B-TREE de forma periódica, por ejemplo (la sintaxis es más compleja):
ALTER INDEX SCOTT.PK_EMP REBUILD;Un B-TREE ideal tiene todas las ramas perfectamete equilibradas, un B-TREE degradado puede ofrecer tiempos de búsqueda lineales en lugar de logarítmicos debido a un fuerte desequilibrio.
Para determinar si un índice debe ser reconstruido: