<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Lost in delta quadrant &#187; redes</title>
	<atom:link href="http://www.theefrit.com/blog/category/redes/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.theefrit.com/blog</link>
	<description>too many parsecs</description>
	<lastBuildDate>Sat, 03 Dec 2011 19:49:57 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Adios, co.mments.com</title>
		<link>http://www.theefrit.com/blog/2009/01/11/adios-commentscom/</link>
		<comments>http://www.theefrit.com/blog/2009/01/11/adios-commentscom/#comments</comments>
		<pubDate>Sun, 11 Jan 2009 22:59:53 +0000</pubDate>
		<dc:creator>TheEfrit</dc:creator>
				<category><![CDATA[redes]]></category>
		<category><![CDATA[blogs]]></category>
		<category><![CDATA[cierre]]></category>
		<category><![CDATA[web]]></category>

		<guid isPermaLink="false">http://www.theefrit.com/blog/?p=786</guid>
		<description><![CDATA[Hoy cierra co.mments. Una lástima, era un buen servicio para seguir comentarios publicados por blogs de forma no intrusiva. Me toca volver a pasarme a cocomment.]]></description>
			<content:encoded><![CDATA[<p>Hoy cierra <a href="http://co.mments.com/">co.mments</a>. Una lástima, era un buen servicio para seguir comentarios publicados por blogs de forma no intrusiva.</p>
<div id="attachment_787" class="wp-caption aligncenter" style="width: 560px"><img class="size-medium wp-image-787" title="co.mments.com cierra" src="http://www.theefrit.com/blog/wp-content/uploads/2009/01/comments-550x259.png" alt="co.mments.com cierra" width="550" height="259" /><p class="wp-caption-text">co.mments.com cierra</p></div>
<p>Me toca volver a pasarme a <a href="http://www.cocomment.com/">cocomment</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.theefrit.com/blog/2009/01/11/adios-commentscom/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Bloqueando ataques continuos con fail2ban y denyhosts</title>
		<link>http://www.theefrit.com/blog/2008/05/01/bloqueando-ataques-continuos-con-fail2ban-y-denyhosts/</link>
		<comments>http://www.theefrit.com/blog/2008/05/01/bloqueando-ataques-continuos-con-fail2ban-y-denyhosts/#comments</comments>
		<pubDate>Thu, 01 May 2008 21:12:07 +0000</pubDate>
		<dc:creator>TheEfrit</dc:creator>
				<category><![CDATA[kernelPanic!]]></category>
		<category><![CDATA[redes]]></category>
		<category><![CDATA[ataque]]></category>
		<category><![CDATA[denyhosts]]></category>
		<category><![CDATA[fail2ban]]></category>
		<category><![CDATA[linux]]></category>
		<category><![CDATA[seguridad]]></category>
		<category><![CDATA[ssh]]></category>

		<guid isPermaLink="false">http://www.theefrit.com/blog/?p=408</guid>
		<description><![CDATA[Una de las cosas que uno puede hacer con su conexión a Internet es montarse un servidor de acceso remoto para conectarse a casa desde cualquier parte del mundo IP. Sin embargo, abrir servicios a Internet expone a tu equipo a las inclemencias propias de la red como son ataques remotos. Salvo errores muy críticos [...]]]></description>
			<content:encoded><![CDATA[<p>Una de las cosas que uno puede hacer con su conexión a Internet es montarse un servidor de acceso remoto para conectarse a casa desde cualquier parte del mundo IP. Sin embargo, abrir servicios a Internet expone a tu equipo a las inclemencias propias de la red como son ataques remotos. Salvo errores muy críticos en los programas que se ejecutan, y manteniendo el equipo actualizado, llegar a colarse en tu máquina por un <em>exploit </em>es difícil, pero eso no quita que a diario puedas recibir continuos intentos de acceso no autorizados, sobre todo desde máquinas <em>zombies </em>de una <em>botnet</em>.</p>
<p>Esto es justo lo que le pasa a mi servidor SSH, cuyos registros de acceso fallidos están rebosando de intentos:</p>
<p>[code]<br />
Apr 23 02:20:52 teroknor sshd[31336]: Invalid user noah from 217.126.56.236<br />
Apr 23 02:20:52 teroknor sshd[31336]: pam_unix(ssh:auth): check pass; user unknown<br />
Apr 23 02:20:52 teroknor sshd[31336]: pam_unix(ssh:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=236.red-217-126-56.staticip.rima-tde.net<br />
Apr 23 02:20:54 teroknor sshd[31336]: Failed password for invalid user noah from 217.126.56.236 port 17228 ssh2<br />
Apr 23 02:20:56 teroknor sshd[31339]: Invalid user joseph from 217.126.56.236<br />
Apr 23 02:20:56 teroknor sshd[31339]: pam_unix(ssh:auth): check pass; user unknown<br />
Apr 23 02:20:56 teroknor sshd[31339]: pam_unix(ssh:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=236.red-217-126-56.staticip.rima-tde.net<br />
[/code]</p>
<p>Una solución muy fácil de instalar en el equipo es un <strong>sistema de prevención de intrusión</strong> o <a href="http://en.wikipedia.org/wiki/Intrusion-prevention_system">HIPS</a> basado en analizar periódicamente los registros de acceso con dos programas: <a href="http://denyhosts.sourceforge.net">denyhosts</a> y <a href=" http://www.fail2ban.org/wiki/index.php/OpenSSH">fail2ban</a>.</p>
<p><span id="more-408"></span></p>
<p>Estos dos programas buscan registros de fallos reiterativos de acceso y en caso de detectar demasiados errores de accesos desde una misma IP, automáticamente la bloquean.</p>
<p>Para sistemas con apt y sus poderes de supervaca, coro es el caso de mi Ubuntu 8.04, bastará con conjurarla con un:</p>
<p>[code]<br />
sudo apt-get install denyhosts fail2ban<br />
[/code]</p>
<p>Los instaladores traen una configuración por defecto que funciona sin problema con el servicio open-SSH que trae Ubuntu.</p>
<h3>Fail2ban</h3>
<p>En el caso de <strong>fail2ban </strong>se pueden añadir patrones de búsqueda personalizados para cada registro de actividad gracias a su configuración basada en los ficheros de filtros que se encuentran en <strong>/etc/fail2ban/filter.d/</strong>. Las acciones de bloqueo temporal de los atacantes se basan en insertar reglas en las iptables, el cortafuegos nativo de los sistemas linux.</p>
<p>Para verificar el correcto funcionamiento de las reglas se puede ejecutar el comando <strong>fail2ban-regex</strong>:</p>
<p>[code]fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf[/code]</p>
<p>Su ejecución devolverá algo parecido a lo siguiente:</p>
<p>[code]Running tests<br />
=============</p>
<p>Use regex file : /etc/fail2ban/filter.d/sshd.conf<br />
Use log file   : /var/log/auth.log</p>
<p>Results<br />
=======</p>
<p>Failregex<br />
|- Regular expressions:<br />
|  [1] (?:error: PAM: )?Authentication failure for .* from \s*$<br />
|  [2] Failed [-/\w]+ for .* from (?: port \d*)?(?: ssh\d*)?\s*$<br />
|  [3] ROOT LOGIN REFUSED.* FROM \s*$<br />
|  [4] [iI](?:llegal|nvalid) user .* from \s*$<br />
|  [5] User .+ from  not allowed because not listed in AllowUsers\s*$<br />
|  [6] User .+ from  not allowed because none of user's groups are listed in AllowGroups\s*$<br />
|<br />
`- Number of matches:<br />
[1] 0 match(es)<br />
[2] 1338 match(es)<br />
[3] 0 match(es)<br />
[4] 932 match(es)<br />
[5] 0 match(es)<br />
[6] 0 match(es)</p>
<p>Ignoreregex<br />
|- Regular expressions:<br />
|<br />
`- Number of matches:</p>
<p>Summary<br />
=======</p>
<p>Addresses found:<br />
[1]<br />
[2]<br />
60.28.167.66 (Mon Apr 21 16:04:29 2008)<br />
200.41.1.220 (Mon Apr 21 20:24:09 2008)<br />
200.41.1.220 (Mon Apr 21 20:24:17 2008)<br />
[...]<br />
217.126.56.236 (Wed Apr 23 02:21:24 2008)<br />
217.126.56.236 (Wed Apr 23 02:21:27 2008)<br />
217.126.56.236 (Wed Apr 23 02:21:31 2008)<br />
217.126.56.236 (Wed Apr 23 02:21:34 2008)<br />
[5]<br />
[6]</p>
<p>Date template hits:<br />
2270 hit(s): Month Day Hour:Minute:Second<br />
0 hit(s): Weekday Month Day Hour:Minute:Second Year<br />
0 hit(s): Weekday Month Day Hour:Minute:Second<br />
0 hit(s): Year/Month/Day Hour:Minute:Second<br />
0 hit(s): Day/Month/Year:Hour:Minute:Second<br />
0 hit(s): Year-Month-Day Hour:Minute:Second<br />
0 hit(s): Day-Month-Year Hour:Minute:Second[.Millisecond]<br />
0 hit(s): TAI64N<br />
0 hit(s): Epoch</p>
<p>Success, the total number of match is 2270<br />
[/code]</p>
<p>Cuando se está ejecutando en segundo plano podemos ver el registro de actividad que va dejando en <strong>/var/log/fail2ban.log</strong>. Por defecto las reglas de rechazo de una determinada duran diez minutos, tiempo más que suficiente para que los molestos zombies desistan.</p>
<p>Más información en su <a href="http://www.fail2ban.org">sitio web oficial</a>.</p>
<h3>DenyHosts</h3>
<p>DenyHosts es un HIPS exclusivo para SSH y se basa por un lado en el análisis de los registros de acceso del servidor SSH y por otro de listas de IPs conocidas que se descargan y sincronizan desde el servidor principal de DenyHosts. Cuenta con más de 27000 sincronizaciones y es un bastante eficiente para protegerse de máquinas que ya se conocen como atacantes, frente a fail2ban, que realiza únicamente análisis de los registros.</p>
<p>El funcionamiento de DenyHosts se basa en ir añadiendo o eliminando direcciones IP al fichero <strong>/etc/hosts.deny</strong> que luego el servicio de SSH tiene en cuenta a la hora de rechazar intentos de conexión.</p>
<p>La configuración por defecto del paquete de las distribuciones de Debian/Ubuntu dejan en el fichero <strong>/etc/denyhosts.conf</strong> la configuración de este demonio. Si queremos que se sincronice con el servidor de DenyHosts de forma periódica, es necesario descomentar una línea del fichero de configuración por defecto, <strong> SYNC_SERVER</strong>=&#8230; y si además queremos que cada vez que actúe se registre en los registros del sistema, deberemos poner <strong>SYSLOG_REPORT</strong> a <strong>Yes</strong>.</p>
<p>[code]SYSLOG_REPORT=YES<br />
SYNC_SERVER = http://xmlrpc.denyhosts.net:9911[/code]</p>
<p>Si observamos los registros de actividad del sistema, veremos cosas como esta:</p>
<p>[code]theefrit@teroknor:~$ cat /var/log/syslog | grep deny<br />
May  1 14:21:56 teroknor denyhosts: Added the following hosts to /etc/hosts.deny - 203.212.65.20 (unknown)[/code]</p>
<p>En el fichero de registro de actividad específico de DenyHosts, <strong>/var/log/denyhosts</strong>,  podemos ver con detalle toda su actividad de sincronización remota.</p>
<p>Más información en la <a href="http://denyhosts.sourceforge.net">página del programa</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.theefrit.com/blog/2008/05/01/bloqueando-ataques-continuos-con-fail2ban-y-denyhosts/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Cuando se caen los DNS, Telefónica censura</title>
		<link>http://www.theefrit.com/blog/2007/03/27/cuando-se-caen-los-dns-telefonica-censura/</link>
		<comments>http://www.theefrit.com/blog/2007/03/27/cuando-se-caen-los-dns-telefonica-censura/#comments</comments>
		<pubDate>Tue, 27 Mar 2007 20:00:20 +0000</pubDate>
		<dc:creator>TheEfrit</dc:creator>
				<category><![CDATA[redes]]></category>
		<category><![CDATA[censura]]></category>
		<category><![CDATA[dig]]></category>
		<category><![CDATA[dns]]></category>
		<category><![CDATA[error]]></category>
		<category><![CDATA[telefonica]]></category>

		<guid isPermaLink="false">http://www.theefrit.com/blog/2007/03/27/cuando-se-caen-los-dns-telefonica-censura/</guid>
		<description><![CDATA[La alegría con que la gente se apresura a afirmar que Telefónica está censurando páginas dedicadas al intercambio de enlaces p2p es cuanto menos curiosa. Ciñéndonos un poco a los hechos, hace una hora he visto en el feed de Meneame que Telefónica censura Internet. En la entrada original, cuentan cómo no pueden acceder desde [...]]]></description>
			<content:encoded><![CDATA[<p>La alegría con que la gente se apresura a afirmar que Telefónica está censurando páginas dedicadas al intercambio de enlaces p2p es cuanto menos curiosa. Ciñéndonos un poco a los hechos, hace una hora he visto en el feed de <a href="http://www.meneame.net/">Meneame</a> que <a href="http://meneame.net/story/telefonica-censura-internet">Telefónica censura Internet</a>. En la <a href="http://www.nukeador.com/27/03/2007/telefonica-censura-internet/">entrada original</a>, cuentan cómo no pueden acceder desde las ADSL de Telefónica a ciertas páginas. Afirma además que &#8220;<em>terra aun no las capa</em>.&#8221;</p>
<p>Veamos, si Terra lo único que es, bueno, era, un revendedor de ADSL de Telefónica y usa su infraestructura. Yo, como cliente de Terra voy a comprobar si tiran esas páginas. Aparentemente, el DNS falla. ¿Censura? Nada más lejos de la realidad. Lo que está pasando es que algún servidor DNS está caído. O bien los de Telefónica o bien alguno a los que se sincroniza. Si nos ponemos a mirar un poco más damos enseguida con el problema.</p>
<p><span id="more-346"></span></p>
<p>El asunto radica en que el Registrar de los dominios &#8220;censurados&#8221;, <a href="http://www.enom.com/registrynews.asp">eNom inc.</a> ha debido de tener un problema o bien en la sincronización o peticiones entre los DNS de Telefónica y los suyos algo ha ido mal y por eso para Telefónica esos nombres de dominio no se resuelven.</p>
<p>Vamos a usar un poco la maravillosa herramienta dig para arrojar algo de luz. Antes de nada, el escenario: mi casa. Como diría E.T. Tengo configurados los DNS de Telefónica 194.179.1.100 y 194.179.1.101. Si hacemos una petición a uno de los dominios afectados, como gamestorrents.com, vemos lo siguiente:</p>
<p>[code]theefrit@teroknor:/tmp$ dig @194.179.1.100 gamestorrents.com</p>
<p>; <<>> DiG 9.3.4 <<>> @194.179.1.100 gamestorrents.com<br />
; (1 server found)<br />
;; global options:  printcmd<br />
;; Got answer:<br />
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26509<br />
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0</p>
<p>;; QUESTION SECTION:<br />
;gamestorrents.com.   IN A</p>
<p>;; Query time: 90 msec<br />
;; SERVER: 194.179.1.100#53(194.179.1.100)<br />
;; WHEN: Tue Mar 27 18:12:41 2007<br />
;; MSG SIZE  rcvd: 35<br />
[/code]</p>
<p>Parece que hay un fallo con los DNS, devuelve un <code><strong>SERVFAIL</strong></code>. Probemos ahora con otro, newpct.com:</p>
<p>[code]<br />
theefrit@teroknor:/tmp$ dig @194.179.1.100 newpct.com</p>
<p>; <<>> DiG 9.3.4 <<>> @194.179.1.100 newpct.com<br />
; (1 server found)<br />
;; global options:  printcmd<br />
;; Got answer:<br />
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 687<br />
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0</p>
<p>;; QUESTION SECTION:<br />
;newpct.com.    IN   A</p>
<p>;; Query time: 50 msec<br />
;; SERVER: 194.179.1.100#53(194.179.1.100)<br />
;; WHEN: Tue Mar 27 18:16:33 2007<br />
;; MSG SIZE  rcvd: 28<br />
[/code]</p>
<p>Mismo error. Aún no sabemos si Telefónica censura o qué está pasando. Veamos otros servidores, como los de <a href="http://www.opendns.com/">OpenDNS</a>:</p>
<p>[code]theefrit@teroknor:/tmp$ dig @208.67.222.222 newpct.com</p>
<p>; <<>> DiG 9.3.4 <<>> @208.67.222.222 newpct.com<br />
; (1 server found)<br />
;; global options:  printcmd<br />
;; Got answer:<br />
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30966<br />
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0</p>
<p>;; QUESTION SECTION:<br />
;newpct.com.    IN   A</p>
<p>;; ANSWER SECTION:<br />
newpct.com.  1800 IN A 85.17.17.50</p>
<p>;; Query time: 220 msec<br />
;; SERVER: 208.67.222.222#53(208.67.222.222)<br />
;; WHEN: Tue Mar 27 18:18:39 2007<br />
;; MSG SIZE  rcvd: 44<br />
[/code]</p>
<p>La opción <code><strong>@IP</strong></code> permite fijar un servidor de DNS distinto. <strong>NOERROR</strong>, esta ha ido bien. Vale, aparentemente no tira bien la cosa con los DNS de Telefónica. ¿Qué tienen en común estos sitios que fallan? Los WHOIS dan la clave:</p>
<p>[code]theefrit@teroknor:/tmp$ whois newpct.com</p>
<p>Whois Server Version 2.0</p>
<p>Domain names in the .com and .net domains can now be registered<br />
with many different competing registrars. Go to http://www.internic.net<br />
for detailed information.</p>
<p>   Domain Name: NEWPCT.COM<br />
   <strong>Registrar: ENOM, INC.</strong><br />
   Whois Server: whois.enom.com<br />
   Referral URL: http://www.enom.com<br />
[/code]<br />
[code]theefrit@teroknor:/tmp$ whois gamestorrents.com</p>
<p>Whois Server Version 2.0</p>
<p>Domain names in the .com and .net domains can now be registered<br />
with many different competing registrars. Go to http://www.internic.net<br />
for detailed information.</p>
<p>   Domain Name: GAMESTORRENTS.COM<br />
   <strong>Registrar: ENOM, INC.</strong><br />
   Whois Server: whois.enom.com<br />
   Referral URL: http://www.enom.com<br />
   Name Server: DNS1.NAME-SERVICES.COM<br />
[/code]</p>
<p>Aquí vamos viendo que los dos dominios están en el mismo Registrar de DNS, ENOM, INC. Vamos a ver si Enom tira:</p>
<p>[code]theefrit@teroknor:/tmp$ dig @194.179.1.100 enom.com</p>
<p>; <<>> DiG 9.3.4 <<>> @194.179.1.100 enom.com<br />
; (1 server found)<br />
;; global options:  printcmd<br />
;; Got answer:<br />
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6375<br />
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0</p>
<p>;; QUESTION SECTION:<br />
;enom.com.   IN A</p>
<p>;; Query time: 56 msec<br />
;; SERVER: 194.179.1.100#53(194.179.1.100)<br />
;; WHEN: Tue Mar 27 18:22:20 2007<br />
;; MSG SIZE  rcvd: 26<br />
[/code]</p>
<p>También falla. Ups. Parece que algo no tira con los DNS de Telefónica y Enom. No creo que Telefónica se cargue así por las buenas ni aunque se lo pidan los reyes de la fritanga o el clan Bardem al unísono. Más bien va a ser una caída en el servicio. Llegados a este punto, las soluciones:</p>
<ol>
<li>La sencilla y rápida: cambiar de DNS, los de OpenDNS nos pueden valer, tal como sugerían en el artículo original, <strong>208.67.222.222</strong> y <strong>208.67.220.220</strong>. Cuando Telefónica resuelva la incidencia, podemos volver a los del ISP, que seguramente estarán menos cargados. Digo seguramente, nunca se sabe.</li>
<li>La del buen samaritano: llamar al servicio técnico y dar parte, armándote de paciencia para explicar al primer operador del 902 que no es un problema con tu Outlook ni tienes virus ni te interesa comprar una casa con ADSL. Luego puedes cambiar de DNS o echarle más paciencia hasta que se resuelva el asunto.</li>
</ol>
<p>Y como conclusión, ¿hay que saber todo esto para determinar si Telefónica censura? La respuesta es <strong>NO</strong>. Lo que hay que hacer es no precipitarse, comprobar primero que no somos nosotros los que fallamos y llamar al servicio técnico. Si sabemos un poco de por dónde van los tiros, probar un DNS distinto y si no, nos tocará cagarnos un poquito en alguien, pero no llegar al extremo de lanzar a los cuatro vientos que Telefónica está censurando páginas de p2p. No adelantemos acontecimientos, por favor.</p>
<p>Sosiego y calma.</p>
<hr/>
<p><strong>Actualización 20:56</strong>: a raíz del comentario de <a href="http://www.nukeador.com/">Nukeador</a>, sobre si afecta a todos los dominios registrados en Enom, he estado indagando más. El problema exacto es un fallo de conectividad entre los DNS de NAME-SERVICES.COM y los de Telefónica. Sus servidores de nombres, nsX.name-services.com parecen estar caídos y no responden a ping ni a ninguna solicitud desde mi conexión, que <em>sale al mundo</em> vía Telefónica. Si al hacer el WHOIS del dominio registrado en Enom se obtiene que los servidores de nombres son de name-services.com, como pasa con los dominios perdidos, entonces no funcionará la resolución de nombres. En el caso de Nukeador, su dominio nukeador.com tiene otros servidores de nombres, accesibles desde la red de Telefónica y por tanto, la resolución del nombre funcionará.</p>
<p>El comando de linux dig permite además hacer trazas para ver hasta dónde llegas directamente desde tu equipo al resolver nombres:</p>
<p>[code]dig @SERVIDOR_NOMBRES nombre.tld +trace[/code]</p>
<p>Así, podemos ver:</p>
<p>[code]theefrit@teroknor:~$ dig @194.179.1.100 nukeador.com +trace</p>
<p>; <<>> DiG 9.3.4 <<>> @194.179.1.100 nukeador.com +trace<br />
; (1 server found)<br />
;; global options:  printcmd<br />
.                       95296   IN      NS      a.root-servers.net.<br />
.                       95296   IN      NS      b.root-servers.net.<br />
.                       95296   IN      NS      c.root-servers.net.<br />
.                       95296   IN      NS      d.root-servers.net.<br />
.                       95296   IN      NS      e.root-servers.net.<br />
.                       95296   IN      NS      f.root-servers.net.<br />
.                       95296   IN      NS      g.root-servers.net.<br />
.                       95296   IN      NS      h.root-servers.net.<br />
.                       95296   IN      NS      i.root-servers.net.<br />
.                       95296   IN      NS      j.root-servers.net.<br />
.                       95296   IN      NS      k.root-servers.net.<br />
.                       95296   IN      NS      l.root-servers.net.<br />
.                       95296   IN      NS      m.root-servers.net.<br />
;; Received 436 bytes from 194.179.1.100#53(194.179.1.100) in 657 ms</p>
<p>com.                    172800  IN      NS      F.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      G.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      H.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      I.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      J.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      K.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      L.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      M.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      A.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      B.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      C.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      D.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      E.GTLD-SERVERS.NET.<br />
;; Received 502 bytes from 198.41.0.4#53(a.root-servers.net) in 1070 ms</p>
<p>nukeador.com.           172800  IN      NS      ns1.dnspropio.com.<br />
nukeador.com.           172800  IN      NS      ns2.dnspropio.com.<br />
;; Received 108 bytes from 192.35.51.30#53(F.GTLD-SERVERS.NET) in 2673 ms</p>
<p>nukeador.com.           14400   IN      A       195.140.142.122<br />
nukeador.com.           14400   IN      NS      ns2.dnspropio.com.<br />
nukeador.com.           14400   IN      NS      ns1.dnspropio.com.<br />
;; Received 92 bytes from 195.140.142.122#53(ns1.dnspropio.com) in 1461 ms<br />
[/code]</p>
<p>Mientras que si intentamos lo mismo con uno de los fallidos:</p>
<p>[code]theefrit@teroknor:~$ dig @194.179.1.100 newpct.com +trace</p>
<p>; <<>> DiG 9.3.4 <<>> @194.179.1.100 newpct.com +trace<br />
; (1 server found)<br />
;; global options:  printcmd<br />
.                       95480   IN      NS      a.root-servers.net.<br />
.                       95480   IN      NS      b.root-servers.net.<br />
.                       95480   IN      NS      c.root-servers.net.<br />
.                       95480   IN      NS      d.root-servers.net.<br />
.                       95480   IN      NS      e.root-servers.net.<br />
.                       95480   IN      NS      f.root-servers.net.<br />
.                       95480   IN      NS      g.root-servers.net.<br />
.                       95480   IN      NS      h.root-servers.net.<br />
.                       95480   IN      NS      i.root-servers.net.<br />
.                       95480   IN      NS      j.root-servers.net.<br />
.                       95480   IN      NS      k.root-servers.net.<br />
.                       95480   IN      NS      l.root-servers.net.<br />
.                       95480   IN      NS      m.root-servers.net.<br />
;; Received 436 bytes from 194.179.1.100#53(194.179.1.100) in 690 ms</p>
<p>com.                    172800  IN      NS      B.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      C.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      D.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      E.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      F.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      G.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      H.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      I.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      J.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      K.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      L.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      M.GTLD-SERVERS.NET.<br />
com.                    172800  IN      NS      A.GTLD-SERVERS.NET.<br />
;; Received 500 bytes from 198.41.0.4#53(a.root-servers.net) in 794 ms</p>
<p>newpct.com.             172800  IN      NS      dns1.name-services.com.<br />
newpct.com.             172800  IN      NS      dns2.name-services.com.<br />
newpct.com.             172800  IN      NS      dns3.name-services.com.<br />
newpct.com.             172800  IN      NS      dns4.name-services.com.<br />
newpct.com.             172800  IN      NS      dns5.name-services.com.<br />
;; Received 217 bytes from 192.33.14.30#53(B.GTLD-SERVERS.NET) in 2700 ms</p>
<p>;; reply from unexpected source: 127.0.0.1#53, expected 216.52.184.230#53<br />
;; Warning: ID mismatch: expected ID 21051, got 53005<br />
;; reply from unexpected source: 127.0.0.1#53, expected 63.251.92.193#53<br />
;; Warning: ID mismatch: expected ID 21051, got 65011<br />
;; reply from unexpected source: 127.0.0.1#53, expected 216.52.184.230#53<br />
;; Warning: ID mismatch: expected ID 21051, got 53005<br />
;; reply from unexpected source: 127.0.0.1#53, expected 63.251.92.193#53<br />
;; Warning: ID mismatch: expected ID 21051, got 65011<br />
;; reply from unexpected source: 127.0.0.1#53, expected 64.74.96.242#53<br />
;; Warning: ID mismatch: expected ID 21051, got 26660<br />
;; reply from unexpected source: 127.0.0.1#53, expected 64.74.96.242#53<br />
;; Warning: ID mismatch: expected ID 21051, got 26660<br />
;; connection timed out; no servers could be reached<br />
[/code]</p>
<p>En este caso dig se va conectando a los servidores de nombres uno detrás de otro, en vez de dejar que el primero -194.179.1.100 en este caso- resuelva conectándose a quien considere oportuno. Como se puede ver, no hay forma de llegar a los servidores de nombres de name-services.com desde la red de Telefónica.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.theefrit.com/blog/2007/03/27/cuando-se-caen-los-dns-telefonica-censura/feed/</wfw:commentRss>
		<slash:comments>6</slash:comments>
		</item>
		<item>
		<title>Ahorrando cables con Power Over Ethernet</title>
		<link>http://www.theefrit.com/blog/2007/01/07/ahorrando-cables-con-power-over-ethernet/</link>
		<comments>http://www.theefrit.com/blog/2007/01/07/ahorrando-cables-con-power-over-ethernet/#comments</comments>
		<pubDate>Sun, 07 Jan 2007 11:38:47 +0000</pubDate>
		<dc:creator>TheEfrit</dc:creator>
				<category><![CDATA[captain's log]]></category>
		<category><![CDATA[redes]]></category>
		<category><![CDATA[ethernet]]></category>
		<category><![CDATA[linksys]]></category>
		<category><![CDATA[network-infraestructure]]></category>
		<category><![CDATA[poe]]></category>
		<category><![CDATA[power-over-ethernet]]></category>

		<guid isPermaLink="false">http://www.theefrit.com/blog/2007/01/07/ahorrando-cables-con-power-over-ethernet/es/</guid>
		<description><![CDATA[Las vacaciones de Navidad sirven entre otras cosas para poderse dedicar a arreglar problemillas y hacer chapuzas que uno tiene pendientes por casa. En mi caso, tocaba entre otras cosas buscar una ubicación mejor para mi punto de acceso para que llegue a todos los rincones de la casa y sin que tuviera las caídas [...]]]></description>
			<content:encoded><![CDATA[<p>Las vacaciones de Navidad sirven entre otras cosas para poderse dedicar a arreglar problemillas y hacer chapuzas que uno tiene pendientes por casa. En mi caso, tocaba entre otras cosas buscar una ubicación mejor para mi punto de acceso para que llegue a todos los rincones de la casa y sin que tuviera las caídas de señal que sufro de vez en cuando, <em>hasta donde ningún AP haya llegado antes</em>. El caso es que tras conectarle el cable de red más largo que tenía y un alargador para el transformador, me puse a moverlo. Al final acabó bastante lejos de su antigua ubicación, con un alargador y encima conectado &#8220;fuera&#8221; del SAI de protección eléctrica.</p>
<p><img src="http://www.theefrit.com/blog/wp-content/uploads/2007/01/wappoe12_c1.jpg" alt="WAPPOE12 Elementos" title="WAPPOE12 Elementos" style="border:0px none;" class="right" align="right" width="300" height="109" /></p>
<p>Para colmo, tanto cable y alargador pone a mi madre de los nervios, así que tocaba buscar una solución para eliminar cables. Recordando las <em>enseñanzas </em>de la carrera, en una optativa de segundo ciclo comentaban todas las distintas tecnologías para conectividad local y una de ellas es el <a href="http://en.wikipedia.org/wiki/Power_over_ethernet">Power Over Ethernet</a>, una solución para llevar alimentación eléctrica por el mismo cable de datos de las redes de área local ethernet. Por desgracia aún no hay mucho producto en el mercado, pero <a href="http://www.linksys.com/">Linksys</a>, fabricante de mi punto de acceso tiene un <a href="http://www.linksys.com/servlet/Satellite?c=L_Product_C2&#038;childpagename=US%2FLayout&#038;cid=1115416830213&#038;pagename=Linksys%2FCommon%2FVisitorWrapper">pequeño kit</a> para precisamente hacer lo que quería hacer: eliminar el cable eléctrico y poder volver a tener todos los cacharros detrás de la protección del SAI.</p>
<p><span id="more-281"></span>
<p>Así que manos a la obra, encargado y recibido el juguete, <a href="http://www.linksys.com/servlet/Satellite?c=L_Product_C2&#038;childpagename=US%2FLayout&#038;cid=1115416830213&#038;pagename=Linksys%2FCommon%2FVisitorWrapper">WAPPOE12</a>, por unos 40€, tenemos los siguientes elementos:</p>
<div class="imgMiddleContainer">[fa:p:id=347904641,s=m,l=p]</div>
<ul>
<li>Inyector de potencia al cable de red, el elemento <a href="http://en.wikipedia.org/wiki/Power_Sourcing_Equipment">PSE</a></li>
<li>Separador de datos y alimentación, que esl el Power Device o PD en este caso, ya que el AP no soporta POE.</li>
<li>Transformador para alimentar al inyector.</li>
<li>Cable eléctrico para conectar el transformador a la red eléctrica.</li>
<li><a href="http://en.wikipedia.org/wiki/Category_5_cable">Cable de red UTP de categoría 5</a> para unir el inyector con el separador en caso de que no tengamos.</li>
<p>El esquema de conexión es bien sencillo:</p>
<div class="imgMiddleContainer"><a class="imagelink" href="http://www.theefrit.com/blog/wp-content/uploads/2007/01/linksys_wappoe12_kit_conexiones.png" title="Linksys WAPPOE12, esquema de conexión"><img id="image280" src="http://www.theefrit.com/blog/wp-content/uploads/2007/01/linksys_wappoe12_kit_conexiones.png" alt="Linksys WAPPOE12, esquema de conexión" style="width: 700px" /></a></div>
<p>Este kit cumple con la especificación del IEEE 802.3, 802.3u y 802.3af para Power Over Ethernet, inyectando 48V de continúa por el cable de red y permitiendo una separación máxima de 100 metros, así que no hay problema con las distancias a alcanzar, antes deja de funcionar la ethernet. La potencia máxima que permite este estándar es de 15.4 watios con una corriente máxima de 400 mA. Al final, a la &#8220;salida&#8221; del conector de alimentación del separador le entrega al punto de acceso 12 bonitos voltios con los que alimentar las antenas y sus circuitos. Eso sí, aunque indica que cumple la especificación 802.3af, que es capaz de trabajar con cables de categoría inferior a la 5, en las especificaciones indican que se precisa de un CAT5 o superior para que funcione correctamente todo y no se produzcan pérdidas de datos.</p>
<p>Una vez alimentado el inyector, éste no se pondrá a meter <em>chicha</em> al cable de datos hasta que no conectemos también el cable de red que comunica el inyector con el switch o el cacharro que tengamos en la infraestructura de red local que dote de conectividad al punto de acceso con el resto de la red. Además, tanto el inyector como el separador incorporan un diodo LED indicador de si reciben o no alimentación.</p>
<p>En definitiva, con estos dos dispositivos de escaso tamaño (80 mm x 22 mm x 56 mm) nos ahorramos tener que llevar un cable más de alimentación hasta elementos de red. De acuerdo que la solución es bastante más cara que <a href="http://barrapunto.com/article.pl?sid=06/12/12/185200">hacerlo a mano</a>, pero paso de volar equipamiento que cuesta más porque se me olvide respetar la polaridad o bien degradar el cable tanto que tenga más pérdidas de datos que otra cosa.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.theefrit.com/blog/2007/01/07/ahorrando-cables-con-power-over-ethernet/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Pasó el fin de los días</title>
		<link>http://www.theefrit.com/blog/2006/06/07/paso-el-fin-de-los-dias/</link>
		<comments>http://www.theefrit.com/blog/2006/06/07/paso-el-fin-de-los-dias/#comments</comments>
		<pubDate>Wed, 07 Jun 2006 08:02:56 +0000</pubDate>
		<dc:creator>TheEfrit</dc:creator>
				<category><![CDATA[redes]]></category>

		<guid isPermaLink="false">http://www.theefrit.com/blog/2006/06/07/paso-el-fin-de-los-dias/</guid>
		<description><![CDATA[Y contra todo pronóstico, el mundo parece que no acabó ayer. Lo que sí que acabó ayer fue 6Bone e IPv6 pasa oficialmente a producción y en IPv6Day, una wiki montada para el evento nos lo contaban. Es una página interesante ya que cuenta con documentación y enlaces a sitios y servicios IPv6 y merece [...]]]></description>
			<content:encoded><![CDATA[<p>Y contra todo pronóstico, el mundo parece que no acabó ayer.</p>
<p>Lo que sí que acabó ayer fue 6Bone e IPv6 pasa <em>oficialmente</em> a producción y en <a title="Página del IPv6 Day" href="http://www.ipv6day.org">IPv6Day</a>, una wiki montada para el evento nos lo contaban. Es una página interesante ya que cuenta con documentación y enlaces a <a title="Listado de servicios v6" href="http://www.ipv6day.org/action.php?n=En.Services">sitios y servicios IPv6</a> y merece la pena perder un poco de tiempo viendo las posibilidades del v6 -y no hablamos coches.</p>
<p>Para el común de los mortales que tenga conexión a Internet en casa v4, se puede solicitar a un <em>tunnel broker</em> de forma totalmente gratuita la asignación de un rango de direcciones v6 y la creación de un túnel <em>6to4</em> para poder acceder a sitios <em>versión 6</em>. Telefónica I+D tiene montado un <a title="Portal IPv6 de TID" href="http://www.portalv6.com">portal</a>, que aunque no actualiza muy a menudo, tiene un <em>broker</em> gratuito y con instrucciones de instalación para los sistemas operativos más comunes, que incluye a los de <a title="Microsoft" href="http://www.microsoft.com">Redmond</a> y distribuciones Linux.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.theefrit.com/blog/2006/06/07/paso-el-fin-de-los-dias/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

