[Ayuda] ligar mac address con ip para autenticar
Sandino Araico Sánchez
sandino en sandino.net
Jue Dic 22 01:22:54 CST 2005
Ing. Gabriel Barba wrote:
> 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,
Al inicio de tus reglas pones la regla de esa máquina y después cierras
lo que quieras....
iptables -t nat -A POSTROUTING -s 192.168.23.45 -d 0/0 -o ppp0 -j MASQUERADE
¿Es eso a lo que te referías?
> 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
> <mailto: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 <mailto:Ayuda en linux.org.mx>
> Para salir de la lista:
> http://mail.linux.org.mx/cgi-bin/mailman/listinfo/ayuda/
>
>
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/
Más información sobre la lista de distribución Ayuda