Hardening e ISO-17799

no conozco mucho del tema, pero supongo que sera segun el tipo de kernel que tienga, la segunda pregunta se contestaria con Bastille linux u Openwall, ambos son proyectos enfocados a hardening.

P.d. Muy buen tema, pero aqui en seguridad(y tambien en linux) se va a oxidar

No pagaria un solo peso por comprar eso del iso 17799, ademas de que debe estar mas que desactualizado, todo eso que es tan caro es malo, como el curso de SANS.
OpenWall y bastille son soluciones peque~as y lo mejor en kernel hardening, es grsec, nada se le compara.
Creo que Linux y otros sistemas abiertos son lo mejor en seguridad, ya que le dan a uno la libertad de hacer con ellos lo que uno quiera, cosa que no sucede en otros sistemas como mac, windows, hp-ux. Igual todo el mundo dice que la seguridad es un proceso, ya vaya y mire los diplomados de seguridad informatica, por lo menos lo que he visto son cursos donde les ense~an a usar algunas herramientas del momento, y a instalar 5 o 6 programas, configurar un checkpoint y listo...............

luser dijo:

lo mejor en kernel hardening, es grsec, nada se le compara.
Creo que Linux y otros sistemas abiertos son lo mejor en seguridad, ya que le dan a uno la libertad de hacer con ellos lo que uno quiera

Haz clic para expandir...

pues aporta un link... no habia escuchado hablar del grsec. y eso me encanta del OS, puedes hacer lo que se te antoje

luser dijo:

No pagaria un solo peso por comprar eso del iso 17799, ademas de que debe estar mas que desactualizado, todo eso que es tan caro es malo, como el curso de SANS.......

Haz clic para expandir...

En realidad la norma Iso 17799 es muy amplia en muchos sentidos de la seguridad. Te recomiendo el siguiente enlace: http://auditi.com/ISO17799.htm, lastimosamente el enlace original de Synmantec ya no está disponible.

Fireman
:llamas2::llamas:

pata_de_jaguar dijo:

pues aporta un link... no habia escuchado hablar del grsec. y eso me encanta del OS, puedes hacer lo que se te antoje

Haz clic para expandir...

El primer resultado de google buscando grsec es:
grsecurity
Grsecurity is an extensive set of security patches to the 2.4 tree of Linux kernels.
The goal of the project is to create the most secure system possible ...
www.grsecurity.net/ - 7k - 13 Jun 2005 - Cached - Similar pages

Ya se que windows sigue siendo el SO mas utilizado a nivel mundial, y que hay software que no corre en linux que le es muy util a la empresa y que por ello no pueden migrar totalmente a linux, pero yo hablo de los sistemas que estan expuestos a redes inseguras, como internet, es decir los sistemas en la dmz, deberian ser sistemas los mas seguros posible, es decir linux idealmente. Los sistemas desprotegidos deben estar detras de un firewall, hay estaran los sitemas de produccion, etx. Se trata de tener varias capas de seguridad y aislar los sistemas mas importantes, que tambien idealmente deben ser linux, pero esos tampoco deben estar en la dmz, sino lo mas aislado posible de redes inseguras...

el tema no es linux en la empresa(si no yo me hubiese puesto a tirar patadas a no mas), claro que en manos inexpertas linux puede ser un win95, pero hoy en dias, en cuantos ataques externos se refieren, existen utilidades tan senciillas como el firestarter, que no se necesita ser un geek al usar. Por otro lado el hardening es tedioso para estructurar, por lo que es es sumamente benefico en servidores(donde ningun pata_de_jaguar cualquiera puede meter la mano ) pero es algo molesto en usuarios finales a los que no les interesa que el hardening. y segun para que vamos a usar el sistema son las politicas que hay que determinar.
A los usuarios comunes no se les debe ni facilitar el pwd root(aunque sea uno privado), y es una buena idea crear "plantillas" de politicas, con el fin de evitar que el mismo end user haga daño a su sistema.
La mejor administracion de Linux(ya sea grafica, end user o corporativa) la determina el administrador, asi que espero ganar esperiencia en este tema.
P.d. Por favor no metamos Win en esto que nada tiene que ver, en win basta un maguito, lo bueno esta en linux.

Primero, si es una empresa organizada no tendra tantas distribuciones diferentes, generalmente se tendran 2 o 3 precisamente es para tener una plataforma standard y facil de administrar. Luego de tener esto , el hardening es un proceso "enfocado" (notese las comillas, para los Kbrones que les gusta criticar por criticar) hacia maquinas nuevas (clientes y servidores), se hace el hardening sobre UNA IMAGEN por cada distro y cada ambiente necesario (servidor produccion, servidor desarrollo, workstation) y luego se distibuye e instala esa imagen a donde deba ser utilizada. Cuando se dice que hardening es un proceso es por que no solo es correr una utilidad que modifica settings especificos en Linux, pero tambien es aplicar ultimos parches de seguridad (que debe ir a la mano de otro proceso para parches) y muchas tareas mas, asi que cuando hablan de hardening y empiezan a hablar sobre una herramienta u otra, es parte del trabajo. Si el hardening va a ser realizado en maquinas que ya estan en produccion, seguramente se haran de la mano del proceso de cambio, para reducir el impacto de down-time. Pero realizar un hardening en servidores en produccion es una tarea traumatica dependiendo de los servicios que la empresa este utilizando.

En mi poca experiencia, ya que nunca he trabajado en una empresa, las maquinas servidores que he instalado y asegurado, he tenido siempre libertad de escoger distribucion y SO, ademas de contar con tiempo. Lo primero, si se trata de empezar de 0 es instalar el SO(debian) siempre en stable, por net install, saco la maquina por otra maquina atravez de un firewall(iptables), que es bastante flexible, lo malo es que algunas personas e dicen que iptables es es bastante complicado para redes muy grandes. Luego de que hago un update de los paquetes y todos lo parches son instalados, busco todos los binarios SUID y borro todos los que no necesito, creo una cuenta no-root, implemento SUDO para la cuenta, uso john de ripper rapidamente para probar que los passwd no son ***************eables, luego bajo todos los servicios, y descargo los sources de los demonios que vaya a usar(apache, y secure shell). El secureshell lo compilo con con -enable-md5-passwds, el apache escondo los tokens, y cambio el banner, luego le pongo el immutable bit on a la mayoria de los binarios importantes. Luego bajo los sources de el ultimo kernel stable de kernel.org, del MAKEFILE modifico la VERSION, PATCHLEVEL ... etx para colocar algun kernel diferente, asi usaran algun exploit diferente antes y con suerte uno detectara esto y podra parchar antes de que descubran la version real. Luego paso a crar chroo jail para el ssh, apache y ciertos procesos, y randomizo las direcciones del stack y el heap, el bit significante a 0x00 con eso es mas dificil utilizar exploits que retornen en system(). Luego activo el logging al sistema completamente, quito el exec en tmp y le quito la posibilidad a /bin/perl /bin/python /bin/sh de ejecutar algo, para que no puedan saltar el noexec con solo poner $perl ejecutable poniendole un chroot jail. Luego si el sistema no le puse grsec(pork necesita X server etx) modifico la libreria libproc para esconder snort, instalo y corro snort, si tiene grsec no es necesario cambiar libproc. Y por ultimo paso a instalar los servicios como CVS, arch y bzflag(un jueguito ) que son servidores no visibles al internet, como si lo son ssh y apache. Eso es mas o menos lo que hago .

luser muy bien , te quedo muy bonito tu enfoque, carita feliz para mi y para ti tambien, gracias Megavolt por darnos tu aprovacion.

Hacer risk managment en codigo es mas complicado, y ademas de que yo no tengo casi experiencia en desarrollo aun mas, pero lo que desarrollo, y si tengo que hacer un parche o algo esto es mas o menos lo que uso. Siempre todo lo que desarrollo yo mismo, lo debbugeo a fondo con kdbg(un wrapper grafico para gdb), y siempre utilizo valgrind(el mejor software del siglo 20) para chequear memoria. Si tengo que auditar algun codigo, primero chequeo rapidamente las funciones que tienen salida con formato(vsprintf(), printf()) si estan mal usadas, eso me dice que ese software no vale la pena usarlo y es mejor reescribirlo, si esta bien, basicamente revizo memcpy, strcpy, y strncpy, le paso argumentos grandes y veo como funciona, nunca uso gdb ni strace ni nada de eso, y esto es a software que usamos pork esta apenas desarrollando por ello tenemos el servidor de arch y CVS. En cuanto a software tal como apache, proFTP, open ssh, nunca revizo el codigo ni nada, pienso que este software ya es bastante robusto, claro que siempre antes de usar un producto revizo BUGS anteriores que le han salido, y si son muchos, como wsFTP, busco otro como proFTP que no ha tenido tantos problemas. Software como gdb, strace y otros, puede usarse para hacer un analisis mucho mas a fondo, pero si uno no esta acostumbrado a realizarlos y trabaja solo como yo, esto es una tarea realmente extenuante, que da resultado varias semanas luego de empezar a analizar el codigo, y creo que unicamente debe realizarse en caso de que se contrate directamente por la empresa de desarrollo. Otra cosa son los casos de CGI's, web scripts y esas cosas, que hay que hac erles una estricta auditoria, para eso lo mejor es paros y leer el code, que generalmente no pasa de 1000 lineas, lo cual lo hace muy manejable, excepto cuando esta en PERL. Yo soy de los que pienso que PERL es un write only language, leer un codigo de mas de 100 lineas de este lenguaje es algo aterrador.
Bueno creo que todo esto hay que verlo mas puntual, pork es un tema demasiado extenso.............

Dr. Megavolt dijo:

Prevencion de errores por SQL Injection.
Que proponen.

Haz clic para expandir...

Pen-test.
1. Leer codigo y cerciorarse que todos los datos ingresados ya sea como parametros post, cookies, o por la url, sean chequeados y se filtren comillas, dobles comillas, slash, doubles slash...........
2. Intentar penetrar el sitio, con ayuda de paros(el mejor) usando spider indexing, se pueden ubicar rapidamente lugares donde podemos enviar input al servidor y hacer consultas, ahi podemos probar inyecciones.
3. Correr el servidor de sql como un usuario con bajos privilegios.
4. Borrar cualquier tipo de procedimientos sql que no usemos, para evitar que otros los usen en sql injection.

Lo mejor en estos casos siempre es el pen-test, despacio, y con ayuda de un proxy, y la revizion del codigo, aca darse cuenta por ejemplo que la presendencia de los chequeos booleanos, AND, OR, siendo AND el de mayor presedencia.