Problemas con IPCOP

[Horst H. von Brand]

Patricio Rojas <tronx76 en gmail.com> wrote:
> On 9/28/06, Rodrigo Fuentealba <darkprox en gmail.com> wrote:
> > >> La mayoría de los firewall hoy en día vienen con monitos

> > caso concreto: un firewall que compraron en un liceo (carísimo, no
> > recuerdo qué marca específica) traía monitos, y un servidor web
> > también (era una máquina Sun, de esas con procesador Intel y discos
> > IDE).

> > Cuento corto, versión Firewall: una vez el servidor web del firewall
> > dejó de funcionar y hubo que sacarle los discos e intentar
> > reinstalarle el software. Por mientras, todo el liceo (de unos 3500
> > alumnos) sin Internet. Terminó funcionando con Slackware 10.0 y
> > Shorewall en casa de un amigo... (y al día de hoy, cero dramas)

> EL problema no es el html es la cantidad de servicios.

Es la cantidad de software involucrado lo que multiplica el riesgo. Y
lamentablemente es la tipica de poner a tus desarrolladores estrella a
hacer la parte dificil, central (y habran pocas pifias alli), y a los
novatos a hacer lo periferico, facil (que estara lleno de ranas). Y el
problema no es simplemente si la funion principal tiene ranas, es el numero
total de ranas el mas relevante...

>                                                        Por años se
> está intentando decir que el html es peligroso cuando no es así.

HTML es un lenguaje, no es peligroso en si. Pero requiere software /muy/
complejo en ambos extremos (generar, enviar, recoger y luego interpretar
respuestas, traspasar a la aplicacion del caso; leer, luego desplegar,
obtener respuestas del cactus que lo maneja, traducir esas respuestas,
enviar respuestas de vuelta). Que tan mal pueden salir las cosas en
cualquiera de estos pasos queda como ejercicio...

[...]

> IPCOPS se puede administrar por vía web,  ssh o consola y he visto que
> es muy bueno.  Por qué desestimarlo si tiene html ?.

Porque (por las razones explicadas) HTML es mala idea...

Porque "<usuario al azar> lo vio y lo encuentro bueno" /no/ es en lo
absoluto indicacion que sea seguro. Que es "bueno" para ti? Tienes los
(especializados) conocimientos para determinar si es seguro? Hiciste el
(extenso) trabajo de evaluacion que significa determinar eso?

Tambien importa que tan extenso y especializado es el grupo de desarrollo,
y que tanto esfuerzo dedican al tema. Alli tiendo a confiar en las
distribuciones grandes, quienes tienen a sus ingenieros entre los
desarrolladores principales de las piezas criticas para seguridad.

Y finalmente, es importante que el usuario conozca bien las herramientas
que esta usando. Muchos problemas se deben a mal uso, por simple
desconocimiento o falta de familiaridad. O sea, lo ideal es usar algo de la
misma familia en todos lados (o sea, todos Debian o Debian estable en los
servidores y demas sistemas criticos + Ubuntu du jour en las estaciones, o
lo que corresponda en otras lineas).

> Una persona con todo el tiempo del mundo puede crear reglas que
> filtren conexiones bajo criterios, pero para qué perder el tiempo si
> pueden ser activadas vía una interfaz?. El aplicarlas en la capa DCL
> /shell es una alternativa válida como también la html.

Y quien te garantiza que la traduccion entre lo que "el usuario entendio
decia la interfaz" y "las reglas finales aplicadas" es fiel?

> > detrás del desarrollo de cualquier software (o hardware), y aunque sea
> > escasamente, los humanos tenemos la mala costumbre de equivocarnos.

> > La mejor manera (a mi parecer) de evitar equivocaciones es
> > simplificando el desarrollo, y lo primero que se iría de patada en la
> > r... para muchos buenos programadores serían los monitos.

> Cosas concretas IPCOP funciona!

Como lo sabes? Lo has probado frente a reales ataques? Auditaste el
codigo?

[No, "le dije que dejara pasar HTTP, y lo deja pasar" /no/ es una prueba de
 un cortafuegos!]

>                                 y tiene sus vulnerabilidades como
> todos los cortafuegos (cosa que no es malo). El problema es cuantas
> vulnerabilidades tiene en un tiempo.

No es tan simple... 

> > >> EL real problema es tener el máximo de tecnología en comodidad  y no
> > >> emplearlo por miedo, temor, fobia. ¿ por qué no ligar ambas a nivel
> > >> adecuado de seguridad?.
> >
> > ¿porque tendría que haber como mínimo dos programadores que pensaran
> > parecido y tuvieran exactamente la misma idea, para que existan cero
> > descoordinaciones, cosa que humanamente es difícilmente posible? (Uno
> > que se preocupe del firewall, el otro de la interfaz, otro de la
> > implementación, otro... etc.)

> No digo que no sea posible, pero me ha dado mejores resultados
> planificar toda la interfaz primero  y luego desarrollo. Así queda
> todo mas estandarizado.

Eso funciona si sabes donde vas; y la mayor parte de los sistemas
construidos de esa forma cuentan con usuarios que /evitan/ areas problema
cuando las notan, un usuario de un "configurador de cortafuegos" que no
haga nada probablemente no se de cuenta que el cuento no funciona...

Aca requieres /garantias/, no basta /a mis usuarios generalmente les
funciona OK/, y los resultados /no/ se ven (aun menos se notan claramente
las fallas antes que es horriblemente tarde).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513