cache1.dnsresolvers.com -> 205.210.42.205
cache2.dnsresolvers.com -> 66.207.199.44

Server Load Balancing berfungsi sebagai berikut :

1. menerima trafik dari sebuah network misalnya web traffic dan mengarahkannya ke site tertentu.
2. melakukan split trafik menjadi individual request dan menentukan server mana yang akan menerima individual request tersebut.
3. memantau server dengan menyakinkan bahwa server tersebut bertanggung jawab terhadap traffik.
4. memberikan redudansi dengan mengaktifkan server lebih dari satu unit melalui mekanisme fail-over.
5. menawarkan distribusi content seperti pembacaan URL, interconnecting cookies, dan XML parsing.

Awal Pemakaian

Internet awalnya digunakan sebagian besar oleh para akademisi dan sangat sedikit digunakan oleh orang umum. Ketika terjadi booming internet di tahun 1995 menjadikan sebuah server tunggal tidak akan mampu mengatasi dan memproses keinginan pengguna setiap harinya apalagi sejak internet digunakan dalam dunia perdagangan dengan e-commerce dan applikasi multimedia lainnya. Disaat seperti inilah orang mulai mencari cara untuk mengatasi redudansi kinerja server terhadap traffik yang terus meningkat.

Perkembangan

Jika sebuah server telah bekerja pada batas limitnya maka seorang administrator biasanya melakukan penambahan RAM atau melakukan upgrading processor untuk mendapatkan hasil yang lebih baik. Namun hal seperti itu tidak dapat terlalu membantu. Ada saatnya walaupun kita telah melakukan setting optimal terhadap hardware dan sistem operasi yang digunakan kegagalan server mesih sering terjadi.

DNS Load Balancing

Sebelum kita mengenal teknologi SLB, seorang server administrator terlebih dahulu harus menerapkan proses Load Balancing yang dikenal dengan DNS round robin. DNS roun robin menggunakan fungsi DNS untuk menggunakan satu IP address digunakan bersama pada sebuah hostname. Setiap entry DNS diketahui sebagai record yang memetakan sebuah hostname (misalnya www.nengnong.net) ke sebuah IP Address misalnya adalah 208.185.43.202. Biasanya hanya satu IP Addresss yang diberikan untuk satu hostname. Dengan ISO DNS server, BIND 8, maka DNS entri untuk www.nengnong.net bisa dilihat seperti berikut :

www.nengnong.net IN 208.185.43.202

Dengan DNS round robin maka dimungkinkan multiple IP address digunakna pada sebuah hostname yang dapat digunakan untuk mendistribusikan trafik sehingga tidak terlalu sibuk seperti halnya hanya menggunakan satu IP Address. Singkatnya disini kita bisa melihat tiga IP Address untuk sebuah web server yakni 208.185.43.202, 208.185.43.203, dan 208.185.43.204 yang di sharing dan di gunakan oleh www.nengnong.net. Konfigurasi DNS server untuk ketiga IP Address tersebut adalah seperti berikut :

www.nengnong.net IN A 202.185.43.202

IN A 202.185.43.203

IN A 202.185.43.204

Kita bisa cek effek dari penggunaan DNS dengan nslookup, seperti berikut :

[n3]# nslookup www.nengnong.net

Server: ns1.nengnong.net

Address: 198.143.25.15

Name: www.nengnong.net

Addresses: 208.185.43.202, 208.185.43.203, 208.185.43.204

Dengan demikian distribusi trafik untuk www.nengnong.net terbagi menjadi tiga seperti pada gambar berikut :

Terlihat bahwa distribusi dengan DNS round robin sederhana, namun menggapa mesti menggunakan SLB? Alasannya adalah DNS round robin masih memiliki keterbatasan, distribusi trafik yang tidak dapat diprediksi, caching isue, dan pengukuran kesalahan yang sulit dilakukan.

DNS 101

DNS berasosiasi dengan IP address dengan sebuah hostname sehingga kita tidak perlu mengingat angka-angka yang rumit. Setiap komputer yang terhubung ke Internet harus memiliki IP Address. Ketika user mengetikan URL sebuah hostname pada Browser, maka sistem operasi akan mengirimkan queri untuk melakukan konfigurasi DNS Server terhadap hostname tersebut. DNS server tersebut biasanya tidak memberikan informasi (kecuali di cached) sehingga domain name server mencari nama domain dengan root server. Root server juga tidak memiliki informasi IP Address tapi mengetahui siapa yang memiliki kemudian memberikan laporan kepada DNS server user. Detail prosesnya dijelaskan seperti berikut :

1. User mengetikan URL ke dalam browser
2. Operating System melakukan DNS request untuk mengkonfigurasi DNS server.
3. DNS server melihat apakah ada IP Address yang di cached. Jika tidak maka melakukan query pada Root Server untuk mencari informasi DNS server yang dimaksudkan.
4. Root server kemudian membalas dengan authoritative DNS Server terhadap request dari hostname.
5. DNS server melakukan query terhadap auhoritative DNS server dan menerima respon.

Caching

Salah satu keterbatasan pada DNS round robin adalah DNS caching. Untuk mengindari DNS Server dari banyaknya request yang sama dan menjaga utilisasi bandtwith maka DNS Server melakukan DNS caching. Selama informasi pada DNS mengalami perubahan yang tidak berarti maka akan berfungsi seperti biasa. Namun jika DNS server memberikan masukan baru pada DNS maka sistem akan mencaching entri tersebut sampai entri tersebut expired.

Distribusi Trafik

Distribusi trafik juga merupakan salah satu masalah pada DNS round robin. DNS round robin akan mendistribusikan trafik pada IP Address yang telah diberikan pada sebuah hostname. Jika ada tiga IP Address yang diberikan maka trafik akan di distribusikan ke masing-masing ketiga IP tersebut. Jika ada empat IP address yang diberikan maka trafik akan didistribusikan pada keempat IP tersebut. Namun permasalahannya distribusi trafik sangat signifikan dan tidak selalu stabil. Gambar berikut menunjukan scenario failure pada DNS berbasis load balancing.

Evolusi

Sangat jelas bahwa SLB digunakan untuk mengatasi masalah redudansi, skalabiliti, dan manajemen yang diinginkan. Web Sites saat ini terus tumbuh semakin banyak. Saat ini downtime adalah asosiasi dengan sebuah ukuran rupiah. Beberapa situs kehilangan jutaan rupiah setiap menitnya hanya karena server mengalami down. SLB dibutuhkan untuk mengatasi hal ini. Load Balancing bekerja dengan trafik yang diarahkan pada situs. Satu URL, satu IP Address, dan load lancing digunakan untuk mendistribusikannya dengan baik. SLB memiliki beberapa keuntungan diantaranya adalah :

Fleksibel

dengan SLB kita dapat menambah atau mengurangi jumlah server pada site kita setiap saat. Keuntungan dari sistem ini adalah perawatan pada mesin dapat dilakukan dengan benar. SLB juga dapat mengarahkan trafik pada cookies, URL parsing, algoritma statik dan dinamis dan masih banyak lagi.

Availability Tinggi

SLB dapat melakukan pengecekan status available sebuah server, mengontrol server yang tidak merespon rotasi dan mengembalikannya pada rotasi sehingga berfungsi kembali. Dilakukan secara otomatis tanpa memerlukan intervensi dari administrator.

Load balancer dimulai dari perangkat berbasis PC, tapi sekarang fungsi loadbalancing juga dapat dilakukan pada switch atau router.

Teknologi Lainnya

SLB bekerja dengan melakukan manipulasi tujuan paket jaringan untuk server. Ada beberapa teknologi lain yang dapat digunakan sama dengan SLB diantaranya adalah sebagai berikut :

Firewall Load Balancing (FWLB)

Firewall Load Balancing (FWLB) dikembangkan untuk mengatasi beberapa keterbatasan pada teknologi Firewall. Sebagian besar Firewall adalah berbasis CPU seperti mesin SPARC atau mesin x86 based. Karena prosesor memiliki keterbatasan, throughput firewall pun menjadi terbatas.Kecepatan prosesor, konfigurasi, dan beberapa metric menjadi factor kinerja firewall. Seperti pada SLB, FWLB memungkinkan implementasi beberaa firewall di sharing dan di load sama halnya seperti SLB. Namun karena trafik yang berbeda maka konfigurasi dan teknologinya pun sedikit berbeda. Konfigurasi umumnya adalah seperti berikut :

Global Server Load Balancing

Global Server Load Balancing (GSLB) juga memiliki konsep yang sama dengan SLB hanya saja digunakan untuk distribusi pada lokasi yang lebih luas. SLB bekerja pada LAN (Local Area Network), sedangkan GSLB bekerja pada Wide Area Network (WAN). Ada beberapa cara untuk mengimplemetasikan GSLB seperti DNS based dan BGP based (Border Gateway Protocol). Berikut ini adalah contoh konfigurasi dasar GSLB :

Clustering

Clustering memberikan yang sama seperti halnya pada SLB yakni memberikan availability yang tinggi dan skalabiliti dengan sedikit perbedaan. Clustering melibatkan software protocol (proprietary dari masing-masing vendor) yang berjalan pada beberapa server dengan tujuan untuk melakukan sharing load (seperti pada gambar dibawah). Cluster berada didepan beberapa server kemudian melakukan manipulasi paket pada network device dan menerima trafik kemudian membaginya pada server lainnya. Ada integrasi yang kuat dengan software server.

Referensi : Tony Bourke, Server Load Balancing, O’Rielly, 2001

Su nombre es Dan Kaminsky, tiene 29 años y por casualidad se encontró con un error en el sistema de asignación de direcciones de Internet que permitiría a cualquier hacker redireccionar el tráfico mundial a sitios falsos.

Hay millones de PC contaminadas.

El hombre que puede haber salvado a Internet del caos cibernético total es un informático de 29 años de Seattle llamado Dan Kaminsky. MPaulero el July 24 2008 20:24:16
LEER MAS >> · 0 Comentarios ]]> http://penguim.wordpress.com/?p=394 Fri, 25 Jul 2008 12:48:18 +0000 penguim http://penguim.wordpress.com/?p=394 Como postei a alguns dias atrás, crackers divulgam código malicioso para explorar as vulnerabilidades no DNS informadas anteriormente.

O código foi gerado pelo desenvolvedor do Metasploit, ele realiza ataques imperceptíveis de phishing nos servidores DNS desatualizados.

"Crackers também poderiam usar o código para redirecionar silenciosamente usuários para servidores falsos de atualização de software, os forçando a baixar programas maliciosos, afirmou o diretor técnico da Symantec Zulfikar Ramizan.

A potencial ameaça é uma variação do que é conhecido como ataque de envenenamento de cachê, que tem relação com a maneira como clientes e servidores DNS obtêm informações de outros servidores DNS na internet."

Fonte

Outras noticias

Desde el 8 de julio se está produciendo uno de los episodios más curiosos vividos nunca en la red. Se publicó ese día una actualización masiva para la mayoría de los dispositivos en Internet que utilizan DNS. Se dijo que había sido descubierta una vulnerabilidad que permitía falsificar las respuestas DNS, y por tanto redireccionar el tráfico. Casi todos los grandes y pequeños fabricantes y programadores actualizaron sus sistemas y se intentó mantener los detalles técnicos de la vulnerabilidad ocultos, por la gravedad y el potencial impacto que podría suponer. Finalmente, dos semanas después, se conocen los detalles.

Toda vulnerabilidad es importante y tiene un potencial impacto en la red. Sin embargo, cuando hablamos de la resolución de nombres y de problemas en los servidores DNS, la gravedad se multiplica porque se supone que los servidores DNS sustentan la red. Dan Kaminsky había descubierto un fallo de base en el protocolo que permitía a cualquiera falsificar las respuestas de un servidor. No era problema de ningún fabricante sino de casi todos, un fallo de diseño de un estándar usado en todo Internet. En un importante esfuerzo de coordinación todos los grandes fabricantes están publicado sus actualizaciones desde el día 8 de julio.

Pero Dan Kaminsky no daba detalles sobre el asunto. Era demasiado grave y pensaba que sería irresponsable proporcionar esa información sin dar suficiente tiempo a todos los administradores para actualizar. Del parche no se podía deducir el problema puesto que simplemente añadía aleatoriedad y entropía a ciertos valores que desde hace mucho se sabía que no eran la mejor solución para asegurar el protocolo. Es por esto que se apostaba desde un principio por que la vulnerabilidad de Kaminsky se tratara en realidad de una nueva forma más eficaz de engañar a los servidores DNS para que den respuestas falsas, gracias a un fallo inherente del protocolo (y así ha sido).

Kaminsky daría los detalles un mes después, en la conferencia Black Hat de agosto. Por una parte, el descubridor estaba siendo responsable (dando tiempo a los administradores) pero tremendamente mediático por otra (creando una expectación exagerada en torno a la conferencia). Todo esto, ayudado por la desinformación de los medios generalistas ha ayudado a que la desconfianza siguiese creciendo. Todos defendían su teoría: desde el escéptico hasta el que hablaba de la debacle de la Red. Sólo un grupo de personas concretas conocía los detalles técnicos, y tenían instrucciones de no revelarlos y de evitar las especulaciones públicas. Kaminsky pretendía así ingenuamente asegurarse que sólo él daría los detalles cuando lo tenía planeado, cumpliendo así la segunda parte de su plan una vez publicadas las actualizaciones. Imposible... poco después las listas estaban llenas de comentarios y elucubraciones.

Afortunadamente en la seguridad informática siempre hay alguien que va más allá. Thomas Dullien, el CEO de la compañía Zynamics (también conocido como Halvar Flake) se aventuró a publicar en su blog su particular visión de lo que podía ser el problema descubierto por Kaminsky, sin tener conocimiento previo de los detalles. Y no se equivocó en su teoría. La insinuación de que estaba en lo cierto vino desde varios frentes (entre ellos desde un post en Twitter del propio Kaminsky), pero lo confirmó totalmente una entrada del lunes pasado en el blog de Thomas Ptacek, director la compañía Matasano que era de los que conocía los detalles reales. La entrada estaba firmada por un/a tal "ecopeland" del equipo de Ptacek. Según linkedin.com existe un/a Erin Ptacek (Copeland), desarrollador/a de software en Matasano (¿familiar del director?). En el post se daba la razón a Dullien, junto con todo lujo de detalles sobre el fallo que Dullien había 'redescubierto'. La explicación fue retirada poco después (actualmente está disponible a través de la caché de Google). Ptacek se ha disculpado públicamente, probablemente se dejó llevar por su ánimo de compartir la información. Demasiado tarde... ya circula libremente por Internet.

Los detalles técnicos pueden ser encontrados en el apartado de más información. No tardarán en aparecer exploits. Ahora la gravedad del problema se multiplica. Afortunadamente casi todos los fabricantes han publicado ya un parche.

Aunque se conocía el problema desde enero, Kaminsky trabajó intensamente con los grandes fabricantes para mantenerlo en secreto y coordinar la aparición de parches un día concreto (que tuvo que coincidir con el día de actualización de Microsoft). Esto resulta extremadamente complicado, y hay que reconocer que ha debido resultar un trabajo complejo el coordinar y mantener la discreción sobre un tema tan delicado. Un esfuerzo elogiable. Sin embargo desde que se anunció la existencia del problema, sólo se han necesitado dos semanas para que sea desvelado, frustrando el plan de Kaminsky de aguantar un mes hasta la Black Hat para revelar los detalles.

Son muchas las moralejas y conclusiones que se pueden extraer de este incidente. De nuevo el debate sobre la revelación responsable de vulnerabilidades, la fuerza del ego de muchos investigadores, la demostración de que un esfuerzo coordinado para una actualización masiva ante un problema común es posible... pero sobre todo llama la atención la capacidad de Thomas Dullien de redescubrir un problema que siempre habría estado ahí, pero que no se había planteado buscar hasta que alguien apuntó que existía. Dullien contaba con las bases (el protocolo DNS sufre de problemas inherentes conocidos) sólo había que mover las piezas para encontrar lo que podía ser el fallo que otro decía ya saber. Y acertó. Una de las mejores formas de captar el interés de un asunto, (aunque siempre haya estado ante nuestras narices y creamos conocerlo) es afirmar que oculta un secreto.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3559/comentar

Más Información:

Kerfuffle erupts as DNS flaw described
http://www.securityfocus.com/brief/779

Reliable DNS Forgery in 2008
http://amd.co.at/dns.htm

On Dan's request for "no speculation please"
http://addxorrol.blogspot.com/2008/07/on-dans-request-for-no-speculation.html

Regarding The Post On Chargen Earlier Today
http://www.matasano.com/log/1105/regarding-the-post-on-chargen-earlier-today/

Bueno, parece que hasta que pase algun tiempo cuando este ya todo parcheado, no se podra acceder ni revelar datos importantes a través de la red.

DNS es básicamente el sistema de traducción de direcciones IP a nombres de dominio, y viceversa. Cualquier fallo en este sistema es lógicamente muy grave, y hace unos días fue encontrada una gravísima vulnerabilidad que podría estar ahí desde hace mucho tiempo.

En Kritópolis han recopilado mucha información referente a este fallo. El experto en seguridad Dan Kaminsky parece ser el que se ha llevado toda la fama del descubrimiento, y en su blog informa de que la cosa ya va sobre ruedas, prácticamente todo el mundo ha publicado sus parches de seguridad y están siendo aplicados rápidamente, sin que nadie esté aprovechando el agujero. Desde su web también puedes comprobar en un momento si el servidor DNS que estás usando está afectado o no, gracias a su DNS Checker.

El descubrimiento ha provocado que las mayores empresas y organizaciones de la red estén trabajando duramente para dar soluciones lo antes posible. Para dar una idea de cuál es la envergadura de las organizaciones que están intentando arreglar el problema tan sólo hay que nombrar las notas que han publicado Microsoft, Sun, Red Hat, Debian, Cisco...

Parece increible, que despues de tantos años usando el dichoso sistema de resolución de nombres, exista un fallo tan grave, y sabiendo que es DNS, ser capaz de poner en jaque a toda internet.

www.dns-oarc.net è l'indirizzo web di un centro di ricerca che si occupa dei DNS e da qualche giorno, anche se io l'ho scoperto solo, ora è disponibile un test per i server DSN.

Si tratta di un test che verifica l'applicazione di alcune patch di cui si è fatto un gran parlare qualche giorno fa, soprattutto per il verificarsi di un ipotetico 0-day; un giorno in cui tutti i maggiori sviluppatori di DNS avrebbero risolto alcune vulnerabilità da poco scoperte e largamente, se non universalmente, diffuse.

C'è una comoda pagina che permette di fare il test dei dns che un computer sta utilizzando, ma non finisce qui.

E' possibile, infatti, da linea di comando, interrogare un qualunque dns.

Il comando è

dig @<dns-ip> +short porttest.dns-oarc.net TXT

dove, ovviamente <dns-ip> è l'ip del server dns da testare.

L'esito della risposta può essere POOR, FAIR o GOOD, la sua interpretazione dovrebbe essere semplice ;) ma in caso ci fosse bisogno di ulteriori informazioni si può fare riferimento al post originale sul sito di dns-oarc.

Ovviamente ho testato i dns che uso normalmente (opendns) e sono risultati molto affidabili mentre i dns che mi vengono comunicati dal provider (alice) hanno comportamenti differenti: molto affidabile il principale, 85.37.17.52, mentre non affidabile il secondario 85.38.28.92.

E questo è tutto.

P.S.

Anche punto-informatico.it ha segnalato il problema e, tra i commenti all'articolo, si trova l'indirizzo di un altro sito che permette di testare i dns: www.doxpara.com

Kaminsky said the word is getting out about the patches, but there are still many systems that are vulnerable. From the period of July 8 through July 13, 86 percent of the people testing their system on his Web site were vulnerable. Today it's 52 percent. "Not perfect; not even good enough," he said. But "I'll take 52 any day of week and twice on Sunday."

He started off by saying that he was trying to find a way to do content distribution using DNS when realized the problem. "How much trouble are we in? A lot."

Of the public discussion from individuals within the security community, Kaminsky said Halvar Flake's speculation was the closest. For those who said they knew of flaws in DNS before today, Kaminsky said "you didn't know this one."
Kaminsky described the flaw he's been working on as containing three flaws; two have been known, but one was not. Security researchers always thought it was hard to poison DNS records. He said to think of the process as a race, with a good guy and bad guy each trying to get a secret number transaction ID. "You can get there first," he said, "but you can't cross finish line unless you have the secret number." The good guy will always have it, but the bad guy has a 1 in 65,000 chance of getting it because the transaction ID is based in part on the port number used.

One bug with DNS is that the bad guy can start the race anytime he wants. If he doesn't know the transaction number, he can always guess. Another fundamental flaw is that there will be multiple bad guys trying to guess the transaction number. The flaw Kaminsky found that builds on the first two is that not only can multiple bad guys participate in a single race, but there can also be multiple races. The example he gave was www.blackhat.com. A bad guy shouldn't just try to guess the transaction ID for that address, but also for 1.blackhat.com, 2.blackhat.com, etc.

Everyone thought, he said, if "one sets a long time to live (TTL), say, for one year, that would work." But Kaminsky found that going to look up 1.blackhat.com, 2.blackhat.com, etc, he can find the name server and then guess the transaction ID. Kaminsky said the process of getting a response is about 10 seconds.

"Patch is the way to go; it shuts down the attack vector," said Jerry Dixon, former director of National Cyber Security Division of DHS. This was echoed by Rich Mogul of Securosis, and by Joao Damas, a senior program manager at the Internet Systems Consortium.

Kaminsky said the current patch has made exploits thousands of times harder--one in several hundred million, "not infinity." The bug is core to the design; it's fundamental to the design."

What have we learned? "We learned what needs to be done to fix the Net in the future. I await the security community's judgment on what we've done."

As for the long-term "Where do we go from here?" Kaminsky said there's going to be an awesome debate about that.

On August 6, Kaminsky will present "End of Cache as we know it" at Black Hat in Las Vegas.
http://news.cnet.com/8301-1009_3-9998906-83.html

Just days after details of a critical bug in the Domain Name System (DNS) software went public, researchers released attack code that can silently redirect users to unintended sites.

HD Moore, the creator of the Metasploit penetration testing framework, and a hacker who goes by the alias "I)ruid," published the attack code in two parts yesterday and today to several security mailing lists and to the Computer Academic Underground Web site.

The two exploits do essentially the same thing, said Andrew Storms, director of security operations at nCircle Network Security Inc.; both poison a DNS server's cache, and therefore can, at least temporarily, replace the legitimate addresses in that cache with bogus destinations. Users steering to what they believe are valid sites could, if they pull the routing information from a victimized DNS server, be sent instead to a fake site such as a phony banking site, where they could be easily duped into divulging confidential information.

Yesterday's exploit, explained Storms, lets an attacker poison a DNS server's cache with a single malicious entry, but today's attack code allows a hacker to poison large quantities of domains with one fell swoop. "This second exploit has the potential for a much larger impact," said Storms, "and could result in potentially thousands of fake addresses inserted into a DNS server's cache.

HD Moore, however, noted that the single entry exploit of Tuesday gives attackers more anonymity, while today's exploit requires hackers to have a real DNS server. "That means they'll be less anonymous," Moore said, adding that it would be possible to trace the DNS requests back to the fake server operated by the attacker, then have it taken offline by, for instance, the host provider.

"Both [kinds of attacks] will be difficult to detect," Storm said. "It will probably take an end user to raise the flag when they go to their banking site, for example, and then report, 'Hey, this just doesn't look quite right.'" Digging through the enormous amount of data generated by a DNS server -- hundreds of thousands of results in an hour at a company like nCircle, said Storms -- is simply impossible.

The DNS cache-poisoning bug exploited by Moore's and I)ruid's attack code was first announced earlier this month by Dan Kaminsky, director of penetration testing at Seattle-based IOActive Inc. The bug, which Kaminsky uncovered earlier this year, was patched that same day by several major vendors, including Cisco Systems Inc., Internet Systems Consortium Inc. and Microsoft Corp.

Although Kaminsky declined to publicly disclose technical information, he briefed several fellow security researchers after he was criticized for overstating the seriousness of the threat. Those researchers recanted, and said Kaminsky's research was on target.

Monday, however, a German hacker went public with his guesses about the bug's details. His speculation was confirmed later in the day by Matasano Security, a consultancy that included at least one researcher who had been briefed on the bug by Kaminsky.

That was when Moore and I)ruid started working on the attack code, Moore said today. "We were keeping an eye on it before, but we didn't really start until Monday," he said. "There have been tools available to check to see if you needed to patch [the DNS software], but there wasn't any way to actually see if you could actually do this attack."

The exploits have been added to the Metasploit framework, said Moore, but at the moment can be launched only from systems running Linux. He said that work on exploits able to run from Mac OS X and other operating systems would start soon, but that the attack code would not be tweaked for Windows. Because of the way the exploits are written, they "would never work on Windows."

That doesn't mean Windows users are safe, however. Although the current exploits can't be launched by attackers from a Windows PC, end users running Windows are at risk if they don't apply this month's DNS patches.

Storms didn't dismiss the possibility of attacks now that exploit code is available, but downplayed the threat because of all the attention the bug has received. "I think the likelihood of a mass attack is limited," said Storms, "because a whole lot more people understand how DNS works than did several weeks ago."

Users should patch now, said Storms, even if they're not operating a DNS server. "It's important that you look at the Microsoft patch now," he said, referring to the fix Microsoft issued two weeks ago for every version of Windows except Vista.

"Anytime you can change [entries on a] DNS server, you run into a lot of other issues, including drive-by Web attacks," warned Moore.

By <a href="http://www.computerworld.com/action/article.do?command=viewArticleBasic

22/07/2008 Descubiertos los detalles de la vulnerabilidad en el protocolo DNS

Desde el 8 de julio se está produciendo uno de los episodios más curiosos vividos nunca en la red. Se publicó ese día una actualización masiva para la mayoría de los dispositivos en Internet que utilizan DNS. Se dijo que había sido descubierta una vulnerabilidad que permitía falsificar las respuestas DNS, y por tanto redireccionar el tráfico. Casi todos los grandes y pequeños fabricantes y programadores actualizaron sus sistemas y se intentó mantener los detalles técnicos de la vulnerabilidad ocultos, por la gravedad y el potencial impacto que podría suponer. Finalmente, dos semanas después, se conocen los detalles.

Toda vulnerabilidad es importante y tiene un potencial impacto en la red. Sin embargo, cuando hablamos de la resolución de nombres y de problemas en los servidores DNS, la gravedad se multiplica porque se supone que los servidores DNS sustentan la red. Dan Kaminsky había descubierto un fallo de base en el protocolo que permitía a cualquiera falsificar las respuestas de un servidor. No era problema de ningún fabricante sino de casi todos, un fallo de diseño de un estándar usado en todo Internet. En un importante esfuerzo de coordinación todos los grandes fabricantes están publicado sus actualizaciones desde el día 8 de julio.

Pero Dan Kaminsky no daba detalles sobre el asunto. Era demasiado grave y pensaba que sería irresponsable proporcionar esa información sin dar suficiente tiempo a todos los administradores para actualizar. Del parche no se podía deducir el problema puesto que simplemente añadía aleatoriedad y entropía a ciertos valores que desde hace mucho se sabía que no eran la mejor solución para asegurar el protocolo. Es por esto que se apostaba desde un principio por que la vulnerabilidad de Kaminsky se tratara en realidad de una nueva forma más eficaz de engañar a los servidores DNS para que den respuestas falsas, gracias a un fallo inherente del protocolo (y así ha sido)... ver mas detalles

Uff... que lio :S

Fuente:

Descubiertos los detalles de la vulnerabilidad en el protocolo DNS > http://www.hispasec.com/unaaldia/3559

Pero Dan Kaminsky no daba detalles sobre el asunto. Era demasiado grave y pensaba que sería irresponsable proporcionar esa información sin dar suficiente tiempo a todos los administradores para actualizar. Del parche no se podía deducir el problema puesto que simplemente añadía aleatoriedad y entropía a ciertos valores que desde hace mucho se sabía que no eran la mejor solución para asegurar el protocolo. Es por esto que se apostaba desde un principio por que la vulnerabilidad de Kaminsky
se tratara en realidad de una nueva forma más eficaz de engañar a los servidores DNS para que den respuestas falsas, gracias a un fallo inherente del protocolo (y así ha sido).

Kaminsky daría los detalles un mes después, en la conferencia Black Hat de agosto. Por una parte, el descubridor estaba siendo responsable (dando tiempo a los administradores) pero tremendamente mediático por otra (creando una expectación exagerada en torno a la conferencia). Todo esto, ayudado por la desinformación de los medios generalistas ha ayudado a que la desconfianza siguiese creciendo. Todos defendían su teoría: desde el escéptico hasta el que hablaba de la debacle de la
Red. Sólo un grupo de personas concretas conocía los detalles técnicos, y tenían instrucciones de no revelarlos y de evitar las especulaciones públicas. Kaminsky pretendía así ingenuamente asegurarse que sólo él daría los detalles cuando lo tenía planeado, cumpliendo así la segunda parte de su plan una vez publicadas las actualizaciones. Imposible... poco después las listas estaban llenas de comentarios y elucubraciones.

Afortunadamente en la seguridad informática siempre hay alguien que va más allá. Thomas Dullien, el CEO de la compañía Zynamics (también conocido como Halvar Flake) se aventuró a publicar en su blog su particular visión de lo que podía ser el problema descubierto por Kaminsky, sin tener conocimiento previo de los detalles. Y no se equivocó en su teoría. La insinuación de que estaba en lo cierto vino desde varios frentes (entre ellos desde un post en Twitter del propio Kaminsky), pero lo confirmó totalmente una entrada del lunes pasado en el blog de Thomas Ptacek, director la compañía Matasano que era de los que conocía los detalles reales. La entrada estaba firmada por un/a tal
"ecopeland" del equipo de Ptacek. Según linkedin.com existe un/a Erin Ptacek (Copeland), desarrollador/a de software en Matasano (¿familiar del director?). En el post se daba la razón a Dullien, junto con todo lujo de detalles sobre el fallo que Dullien había 'redescubierto'. La explicación fue retirada poco después (actualmente está disponible a través de la caché de Google). Ptacek se ha disculpado públicamente, probablemente se dejó llevar por su ánimo de compartir la información.
Demasiado tarde... ya circula libremente por Internet.

Los detalles técnicos pueden ser encontrados en el apartado de más información. No tardarán en aparecer exploits. Ahora la gravedad del problema se multiplica. Afortunadamente casi todos los fabricantes han publicado ya un parche.

Aunque se conocía el problema desde enero, Kaminsky trabajó intensamente con los grandes fabricantes para mantenerlo en secreto y coordinar la aparición de parches un día concreto (que tuvo que coincidir con el día de actualización de Microsoft). Esto resulta extremadamente complicado,
y hay que reconocer que ha debido resultar un trabajo complejo el coordinar y mantener la discreción sobre un tema tan delicado. Un esfuerzo elogiable. Sin embargo desde que se anunció la existencia del problema, sólo se han necesitado dos semanas para que sea desvelado,
frustrando el plan de Kaminsky de aguantar un mes hasta la Black Hat para revelar los detalles.

Son muchas las moralejas y conclusiones que se pueden extraer de este incidente. De nuevo el debate sobre la revelación responsable de vulnerabilidades, la fuerza del ego de muchos investigadores, la demostración de que un esfuerzo coordinado para una actualización masiva ante un problema común es posible... pero sobre todo llama la atención la capacidad de Thomas Dullien de redescubrir un problema que siempre habría estado ahí, pero que no se había planteado buscar hasta que alguien apuntó que existía. Dullien contaba con las bases (el protocolo DNS sufre de problemas inherentes conocidos) sólo había que mover las piezas para encontrar lo que podía ser el fallo que otro decía ya saber. Y acertó. Una de las mejores formas de captar el interés de un asunto, (aunque siempre haya estado ante nuestras narices y creamos conocerlo) es afirmar que oculta un secreto.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3559/comentar

Más información:

Kerfuffle erupts as DNS flaw described
http://www.securityfocus.com/brief/779

Reliable DNS Forgery in 2008
http://amd.co.at/dns.htm

On Dan's request for "no speculation please"
http://addxorrol.blogspot.com/2008/07/on-dans-request-for-no-speculation.html

Regarding The Post On Chargen Earlier Today
http://www.matasano.com/log/1105/regarding-the-post-on-chargen-earlier-today/

This?! This is the DNS flaw?

The above Infoworld blog is where I initially found out about this. Then I move the the link in the article to Poor DNS blog post of someone who has been doing testing. Checkout what he found, but here is the latest list of vulnerable DNS servers.

Here is the wall of shame so far. These are the DNS servers that I
tested using dig and that returned a "POOR" result (indicating that
they are vulnerable):

1. 4.2.2.1 -- Verizon (Level3) [Update: Reports 'FAIR' on 2008-07-24]
2. 4.2.2.2 -- Verizon (Level3) [Update: Reports 'FAIR' on 2008-07-24]
3. 4.2.2.3 -- Verizon (Level3) [Update: Reports 'FAIR' on 2008-07-24]
4. 4.2.2.4 -- Verizon (Level3) [Update: Reports 'FAIR' on 2008-07-24]
5. 4.2.2.5 -- Verizon (Level3) [Update: Reports 'FAIR' on 2008-07-24]
6. 4.2.2.6 -- Verizon (Level3) [Update: Reports 'FAIR' on 2008-07-24]
7. 24.113.32.29 -- Wave Broadband [Update: Still reports 'POOR' as of 2008-07-24]
8. 24.113.32.30 -- Wave Broadband [Update: Still reports 'POOR' as of 2008-07-24]
9. 24.48.217.226 -- Adelphia (Comcast RoadRunner) [Update: Still reports 'POOR' as of 2008-07-24]
10. 24.48.217.227 -- Adelphia (Comcast RoadRunner) [Update: Still reports 'POOR' as of 2008-07-24]
11. 67.21.13.2 -- Adelphia (Comcast RoadRunner) [Update: Still reports 'POOR' as of 2008-07-24]
12. 67.21.13.4 -- Adelphia (Comcast RoadRunner) [Update: Still reports 'POOR' as of 2008-07-24]
13. 68.168.1.42 -- Adelphia (Comcast) [Update: No longer returns results]
14. 68.168.1.46 -- Adelphia (Comcast) [Update: No longer returns results]
15. 68.87.64.196 -- Comcast [Update: Still reports 'POOR' as of 2008-07-24]
16. 68.87.66.196 -- Comcast [Update: Still reports 'POOR' as of 2008-07-24]
17. 68.87.85.98 -- Comcast [Update: Still reports 'POOR' as of 2008-07-24]
18. 68.87.96.3 -- Comcast [Update: Reports 'GOOD' as of 2008-07-24]
19. 68.87.96.4 -- Comcast [Update: Reports 'GOOD' as of 2008-07-24]
20. 68.94.156.1 -- SBC/AT&T [Update: Reports 'GOOD' as of 2008-07-24]
21. 68.94.157.1 -- SBC/AT&T [Update: Reports 'GOOD' as of 2008-07-24]
22. 194.72.9.38 -- BTInternet [Update: Still reports 'POOR' as of 2008-07-24]
23. 199.2.252.10 -- Sprintlink [Update: Still reports 'POOR' as of 2008-07-24]
24. 202.188.1.5 -- Tmnet Streamyx [Update: Still reports 'POOR' as of 2008-07-24]
25. 202.27.156.72 -- Xtra (New Zealand) [Update: Still reports 'POOR' as of 2008-07-24]
26. 202.27.158.40 -- Xtra (New Zealand) [Update: Still reports 'POOR' as of 2008-07-24]
27. 204.117.214.10 -- Sprintlink [Update: Still reports 'POOR' as of 2008-07-24]
28. 204.97.212.10 -- Sprintlink [Update: Still reports 'POOR' as of 2008-07-24]
29. 205.152.37.23 -- Bellsouth [Update: Still reports 'POOR' as of 2008-07-24]
30. 207.69.188.186 -- Earthlink [Update: Reports 'GOOD' as of 2008-07-24]
31. 207.69.188.187 -- Earthlink [Update: Reports 'GOOD' as of 2008-07-24]
32. 209.55.0.110 -- Suddenlink [Update: Reports 'GOOD' as of 2008-07-24]
33. 209.55.1.220 -- Suddenlink [Update: Reports 'GOOD' as of 2008-07-24]

No TimeWarner/RoadRunner thankfully.

C'est le serveur DNS qui gère tout ça. Le hic c'est qu'il y a une faille (connue depuis longtemps mais restée sous silence) dans ce système qui permettrait à un site malveillant de vous rediriger automatiquement vers un site "pirate" sans que vous ne vous en aperceviez; c'est la même méthode que le phishing mais beaucoup plus pernicieuse...

Pour corriger cette faille Microsoft a sorti un update pour Windows mais il n'est pas efficace à 100%.

Donc pour vérifier que vous surfez en sécurité avec les DNS de votre fournisseur d'accès, rendez-vous sur ce site, puis cliquez sur Check my DNS (colonne de droite). Le résultat devrait être de ce genre:

Your name server, at 212.27.37.10, appears to be safe, but make sure the ports listed below aren't following an obvious pattern

Si ce n'est pas le cas, ne vous alarmez pas; passez par OpenDNS qui fournit des DNS gratuits et sûrs et  contactez simplement votre FAI pour lui signaler le problème en lui décrivant la démarche que vous venez d'accomplir.

"Vários crackers estão prontos para desenvolver um código de ataque para o bug e mostrarão isso nos próximos dias, disse Dave Aitel, chefe de tecnologia de segurança Immunity.

Sua empresa desenvolverá exemplos de código para seu software de testes de segurança, o Canvas, uma tarefa que espera tomar cerca de apenas um dia, dada a simplicidade do ataque. “Não é difícil”, disse ele.

O autor de uma das ferramentas amplamente utilizadas por hackers e crackers afirmou que espera explorá-lo até a próxima terça-feira. HD Moore, autor do software de testes de invasão Metasploit, concordou com Aitel de que o código do ataque não foi muito difícil de escrever."

Fonte

Toda vulnerabilidad es importante y tiene un potencial impacto en la red. Sin embargo, cuando hablamos de la resolución de nombres y de problemas en los servidores DNS, la gravedad se multiplica porque se supone que los servidores DNS sustentan la red. Dan Kaminsky había descubierto un fallo de base en el protocolo que permitía a cualquiera falsificar las respuestas de un servidor. No era problema de ningún fabricante sino de casi todos, un fallo de diseño de un estándar usado en todo Internet. En un importante esfuerzo de coordinación todos los grandes fabricantes están publicado sus actualizaciones desde el día 8 de julio.

Pero Dan Kaminsky no daba detalles sobre el asunto. Era demasiado grave y pensaba que sería irresponsable proporcionar esa información sin dar suficiente tiempo a todos los administradores para actualizar. Del parche no se podía deducir el problema puesto que simplemente añadía aleatoriedad y entropía a ciertos valores que desde hace mucho se sabía que no eran la mejor solución para asegurar el protocolo. Es por esto que se apostaba desde un principio por que la vulnerabilidad de Kaminsky se tratara en realidad de una nueva forma más eficaz de engañar a los servidores DNS para que den respuestas falsas, gracias a un fallo inherente del protocolo (y así ha sido).

Kaminsky daría los detalles un mes después, en la conferencia Black Hat de agosto. Por una parte, el descubridor estaba siendo responsable (dando tiempo a los administradores) pero tremendamente mediático por otra (creando una expectación exagerada en torno a la conferencia). Todo esto, ayudado por la desinformación de los medios generalistas ha ayudado a que la desconfianza siguiese creciendo. Todos defendían su teoría: desde el escéptico hasta el que hablaba de la debacle de la Red. Sólo un grupo de personas concretas conocía los detalles técnicos, y tenían instrucciones de no revelarlos y de evitar las especulaciones públicas. Kaminsky pretendía así ingenuamente asegurarse que sólo él daría los detalles cuando lo tenía planeado, cumpliendo así la segunda parte de su plan una vez publicadas las actualizaciones. Imposible... poco después las listas estaban llenas de comentarios y elucubraciones...sigue

LEER mas en hispasec.com

Kerfuffle erupts as DNS flaw described
http://www.securityfocus.com/brief/779

Reliable DNS Forgery in 2008
http://amd.co.at/dns.htm

On Dan's request for "no speculation please"
http://addxorrol.blogspot.com/2008/07/on-dans-request-for-no-speculation.html

Regarding The Post On Chargen Earlier Today
http://www.matasano.com/log/1105/regarding-the-post-on-chargen-earlier-today/

Toda vulnerabilidad es importante y tiene un potencial impacto en la red. Sin embargo, cuando hablamos de la resolución de nombres y de problemas en los servidores DNS, la gravedad se multiplica porque se supone que los servidores DNS sustentan la red. Dan Kaminsky había descubierto un fallo de base en el protocolo que permitía a cualquiera falsificar las respuestas de un servidor. No era problema de ningún fabricante sino de casi todos, un fallo de diseño de un estándar usado en todo Internet. En un importante esfuerzo de coordinación todos los grandes fabricantes están publicado sus actualizaciones desde el día 8 de julio.

Pero Dan Kaminsky no daba detalles sobre el asunto... (sigue en http://www.hispasec.com/unaaldia/3559)

I've been experiencing a couple of day of infuriating disconnections from our Virgin media (rebranded NTL) cable based Internet connection. During periods of connectivity I'd managed to look on-line and see that I was not alone.

Before the desperation of trying to embark on the tortuous process that is technical support on the phone I decided to do some troubleshooting myself using my own slightly sad but sometimes useful technical abilities.

I was having to unplug and restart the cable modem up to 10 times a day so the problem needed diagnosing. I noticed that during periods where there were seemingly devoid of an Internet connection I could ping Virgin's two DNS servers so that suggested to me that perhaps this was some kind of DNS resolution issue.

I then input Virgin's DNS servers manually into our netgear router & also made sure that the ethernet mac address showing was that of our main computer and not the router after reading that people using routers were having more problems that those where the modem was connected directly to a computer. I had also tried removing the router from the equation but the problem persisted.

So I then dispensed with Virgin's DNS server addresses and used the third party OpenDNS server addresses input manually into the netgear router and this seems to have resolved our connection reliability issues completely.

If you're using Virgin's cable broadband and having similar issues it's worth trying this solution to see if it also solves your own intermittent connection problems. Many Virgin media cabled areas are experiencing connectivity issues. In some cases it's the local exchange, in others it's faulty modems which can be replaced but for us using an alternative DNS service has improved our connection 100%.

Details of the attack have been leaked this week (Slashdot article) earlier than expected, Wired also has a good article on the topic.

Happily, it appears that m0n0wall is not significantly affected. Manuel Kasper made a post on the user mailing list some time ago announcing v1.3b13-pre with an update to Dnsmasq. I installed this today without incident.

Words cannot express how much I appreciate m0n0wall. It's simply fantastic for SOHO situations like my office.

If this is correct, it confirms that it was an issue based on being able to identify a DNS resolver's source port, combined with the transaction ID, as well as being able to craft a packet to add an Additional Resource Record (this additional RR is where the malicious data is). In the testing I did on Microsoft DNS implementations, prior to the patch, a server's resolver for recursive data used the same source port for queries. This is one of the fixes in the latest patches; resolvers are now using a random source port for each query.

Knowing the source port makes it moderately easy to spoof a DNS response. Using a slightly different variation of the example in my previous post on this subject, an attacker could use this exploit on an un-patched DNS server as follows:

1) An attacker wants to spoof a DNS response for www.youronlinebank.com.

2) The attacker continuously queries your recursive DNS server for xxxxx.youronlinebank.com (where xxxxx is a variable, resulting in a Non-Existent domain response).

3) During this time, the attacker submits a large number of DNS response queries to your DNS server, knowing the source port, all he needs to eventually get correct is the transaction ID. The majority of these packets will be dropped by your DNS server. However, when the attacker finally gets the correct query ID, as long as the malicious packet beats the actual recursive response, it will be accepted.

4) This packet will tell your DNS server that xxxxx.youronlinebank.com can be found at 1.2.3.4 (a rogue IP), but will also contain an Additional RR for www.youronlinebank.com, directing it to a rogue IP. A patch to DNS some time ago, called bailiwick checking, specifies that Additional RR's must match the domain in the DNS query, and in this case, it does.

5) Setting a high TTL on the RR means that your clients are vulnerable to this attack for as long as the record is cached.

So the patch for this at the very least addresses source port randomization, making this current exploit nearly impossible. I don't know what other fixes are included, but I could see some sort of record name checking on the response being good, though I don't know what affect that may have on DNS wild-carding (probably none). This is a difficult vulnerability to take advantage of, but still very possible, especially with the details now being out there. Now is a good time to patch this if you haven't already.

Update (23-Jul): Check here or here for details on how to check your resolvers for this vulnerability. Confirmed that MS patch fixes this by "using strongly random DNS transaction IDs, using random sockets for UDP queries, and updating the logic used to manage the DNS cache".

Despite obvious issues with Net Neutrality, Rogers brakes one of most usable features browsers provide that is autocompletion of standard domain name extensions, such as .com or .net

Most of browsers, safe IE, have been providing this extremely useful feature to their customers for years. I can't even remember when i had to actually type in a domain extension. Only for international domains such as .ru, co.il, etc. 

It is also interesting how Rogers implemented that. At the bottom of the page there is a link to more information. When clicked one gets an option to disable the page.

Rogers keeps cookie on your machine that prevents the page to be shown and makes it clear that if you happen to use any internet privacy app that cleans up the cookies you will see their search page again and again. 

Another interesting thing is that even when you choose not to use their "option page" you sill won't be able to just type apple and get to their page.  Instead "Page cannot be found" error displayed. 

Summarizing: If you happen to be a happy Rogers Cable customer wave goodbye to a nice URL auto completion feature in all of your browsers until Rogers make changes...

Viettel:
203.113.131.1
203.113.131.2

FPT:
210.245.31.10
210.245.31.130
210.245.0.11
210.245.0.58

EVN:
203.119.36.106
203.190.163.13
203.162.57.108
208.190.163.10

Netnam:
203.162.7.89
203.162.7.71

20080725 Update:

Please use OpenDNS servers below to avoid DNS poisoning exploitation which has just rising up recent days - and especically not being patched by Vietnamese ISPs:

208.67.222.222

208.67.220.220