[Ayuda] ligar mac address con ip para autenticar
Ing. Gabriel Barba
gabbobarba en gmail.com
Mie Dic 21 17:26:40 CST 2005
hola sandino, soy un linuxero de corazon y ps tengo varios años trabajando
con linux, desde el redhat 5.1 nomas para que te des una idea jejeje pero
hasta ahorita por mas que leo y hago mis reglas de iptables no he podido
hacer este esquema
modem - router - servidor con squid - red local
porque el router esta antes del servidor y eso, mejor no preguntes, pero por
necesidad quedo asi, pues bien, mi pregunta es la siguiente, como le puedo
hacer para que una maquina con la ip 192.168.x.x pero solo una, tenga
acceso de entrada y salida a cualquier puerto? por el momento todo lo manejo
por el puerto 3128 pero hay programas que no funcionan por ese puerto
(particularmente el gunbound) podrias ayudarme?
On 12/21/05, Sandino Araico Sánchez <sandino en sandino.net> wrote:
>
> garaged wrote:
>
> > > Eso viene del que da las platicas del falso sentido de seguridad
> ???
> >
> > ¿Quieres discutir los riesgos con más detalle?
> >
> >
> > La verdad es un tema que a ti y a mi nos apaciona, Gunnar podria
> > entrar aqui y cualquier otro que tenga interes, yo se que ambos son
> > expertos en muchas cosas que yo no :-), perdon por dar mi opinion.
> > NOTA: No lo dije ofensivamente, lo dije tratando de hacer notar que yo
> > estoy bastante de acuerdo en lo que he visto de tus platicas (por las
> > presentaciones que he visto, nunca he visto una en persona) aunque
> > creo que queda claro.
>
> No te preocupes. Enfócate en los detalles, que la última semana he
> observado poco tráfico en esta lista y podría ser benéfico profundizar
> en estos temas...
>
> >
> >
> > El problema (según leí) es acceso no autorizado a servidores Samba
> > (archivos, impresoras....). Desde luego, sabemos que núnca hay que
> > subestimar a un usuario con ganas de chingar la madre, pero para
> > eso hay
> > otras herramientas como los detectores de intrusos. La diferencia
> > es qué
> > tanto control tengas sobre tu red. Si cada quién hace en tu red lo
> > que
> > se le pega la gana y tienes a un usuario que más allá de saltarse
> las
> > reglas quiere chingar pues te va a ser muy difícil encontrarlo a
> > diferencia de una red donde tienes a todos tus usuarios bajo control
> y
> > todo tu tráfico bajo control, donde las anomalías se vuelven más
> > evidentes para los detectores de intrusos.
> >
> >
> >
> > Este parrafo que escribiste es muy interesante, porque el hecho de que
> > no puedes darle acceso a recursos criticos a usuarios inexpertos o
> > desconfiables, por una simple razon, si saben suficiente (que no es
> > complicado) va a poder tener acceso a cualquier cosa suplantando
> > "personalidades" porque facilmente van a poder poner una maquina
> > legitima fuera de juego, usar su mac/ip y la contraseña que
> > previamente habras conseguido (tampoco seria dificil) y van a atacar,
> > en el peor de los casos tambien van a hacer que el ataque parezca
> > venir de la persona legitima, no de la copia, no solo de su computadora.
>
> Si el recurso compartido es una impresora y algún extraño llegara a
> suplantar a un usuario para mandar cien impresiones, seria
> definitivamente un abuso, pero el impacto sería menor. Aún así puedes
> desear el control del tráfico de tu red porque cualquier otra actividad
> podría ser anómala y podrías detectarla. Incluso, el intento de
> suplantar a otro equipo si no está bién hecho (one shot) tendrías la
> oportunidad de detectarlo antes de que se concrete.
>
> Si el recurso es más sensible que un simple servicio del que los
> usuarios puedan abusar, entonces estás usando la herramienta equivocada.
> En ese caso tendrías que recurrir a otras herramientas más difíciles de
> suplantar. La debilidad del uso de la criptografía radica en la relación
> de confianza que se delega a la fuerza de la llave. Si una llave es rota
> por alguien y el usuario dueño de esa llave llega a ser suplantado, un
> IDS no podrá darse cuenta porque lo único que observa son paquetes
> cargados con basura.... Sin embargo, puedes obligar al usuario (por
> medio de contratos con penalizaciones muy manchadas) a seguir estrictos
> procedimientos de manejo, cuidado y custodia de sus llaves y de la
> información sensible que éstas protegen.
>
> Aunque también está permitido poner IDSes dentro de la VPN y también
> está permitido ponerlos en la capa de aplicación (o incrustados dentro
> de la misma aplicación). Tu limitante es la capacidad que tengas de
> controlar la actividad de tus redes y de tus sistemas.....
>
> >
> > > En mi opinion en LAN no vale la pena hacer ningun tipo de
> > > complicacion, la politica debe ser "legal", de la forma: "no debes
> > > cambiar la configuracion de tu maquina porque te corro", si
> > alguien lo
> > > hace lo corres,
> >
> > Las soluciones de tipo legal funcionan a posteriori y sólamente
> > funcionan si tienes la capacidad de demostrar la infracción (o el
> > delito) ante un tribunal. Si alguien le causó algún daño a tu
> > organización evidentemente lo puedes demandar por cien millones de
> > dólares (o lo que le puedas sacar), pero mientras el juicio
> transcurre
> > sigue habiendo un daño que hay que reparar y una operación que hay
> > que
> > seguir manteniendo. De ahí la importancia de la prevención en los
> > sistemas de calidad.
> >
> >
> > De acuerdo, pero seria extremandamente mala una politica empresarial
> > que no proteja sus datos por fuera, de tal manera que siempre
> > persigues la intencion de dañarte, no realmente el daño, porque casi
> > siempre el daño es minimo porque el sistema es consistente aun a
> ataques.
>
> Sigue siendo cuestión de costos. Cualquier demanda se puede ir a las
> decenas de miles de pesos mientras que poner una PKI con OpenSSL o una
> VPN te costaría el sueldo de una semana de un sysadmin experimentado.
> Cuando los pones en la balanza puedes elegir entre prevención,
> recuperación o ambas.
>
> >
> > > porque por mas que hagas politicas de acceso a la red, todas son
> > > suceptibles de ser engañadas y atacadas trivialmente para
> > cualquiera
> > > que sepa tantito de TCP y relacionados.
> >
> > Eso depende de cuántos detectores de intrusos tengas, en dónde los
> > tengas y qué tipo de anomalías estés buscando.
> > Eso también depende de qué tan protegidos tengas a tus servidores
> > contra
> > ataques que no es lo mismo que tenerlos protegidos contra abusos.
> >
> >
> > Exacto, y va a ser mas util tener detectores adecuados, porque
> > necesitas tener registro de los ataques aun cuando no los detectes
> > rapidamente, y los datos no son tan preocupantes porque el sistema es
> > adecuado y no pierde datos por simples ataques, asi como valida nuevos
> > datos que puedan no ser legitimos. La deteccion humana es mejor que
> > cualquier metodo inventado por el hombre, y casi siempre va a ser la
> > que detecte el ataque tambien, asi que insisto, el sistema debe ser
> > adecuado para evitar todo eso.
>
> El detector de intrusos siempre lo tiene que entrenar un ser humano
> inteligente, por eso un snort en manos de un estúpido significa solo un
> agujero potencial más en el sistema. Se necesita inteligencia natural
> para poder decidir de entre toda la actividad cuál es normal y cuál es
> anómala. Puedes irte al nivel de detalle que quieras, poner puntos de
> observación donde quieras y usar los cálculos estadísticos que quieras,
> pero se va volviendo cada vez más cara tu detección de intrusos.
>
> En sistemas operativos libres tenemos la ventaja de que podemos
> incrustar módulos de detección de intrusos casi en cualquier lado.
>
> >
> > > Los usuarios no deben abusar porque esta prohibido, no porque se
> los
> > > haces "dificil", donde dificil es facil en casi cualquier caso.
> >
> > Si en tu organización está prohibido cierto tipo de abuso a cierto
> > recurso eso debe estar controlado en todos los puntos de acceso a
> ese
> > recurso. Un contrato en papel no te sirve de nada si no demuestras
> > intención, si no demuestras control y si no demuestras evidencia
> > contundente del abuso. Y sabemos que en los medios digitales toda la
> > evidencia es falsificable y eso la debilita.
> >
> >
> > En mi opinion no debe interesar demasiado la posibilidad de demandar,
> > sino de eliminar a las personas que traten de hacer daño.
>
> Si encuentras la manera de demostrar que un usuario siguió o no siguió
> un procedimiento que está establecido en un contrato tiene sentido poner
> penalizaciones por no seguir esos procedimientos y en la corte tienes
> las de ganar, pero en un contrato que diga 'está prohibido hackear el
> servidor' tienes que recurrir a un muy costoso análisis forense que
> demuestre que ese usuario hackeó el servidor y después en la corte
> tienes que demostrar que esa evidencia no pudo ser generada de otra
> manera (falsificada).
>
> > Pero si es necesario demandar, necesitas tener evidencia, usando VPN
> > lo mas probable es que vas a tener evidencia de que un usuario
> > inocente te ataco.
>
> El acceso a la VPN tú lo controlas. Dentro de la VPN es muy común
> encontrar relaciones de confianza, pero no está prohibido poner
> restricciones de acceso a los recursos. Si un intruso toma la llave de
> un usuario y logra entrar a la VPN tal vez no podrías detectarlo, pero
> si ese intruso intenta atacar a los sistemas que se encuentran dentro de
> tu VPN inmediatamente puedes detectarlo y aislarlo; lo mismo con
> cualquier otra actividad anómala.
>
> Si nos queremos ir al lado penal, una vez que detectaste al intruso
> puedes comenzar a registrar toda su actividad (siempre y cuando no ponga
> en riesgo a la organización) y una vez que lo has localizado derrepente
> llegas con un notario y par de guardias y le caes cuando tiene toda la
> tinta encima..... De esa casi seguro que no se salva.
>
> >
> > Estoy equivocado ?? aun cuando no soy mucho del estilo empresarial,
> > tengo cierta experiencia en esto, y en redes lo mejor que puedes hacer
> > es no depender de que funcionen correctamente, tarde o temprano se va
> > a caer el teatrito, y no quieres que todo dependa de ella, al
> > contrario, es solo una herramienta, no el medio.
> >
> > Saludos
> > Max
> >
> > p.d. Mis malditos correos siguen siendo "rechazados" por el
> > majordomo(suspicious header), y realmente no se si estan llegando a la
> > lista, o solo a los Cc. Alguien podria hacer algo ??? si es que leen
> esto
> > --
> > -----BEGIN GEEK CODE BLOCK-----
> > Version: 3.12
> > GS/S d- s: a-29 C++(+++) ULAHI+++ P+ L++>+++ E--- W++ N* o-- K- w++++
> > O- M-- V-- PS+ PE Y-- PGP++ t- 5- X+ R tv++ b+ DI+++ D- G++ e++ h+ r+
> z**
> > ------END GEEK CODE BLOCK------
>
>
>
> Sandino Araico Sánchez
> --
> Puede que no esté de acuerdo con lo que dices.
> Entonces daré mi opinión hasta el cansancio,
> ya que tengo el mismo derecho que tú......
>
>
>
>
> _______________________________________________
> Ayuda mailing list
> Ayuda en linux.org.mx
> Para salir de la lista:
> http://mail.linux.org.mx/cgi-bin/mailman/listinfo/ayuda/
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://lists.srvr.mx/pipermail/ayuda/attachments/20051221/e3bceca5/attachment.html>
Más información sobre la lista de distribución Ayuda