Infraestructura de clave publica II

Realmente debería de haber empezado por esta introducción pero ya que voy a comentar como configurar ahora nuestro EJBCA, entonces lo voy a denotar..

En cualquier infraestructura de clave publica, es muy importante la etapa de Diseño previa la cual se detallan las reglas de juego, como :

¿Como se llamara nuestra CA?
¿Cuantas sub-CA's va a tener?
¿Quien va  a ser el administrador?
¿A que entidad le pertenece la administración de la CA o Sub-CA's?
¿Que servicios va a ofrecer cada CA o Sub-CA?
¿Con que seguridad se va a permitir el acceso?
¿Cuanto tiempo de vida va a tener los Certificados emitidos o la propia CA?
¿Cuales van a ser los requerimientos para la emisión?
¿Que seguridad Perimetral va a contar la infraestructura?
¿Como se van o cual va a ser el procedimiento mas seguro para otorgar los certificados?
...
...etc.. etc

y algunas preguntas mas que tenemos que ir respondiendo enfocado en el negocio de la fase de producción que tendrá la infraestructura de clave publica antes incluso de la etapa de instalación en el diseño de la misma, Una implementación Correcta desde su etapa de diseño nos puede Resolver en un menor % de riesgo durante la fase de producción

Entonces vamos a empezar una vez ya instalada y dentro del Panel Administrador que lo deje en Post >> "Infraestructura de clave publica I" , creando  la CA root Inicial

(Ojo, los nombres de los paneles voy a dejarlos en ingles, aunque los pueden cambiar en la parte inferior a la izquierda en las configuraciones verán para poder modificar el lenguaje en Español o desde el Archivo que les comente en el primer post de esta serie)

Ahora con la Instalación , básica, dentro del panel de administración vamos a 
 Edit >>Certificate Authorities 
Después en en la pagina podemos  poner Cyttek Root CA como nuestro nombre de la Autoridad de certificación  y luego en el Boton "Create", Deberemos hacer los siguientes cambios :

Signing Algorithm: SHA256WithRSA
RSA key size: 4096
Description: Root CA de Cyttek Group.
Validity (*y *mo *d) or end date of the certificate: 20y
Subject DN: CN=Cyttek Root CA,O=Cyttek Group.,C=RS
Use Issuing Distribution Point on CRLs: On
Default CRL Dist. Point: http://crl.cyttek.com/rootca.crl
CRL Expire Period (*y *mo *d *h *m): 1y
CRL Overlap Time (*y *mo *d *h *m): 2d

Una vez que la información este rellenada, podemos darle al botón "Crear". una vez terminado el proceso ya veras que La CA esta dentro de la Lista de CA's Disponibles 

Una vez creada la CA root en este caso vamos a crear una Sub-CA por ejemplo o sí estamos en una instalación para alguna entidad o país deberemos delegar el Root para la entidad encargada de la administración y calcular cuantas Sub-CA's vamos a tener que implementar y quienes serán los destinatarios. en mi caso , solo voy a comentar una única instalación.

Uno de los parámetros que me gusta crear por seguridad es una Jerarquía de Sub-Ca que no sea Root, el cual ayuda para poder distinguir los permisos, y los perfiles.

En  Edit Certificate Profiles , Selecciona >>>  SUBCA (FIXED) de la lista
en la caja de texto puedes poner  "cyttek Sub-CA" , y luego lo vamos a usar como una plantilla para nuestro >>> Use selected as template . Esto creara un perfil de SubCA del perfial de SUBCA (FIXED) que anteriormente hemos seleccionado


Ahora en la nueva subCA que hemos creado seleccionamos y le damos click en el botón de >> Edit Certificate Profile . 
Vamos a ajustar algunas opciones para nuestro caso:

Available bit lengths: 4096 bits
Validity: 15y
Allow validity override: Off
CRL Distribution Points: On
Use CA defined CRL Dist. Point: On
Available CAs: Cyttek Root CA

Una vez ajustado estos prametros, le damos en el boton Save o Guardar ;)

Ok ahora vamos a la parte que mola, la creacion de la entidad de certificación la que sirve los Certificados a las entidades finales.

En >>Edit Certificate Authorities y en la caja de texto podemos escribir  "Cyttek-Bl4ckD4wn CA" (sin las comillas) y luego en el boton  Create...  .para crear la entidad de la cual deberemos ajustar algunos parametros según los necesitemos en nuestro caso serán los siguientes:

Signing Algorithm: SHA256WithRSA
RSA key size: 4096
Description: Example's CA in charge of issuing certificates for individuals within the organisation.
Validity (*y *mo *d) or end date of the certificat: 15y
Subject DN: CN=Cyttek-Bl4ckD4wn CA,O=Cyttek Group,C=RS
Signed By: Cyttek Root CA
Certificate Profile: Cyttek Sub-CA
Use Issuing Distribution Point on CRLs: On
Default CRL Dist. Point: http://crl.cyttek.com/personca.crl
CRL Expire Period (*y *mo *d *h *m): 14d
CRL Overlap Time (*y *mo *d *h *m): 12h
Default OCSP Service Locator: http://ocsp.cyttek.com/ejbca/publicweb/status/ocsp

Después de ajustar las opciones y crear la nueva CA, aparecerá en el apartado como nueva entidad de certificación disponible.

Ahora que ya tenemos quien se encargara de sacar los Certificados vamos a configurar la creación de perfiles para las entidades finales.  osea los perfiles necesario de los certificados de las entidades finales

Vamos a >>> Edit Certificate Profiles , Seleccionamos >> ENDUSER (FIXED) .
Metemos en la caja de texto el nuevo nombre que le queramos dar Cyttek-Bl4ckD4wn Signing, y lo vamos a usar como base seleccionando en el boton "Use selected as template" ahora que lo tenemos como una plantilla vamos a ajustar unos parámetros dentro del "Cyttek-Bl4ckD4wn Signing " con los siguientes ajustes:

Available bit lengths: 1024, 2048, 4096
Validity (*y *mo *d) or end date of the certificate: 1y
Key Usage: Digital Signature, Non-repudiation
Extended Key Usage: Client Authentication, Email Protection
CRL Distribution Points: On
Use CA defined CRL Dist. Point: On
Authority Information Access: On
Use CA defined OCSP locator: On
Available CAs: Cyttek-Bl4ckDwn CA

Cuando la info este modificada, Guarda en el boton "Save"  en el inferior de la pagina de configuración (Ojo con la opcion " Key encipherment " que este apagada, si no lo podrá tomar para otro uso que por el momento no nos interesa).

Ahora le vamos a meter mano al perfil de  ENDUSER (FIXED) , vamos a darle el nombre de "Cyttek-bl4ckD4wn Encriptacion" como el nuevo perfile que vamos a cargar también.. Seleciona " Use selected as template" .
Luego le damos al perfil que le hemos dado nombre anteriormente y le damos a >> Edit Certificate Profile . Para hacer los siguientes ajustes:

Available bit lengths: 1024, 2048, 4096
Validity (*y *mo *d) or end date of the certificate: 1y
Key Usage: Key encipherment, Data encipherment
Extended Key Usage: Email Protection
CRL Distribution Points: On
Use CA defined CRL Dist. Point: On
Authority Information Access: On
Use CA defined OCSP locator: On
Available CAs: Example Person CA

Para Terminar lo guardamos con el botón en la parte inferior.

Añadiremos a esta configuración un perfil mas para Servidores llamado SERVER (FIXED) el cual sera el perfil que vamos a usar como template, ok repetimos otra vez las configuraciones anteriores., Escribimos "Bl4ckD4wn Server"  como el nombre del perfil que vamos a crear y lo seleccionamos como perfil con el botón  "Use selected as template." luego repetimos el proceso anterior con la plantilla  nueva creada, y le damos al boton  "Certificate Profile" . para ejecutar algunos ajustes:

Available bit lengths: 1024, 2048, 4096
CRL Distribution Points: On
Use CA defined CRL Dist. Point: On
Authority Information Access: On
Use CA defined OCSP locator: On
Available CAs: Cyttek-Bl4ckDwn CA


Para Terminar lo guardamos con el botón en la parte inferior. y con eso tenemos concluido la configuración de los perfiles de certificados para poder emitirlos ...

Ok, ahora estamos en fase Rambo II, creando perfiles de entidades final

Bueno los perfiles de los certificados definen para que van a ser usados los certificados, pero los perfiles de entidades finales  define el contenido del certificado , esta es una parte importante para mantener la información que se requiere para emitir el certificado, para su uso ya pueda ser SSL, VPN, Email , DNIe, etc...
Ahora vamos a crear 2 perfiles uno para la organización y otro para los servidores

Vamos al  Administration >> Edit End Entity Profiles . luego dentro del campo de texto escribimos el nombre de la persona Person y la agregamos con el botón "Add".  Seleccionamos el nuevo perfil creado y le damos en " Edit End Entity Profile " para poder agregar los atributos siguientes "Subject DN Attributes":

• UID, Identificador Único     
• O, Organización
  
• C, País que en ingles es Country 

Con estos 3 Atributos agregas y modificables , tenemos que agregar un campo alternativo para Nombre  RFC 822 Name (e-mail address).

Entonces los ajustes del perfil persona seran los siguientes para nuestro caso:

E-mail Domain: cyttek.com
O, Organization: Cyttek Group.
C, Country (ISO 3166): CO
RFC 822 Name (e-mail address) Required: On
Default Certificate Profile: Cyttek-Bl4ckD4wn Signing
Available Certificate Profiles: Cyttek-Bl4ckD4wn Signing, Cyttek-Bl4ckD4wn Encryption
Default CA: Cyttek-Bl4ckD4wn CA
Available CAs: Cyttek-Bl4ckD4wn CA
Default Token: P12 file
Number of allowed requests: 2
Number of allowed requests use: On
Key Recoverable Use: On

Ok, para terminal el perfil lo guardamos como las anteriores.con el botón "Save".


Ok ahora vamos a configurar el segundo perfil de servidor. ( básicamente voy a repetir el proceso anterior para los que no lo pillen a la primera.)
Vamos atrás al panel de Administration >> Edit End Entity Profiles luego en el campo de texto agregamos el nombre " Server " y le damos al boton " Add ".
 Seleccionamos el nuevo perfil creado y le damos en " Edit End Entity Profile " para poder agregar los atributos siguientes "Subject DN Attributes":

• O, Organización    
  
• C, Pais que en ingles es Country  
  

 Tenemos que agregar un campo alternativo para Nombre  RFC 822 Name (e-mail address).

Ajustamos los campos del perfil servidor con:

Batch generation (clear text pwd storage) use: On
E-mail Domain: Cyttek.com
O, Organization: Cyttek Group.
C, Country (ISO 3166): RS
RFC 822 Name (e-mail address) Required: On
Default Certificate Profile: Bl4ckd4wn Server
Available Certificate Profiles: Bl4ckD4wnServer
Default CA: Cyttek-Bl4ckd4wn CA
Available CAs: Cyttek-Bl4ckd4w CA
Default Token: PEM file

 para terminal el perfil lo guardamos como las anteriores.con el botón "Save".

Ok ahora vamos a remplazar los valores para poder poner en producción nuestro PKI calvin klein
Vamos a remplazar los certificados del frontend por los certificados que tenemos que emitir desde nuestra CA configurada anteriormente con sus perfiles para poder autentificar al administrador.

Vamos a preparar el Certificado para el administrador de la interfaz administrativa y poder remplazarlo para la fase de producción:
Vamos a >> Administration >> Add End Entity . Selecionamos el perfil de la entidad final de Person y le metemos mano a estas configuraciones:

Username: {{admin_username}}
Password: {{admin_password}}
Confirm Password: {{admin_password}}
Email: {{admin_mail}} @ cyttek.com
CN, Common name: {{admin_name}} {{admin_surname}}
UID, Unique Identifier: {{user_id}}
O, Organization: Cyttek Group.
C, Country (ISO 3166): RS
Use data from E-mail address field: On
Certificate Profile: Example Person Signing
CA: Cyttek-Bl4ckD4wn CA
Token: P12 file
Number of allowed requests: 2
Key Recoverable: Off

Ojo, ajustar los parámetros con los valores que queráis.
Y terminamos este proceso con el botón "Add End Entity"

Ahora vamos a obtener los certificados que hemos configurado mediante la interfaz publica que se encontraba al principio . >> Public Web Seleccionamos la opcion del menu >> Create Browser Certificate  y dentro de las cajas de texto ponemos las credenciales que hemos escrito anteriormente para la entidad de administración final del Administrador.( Ten en cuenta que el perfil que tenemos que seleccionar para esta descarga debe de ser Cyttek-Bl4ckd4wn Signing ), y luego lle damos al "OK".

Ok ya tenemos el "Famoso" .p12 para poder importarlo en nuestro Firefox o browser de preferencia para poder a la próxima vez acceder a la consola de administración , el tema es que sera tan seguro como el password que hayamos configurado para la entidad final  . Obviamente el atacante debe de contar con el archivo .p12 y el user y password de accesos para poder logearse a la interfaz de administración.

Por el momento no le hemos metido mano a la terminal para ajustar y configurar no se desesperen, no todo se hace con clicks }:)


Ahora vamos a la page del >> Administration >> Edit Administrator Privileges .
Seleccionamos en el link de " Add " y podemos un super adminsitrador el cual el nombre puede ser >> "Super Administrator".  Ahora debemos hacer una configuración mas en el panel del Administrador en el link cercano al grupo de  Super Administrators y le metemos mano a esta información el cual sera necesari:

CA: Cyttek-Bl4ckD4wn CA
Match with: Certificate serial number (recommended)
Match type: Equals, case sens.
Match value: {{SERIAL_PARA_EL_CERTIFICADO}}

El campo {{SERIAL_PARA_EL_CERTIFICADO}}debe ser remplazado por el numero de serial del certificado que hemos emitido. Y para terminar con esta configuración le damos click al botón "Add" y luego >>> Edit Access Rules en la misma pagina , con el Rol de Super Administrator, para terminar guardando la información que acabamos de configurar.

Ahora dentro del perfil de Servidor en la configuración de >> Administration >> Add End Entity , vamos a ajustar unos parámetros básicamente para ajustar la entrada:

Username: ca.cyttek.com_ejbca
Password: {{CONTRASEÑA_Keystore_CA}}
Confirm Password: {{CONTRASEÑA_Keystore_CA}}
Batch generation (clear text pwd storage): On
E-mail address: ejbca @ cyttek.com
CN, Common name: Cyttek CA Server
O, Organization: Cyttek Group.
C, Country (ISO 3166): RS
DNS Name: ca.cyttek.com
Use data from E-mail address field: On
Certificate Profile: Example Server
CA: Cyttek.Bl4ckD4wn CA
Token: JKS file

Ojo el password debe ser el mismo que el que especificamos en el archivo  web.properties de la primera serie ( Infraestructura de clave publica I ) en el archivo >>  ejbca_https_keystore_password . Una vez terminado estos ajustes repetimos con el botón  Add.

Luego despues de volvernos a logear , añadimos al final del archivo siguiente la linea especificada

# /opt/ejbca/bin/batchtool.properties
----BEGIN----
keys.spec=4096
-----END-----

Y generamos el keystore con el siguiente comando:

$ su ejbca
$ cd /opt/ejbca/
$ bin/ejbca.sh batch

Ahora después de generar el Keystore, también sera necesario crear un nuevo truststore, el cual servirá para identificar que certificados se deben de creer en la cadena de confianza para poder acceder a la interfaz de administración del nuestra infraestructura Calvin Klein.

----BEGIN----$
cd /opt/ejbca/
bin/ejbca.sh ca getrootcert 'Cyttek Root CA' rootca.der -der
bin/ejbca.sh ca getrootcert 'Cyttek-Bl4ckD4wn CA' personca.pem
openssl x509 -in personca.pem -out personca.der -outform DER
keytool -importcert -alias cyttekrootca -file rootca.der -keystore p12/truststore_new.jks
keytool -importcert -alias cyttekbl4ckd4wnca -file personca.der -keystore p12/truststore_new.jks
-----END-----$

Ojo, la contraseña que le metimos al nuevo truststore debe ser la misma que le metimos en el archivo  web.properties dentro de la configuración de ejbca_truststore_password

Antes de seguir con el nuevo Keystore y truststore vamos a bajar el servicio:

$ su root
$ service ejbca stop

Y para hacer el deploy con el servicio abajo debemos hacer ;

$ su ejbca
$ cd /opt/ejbca/p12/
$ cp ca.cyttek.com_ejbca.jks /opt/jboss/server/ejbca/conf/keystore/keystore.jks
$ cp truststore_new.jks /opt/jboss/server/ejbca/conf/keystore/truststore.jks

y luego levantando el servicio

$ su root
$ service ejbca start

Ok ahora ya tenemos nuestros ajustes por seguridad para poder acceder a la pantalla de adminstracion de nuestro PKI necesitaremos la nueva llave y certificado , Ojo, con el cache del browser y el antiguo certificado que no les dejaran entrar a la pantalla de administración.
para comodidad aremos que esta llave y certificado sea por defecto en futuras llamadas o extensiones de EJBCA:

% su ejbca
$ cd /opt/ejbca/p12/
$ mv ca.example.com_ejbca.jks tomcat.jks
$ mv truststore_new.jks truststore.jks

Para ir terminado esto , por que supongo que estaréis mas cansados que Rambo en bilmania. ahora para ir finalizando vamos a terminar con nuestras configuraciones de seguridad,Vamos a >> Administration >>; Edit Administrator Privileges  y en esa pagina le damos a >> delete en el grupo>> Temporary Super Administrator Group. y cuando tengamos eso vamos a la pagina de Administración >> CA Activation,>>> Make off-line  en la caja seleccionamos Off para la caja de monitoreo cercana a  ExampleTempAdminCA. y le damos a aplicar >> Apply .

ademas de Revocar el certificado anterior, para la configuración inicial como lo hacemos??

Ahí vamos en la configuración de panel >>  Administration >> Search/Edit End Entities .Vamos a buscar las entidades con un estatus generado, en el checkbox cercano a superadmin y Tomcat las entidades , le damos click a Revoke and Delete(revocar y eliminar )  

**Esta ultima configuración la vamos a hacer para entornos de producción mas exigentes

Todavía no tenemos el servicio 100% habilitado, ahora vamos a configurar el cola de procesos para publicar, en caso de que el certificado y las CRL's  fallen por lo menos cuando consigamos resolver esos errores siga el proceso de emisión..

Vamos a >> Administration >>>; Edit Services . En >>Publis Queue Process Service  y lo agregamos con el botón de >> "Add"  y con el servicio creado lo vamos a editar con la siguiente información :

Select Worker: Publish Queue Process Service
Select Interval: Periodical Interval
Period: 1 minutes
Select Action: No Action
Active: On
Pin to Specific Node(s): ca.cyttek.com
Description: Publish certificates and CRL's from the publisher queue.

Y para terminar como todo le damos al botón Guardar


Charlyyyy no siento los botones del Ratón.. no te preocupes que vamos a automatizar un poco esto..

Configurando el Actualizador de la CRL se encargara  de cuando la CRL se expire pueda ser regenerada periódicamente   Todavía no me voy a meter en la publicación de la CRL por que debemos de configurar la correctamente, Entonces en la pagina de >> Administration >>> Edit Services >>. CRL Updater y en le damos al botón >> Add . luego con este servicio creado lo vamos a configurar con unos ajustes:

Select Worker: CRL Updater
CAs to Check: Cyttek Root CA, Cyttek-Bl4ckD4wn CA, cyttek Server CA
Select Interval: Periodical Interval
Period: 5 minutes
Select Action: No Action
Active: On
Pin to Specific Node(s): ca.cyttek.com
Description: Updates the CRL's if necessary. Checks are made every 5 minutes.

Luego después de guardar esta ultima configuración terminamos con nuestro ajuste y configuración de EJBCA nuestra PKI calvin klein por este capitulo

Saludos

Bl4ckD4wn

HoneyDark Opensource

En que consiste este HoneyDark bueno básicamente necesitaba una red donde poder recolectar info , analizarla y correr trabajos predefinidos donde se analicen algunos patrones, (lo podéis usar para análisis de ataques malware, virus,gusanos etc.. ) y la idea me vino de la DarkNet de Chile . Pero me apetecía darle un enfoque mas practico y adelantando un poco lo que les faltaba de implementar honeypots y trabajar con mas trafico y identificar a quien están atacando  ,

Es una red diseñada para poder inicialmente soportar un trafico de 9 a 10GB ( en el caso de mi DC la tengo cableado con fibra ) poder detectar y procesar incidentes en ese trafico, analizarlo  y reportar diferentes eventos y analizarlos.

En que consiste la idea que se me paso para resolver unas cosas.... :) ( y el esqueleto de la red que les voy  a pasar )

Algunos requisitos:

1) En que consiste bueno necesitamos que cualquier trafico entre a la red pero que no salga nada,

2) Necesitamos almacenar el trafico

3) Necesitamos procesarlo 

4) Necesitamos buscar eventos de seguridad generados por ese trafico.

5) Que sea esclable, y que soporte cualquier cantidad de trafico desde donde venga 

6) Evidenciarlo

7) Reportarlo

Entonces en el archivo lo podrán descargar la estructura básica de la red, no es el que tengo para producción pero algo con las ideas que les voy a dejar seguro que algunos lo pillan por donde van los tiros.

Entonces Con:

El pfsense ya le instale  Cron's, Tcpdump, Snort, countryblocker, ntop

En el Server (ubuntu) tenemos NOVA , etherape, Moncube, AfterGlow

OSSIM no creo que necesite presentación.

El servidor de evidencias es simplemente recolectar información de las tools y procesarla

La idea inicial es simple de conceptualizar no tiene ninguna complicación, entonces entremos al detalle de como esa la versión beta que :

___________________________________________________________________________

Servidor Pfsense:
IP:192.168.3.51

user : admin

Pass : 1q2w3e

Mediante el TCPdump podemos capturar el trafico que queramos y almacenarlo donde necesitemos.

El Cron nos ayudara a automatizar unas tareas, 

Contryblocker como dice el nombre nos permite bloquear por país el Trafico que queremos que NO entre a la red  (lo podríamos hacer por IP pero por tiempo es mejor tener una app que te maneje eso para casos que posiblemente tenga a futuro de revisión en tiempo real)

y el Ntop podemos adquirir muy buena información de trafico bien detallada..
El Pfflowd nos ayudara para generar los Netflows y reportarlos al Ossim. 

Las reglas que cada uno ponga en el firewall ya es vuestra Configuración.
Ojo la interfaz WAN del Pfsense deben cambiar la IP ;)

HoneyDark::

IP:192.168.3.53

user: HoneyDark

pass: 1q2w3e

En el Servidor llamado "HoneyDark" para correr NOVA simpelmente en la termial tipear "$ quasar" y listo en https://localhost:8080 se encontrara NOVA ,
 Etherape, es mas simple desde la terminal tipear "etherape" y listo

Con Nova el cual nos permiten generar una red de honeypots mediante el haystack de nova y mediante las otra herramientas no solo monitorizamos lo que llega a nuestro server sino a todas las conexiones peticiones y trafico de nuestra red de honeypots con la configuración que le queramos dar dentro de la interfaz grafica Web

OSSIM 4.1:

Datos de acceso a la interfaz Web.
IP:192.168.3.50
user: admin

Pass: 1q2w3e

Bueno como dije no creo que necesite presentación pero para esta red, yo personalmente lo usare por la parte de recolleción de logs, OCS, OSSEC  para poder monitorizar al detalle los eventos y si algún tipo de trafico que entre a la red, puede llegar a instalar algún archivo o instalar algún rootkit etc..

Evidencias:

IP:192.168.3.52
user: evidencias
pass: 1q2w3e

En este Debian cuentan con un servidor SSH y Los aplicativos instalados en /opt Moncube y Afterglow
 le pueden mandar los Pcaps del TCpdump del Pfsense o los Pcaps del  Ossim, para que los grafique bien bonito..

La Red de la Darknet se llama "NetProperties" >> 192.168.3.0/24

_________________________________________________________________________________

Los aplicativos ya están instalados y listo para poder usarse en sus ultimas versiones , simplemente en cada aplicativo se debe ajustar a tus requerimientos de producción pero el esqueleto lo dejo ya para descarga.. (ojo asumo por falta de tiempo conocimientos en uso de las diferentes herramientas.. es por eso que no me alargo con sus instalaciones y configuraciones)

Me gustaría haber tenido un poco mas de tiempo, para poder documentar cada procedimiento, pero hacer un documental de 100 hojas todavía no estoy tan loco.. así que si te animas solo escríbeme un correo o un twitt  y te echo una mano.

La idea de esta red en forma de agujero negro, es que cualquier trafico que se enrute hacia el pfsense entre dentro de la red, y mediante las diferentes herramientas poder extraerlo , analizarlo y reportar el todo tipo de eventos, sin importar la magnitud de conexiones ni trafico.

Otra cosa lo tengo echo en un Datacenter en Vmware vCloud 5.1 así que todavía estoy trabajando para bajarle los requisitos ..

Luego la que versión que les dejo para descargar  sigo adelantando; corrigiendo la automatización y la capacidad de escalabilidad y procesamiento de trafico masivo.., el cual la red me esta quedando así multiplico por mas de 10 la capacidad de poder soportar trafico almacenarlo, pintarlo con las gráficas bonitas, generar  honeypots, almacenar sus logs, y otras funciones que quiera con trabajos pre echos en Mapreduce.

Básicamente se rutea en esta red desde la ip publica del exterior hacia el pfsense el pfsense rutea el trafico hacia un honeypot especifico de la plantilla del haystack luego el ossim hace otro trabajo con los netflows, y el nova colecciona todo el ataque aparte de la redundancia del Tcpdump en el pfsense , luego todo lo mando para una partición montada de hadoop le añado los Slave que quiera al master y corro los trabajos finales eliminan la data tal cual encontraran en el PDF de la Darknet de chile , pero desde NOVA y pfsense y ossim puedo tener un control mucho mas especifico de a que supuesto cliente le están atacando mediante alias pre definidos y como le están atacando su frecuencia y otras cosas que quiera ver..

No se si sera mejor o peor pero es un acercamiento que el de Chile pero es diferente para poder solucionar el problema de los análisis de ataques masivos,  pero fue interesante montarla como pasatiempo..



Así que si eres un Cert, Csirt, Banco o ISP ya pueden usarlo para que dejen de tocarse las #$%#&"  y empezar a analizar trafico  y intercambiaros incidentes y no delegar todo a las redes inteligentes esas de los antivirus.. :)
(ojo para entornos de producción el BETA que les dejo no esta diseñado  para poder soportar cargas masivas analizar mas de 10G de trafico en una futura versión posiblemente haga el release de producción que soporta cualquier trafico y colección mediante HDFS)

Saludos

Bl4ckD4wn

PD.El link de Descarga de la HoneyDark es: HoneyDark

Infraestructura de clave publica I

Bueno vamos a hablar un poco de las infraestructuras de clave publica, y ya que algunos alumnos las han instalado sin existo, en nuestro caso hablaremos sobre EJBCA que  haciendo referencia a un post del blog de un amigo Software PKI Opensource. me parece a mi punto de vista la infraestructara de clave publica open source mas completa para algunas implementaciones .

 Y como bien dijo nuestros amigos de Security By Default que algun dia subire fotos de la camisa, vamos a montar nuestro PKI de "Calvin klein".Para empezar desde 0 dejo la referencia a la Wikipedia sobre la explicación de los usos y deficion de PKI, para los que no tiene conocimiento puedan referirse .

Ademas de ello la instalacion de la guia rapida que siempre dejaba como trabajo la pueden encontrar en : http://www.ejbca.org/installation.html

Pero como se que algunos les gusta entrar en la jungla con machete y arco entonces vamos adelante. Ademas esta serie de post van para un amigo que queria montar su tesis de "tarjetitas" entonces espero que esta serie de post de infraestructuras de clave publica que terminaran con DNIe les sirva para sus "tarjetitas" :)..

Vamos a hacer la instalación con Ubuntu asi que entremos como root!. (recuerden tener mas de 2048MB de memoria ram en su Ubuntu Server o Desktop igual deberia funcionar para Debian)

Entonces empezemos..

$apt-get install unzip openjdk-6-jdk ant libmysql-java
instalaremos las utilidades de descompresion , el jdk de java el mysql JDBC conector y apache Ant.

Luego le podemos meter mano para agregar UTF8 a MySQL y quitarnos algunos dolores de cabeza mas adelante.
 $ nano /etc/mysql/conf.d/utf-8.cnf

----BEGIN----
[client]
default-character-set=utf8
[mysqld]
default-character-set=utf8
default-collation=utf8_unicode_ci
character-set-server=utf8
init-connect='SET NAMES utf8'
character-set-client = utf8
-----END-----

Despues de escribir ell archivo debemos reiniciar la BD's
 $ service mysql restart                                                   
$/etc/init.d/mysql restart

Para gustos estan los sabores, cualquiera de los dos comandos anteriores les deberia servir, si no consulten a su cardiologo.

Ok ahora vamos a agregar unas cuentas de usuarios para darle un poco de seguridad a la instalación, una cuenta para correr la instancia de jboss por encima de ejbca y la segunda para restringir los accesos a la instalación y los archivos de instalación

$ adduser --system --shell /bin/bash --group ejbca
$ adduser --system --shell /bin/bash --group jboss
$ usermod -a -G jboss ejbca

 Descargen y descompriman en un directorio de trabajo elegido por ustedes o para el proyecto. en mi caso /opt sera mi directorio..

$ wget http://sourceforge.net/projects/jboss/files/JBoss/JBoss-5.1.0.GA/jboss-5.1.0.GA-jdk6.zip
$ unzip ~/packages/bin/jboss-5.1.0.GA.zip -d /opt/
$ chown -R jboss.jboss /opt/jboss-5.1.0.GA
$ chmod -R o= /opt/jboss-5.1.0.GA

Luego creamos un link simbolico apuntando a la instalacion del jboss
$ cd /opt/
$ ln -s jboss-5.1.0.GA jboss

En la mayoria de intalaciones de PKI se requiere que la instalacion inicialice junto con el boteo del sistema operativo

$nano ejbca
 _____________________________________________________________________________

#!/bin/bash

. /lib/lsb/init-functions

jbossInstance="$(basename $0 | sed -e 's/^[SK][[:digit:]]*//')"
configFile="/etc/jboss/$jbossInstance.conf"
daemonName="$jbossInstance"
pidFile="/var/run/$jbossInstance.pid"

function checkEnvironment() {
  
    local binaries=(env)

    for bin in "${binaries[@]}"; do
        if ! which "$bin" > /dev/null; then
            log_failure_msg "Binary '$bin' is not available. Please install \
package containing it."
            exit 5
        fi
    done
}

function checkConfig() {
    
    if ! [[ -f $configFile ]]; then
        log_failure_msg "Please populate the configuration file '$configFile' \
before running."
        exit 6
    fi
    local reqOptions=(user group javaHome javaOpts jbossHome jbossConf)
    for option in "${reqOptions[@]}"; do
        if ! grep -q -e "^[[:blank:]]*$option=" "$configFile"; then
            log_failure_msg "Mandatory option '$option' was not specified in \
'$configFile'"
            exit 6
        fi
    done
}

function configure() {
    . "$configFile"

    env="$(which env)"
    
    java="$javaHome/bin/java"

    jbossEndorsedDirs="$jbossHome/lib/endorsed"

    if [[ -n $jbossClasspath ]]; then
        jbossClasspath="$jbossClasspath:$jbossHome/bin/run.jar"
    else
        jbossClasspath="$jbossHome/bin/run.jar"
    fi
    if [[ -n $javacJar && -f $javacJar ]]; then
        jbossClasspath="$jbossClasspath:$javacJar"
    elif [[ -f $javaHome/lib/tools.jar ]]; then
        jbossClasspath="$jbossClasspath:$javaHome/lib/tools.jar"
    fi

    javaOpts=("${javaOpts[@]}" '-Djava.net.preferIPv4Stack=true')
    if "$java" -version 2>&1 | grep 'HotSpot' > /dev/null; then
        javaOpts=("${javaOpts[@]}" '-server')
    fi

    if [[ -n $jbossNative ]]; then
        javaOpts=("-Djava.library.path=$jbossNative" "${javaOpts[@]}")
    fi
    if [[ -n $jbossNative && -z $LD_LIBRARY_PATH ]]; then
        LD_LIBRARY_PATH="$jbossNative"
    elif [[ -n $jbossNative ]]; then
        LD_LIBRARY_PATH="$jbossNative:$LD_LIBRARY_PATH"
    fi

    jbossOpts=("-c" "$jbossConf")
    if [[ -n "$jbossBind" ]]; then
        jbossOpts=("${jbossOpts[@]}" "-b" "$jbossBind")
    fi
    if [[ -n "$jbossPart" ]]; then
        jbossOpts=("${jbossOpts[@]}" "-g" "$jbossPart")
    fi
    if [[ -n "$jbossUdpIp" ]]; then
        jbossOpts=("${jbossOpts[@]}" "-u" "$jbossUdpIp")
    fi

    daemonExec="$env"
    daemonArgs=(-i $java "${javaOpts[@]}" -Djava.endorsed.dirs="$jbossEndorsedDirs" -classpath "$jbossClasspath" org.jboss.Main "${jbossOpts[@]}")
}


function start() {
    start-stop-daemon --start --quiet --oknodo --pidfile "$pidFile" \
        --make-pidfile --chuid "$user:$group" -b --name java --startas \
        "$daemonExec" -- "${daemonArgs[@]}"
}

function stop() {
    start-stop-daemon --stop --quiet --oknodo --retry 30 --pidfile "$pidFile" \
        --chuid "$user:$group" --exec "$java"
}

function status() {
    status_of_proc -p "$pidFile" "$daemonExec" "$jbossInstance"
}


checkConfig
configure
checkEnvironment

case "$1" in
    start)
        log_daemon_msg "Starting daemon" "$jbossInstance"
        start && log_end_msg 0 || log_end_msg $?
        ;;
    stop)
        log_daemon_msg "Stopping daemon" "$jbossInstance"
        stop && log_end_msg 0 || log_end_msg $?
        ;;
    restart)
        log_daemon_msg "Restarting daemon" "$jbossInstance"
        stop
        
        /bin/sleep 1
        start && log_end_msg 0 || log_end_msg $?
        ;;
    force-reload)
        log_daemon_msg "Restarting daemon" "$jbossInstance"
        stop
        start && log_end_msg 0 || log_end_msg $?
        ;;
    status)
        status && exit 0 || exit $?
        ;;
    *)
        echo "jboss (start|stop|restart|force-reload|status|help)"
        ;;
esac

 ______________________________________________________________________________

Copienlo y pegenlo en su archivo  

Ahora le metemos los permisos para los archivos
$ chown root.root /etc/init.d/ejbca
$ chmod 755 /etc/init.d/ejbca

Change the init script so that it provides the EJBCA service:

# /etc/init.d/ejbca
----BEGIN----p
--- # Provides: jboss
+++ # Provides: ejbca
-----END-----p

El Script en si mismo se configura desde /etc , pero como todavia no tenemos nada configurado alli vamos a empezar a crear un directorio de trabajo para la instancia de Jboss,
 $mkdir /etc/jboss
$chmod 750 /etc/jboss

Creamos el archivo de conifguración para el EJBCA dentro de la instancia de Jboss

# /etc/jboss/ejbca.conf
----BEGIN----
user=ejbca
group=ejbca
javaHome=/usr/lib/jvm/java-6-openjdk/
javaOpts=(-XX:PermSize=96m -XX:MaxPermSize=128m -Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000)
jbossHome=/opt/jboss
jbossConf=ejbca
jbossBind=0.0.0.0
jbossClasspath=/usr/share/java/mysql.jar
-----END-----

Ojo con los permisos del archivo!!

$ chmod 640 /etc/jboss/ejbca.conf

Bueno en Jboss tenemos un archivo donde podemos crear varias configuraciones donde podemos instalar varias aplicaciones dentro del mismo jboss..Entonces vamos a crear un archivo de configuración por defecto para nuestro ejbca

$ cd /opt/jboss/server/
$ cp -pr default ejbca
$ chown -R ejbca.ejbca ejbca

Unas configuraciones recomendadas para entornos de producción son estos ajustes de seguridad dentro del Jboss eliminar algunas apps.
$ rm -rf /opt/jboss/server/ejbca/deploy/ROOT.war/
$ rm -rf /opt/jboss/server/ejbca/deploy/jmx-console.war/
$ rm -rf /opt/jboss/server/ejbca/deploy/management/
$ rm -rf /opt/jboss/server/ejbca/deploy/admin-console.war/

Ademas de ello podemos tener mejores precuaciones conifgurando Jboss mas seguro o añadir reglas de IPTABLES, generalmente los usuario sin privilegios que van a correr el Jboss Ejbca no podran iniciar servicios con puertos inferiores a 1024 pero lo podemos resolver con:

-t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
-t nat -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443

Ojo estas reglas no te seviran si accedes de una instalacion local solo son para accesos remotos, para el acceso local deberan usar los puertos 8080 y 8443.

Ahora vamos a instalar nuestra Central de PKI

$ wget http://sourceforge.net/projects/ejbca/files/ejbca4/ejbca_4_0_10/ejbca_4_0_10.zip
$ unzip ~/packages/src/ejbca_4_0_10.zip -d /opt/
$ chown -R ejbca.ejbca /opt/ejbca_4_0_10/
$ chmod -R o= /opt/ejbca_4_0_10/
$ cd /opt
$ ln -s ejbca_4_0_10 ejbca

Ahora vamos a configurar los archivos de configuración del EJBCA, dentro del directorio /opt/ejbca/conf donde se encuentran no solo los archivos de conifugracion de la instalacion sino ademas achivos para linkear un HSM o un Base de Datos a nuestra PKI en producción,
La mayoria de archivos de configuracion terminan con la palabra "sample" , pero para nuestra configuracion deberemos renonbrar el "ejbca.properties.sample" a "ejbca.properties " y tener encuenta las siguientes anotaciones que dejo del archivo, deben de coincidir dentro del archivo que hemos renombrado.

# /opt/ejbca/conf/ejbca.properties
----BEGIN----
# Specify the root directory of the application server that's being used.
appserver.home=/opt/jboss
# Explicitly specify the application server being used. Useful if the root
# (home) directory of the application server doesn't use a standard name.
appserver.type=jboss
# Force deployment only of CA part. OCSP will be deployed on a separate server.
ejbca.productionmode=ca
# Specify the password which will be used for protecting the keystore where the
# CA's private key and certificate will be stored.
ca.keystorepass={{PASSWORD}}
# Specify the configuration of JBoss AS that should be used.
jboss.config=ejbca
# Make the healthchecker a bit more strict than the default. It will trigger an
# alarm once this much of free memory is left (in megabytes).
healthcheck.amountfreemem=32
# Make the healthcheck actually perform signing operation to make sure it's
# working properly.
healthcheck.catokensigntest=true
-----END-----

No se olviden de modificar el campo de "ca.keystorepass" con el password que se necesite para la seguridad de la llave del certificado dentro de la autoridad de certificación, recuerden minimo de  8 caracteres.

Ahora configuraremos el archivo de base de datos, exactamente el mismo procedimiento lo renonmbramos el archivo y revisamos que los parametro esten como los necesitamos.

# /opt/ejbca/conf/database.properties
----BEGIN----
# Specify desired type of database server.
database.name=mysql
# Specify the database connection URL. This property should be set according to
# the JDBC connector used (in this case the MySQL connector). See the MySQL JDBC
# for details on other options.
database.url=jdbc:mysql://127.0.0.1:3306/ejbca?characterEncoding=UTF-8
# Specify the class which should be used for the communication with the
# database. This class should correspond to the select database, and its name is
# dependant on the JDBC implementation for the given database server.
database.driver=com.mysql.jdbc.Driver
# Login credentials for the database which should store the CA information.
database.username=ejbca
database.password={{password_ejbca_mysql}}
-----END-----
Recuerden en el parametro "database.password "  debera ser el mismo password que elijieron en la creación del usuario ejbca dentro de la BD MySQL

Otro Archivo importante que vamos a meterele mano es al "install,properties", el cual especifica mucha de la información para la autoridad de certificación.   El archivo debemos verificar que contenga estas configuraciones.

# /opt/ejbca/conf/install.properties
----BEGIN----
# Name of the temporary CA used for initial configuration and access (before the
# proper CA hierarchy is in place).
ca.name=PKICyttek
# Distinguished name of the temporary admin CA
ca.dn=CN=PKICyttek,O=Cyttek Group.,C=RS
# Software tokens should have this set to null
ca.tokenpassword=null
# Type of the temporary admin CA private key. (default value listed)
ca.keytype=RSA
# RSA key size for the temporary admin CA.
ca.keyspec=4096
# Default signing algorithm for the temporary admin CA.
ca.signaturealgorithm=SHA256WithRSA
# Validity period for the temporary admin CA in days.
ca.validity=30
# Policy for the temporary admin CA.
ca.policy=null
-----END-----

Ademas de ello debemos de configurar las propiedades archivo para el servidore Web que servira la aplicacion, Entonces debemos de verificar que contenga lo siguiente:

# /opt/ejbca/conf/web.properties
----BEGIN----
# Password for the Java truststore used by EJBCA.
java.trustpassword={{ejbca_truststore_password}}
# Common and distinguished name for the temporary super-administrator.
superadmin.cn=TempSuperAdmin
superadmin.dn=CN=${superadmin.cn}
# Password for the temporary super-administrator's p12 keystore.
superadmin.password={{superadmin_password}}
# Specify that the temporary super-administrator's p12 keystore should be
# generated a part of a 'batch' operation. (otherwise it's useful for storing it
# on a smart-card through the EJBCA public web interface)
superadmin.batch=true
# Password for protecting the keystore containing the application server's
# private key and certificate.
httpsserver.password={{ejbca_https_password}}
# Hostname which will be used for accessing the CA (must be resolvable from
# client stations accessing the web interface).
httpsserver.hostname=ca.cyttek.com
# Distinguished name for the application server.
httpsserver.dn=CN=${httpsserver.hostname},O=Cyttek Group.,C=RS
# Specify external port visible to users of EJBCA.
httpserver.external.privhttps=443
# Specify desired language for the web frontend.
web.availablelanguages=EN
# Error message which should be shown to end users in case of an error.
web.errorpage.notification=An exceptions has occurred while trying to process your request. Please contact the administrators and provide the information presented within this page.
-----END-----

Ojo con los password de configuracion de este achivo deben se remplazados con minimo 8 caracteres y son sensibles a mayusculas y miñusculas. Ademas el parametro "web.availablelanguages" si lo ponen en "ES" tendran la interface en español , pero mejor hacerlo desde la propia interface donde es mas grafico ..

Ademas podemos configurar el archivo de envio de correos  para que EJBCA nos mande correos a nuestro email personal:

# /opt/ejbca/conf/mail.properties
----BEGIN----
# Log-in credentials for sending email notifications from EJBCA.
mail.user={{demo@cyttek.com}}
mail.password={{ejbca_mail_contraseña}}
# Mail server used for sending out email notifications.
mail.smtp.host=mail.cyttek.com
# Specify whether the mail server requires the authentication or not.
mail.smtp.auth=true
# Specify whether STARTTLS should be used or not.
mail.smtp.starttls.enable=true
# Email address used for sending the emails.
mail.from=ejbca-info@cyttek.com
-----END-----

Dentro de esta confijuración recuerde tener el archivo /etc/hosts bien configurado con el nombre de dominio. y modificar el  "ejbca_mail_contraseña " con la contraseña usada para entrar en "demo@cytek.com"  

Luego por ultimo asegurense que los archivos que acabamos de configurar 

$ chown ejbca.ejbca /opt/ejbca/conf/*.properties
$ chmod 640 /opt/ejbca/conf/*.properties

Luego me faltaron algunos archivos como enlazar la pki a un HSM o configurar CMP entre otras configuraciones que se pueden hacer  como en PKI enterprice privadas extraer la Base de datos con en otro servidor y etc.. pero lo dejamos asi :).

En este momento estaran como RAMBO I >> "Charly no siento los dedos...."  jejeje..

pero ahora empezamos a instalar EJBCA,pasemos como el user ejbca que creamos anteriormente

$ su ejbca
$ cd /opt/ejbca/
$ ant bootstrap

Despues de que termine el proce de instalación , necesitamos correr el servicio de Jboss que contiene el EJBCA que configuramos mas arriba. en necesario para seguir mas adelante, pero esta vez como usuario root:

$ sudo su
$ service ejbca start

Ojo, ! Jboss tarda un poco en terminar de arrancar pero podemos saber cuando termino con os siguientes comandos

$ su ejbca
$ tail -f /opt/jboss/server/ejbca/log/server.log

En el Tail buscamos dentro del archivo "log" una linea como estas.

2013-10-1 22:22:40,743 INFO  [org.jboss.bootstrap.microcontainer.ServerImpl] (main) JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=201312011022)] Started in 4m:59s:229ms

no debe ser literal la linea pero muy parecida.Ok una vez el Jboss este corriendo , procedemos con la instalación de EJBCA donde se creara todo lo que hemos configurado anteriormente.

$ su ejbca
$ cd /opt/ejbca/
$ ant install

Ok despues que termine la instalación que tarda lo suyo.. Debemos para la instancia del Jboss para seguir

$ sudo su
$ service ejbca stop

Y terminamos la instalación de Rambo con ;

$ su ejbca
$ cd /opt/ejbca/
$ ant deploy

Ok una vez termine , vamos a configurarlo para que se inicialize cada vez que el server inicialize sus demonios en el proceso de booteo:

$ sudo su
$ update-rc.d ejbca defaults
$ service ejbca start

Entonces "Charly cortame los dedos" e terminado con la instalación. ahora dentro de estas instalacion faltaria las configuraciones que se requieren, de ahora en adelante nos meteremos con unos temas bien interesantes de configuraciones , diseño , creaciones de OSCP, CA, CR, Sub-CA's . Esto era el abra bocas ahora viene Rambo I , II, III, IV, V y luego vendra la etapa de Rocky de la configuración.. asi que no se vallan..


 Ahora vamos a acceder al panel Administrador, como anteriormente hemos configurado el certificado del superadministrador con su password para acceder en el servidor Web. entonces desde el archivo "/opt/ejbca/p12/superadmin.p12 " el cual debe ser copiado a al computador de trabajo desde el servidor por "scp" o "sftp" , tengan cuidado con mandar el certificado por protocolos no seguros posublemente todavia no hemos hablado del diseño y las politicas pero en algunos casos estaria vulnerando las politicas de implementación de una infraestructura de clave publica en producción.

En el caso de Firefox para importarlo vamos a  Edit -> Preferences -> Security -> Advanced -> Encryption -> Show Certificates . y importamos el certificado superadmin.p12 ahora les preguntara el passwor dque hemos configurado anteriormente en "web.properties" lo insertan  y como hemos configurado los IPTABLES y enviado el .p12 a un cliente para configurar el servidor PKI deberemos entrar a la siguiete URL

>>  http://ca.cyttek.com/ejbca/

Ok, asta el momento tenemos instalado correctamente nuestro infraestructura de clave publica, todavia no hemos entrado en las configuraciones ni emisión ni diseño que correctamente en un desarrollo el diseño es la parte mas compleja de la infraestructura, pero esta serie de post , van enfocados , en esos proyectos, que constantemente veo, de implementación de infraestructuras de clave publica, donde las empresas de cierto calibre estafan una cantidad risoria  de millones de dolares a los gobiernos para sus PKI, sus tarjetitas sus OSCP , como ENTRUST, RSA, entre otras, viene y decontruyen millones de USD para implementar sus infraestructuras, con estos post intento que los gobiernos con sus presupuestos publicos se asesoren mejor en las implementaciones  y al final de esta seria consegiremos crear DNIe , publicar una OSCP , entre otros ..

Lo que quiero es esclarecer bien que una infraestructura de clave publica no es simple su diseño y su  configuración, pero estoy cansado de esas estafas que alfinal se reparte algun politico  como la de Perú, o OpenCA de venezuela a saber como manejan el Timestamping, y esperemos que colombia, ecuador, y bolivia no caigan en los mismos ejes de proyectos con estafas, aqui pueden ver. que se puede remplazar una PKI enterprice, con los ajustes correctos...

Saludos

Bl4ck_D4wn


¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬|||

Infraestructura de clave publica I
Infraestructura de clave publica II (proximamente.)
Infraestructura de clave publica III
Infraestructura de clave publica IV
Infraestructura de clave publica V

¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬|||

Bancos Seguridad por estupidez publicitaria

Cuantos no habéis visto las presentaciones de CISCO, IBM, ,Symmantec, ESET , entre otros (los primeros que se me pasan por la cabeza).. o de grandes empresas de seguridad o de IT de vuestros países , en donde un producto hace de todo , es contra la ciber guerra, es antivirus, para 0days, es firewall, IDS, o tienes DLP , vente con nosotros por nuestra red inteligente donde nosotros sabemos todo, tenemos las mejores soluciones del mercado.

Miren este esta enfocado para ustedes Bancos, se que nadie es profeta en su casa, pero el conocimiento no se centrifuga terminando la espiral en el mismo punto, no le pertenece todo a un solo producto o proveedor, y menos a una solución. "Le pertenece a un proceso constante , técnico bien ejecutado y con los parámetros de evaluación correctos y con los profesionales correctamente cualificados"

Pretendo enfatizar en ustedes , que mueven "X" cantidad de transacciones online, transacciones internacionales, inversiones de miles de clientes, Ladrones y usurpadores del control económico mundial (algunos bancos).

Bueno siguiendo uno de los post Anteriores que igual también puede aplicar para bancos aunque están un poco mas regulados las empresas privadas.

Al grano, Bueno me parece que se están llevando por la estupidez publicitaria cada vez veo mas gerentes que por cambiar a un producto que les vendieron que era mejor están mas seguros , pues Sr's no es así especialmente me voy a enfocar en la Banca de Latam, Tienen problemas de phising , su seguridad web (mejor dicho la web que hacen outsourcing) no la verifican  adquieren productos que ni siquiera saben si es lo que necesitan para el caso de Firewalls, NGF, UTMs, Balanceadores de carga , IDS, Etc..

• En Venezuela el 90% de la banca online en vulnerable. y me remito a las experiencias dictando una clase de seguridad e la información encontramos el banco con mas transacciones online de todo el país con SQL injection , entre muchas otras..
• En Colombia son tan recelosos y quieren mantener tanta discrepción y secretismo que la seguridad por ofuscación no funciona no son las políticas que deberían llevar y los outsourcing la mayoría de aplicaciones web son CMS que no tienen dinero para desarrollar con buenas políticas .
• En Perú, creo que ni lo voy a comentar, no perderé muchas lineas de este post explicando como realmente funciona.
• Ecuador, para que les ponen directrices sin parcialmente ni las siguen o las engañan para quedar bien con la superintendencia de banca.

Y podríamos ir mas países pero no quiero "romper los huevos para hacer tortillas", quiero enfatizar en su visión , Sr's se que mensualmente ven a muchos proveedores  de diferentes soluciones pero tomen el tiempo de escuchar atender , localizar y probar las soluciones con sólidos pases a producción, están jugando con nuestro dinero con el dinero del resto .

Ademas que las políticas para ascender en un banco en el área de seguridad sean tener ISO, COBIT, ITIL,PMP  y donde quedan SANS? EC_Council ?, Infosec.??? osea que al final quien decide es una persona que no sabe ni lo que adquiere.

Haber si con esto lo ven quiero que miren la foto y vean si alguna de esas certificaciones cubre todo el espectro tanto de procedimiento el ¿Como? y el ¿Que?

No pretendo que las que propongo son buenas pero una mezcla de todo , para esa gente que asegura el dinero del resto no estaría nada mal, que una persona que no sabe ni lo que es linux este en un área de seguridad de un banco y que en su vida a programado me parece un insulto a mi fé por la seguridad de las operaciones de ese banco.

He visto Bolsas de valores que intercambian mediante protocolos FIX 3.5 y claves Wifi en WEP( los Stocks de miles de clientes.) y luego se quejan de la ciber Guerra; si tu entidad que mueves mas de 1,000,000 USD al día tienes una clave web que con Aircrack cualquiera sentado en el café que esta en tu esquina puede acceder. (no pongo el nombre por que seria muy jugoso)

O Bancos con aplicaciones Web como estas 

La primera Foto es para que habrán los ojos.

Ya abrieron los ojos.??


Al parecer nadie les explico que usar Drupal con FckEditor no es lo mas optimo.. y que el .htcaccess puede ejecutar archivos con las extensiones que queramos. y que parchean 30 veces y 30 veces lo siguen teniendo igual.

Oque Jboss y Oracle se pueden hacer mejores configuraciones

Al parecer pueden infravalorar la bolsa hacer estafas bursátiles y  nunca han escuchado de OWASP TOP 10 al parecer

ATMs que solo falta que te pongan el puerto USB y no quiero pensar las nuevas adquisiciones del BCP del solidCORE o otros bancos que andan a pelo o con con Antivirus.

*no pongo mas fotos por que se volvería en una pasarela de parís con tantas fotos .

y tampoco pretendo que sea un bug party..

•  Usar OpenCMS antiguo y mal configurado para un Banco?
•  Delegar a un firewall de capa 3 la seguridad de la capa de aplicación?
•  Dejar aplicaciones de transacciones bancarias entre bancos publicas a la intemperie.
•  Aplicaciones de banca mobil con bugs..?
•   Seguridad en los ATMs con windows XP?
• Usar aplicaciones donde la seguridad de los inputs se las dejas a los clientes?

Un sin fin de diferentes problemas que encuentras en el día a día y te hacen pensar muchas cosas..


Podríamos hacer las publicaciones esas de 30 días un día por falla y todavía faltarían días para cubrir todas las aberraciones que se encuentran en LATAM. pero ni ustedes entenderían que es ni cual es su fin, ni tampoco perdería yo tanto tiempo para que ustedes vallan corriendo a "big providers" a pedirle ayuda o despidan a la gente que no tiene la culpa, y al final terminaría con un espectro de lectores que solamente buscarían fallas en el blog que no es el objetivo..

He visto de todo y en muchos casos hemos recomendado pero como dijo un dicho "maduramos con los daños no con los años" ,Y creo que para ustedes también sera así..

Espero que alguna reflexión levante se que el día a día de los procesos operaciones y otros comen el tiempo a cualquiera pero  tomen su tiempo en mejorar las políticas , para que tomen en cuenta las recomendaciones ,  por que si no al final terminaran madurando con los daños que les costaran de su bolsillo. :)

y para Terminar.. por que podríamos seguir :

y eso también aplica para todos esos ing. que se ven por ahí sueltos..

Saludos

Bl4ck_D4wn