Re: [OT] Re: Hola amigos
El día 11 de abril de 2015, 12:13, Camaleón escribió: > El Sat, 11 Apr 2015 09:54:30 -0500, Informático Leandro escribió: > > Lo marco como OT por tratarse de una cuestión genérica. > >> hola a todos los listeros espero puedan ayudarme la cuestion es que >> necesito saber si existe un modo de eliminar la creación de identidades >> falsas en clientes de correo como squirrelmail y outlook el problema es >> que eso para mi representa tremenda brecha de seguridad tal ves no sea >> de mucho peso para unos pero me lo estan exigiendo bueno el punto es que >> desde los clientes de correo se peude crear identidades falsas las >> cuales se prestan para muchas cosas y lo peor que salen como si >> existiera la cuenta en el servidor AYUDA! > > Lo que pides no lo puede hacer ni Google así que te han puesto alto el > listón, vamos, que lo tienes difícil :-) > Lo que quieres es que quien envíe un mail solo pueda hacerlo con la dirección/direcciones de origen que tenga autorizado a hacerlo? Primero deberías decir indicar que MTA utilizas. Con postfix pues armar una tabla con alias authorizado / userID utilizado en la autenticación smtpd_sender_login_maps = pcre:/etc/postfix/sender_login_maps sender_login_maps: /^(admin)@xxx\.yyy\.zz$/ usuario1 usuario2 ... /^(hostmast)@xxx\.yyy\.zz$/usuario1 usuario2 ... /^(.*)@xxx\.yyy\.zz$/ $1 Con Sendmail también es posible, pero no lo tengo a mano y es algo más complejo. > Saludos, > > -- > Camaleón > > Saludos, Santiago.- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj5esfydhk_v-5c-6naymvlkxe0xztggdahrhkwowwzf2zv...@mail.gmail.com
Re: Proteger Bind contra ataques
El día 9 de abril de 2015, 9:05, Jose Pablo Rojas escribió: > Yo en lo personal lo que haría es implementar fail2ban, para que este a > partir de los logs haga la tarea. > Las reglas que lo hacen son [named-refused-udp] y [named-refused-tcp] Hay que tener muy claro que al habilitar [named-refused-udp] en fail2ban se corre un gran riesgo con el spoofing. Se pueden terminar bloqueando IP que no tienen nada que ver con el ataque. Ademas de esto, a la configuración que viene con el paquete le faltan fail2ban algunas expresiones regulares para matchear efectivamente el log del bind. > Saludos > > El 9 de abril de 2015, 5:13, Mauro Antivero > escribió: >> >> Estimados, necesito ver como hacer para proteger un servidor DNS (con >> Bind) contra ataques del tipo DOS. Como siempre digo, hay mucha información >> en Internet, pero lo que necesitaría es que me orienten un poco para ver por >> donde empezar a leer. Que tipo de ataques DOS estas recibiendo? Si el Bind tienen una configuración razonable, deberías tener un ataque muy importante para que afecte significativamente la performance. Muchas veces se aprovecha la posibilidad de realizar consultas recursivas. >> >> Les agradezco cualquier comentario que me puedan hacer. >> >> Saludos y muchas gracias, >> >> Mauro. >> >> Saludos, Santiago.- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ5eSfbTr15tafuyaAWLgaDJcHZEXe28ecywmH=nrgreq5x...@mail.gmail.com
Re: ifupdown en jessie, iproute2 e interfaces bridge
El día 24 de marzo de 2015, 17:33, José Miguel (sio2) escribió: > El Tue, 24 de Mar de 2015, a las 06:37:12PM +, Camaleón dijo: > >> Como te he ido diciendo a lo largo del hilo, eso "mágicamente" no creo >> que funcione. Hasta bridge-utils necesita tirar de los scripts (que te >> genera al instalar el paquete) para detener o reiniciar los puentes que >> se hayan creado con brtcl. > > Eso lo tengo claro, Camaleón. Pero el caso es que para crear interfaces > vlan no se necesita ya ningún script en if-pre-up.d. El comando necesario, > previo a la configuración de la interfaz, que crea la interfaz vlan, o sea, > uno parecido a este: > > ip link add link eth0 name eth0.10 type vlan id 10 > > lo ejecuta ifupdown él solito, sin doparse con scripts externos, en > cuanto ve que una interfaz se llama "XXX.NUMERO". > En /etc/interfaces se puede definir el bridge como otra interface, no se si es eso a lo que te referís. Ej.: iface br0 inet static bridge_ports eth0 eth1 address 192.168.1.2 broadcast 192.168.1.255 netmask 255.255.255.0 gateway 192.168.1.1 bridge_fd 9 bridge_hello 2 bridge_maxage 12 bridge_stp off https://wiki.debian.org/BridgeNetworkConnections >> Por lo tanto, si quieres hacer lo mismo con iproute2 tienes que crear >> manualmente esos scripts para que ifupdown pueda gestionar las interfaces >> puente. > > No veo cuál es la consecuencia lógica que te lleva a tal conclusión. Si > los desarrolladores de ifupdown hubieran hecho con las interfaces puente > lo que han hacho con las interfaces vlan, entonces el comando: > > ip link add name br0 type bridge > > también se podría ejecutar automáticamente antes de configurar la > interfaz con que sólo hubiera algún modo de que ifupdown supiera que > cuando declaras "br0" en el fichero interfaces, quieres que sea una > interfaz bridge. ¿Que los puentes tienen una casuística distinta que > desaconseja o impide hacer esto o que simplemente no se ha implementado? > Pues a lo mejor. Pero la razón no es que "como hay que crear la interfaz > antes, tiene que haber un script externo que la cree", que es lo que > entiendo que vienes a argumentar. Y no es la razón, porque las > interfaces vlan, se crean sin necesidad de script. > > Saludos. > > -- >Vine a desembuchar y desembucho. > --- Muñoz Seca --- > > > -- > To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/20150324203358.ga9...@cubo.casa > Saludos, Santiago.- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ5eSfaHFg3f9yMsqa7E_OZLJN24w�bfpb83zniy4fwvg...@mail.gmail.com
Re: Subredes, proxy y otras yerbas
No hagas top posting porque se vuelve difícil seguir el tema... No abras otro hilo para el mismo tema... pego acá >El día 30 de diciembre de 2014, 21:24, Santiago Liz >escribió: >> El día 30 de diciembre de 2014, 17:23, Fernando Miculan >> escribió: >>> Hola, como están?. >>> Me presento, me llamo Fernando, vivo en La Plata, Argentina y hace unos >>> cuantos años que utilizo Linux, en especial Debian y Ubuntu. >>> >>> Se me presento un caso en mi trabajo. Tenemos un squid linkeado a un active >>> directory de Win(fucker) 2008 en la red 192.168.0.0, ademas de haber >>> implementado un firewall con iptables. Todo realizado en un Debian 7. >>> Hasta ahí no hay inconvenientes, los usuarios navegan perfectamente según >>> los grupos asignados en el active directory. >>> El problema se presento justamente hoy, al querer ampliar la red a otra >>> subred (192.168.30.0, que dicho sea de paso se implemento en forma de vlan >>> en un router mikrotik.) >>> La cuestión es, que después de haber agregado la ruta en una de las >>> interfaces del debian para que vea la subred 30, estos navegan perfectamente >>> en internet, pero no la subred 0, todo lo que sea web no funciona, salvo el >>> correo electrónico y el skype. >>> Que es lo que puede estar pasando? >>> Con netstat -nr se ven las rutas asignadas perfectamente, por ese lado no >>> veo el problema... me estará faltando algún tipo de regla adicional en el >>> firewall ?? >>> Si les sirve les puedo postear el script del firewall. La política por >>> defecto es DROP y luego permito algunos puertos y mac address para que >>> bypaseen el proxy. >>> >> >> Falta algo de info, pero adivinando diría que algún cambio afectó la >> configuración de squid donde se daba permiso a la red >> 192.168.0.0/(24?) para utilizar el mismo al habilitar la >> 192.168.30.0(/24?) o lo mismo en iptables donde se permite acceder a >> la IP:Puerto donde escucha squid. >> Al decir que anda el correo y skype descarto problemas de ruteo/nat. >> Cuando desis que no navegan, cual es el error? un error de squid >> diciendo que no tienen permiso o que no los clientes nos se pueden >> conectar al proxy? >> >> > > Los que no navegan son los equipos de la subred 0 que esquivan el proxy > squid a través de una regla iptables por mac address. Si esos equipos los > apunto al squid desde el navegador, funcionan bien. > Lo extraño es que esa regla funciono de maravillas antes de hacer la subred > 30. > > Aqui posteo lo que me tira un netstat -nr > > Destination Gateway Genmask Flags MSS Window irtt Iface > 0.0.0.0 192.168.0.216 0.0.0.0 UG0 0 0 eth1 > 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 > 192.168.30.0192.168.0.1 255.255.255.0 UG0 0 0 eth0 > > Donde 192.168.0.216 es el gateway de la subred 0 y 192.168.0.1 es lo mismo > para la subred 30 El equipo tiene dos interfaces (eth0 y eth1) con IPs dentro de la misma red 192.168.0.0/24 ? 192.168.0.00.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.0.00.0.0.0 255.255.255.0 U 0 0 0 eth0 La IP 192.168.0.216 es el default que te conecta a Internet y hace el NAT? Eth0 y eth1 están conectadas al mismo segmento de red? Donde están conectados los equipos que no tienen acceso físicamente, a la eth0 o eth1? Con esos datos parecería ser que hay un problema independiente de la red 192.168.30.0/24 y es que (salvo que estés omitiendo datos) estás intentando que el equipo forwardee paquetes entre dos interfaces de la misma red, lo cual no tiene mucho sentido. Si un equipo cualquiera de las red 192.168.0.0/24 tiene como default la IP 192.168.0.216 debería andar sin intervención del proxy/firewall. Deberías aclarar como está implementada la red. > > > -- > Fernando Miculan.- > FCM Sistemas > Tel. 15-5435862 / ID: 160*6915 > ICQ: 6410724 / Skype: fcmsistemas > http://ferchobbs.ddns.net > BBS Telnet: ferchobbs.ddns.net:23 Saludos, Santiago.- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ5eSfaC9sQcAXwhyA_�iRs_4GN5yq7R3TtxQcj_Ur+RU=d...@mail.gmail.com
Re: Subredes, proxy y otras yerbas
El día 30 de diciembre de 2014, 17:23, Fernando Miculan escribió: > Hola, como están?. > Me presento, me llamo Fernando, vivo en La Plata, Argentina y hace unos > cuantos años que utilizo Linux, en especial Debian y Ubuntu. > > Se me presento un caso en mi trabajo. Tenemos un squid linkeado a un active > directory de Win(fucker) 2008 en la red 192.168.0.0, ademas de haber > implementado un firewall con iptables. Todo realizado en un Debian 7. > Hasta ahí no hay inconvenientes, los usuarios navegan perfectamente según > los grupos asignados en el active directory. > El problema se presento justamente hoy, al querer ampliar la red a otra > subred (192.168.30.0, que dicho sea de paso se implemento en forma de vlan > en un router mikrotik.) > La cuestión es, que después de haber agregado la ruta en una de las > interfaces del debian para que vea la subred 30, estos navegan perfectamente > en internet, pero no la subred 0, todo lo que sea web no funciona, salvo el > correo electrónico y el skype. > Que es lo que puede estar pasando? > Con netstat -nr se ven las rutas asignadas perfectamente, por ese lado no > veo el problema... me estará faltando algún tipo de regla adicional en el > firewall ?? > Si les sirve les puedo postear el script del firewall. La política por > defecto es DROP y luego permito algunos puertos y mac address para que > bypaseen el proxy. > Falta algo de info, pero adivinando diría que algún cambio afectó la configuración de squid donde se daba permiso a la red 192.168.0.0/(24?) para utilizar el mismo al habilitar la 192.168.30.0(/24?) o lo mismo en iptables donde se permite acceder a la IP:Puerto donde escucha squid. Al decir que anda el correo y skype descarto problemas de ruteo/nat. Cuando desis que no navegan, cual es el error? un error de squid diciendo que no tienen permiso o que no los clientes nos se pueden conectar al proxy? > Desde ya agradezco toda a ayuda que me puedan brindar. > > Saludos!!! > > -- > Fernando Miculan.- > FCM Sistemas > Tel. 15-5435862 / ID: 160*6915 > ICQ: 6410724 / Skype: fcmsistemas > http://ferchobbs.ddns.net > BBS Telnet: ferchobbs.ddns.net:23 Saludos, Santiago.- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ5eSfaQfB-3QwPZuu1=npoyb4x6v7mhd4+af7+6_plpnui...@mail.gmail.com
Re: [debian] balanceo internet
El día 2 de julio de 2014, 8:46, Francesc Guitart escribió: > Hola, > > El 02/07/2014 5:31, gustavo c escribió: > >> En mi trabajo voy a tener dos proveedores de internet y quiero hacer >> balanceo de carga. Tener un servidor con dos tarjetas de red para los >> Proveedores de internet y una para la red lan. >> Alguna recomendación, dificultad que voy a tener? >> Me conviene usar algo que está preparado como zeroshell? >> Yo deseo usar Debian >> >> gracias >> > > Necesitas iproute2: > > http://www.linuxcolombia.com.co/?q=node/47 > > Otra opción es Shorewall http://shorewall.net/ (no lo utilicé, pero tengo buenas referencias). De todas maneras, con iproute2 más iptables para mantener un marcado de paquetes y/o nat lo puedes hacer tranquilamente. Si quieres tener un conocimiento más profundo del tema: http://lartc.org/howto/ > -- > Francesc Guitart > > > > -- > To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: https://lists.debian.org/53b3f112.1070...@gmx.com > Saludos, Santiago.- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj5esfzysy1+okg89fzagduca1v6g6qsef+4mubtjqed29z...@mail.gmail.com
Re: Routing directo sin pasar por el gateway en la misma LAN
El día 3 de abril de 2014, 12:58, Camaleón escribió: > El Thu, 03 Apr 2014 12:36:56 -0300, Santiago Liz escribió: > >> El día 3 de abril de 2014, 12:14, Camaleón >> escribió: >>> El Thu, 03 Apr 2014 08:51:53 +0200, Roberto Leon Lopez escribió: > > (...) > >>>> ¿como podría obligar a que dicho trafico pase por el gateway? >>> >>> ¿A dónde va ese paquete? >>> >>> Un switch no gestionable "convencional" es un equipo "tonto" cuya única >>> lógica ahorrativa se da en que envía el paquete al destinatario que le >>> corresponde en lugar de lanzar el paquete a todos los equipos que tiene >>> conectados. >>> >>> Ahora bien, como te dice Antonio ¿por qué debería pasar el paquete por >>> la pasarela que tienes definida? Si no hay más reglas de enrutado en el >>> equipo, sólo los paquetes que no encuentran su destino en la red local >>> salen por la puerta de enlace. De hecho, en teoría ese sistema es el >>> menos eficiente pero el más sencillo de implementar de ahí que todos >>> tengamos configurada una pasarela predeterminada pero no un sistema de >>> gestión de rutas como debería ser. >> >> Si es lo mismo que veníamos hablando en le hilo anterior por la conexión >> SSH, la cosa es así: >> >> Equipo A tiene IP de la red N1 (origen conexión) > > (...) > > El Equipo A tiene a "Mister T" ;-P > > Fuera de bromas, si seguimos usando terminología genérica vamos a liarnos > más. Creo que en estos casos la precisión es necesaria para evitar > malentendidos. Es decir, que ese "Equipo A" tiene que transformarse en > "eth0" con datos de IP/máscara/pasarela y acción que lleva a cabo con > resultado. > > Y lo mismo para el resto, porque una "pasarela" puede ser una IP un > servidor con 20 tarjetas de red, un appliance, etc... es mejor ser > precisos con las descripción de los elementos que estamos definiendo. Entonces esperemos que Roberto nos indique los datos de los tres equipos involucrados... > >> El problema es que algunos equipos en la red N1 al conectarse a otros de >> la red N2 deberían enviar los paquetes con destino a la IP de N2 pero >> con mac del default gateway y viceversa. > > Es que ese "debería" está un poco en el aire. Lo que "debería" hacer (o > no) depende de dónde se dirija el tráfico y cómo esté configurado el > equipo que lo genera. Ya lo dijeron por ahí, el equipo tiene configurado su DG. El tráfico que tiene destino otra red no local, va (debería ir) al default. > >> Por algún motivo, al estar las dos redes en el mismo medio físico y >> ambos equipos ver algún tráfico con origen en la mac/IP del otro, >> terminan >> Habría que hacer un mini lab para ver que genera este comportamiento >> (algún ICMP redirect quizás?) > > Hasta donde sé, ese es el comportamiento normal de un switch por eso es > primordial dirigir el paquete a su destino para que el switch no tome > iniciativas. No me queda claro a que te refieres con que "ese es le comportamiento normal de un switch"? Un switch capa 2 solo "decide" por donde envía un paquete basado en la mac de destino y en sus tablas recopiladas del tráfico entrante en cada port. El problema está más arriba y es por qué el host de origen del paquete lo envía con la IP de destino, pero con la mac del host de destino y no con la mac del DG (que sería lo correcto). Lo curioso (Roberto lo deberá confirmar) es que algunos paquetes siguen el camino correcto y otros no. > Saludos, > > -- > Camaleón > > > -- > To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/pan.2014.04.03.15.58...@gmail.com > Saludos, Santiago.- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ5eSfbVDqWde7GNJO=0m_udtpye_wgcerxeql2kn6+_jde...@mail.gmail.com
Re: Routing directo sin pasar por el gateway en la misma LAN
El día 3 de abril de 2014, 12:14, Camaleón escribió: > El Thu, 03 Apr 2014 08:51:53 +0200, Roberto Leon Lopez escribió: > >> Esta consulta viene de otro problema que ya he dirigido a la lista. > > Hum... y si no recuerdo mal había máquinas virtuales de por medio. > >> Tengo dos subredes en la misma LAN, los equipos conectados al mismo >> switch, los equipos de cada subred tienen su gateway que apunta a la ip >> correspondiente, las dos ip están sobre el mismo interfaz de red del >> gateway. >> >> La cuestión es que observo como un servidor Debian de una subred no pasa >> por el gateway porque puede hacerlo de manera directa vía switch, >> es como si el switch que tiene toda la relación de ips/mac lo redirige >> sin problemas, es un switch no gestionable >> >> ¿como podría obligar a que dicho trafico pase por el gateway? > > ¿A dónde va ese paquete? > > Un switch no gestionable "convencional" es un equipo "tonto" cuya única > lógica ahorrativa se da en que envía el paquete al destinatario que le > corresponde en lugar de lanzar el paquete a todos los equipos que tiene > conectados. > > Ahora bien, como te dice Antonio ¿por qué debería pasar el paquete por la > pasarela que tienes definida? Si no hay más reglas de enrutado en el > equipo, sólo los paquetes que no encuentran su destino en la red local > salen por la puerta de enlace. De hecho, en teoría ese sistema es el > menos eficiente pero el más sencillo de implementar de ahí que todos > tengamos configurada una pasarela predeterminada pero no un sistema de > gestión de rutas como debería ser. Si es lo mismo que veníamos hablando en le hilo anterior por la conexión SSH, la cosa es así: Equipo A tiene IP de la red N1 (origen conexión) Equipo B tiene IP de la red N2 (servidor ssh) Gateway tiene IP de N1 y N2 en la misma interfaz física (sin VLAN) El problema es que algunos equipos en la red N1 al conectarse a otros de la red N2 deberían enviar los paquetes con destino a la IP de N2 pero con mac del default gateway y viceversa. Por algún motivo, al estar las dos redes en el mismo medio físico y ambos equipos ver algún tráfico con origen en la mac/IP del otro, terminan aprendiendo estos y enviando el tráfico en forma directa. Habría que hacer un mini lab para ver que genera este comportamiento (algún ICMP redirect quizás?) > Saludos, > > -- > Camaleón > > > -- > To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/pan.2014.04.03.15.14...@gmail.com > Saludos, Santiago.- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj5esfz+2prjrmqnf8l_hjhrz_zhmgugn9f44lnsg33kzpr...@mail.gmail.com
Re: Problemas de ruteo
El día 8 de enero de 2014, 8:50, Demian Pazos escribió: > Consulta para la lista: > > > Tengo el siguiente escenario: > > - Una interfaz con conectividad WAN, IP fija en un /30. (eth0) > - Una interfaz LAN en la 192.168.2.0/24 (el router tiene la 192.168.2.2) > > En este escenario, agregué una tercera interfaz para comunicar dos redes en > la dirección 10.1.1.2/24. El router Linux del otro lado tiene la dirección > 10.1.1.1/24. El objetivo es tener conectividad entre mi LAN 192.168.2.0 y un > segmento LAN del otro lado (192.168.0.0/24) a través de la 10.1.1.1/24. > Desde la red 192.168.0.0/24 llego sin problemas a mi red, pero no tengo el > mismo resultado desde mi LAN. Desde mi router sí tengo conectividad a la > otra red. Estos ping tienen respuesta porque tienen IP de origen de la WAN que el otro router ve directamente conectada y sabe hacia donde devolver las respuestas. > > Cuando realicé una captura sobre la interfaz que utilizo para el ruteo, > descubrí que los paquetes de ping que envié salen con la dirección de origen > de mi WAN en lugar de la 10.1.1.2. Cuando haces el ping asegurate que tenga como dirección de origen la ip de la LAN. ping -I interface destino (donde interface es el nombre o la ip) > > las rutas en mi router son (marco X para no publicar la WAN): > > Destination Gateway Genmask Flags MSS Window irtt > Iface > 19x.x.x2.x2 0.0.0.0 255.255.255.252 U 0 0 0 > eth0 > 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 > eth2 > 192.168.0.0 10.1.1.1255.255.255.0 UG0 0 0 > eth3 > 20.0.0.00.0.0.0 255.255.255.0 U 0 0 0 > tap0 > 10.1.1.00.0.0.0 255.255.255.0 U 0 0 0 > eth3 > 0.0.0.0 19x.x.x2.x4 0.0.0.0 UG0 0 0 > eth0 > > > ¡Gracias por la ayuda! Habría que ver que el otro router tenga la ruta hacia tu LAN con gateway en la IP 10.1.1.2 Saludos, Santiago.- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ5eSfZzmA2E9EqAsxp4=k+zujo+nttkjjppiig+vaeoona...@mail.gmail.com
Re: [OT] Re: UAYRA - ¡Una buena noticia!
El 18 de septiembre de 2013 22:03, Angel Claudio Alvarez escribió: > > El Tue, 17 Sep 2013 20:40:49 -0300 > Fabián Bonetti escribió: > > > On Tue, 17 Sep 2013 19:26:32 -0300 > > Angel Claudio Alvarez wrote: > > > > > > > Flaco esto es una lista tecnica. > > > > Mira el asunto de la lista técnica, ignorante. No te di confianza para que > > me llames "Flaco", se educado. > > fui educado, deberia haberte trqatado de PELOTUDO directamente > > > > > No sientes tu posicion politica sin argumentos solidos > > > En que te basas para decir "desviar dinero sucio" ??? > > > > Antes de hacer esa pregunta te preguntaste cuanto gastaron? > > > > el )ue hace la primera afirmacion sos vos, no chicanees con otra pregunta > > > De donde sacaste que no es transparente?? > > > > Dame link con todo el dinero invertido... > > > > segui bardenado sin argumentar > > > > Politica nefasta?? argumenta > > > > Esto ya es perder el tiempo con alguien poco inteligente. Vos seguro vivís > > en Argentina? > > > > > y??? los argumentos??? > > > > > No apoyes la mala educación de niños de Argentina, no querrás eso en tu > > > > nación. > > > repito en que te basas para decir semejante boludez??? > > > > que léxico que tenes, y así queres que te tomen en serio? > > > > Lo unico que tenes para responder es el lexico?? evidentemente sos UN > PELOTUDO que ademas no tiene argumentos > > > > > > Para acusar hay que tener pruebas, si no controla los deditos y no > > > escribas por escibir > > > Si no te gusta lo que esta haciendo el gobierno por el software libre, > > > arma algo vos > > > Y si tenes pruebas de "dinero sucio, corupcion y politica nefasta" > > > presentalas, si no por favor encauza tu fastidio politico con el Gobierno > > > por su cauce natural, es decir, participa en politica. Basta de quejarse > > > como vieja cerolera, hace algo, presenta una propuesta superadora si no, > > > mejor no opines. > > > > > > > Aquí me obligas a que no opines?... es de no creer. No podes defender lo > > indefendible. > > > > evidentemente sos un PELOTUDO que nunca aprobo comprension de textos, yo no > te obligo a nada, te doy una sugerencia y justo vos venis a hablar de > defender?? si no podes arguentar tu posicion, solo te quejas como las viejas > caceroleras > ... > y lo de hacer algo?? ah cierto que no tenes argumentos, entonces meno vas a > tener una propuesta > > > Deberías aprender a tratar con personas. > > > me viste tratar a alguna persona?? > > una ultima cosita > Cuando trates de invertir la carga de la prueba, tene fundamentos solidos a > mano, asi no pasas otro papelon, muñeco > segui participando > > > > > > > -- Gente esto es una lista técnica... Ninguno esta dando argumentos ni a favor ni en contra, solo insultos Para los que no leen foros o grupos donde participamos más de dos argentinos, les comento que esto se está volviendo de lo más común (en todos los ámbitos), donde la política se mezcla y pasa a tener el papel principal en las opines relegando a un segundo plano la idea orinal del intercambio. Así las cosas se vuelve muy difícil poder expresar ideas fundamentadas e imparciales sin recibir ataques de uno u otro lado (o los dos a la vez). Con respecto a Huayra que cada uno saque sus conclusiones, pero sin apresurarse. El mantenimiento en le tiempo va a decir si valió la pena poner esfuerzos en esta nueva distro o era preferible apoyar proyectos anteriores. Habiendo la idea nacido de la política, es poco probable que se apoye algo existente, siempre es mejor (políticamente hablando) mostrar que se tuvo la iniciativa antes que apoyar ideas de otros. Nadie pone en duda que es bueno que se apoye el software libre, pero como todo, no falta quien sospeche que los motivos reales detrás sean otros y no se los puede culpar porque ejemplos en ese sentido sobran. Si a esto le sumamos falta de información clara, es un cóctel perfecto para la polémica. Tanto el tema de las netbooks como del software libre, son temas que viene desde comienzos de esta gestión de gobierno. Con sosas buenas (las propias netbooks, Argentina conectada) y cosas malas (como la falta de infraestructura o capacitación para que tenga sentido utilizarlas en el aula, la incorporación de último momento de Windows en las mismas, el frenado de la ley de software libre en el estado y mucho bla bla bla por todos lados). Las dos visiones son: "La idea es buena pero a implementación es mala", contra "Mal, pero se hizo algo que antes no se hacía" Los primeros no van a reconocer que la idea es buena, pero los segundos no van a reconocer que se hizo mal. Saludos, Santiago.- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj5esfyd++2woxvrrlx-jqmp3nrff+rcgsrasz_kv0qrg9w...@mail.gmail.com
Re: Spamassassin: "sa-update" no se ejecuta
No tengo a mano una maquina con spamassassin andando pero pregunto por una
experiencia que tuve hace unos años:
¿No descarga las actualizaciones o no compila las reglas y hace el reload?
Quizás tenga que ver con esto:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601798 (que no es un bug
sino una metida de pata mia)
Saludos,
Santiago.-
El día 26 de junio de 2013 12:03, Camaleón escribió:
> Hola,
>
> Hace unos días activé en Wheezy la tarea del cron para actualizar a
> diario las reglas de spamassassin pero me he dado cuenta de que no se
> está ejecutando ya que "sa-update" genera un directorio con las
> actualizaciones que no existe en mi sistema.
>
> Ejecutando el comando manualmente ("sa-update && service spamassassin
> reload") se ha actualizado correctamente.
>
> El archivo "/etc/default/spamassassin" dice que la tarea se ejecuta "por
> las noches" (el equipo se apaga por la noche) pero no sé de dónde saca
> esa "nocturnidad" porque el script está en "/etc/cron.daily/spamassassin"
> sin hora concreta de ejecución.
>
> ¿Alguien más sabe qué sucede con este script? ¿Funciona, no funciona, es
> nocturno, diurno, configurable...?
>
> Saludos,
>
> --
> Camaleón
>
>
> --
> To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/pan.2013.06.26.15.03...@gmail.com
>
Re: Configurar registro SPF, BIND9
Es muy "Hotmail" esto que comentás. Si ya tenés todo en orden, puede ser que se tomen su tiempo para aceptar los mail. Por algún lado (no recuerdo) en el soporte de hotmail había un test para realizar sobre tu dominio y el spf. Otra posibilidad es que alguien haya mandado alguna cantidad de mails desde tu dominio que hayan sido marcados como spam. Supongo que trabajan con algún tipo de lista negra interna o alguna estadística propia. Algo que no se está resolviendo es la IP de mail.mauritest.com.ar Saludos, Santiago.- El 18 de diciembre de 2012 11:33, Fernando escribió: > Si entendi bien, deberia ser asi: > > mauritest.com.ar 86400 TXT"v=spf1 ip4:186.153.137.44 a mx > ~all" > > Pero no funciona :/ > > tengo configurado tambien el dns reverso > > http://www.dnswatch.info/dns/dnslookup?la=en&host=186.153.137.44&submit=Resolve > > No puedo encontrar donde reside el problema > > El día 18 de diciembre de 2012 11:16, Santiago Liz > escribió: > > Si el dominio con el cual envías tus mail es mail.mauritest.com.ar, con > esa > > definición de spf estás diciendo que tus mail van a ser enviados desde > la IP > > que mencionás, la IP que resuelva ese nombre y los MX que tengas > definidos > > para ese dominio. > > > > Ahora si tus mail salen con dominio mauritest.com.ar, tendrías que > definir > > el registro TXT para este dominio. > > > > Saludos, > > Santiago.- > > > > El 18 de diciembre de 2012 11:02, Fernando escribió: > > > >> uacion pego mi archivo de configuracion quizas alguien pueda > >> ayudarme o indicarme por donde puedo seguir investigando. > > > > > > > -- > To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > http://lists.debian.org/cakvp9rz3boyhnnrcxapc4rh0jtco72xd6npvmq9oe47aevq...@mail.gmail.com > >
Fwd: Configurar registro SPF, BIND9
Si el dominio con el cual envías tus mail es mail.mauritest.com.ar, con esa definición de spf estás diciendo que tus mail van a ser enviados desde la IP que mencionás, la IP que resuelva ese nombre y los MX que tengas definidos para ese dominio. Ahora si tus mail salen con dominio mauritest.com.ar, tendrías que definir el registro TXT para este dominio. Saludos, Santiago.- El 18 de diciembre de 2012 11:02, Fernando escribió: uacion pego mi archivo de configuracion quizas alguien pueda > ayudarme o indicarme por donde puedo seguir investigando. >
Re: Re: Ayuda Urgente: Iptables e ip rule no funcionan correctamente endebian 6?
Tengo exactamente el mismo problema, con la misma versión de kernel e iptables y una configuración similar. Algo que observo, es que al hacer un tcpdump en alguna de las placas externas, veo algunos paquetes (muy pocos en comparación con el tráfico total) con ip de la otra placa externa. Es decir que el NAT se hace deacuerdo a lo previsto con el marcado, pero termina saliendo por la otra interface. ¿Alguna pista de lo que puede estar pasando? Saludos, Santiago.- El 06/09/12 09:50, Juan Antonio escribió: > El 06/09/12 09:35, Francisco J. Bejarano escribió: >> El 04/09/12 23:19, Juan Antonio escribió: >>> On 05/09/12 16:13, Francisco J. Bejarano wrote: Sep 5 15:24:55 firewall kernel: [1883719.204551] fwmark 1: IN=eth1 OUT= MAC=00:18:8b:f9:f3:34:00:24:8c:de:c8:fb:08:00 SRC=10.0.1.153 DST=10.0.1.1 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=1436 DF PROTO=TCP SPT=57856 DPT=22 WINDOW=16323 RES=0x00 ACK FIN URGP=0 MARK=0x1 Sep 5 15:24:55 firewall kernel: [1883719.205085] fwmark 1: IN=eth1 OUT= MAC=00:18:8b:f9:f3:34:00:24:8c:de:c8:fb:08:00 SRC=10.0.1.153 DST=10.0.1.1 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=1437 DF PROTO=TCP SPT=57856 DPT=22 WINDOW=16323 RES=0x00 ACK URGP=0 MARK=0x1 Sep 5 15:25:20 firewall kernel: [1883744.276724] fwmark 2: IN=eth2 OUT= MAC=00:0d:88:c5:ba:53:20:cf:33:d3:a6:d5:08:00 SRC=10.0.2.226 DST=10.0.2.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=8254 DF PROTO=TCP SPT=52845 DPT=22 WINDOW=2641 RES=0x00 ACK URGP=0 MARK=0x2 Sep 5 15:25:20 firewall kernel: [1883744.280404] fwmark 2: IN=eth2 OUT= MAC=00:0d:88:c5:ba:53:20:cf:33:d3:a6:d5:08:00 SRC=10.0.2.226 DST=10.0.2.1 LEN=100 TOS=0x00 PREC=0x00 TTL=64 ID=8255 DF PROTO=TCP SPT=52845 DPT=22 WINDOW=2641 RES=0x00 ACK PSH URGP=0 MARK=0x2 >>> mmm, a propósito, las direcciones 10.0.2.1 y 10.0.1.1 ¿son las que >>> tiene configuradas la pasarela? fíjate que no se especifica ningún >>> interfaz en OUT = y de hecho ese tráfico no tiene que llegar a >>> ninguna tabla porque es local ¿tienes tráfico en el log marcado que no >>> sea para el propio router? ¿por dónde sale el tráfico que no sale por >>> donde debería? >>> >>> Un saludo. >> Hola, el trafico marcado lo logeo en mangle, prerouting despues de >> marcarlo con 1 o 2. Por eso no tiene out, porque todavia no se ha tomado >> la decision de ruteo. No es local es forward de eth1 o eth2 a la eth que >> corresponda de las adsl. No es para el propio router. >> >> El trafico, en la tabla main tiene un default route a TB2 (debido a >> ciertas necesidades de mi empresa) De hecho se va por ahi el trafico no >> marcado. >> >> >> > > ¿pero por qué se ve en DST una ip del mismo rango de red? Si es tráfico > forwarded debería verse el dst original y la mac del interfaz del router. Te pongo otro trozo de log de una ip de la red interna 2 que va hacia afuera a una ip de internet (forward). Como ves tampoco tiene interfaz out. Asi descarto que fuera mi direccion al firewall ya que estoy conectado por ssh y mi trafico si iria al propio firewall. Sep 5 17:13:51 firewall kernel: [1890254.612411] fwmark 2: IN=eth2 OUT= MAC=00:0d:88:c5:ba:43:90:4c:e5:41:6b:d7:08:00 SRC=10.0.2.121 DST=88.106.32.213 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=312 DF PROTO=TCP SPT=43691 DPT=22 WINDOW=2608 RES=0x00 ACK URGP=0 MARK=0x2 Sep 5 17:13:51 firewall kernel: [1890254.649763] fwmark 2: IN=eth2 OUT= MAC=00:0d:88:c5:ba:43:90:4c:e5:41:6b:d7:08:00 SRC=10.0.2.121 DST=88.106.32.213 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=313 DF PROTO=TCP SPT=43691 DPT=22 WINDOW=2597 RES=0x00 ACK URGP=0 MARK=0x2 > > Si el main default es el mismo que el default de TB2 ¿para que añades > reglas explicitas para usar esa tabla? ¿hay otras rutas en TB2 > diferentes a main? Me parece una configuración muy compleja que > seguramente podrías reducir a 3 o 4 líneas de iptables y dos rules de > iproute, asi podrías depurar mucho mejor. Tengo 5 redes y hay que enviar el trafico dependiendo del origen de la red y dentro del origen de la red dependiendo del puerto del destino. Si es algo complejo pero necesario debido a ciertas validaciones de seguridad de ips en servidores de destino que dependen de donde salga el trafico. Las 2 redes que pongo son de 2 empresas diferentes que comparten la misma salida TB3 (adsls balanceados con ancho de banda elevado) pero que para ciertos traficos, cada empresa ha de salir por su propio adsl con ip fija y solo cuando usa determinados puertos, si no debería usar la TB3, peero, por defecto global se usa una de las TB con ip fija... Yo no pongo las reglas pero he de ceñirme a ellas y esto estaba funcionando correctamente en debian 4 y no creo que haya cambiado mucho iptables a nivel funcionamiento general, o eso espero. De hecho como esta echo debería funcionar a no ser que algo del marcado y prioridades este haciendolo yo mal. > Un saludo. > > -- - Francisco J. Bejarano Responsable de Sistemas Dpt. Sistemas e
