ABSTRACT

Unlike spam, worms, viruses, and phishing—all of which confront end users directly—infrastructure attacks occur outside their normal frame of reference and control. But attacks on the Domain Name System (DNS), an engine of the Internet infrastructure, appear to be increasing in length and severity, affecting DNS information associated with financial services institutions, Internet service providers, and major corporations in the travel, health, technology, and media/ entertainment sectors. Such attacks can result in, say, dropped or intercepted email messages or users unknowingly redirected to fraudulent sites where they inadvertently hand over personal information.
The ultimate casualty in a serious infrastructure attack is public trust. The Internet technical community has responded to threats to the DNS infrastructure by developing the DNS Security Extensions (DNSSEC) protocol standard. DNSSEC-enabled systems run primarily in only a few early adoption and experimental zones.
DNSSEC introduces security at the infrastructure level through a hierarchy of cryptographic signatures attached to DNS records. In the context of DNSSEC, users are assured that the source of the data is verifiable as the stated source, and the mapping of a name to an IP address is accurate. DNSSEC – capable name servers also provide denial of- existence; that is, they tell a user that a name does not exist.

If you are you interested in this seminar topic, mail to us to get

the full report * of the seminar topic.

Mail ID: - contact4seminars@gmail.com 

* conditions apply

– OR –

Click here for Quick Contact (Request for Topics)

…in mancanza di canali più ufficiali, ICANN e Verisign hanno provveduto a mettere online un sito che contenga quantomeno la timeline e un minimo di dettaglio.

Opportuno dargli un occhio di tanto in tanto.

Nonostante alla cosa stia venendo data ben poca pubblicità, rispetto a quella che l’evento meriterebbe, ci stiamo avvicinando -un giorno per volta- alle date previste per il deploy delle firme DNSSEC nella root zone.

Le ragioni della scarsa pubblicizzazione della questione possono essere fatte risalire -pare- alla melassa burocratica che -nel corso degli ultimi 10 anni in particolare- ha avvolto i processi decisionali riguardanti la governance di Internet, e la cosa preoccupa un poco chi si occupa degli aspetti tecnici ed operazionali dell’infrastruttura delle rete.

Indipendentemente dal fatto che decidiate di attivare o meno le funzionalità di DNSSEC, infatti, qualche problema lo potreste incontrare, ed è bene saperlo con buon anticipo. La dimensione di parecchie risoluzioni DNS, infatti, aumenterà.

Ma perchè questo è un problema?

La spiegazione è un po’ lunga…

Nella notte dei tempi (RFC 1035) venne apposto un limite superiore alle dimensioni di un messaggio DNS (53/UDP), pari a 512 byte. Zone DNS corpose potevano comunque superare tale limite, come risposta alle interrogazioni, quindi la regola è: se la risposta non ci sta nei 512 byte, viene troncata e inviata ugualmente, aggiungendo un flag (TC) negli header del mesaggio per informare del fatto il resolver che ha eseguito la query. Quest’ultimo dovrà quindi provvedere ad instaurare una sessione TCP (sempre su porta 53) in direzione del DNS remoto -per la quale il limite dei 512 byte ovviamente non si applica- e provvederà in tal modo a reperire la risposta completa.

Già con questo meccanismo, purtroppo, spesso capita che la risoluzione di determinati domini incontri problemi a causa sostanzialmente della mancanza di conoscenza, anche da parte di molti tecnici, della indispensabilità della porta 53/TCP per il corretto funzionamento del DNS, con il risultato che i firewall perimetrali del client o del server spesso non la lasciano transitare…

Proprio in virtù dell’avanzamento di DNSSEC, comunque, questo meccanismo è stato in qualche misura superato (o, perlomeno, integrato) dall’introduzione EDNS0 (definito in RFC 2671), il quale consente a client e server di passare di comune accordo ad una dimensione massima per i messaggi UDP pari a 4096 byte.

Problema risolto quindi?

Purtroppo, no.

Nonostante la definizione di EDNS0 sia cosa di 10 anni fa, accade tutt’oggi infatti che molti apparati (firewall, router, ecc) in giro per la rete si occupino solertemente di segare i pacchetti diretti o provenienti da porta 53/UDP che superino i fatidici 512 byte, in quanto li considerano sospetti, malformati o quel che loro pare.

Per sopperire a questo potenziale problema, le implementazioni di EDNS0 (bind nello specifico) provvedono ad adattare la massima dimensione del messaggio in funzione dell’andamento delle risoluzioni con determinati sistemi remoti:

Dec 11 11:42:02 dns2 named[28944]: too many timeouts resolving ‘ns.shelter.it/AAAA’ (in ’shelter.it’?): reducing the advertised EDNS UDP packet size to 512 octets
Dec 11 11:42:02 dns2 named[28944]: too many timeouts resolving ‘ns.shelter.it/A’ (in ’shelter.it’?): reducing the advertised EDNS UDP packet size to 512 octets
Dec 11 11:42:02 dns2 named[28944]: too many timeouts resolving ‘ns.scelta.com/AAAA’ (in ’scelta.com’?): reducing the advertised EDNS UDP packet size to 512 octets

Se già oggi questo può portare a problemi, la dimensione delle difficoltà potrebbe facilmente ingigantirsi a seguito del deploy di DNSSEC nella root zone, dato che anche le query dirette a quest’ultima (che, per i non addetti, è appunto la radice da cui parte l’intera struttura DNS di Internet) supereranno il fatidico limite.

Come verificare da sè di non avere problemi simili? Un test lo fornisce OARC.

Assumendo di avere dig installato sulla vostra macchina, eseguite la seguente query:

dig +short rs.dns-oarc.net txt

Dovreste ottenere una cosa simile alla seguente:

skull@mithrandir:~$ dig +short rs.dns-oarc.net txt
rst.x4001.rs.dns-oarc.net.
rst.x3985.x4001.rs.dns-oarc.net.
rst.x4023.x3985.x4001.rs.dns-oarc.net.
“147.123.1.3 sent EDNS buffer size 4096″
“147.123.1.3 DNS reply size limit is at least 4023 bytes”

La parte interessante della risposta sono le ultime due righe, che dicono sostanzialmente che il vostro resolver (147.123.1.3 è il mio, il vostro lo saprete voi) ha annunciato la disponibilità a gestire messaggi per una dimensione massima pari agli attesi 4096 byte, e che si è verificato come un messaggio di 4023 riesca a transitare correttamente.

Se la penultima riga riporta il mancato supporto ad EDNS, è meglio investigare (e/o cambiare resolver).

Analogamente è opportuno investigare (o far investigare chi gestisce il resolver) nel caso in cui l’ultima riga riporti valori troppo bassi (sensibilmente inferiori a 4000 byte), poichè ciò potrebbe significare la presenza di filtri inopportuni nel mezzo.

Per ulteriori spiegazioni sul funzionamento del test e sull’interpretazione dei risultati da esso ottenuti, rimando con piacere alla stessa pagina di OARC, ma invito caldamente a mettere in moto le verifiche del caso, onde evitare di trovarsi per le mani problemi da cui dover uscire in emergenza…

Google has announced Google Public DNS, which will route all requests for internet addresses, a core Internet function, through Google’s servers. These requests would normally only pass through the servers of the users’ internet service providers. Google’s Domain Name System service does not use the new authentication standard DNSSEC, (Domain Name System Security Extensions) but instead uses a proprietary security method. By tradition, DNS is a distributed function, subject to an open standard-setting process. For more information, see EPIC DNSSEC.  (Electronic Privacy Information Center)

Die Vorbereitungen für die Absicherung der Rootzone des Domain Name Systems (DNS) mit dem Protokoll DNS Security Extensions (DNSSEC) gehen in die heiße Phase. Beim 76. Treffen der Internet Engineering Task Force (IETF) in Hiroshima präsentierte das Design-Team von VeriSign, der Internet-Verwaltung ICANN und der US-Behörde NTIA die scharfen Sicherheitsbestimmungen, unter denen die verschiedenen notwendigen Schlüssel erzeugt, aufbewahrt und erneuert werden. Sorge bereitete den Entwicklern bei der IETF, dass noch Kanäle dafür fehlen, mögliche Effekte des DNSSEC-Roll-Out ab Januar den Internet Service Providern zu erklären, beziehungsweise deren Beobachtungen zu Problemen abzufragen.

Im Oktober überraschten ICANN und VeriSign mit dem Zeitplan für die DNSSEC-Signierung der Rootzone. Bereits am ersten Dezember wird intern signiert, ab Januar publiziert der erste Rootserver die Zone nach außen. Mittels der kryptographisch abgesicherten DNSSEC-Signaturen soll verhindert werden, dass DNS-Informationen auf dem Weg vom Absender zum Empfänger verändert werden. Der Abgleich von privatem und öffentlichem Schlüssel offenbart, wenn Antworten nicht von der richtigen Domain kommen.

Die Signierung der Rootzone ist notwendig, um die Vertrauenskette innerhalb des Domain Name System zur Umsetzung von Domain- und Host-Namen auf IP-Adressen durchgängig zu machen; erste Top Level Domains wie .se und .org haben ihrer Zonen bereits signiert. Da der Eingriff ins DNS erheblich ist und bei Fehlern ganze Zonen vom Netz verschwinden können, soll der Roll-Out in kleinen Schritten erfolgen. Nacheinander werden ab Januar die Rootserver L, J, M, I,  D, K und so weiter signierte Antworten ausgeben. Voraussichtlich im Mai wird A als letzter Server hinzukommen. A erst ganz zum Schluss einzubeziehen, sei eine schlechte Idee, warnten die IETF-Entwickler, es befördere den längst überholten Mythos, dass A etwas besonders sei.

Jakob Schlyter vom Beratungsunternehmen Kirei sagte gegenüber heise online, es sei heute nicht mehr so, dass DNS-Resolver bei Priming-Anfragen, also bei einem ersten Abruf der Rootzone, immer zuerst auf A zurückgriffen. Die Wahl, A ans Ende zu setzen, sei reine Vorsicht. Einen möglichen Stopp des gesamten Roll-Outs für den schlimmsten Fall hält man sich ebenfalls offen: Bis Juli wird ein nicht validierbarer Schlüssel präsentiert. Damit lasse sich jederzeit die signierte Zone zurückziehen, ohne dass diejenigen, die bereits validierten, keine DNS-Zonen und -Auflösung mehr sähen.

Die enormen Vorsichtsmaßnahmen spiegeln sich schließlich auch beim Schlüsselmanagement, das in hoch gesicherten Rechenzentren und mit Gruppen von “Schlüsselbewahrern” stattfinden wird. Die Internet-Verwaltung ICANN hält dabei den Masterschlüssel (Key Signing Key) über das ganze System einschließlich des Schlüssels für die Rootzone; die ICANN sucht dafür derzeit sieben Personen, von denen jeweils mindestens fünf anwesend sein müssen, um einen neuen Masterschlüssel zu erzeugen, und mindestens drei für neue Signaturen.

Der Aufwand, der betrieben wird, ist beachtlich. Die eigentlichen Tokens, die die zur Signatur- und Schlüsselgenerierung vorgesehene Hardware freischalten, liegen in verschlossenen Boxen bei der ICANN.  Die Schlüssel zu diesen Boxen bringen die Schlüsselbewahrer, die aus der ganzen Welt kommen sollen,  zu den Schlüsselzeremonien mit. Alle zwei bis fünf Jahre soll ein neuer Masterschlüssel erzeugt werden; bei Notfällen  kann dies auch in kürzeren Zeiträumen passieren. Weil man für die sieben Schlüsselbewahrer aus dem Umfeld der ICANN und der IP-Adressverwaltungsstellen jeweils zwei Stellvertreter sucht, benötigt man 21 vertrauenswürdige Personen.

Ähnliche Verfahren gibt es bei VeriSign für das Management des Rootzonen-Schlüssels (Zone Signing Key, ZSK). Anders als der Key Signing Key wird dieser viermal im Jahr ausgetauscht. Während der Übergangsphase liegen alter und neuer Schlüssel bereit. Damit nicht jeder neue ZSK vom Masterschlüssel signiert werden muss, bekommt VeriSign von der ICANN zudem einen Satz von KSK-Signaturen. Ob deren Verlust nicht zu einer Unsicherheit führe, wollte Joao Damas, Entwickler der BIND-Schmiede ISC wissen. Das Signaturen-Bündel und der Rootzonenschlüssel seien “tief im Hause VeriSign” verborgen, entgegnete Matt Larson, Vizepräsident und DNSSEC-Verantwortlicher bei VeriSign.

Während die Entwicklergemeinde über die Sicherheitsmaßnahmen insgesamt beruhigt war, hagelte es Nachfragen zur als dringend notwendig erachteten Informationskampagne. Mit der Lieferung der längeren DNSSEC-Antworten nimmt die Last auf die DNS-Server zu. Alte DNS-Resolver haben Schwierigkeiten mit den langen Antworten,  stellen neue Anfragen über das schwergewichtigere TCP, was erneut die Last erhöht. Die Nutzer sollten vorerst nichts von alledem sehen, versichern die Experten vollmundig. Höhere Latenzzeiten könnten aber schon zu Anrufen von Nutzern führen, warnte ein Experte. Provider müssten wissen, wohin sie ihre Beobachtungen melden sollten.  Der volle Spaß, wenn wirklich validiert werden kann, beginnt im kommenden Juli – wenn alles gutgeht. (Quelle:heise.de)

Die Vorbereitungen für die Absicherung der Rootzone des Domain Name Systems (DNS) mit dem Protokoll DNS Security Extensions (DNSSEC) gehen in die heiße Phase. Beim 76. Treffen der Internet Engineering Task Force (IETF) in Hiroshima präsentierte das Design-Team von VeriSign, der Internet-Verwaltung ICANN und der US-Behörde NTIA die scharfen Sicherheitsbestimmungen, unter denen die verschiedenen notwendigen Schlüssel erzeugt, aufbewahrt und erneuert werden. Sorge bereitete den Entwicklern bei der IETF, dass noch Kanäle dafür fehlen, mögliche Effekte des DNSSEC-Roll-Out ab Januar den Internet Service Providern zu erklären, beziehungsweise deren Beobachtungen zu Problemen abzufragen.

Im Oktober überraschten ICANN und VeriSign mit dem Zeitplan für die DNSSEC-Signierung der Rootzone. Bereits am ersten Dezember wird intern signiert, ab Januar publiziert der erste Rootserver die Zone nach außen. Mittels der kryptographisch abgesicherten DNSSEC-Signaturen soll verhindert werden, dass DNS-Informationen auf dem Weg vom Absender zum Empfänger verändert werden. Der Abgleich von privatem und öffentlichem Schlüssel offenbart, wenn Antworten nicht von der richtigen Domain kommen.

Die Signierung der Rootzone ist notwendig, um die Vertrauenskette innerhalb des Domain Name System zur Umsetzung von Domain- und Host-Namen auf IP-Adressen durchgängig zu machen; erste Top Level Domains wie .se und .org haben ihrer Zonen bereits signiert. Da der Eingriff ins DNS erheblich ist und bei Fehlern ganze Zonen vom Netz verschwinden können, soll der Roll-Out in kleinen Schritten erfolgen. Nacheinander werden ab Januar die Rootserver L, J, M, I, D, K und so weiter signierte Antworten ausgeben. Voraussichtlich im Mai wird A als letzter Server hinzukommen. A erst ganz zum Schluss einzubeziehen, sei eine schlechte Idee, warnten die IETF-Entwickler, es befördere den längst überholten Mythos, dass A etwas besonders sei.

Jakob Schlyter vom Beratungsunternehmen Kirei sagte gegenüber heise online, es sei heute nicht mehr so, dass DNS-Resolver bei Priming-Anfragen, also bei einem ersten Abruf der Rootzone, immer zuerst auf A zurückgriffen. Die Wahl, A ans Ende zu setzen, sei reine Vorsicht. Einen möglichen Stopp des gesamten Roll-Outs für den schlimmsten Fall hält man sich ebenfalls offen: Bis Juli wird ein nicht validierbarer Schlüssel präsentiert. Damit lasse sich jederzeit die signierte Zone zurückziehen, ohne dass diejenigen, die bereits validierten, keine DNS-Zonen und -Auflösung mehr sähen.

Die enormen Vorsichtsmaßnahmen spiegeln sich schließlich auch beim Schlüsselmanagement, das in hoch gesicherten Rechenzentren und mit Gruppen von “Schlüsselbewahrern” stattfinden wird. Die Internet-Verwaltung ICANN hält dabei den Masterschlüssel (Key Signing Key) über das ganze System einschließlich des Schlüssels für die Rootzone; die ICANN sucht dafür derzeit sieben Personen, von denen jeweils mindestens fünf anwesend sein müssen, um einen neuen Masterschlüssel zu erzeugen, und mindestens drei für neue Signaturen.

Quelle: heise.de

October 29, 2009, San Jose: .TM Domain Registry operated from London, UK, with representatives around the globe, has implemented a system to protect companies and their customers from cyber attacks, Internet fraud and counterfeit services. From the 1^st November ONLY customers of companies using a .TM internet domain name receive the highest levels of protection whilst using the Internet.

Internet names ending with the .TM suffix are a valuable asset to Fortune 100, Fortune 500 and Fortune 1,000 companies who are serious about their corporate image. Around 40,000 companies are already registered and many Trademark holders already use the .TM Internet extension in preference to .COM.  Now the .TM Domain Registry is using the latest technology designed to protect .TM users and their customers.

Cyber crime is increasing at a feverish pace especially  “Phishing”, where cyber-criminals lead consumers to counterfeit websites under the guise of legitimate businesses and brands, therefore stealing business.  In June, 2009 alone, 21,085 unique “phishing scams” occurred where a domain name was used to attack specific brands.

Corporations now seek new means of protecting their brand and their customers from fraudulent operations on the Internet.  The cost to businesses through lost revenue and time spent legally to neutralise fake websites is vast and can now be avoided by using a .TM name.

.TM domains are already operating on a state-of-the-art, global infrastructure designed for secure operations, “Technology can never stand still, and Registries and Companies will always need to keep one step ahead of the cyber criminals, we welcome this initiative by .TM Domain Registry” states Paul Kane, Chair of the DNS Infrastructure Resilience Task Force.

Consequently the .TM Domain Registry has introduced DNSSEC which is short for “DNS SECurity” which provides a “chain of authentication” between the domain owner and their clients.

.TM continues its aim for a secure and resilient Internet by signing the registry with DNSSEC and implementing a “first-of-its-kind” method in providing service for its customers and preventing the phishing activity plaguing legitimate corporate brands.

For technologists:

Maintaining the technological leading edge, .TM is the first registry to allow customers the ability to update their DS (Delegation Signer) records in real-time.  With changes taking effect within seconds, .TM name holders can fix compromised domain names instantly by providing a new customer encrypted fingerprint to the registry, minimizing exposure and compromised downtime.  .TM Domain Registry gives companies the tools to shield their customer from malicious attack and corporate-espionage while at the same time protecting their brand and corporate image.

For a list of Registrars selling .TM names please visit:

http://www.nic.tm/registrars.html located in Australia, China, Cyprus, Denmark, France, Germany Italy, Japan, Singapore, Taiwan, UK, USA.

For those serious about their corporate image, security and their trademarked, branded names, their names are secure with .TM.

.TM Registry – Building trust online!

Contact:

Chuck Kisselburg

Office: +1 (503) 928-7967

www.nic.tm

Provided by CommunityDNS, the information in this post consists of news items in the security-based Internet community.

.TM Names Are Now One of the Most Secure on the Internet

Catering to trademarked and brand-conscience corporations serious about their corporate image the .TM Domain Registry has signed with DNSSEC, providing its users with enhanced security against phishing and the malicious community. As a first-of-its-kind for DNSSEC, .TM domain owners can update their DS records in real time.

Click here for more information.

Facebook Phishing Attack Powered by Zeus Botnet, Researchers Say

Asking Facebook users to click on the e-mail provided link to receive their updated password, phishers are using this method as another way to trick users in revealing their usernames and passwords.

Sending the phishing messages at 30,000 per minute as shown researchers the messages are coming from the Zeus botnet.

Click here for more information.

Internet phone systems become the fraudster’s tool

A new angle from cybercriminals include obtaining banking credentials by placing calls FROM the bank. Hackers are breaking into the phone systems of smaller banks because:

• Smaller banks can’t afford the security resources of larger banks.

• People like to bank with smaller local banks.

Hackers will break into phone systems and place calls to customers from the bank’s phone system. Using a prerecorded message regarding suspicious account activity bank customers are asked to respond by inputting their account number and ATM password.

This form of hacking is becoming easier because many of the phone systems are now Internet-based using VoIP.

Click here for more information.

U.K. Proposes To Cut-Off Pirates Internet Connections

The UK looks to curb illegal downloads by disconnecting violators from the internet. Violators would first receive a letter, followed by Internet slowdowns if they persist. If continued violators would face disconnection from the Internet. At this point Britain is looking at France’s 3-Strikes law in that disconnection would occur for a year.

Not mentioned was France’s use of a violator going before a judge to have their day in court before Internet connectivity has been disconnected. ISPs are not in favor of the UK’s move fearing they would have to become the police of the network.

Click here for more information.

Symantec reveals lack of confidence in online retailers

A recent study shows those in the UK have a higher trust in banks protecting their information than other organizations specializing in online retail. The same holds true with Germany in that, while not as confident as the Brits, Germans are more inclined to trust banks with their personal information than they are online-retailers.

Click here for more information.

Buone nuove sul fronte dell’implementazione di DNSSEC.

In base alla presentazione fatta da Matt Larson (Verisign) e Joe Abley (ICANN) al meeting RIPE l’altroieri, ci si propone di introdurre DNSSEC nella root zone entro il 1° luglio 2010.

Nel frattempo, qualcuno ha avuto modo di accorgersi di come qmail sia pressochè impossibilitato a funzionare in presenza di zone DNS firmate, comportamento legato agli errori di qmail nel trattare risoluzioni DNS di dimensioni maggiori di 512 byte.

Problema che, notoriamente, qmail incontra abitualmente per domini con zone DNS “corpose” relativamente poco frequenti, ma quasi inevitabile anche per zone DNS “modeste” nel momento in cui la risoluzione DNS fornisce anche i record RRSIG insieme con il resto della pletora di informazioni legate a DNSSEC.

In pratica, appare plausibile che il progressivo deploy di DNSSEC avrà l’effetto collaterale di far sparire di concerto anche le installazioni di software non più mantenuto.

Dubito che piangerò per questo.

Provided by CommunityDNS, the information in this post consists of news items in the security-based Internet community.

DNSSEC – A Way Forward for TLDs

CommunityDNS recently released a white paper regarding quicker adoption of DNSSEC by TLDs through the use of NSEC3+OptOut.

NSEC3+OptOut allows for:

• Quicker adoption of DNSSEC

• Less impact on Root scalability

• Flexibility for TLDs through incremental adoption

• Provides users with less exposures to current vulnerabilities

• Provides non-DNSSEC-aware users with a better user experience

• Allows organizational adoption based upon established objectives

Click here for more information.

ICANN be independent

The agreement (Joint Project Agreement, or JPA) between ICANN and the Department of Commerce is due to expire the 30th of September. The day before the JPA expires a new agreement goes into effect. The new agreement passes oversight to representatives of the general Internet community, therefore bringing in oversight from a more global perspective. Representatives of foreign governments will conduct regular reviews of ICANN in four areas.

• Competition among generic domains

• Handling of data on registrants

• Security of the network and transparency

• Accountability and the public interest

The U.S. will retain a permanent seat on the panel dealing with accountability and the public interest; the only panel on which the U.S. is to retain such a permanent seat.

Click here for more information.

UNC data breach exposes 163,000 SSNs

The University of North Carolina’s School of Medicine collected information based upon a federally funded mammography research project. Information was collected from 31 different sites from across the state. Records were kept on 236,000 women, with 163,000 of the records containing the participant’s social security numbers. While the breach was discovered in July, 2009, the hack was believed to have taken place as early as 2007.

Click here for more information.

Phishing fraud hits two year high

151,000 unique phishing attacks occurred during the second quarter of 2009, according to a recent report, with the favorite being organizations in the financial and payment services sectors. The prize being the ever sought-after credentials. The study revealed an average of 351 attacks per organization.

Click here for more information.

ISPs force rewrite of law

The Australian parliament recently tabled a bill that, based on wording, could have yielded ISPs to monitor the net. A bill being expanded beyond government protection of network administrators would have soon included all persons operating networks. This would now include businesses such as ISPs. Members of Electronic Frontiers Australia raised concern over the “generality” of the bill’s verbiage. The bill, as worded, could have expanded the purpose of an ISP from being a conduit for people to access the Internet to that of policing users of their respective networks.

Click here for more information.

Get a full dose of great Windows 7 information and advice in the October issue of TechNet Magazine. The entire issue is dedicated to helping you learn about and deploy the newest version of Windows in your organization. Included is my article “Groovy security in Windows 7,” where I discuss my favorite new security features: DirectAccess, BitLocker and BitLocker To Go, AppLocker, and DNSSEC (yes, I’ve changed my thinking about the need for authentication and integrity in DNS), multiple firewall profiles, and the Windows Biometric Framework. Please take a look. I hope you enjoy it, and as always, I welcome your feedback.

Provided by CommunityDNS, the information in this post consists of news items in the security-based Internet community.

Scaling the Root

An independent, third party organization was selected to analyze the impact of scaling the root in order to meet future needs currently on the horizon.

Currently the root zone is relatively small and changes slowly. This is expected to change with the support of DNSSEC, the addition of IDNs, support for IPv6 and the addition of new TLDs.

As a result of the study it is found DNSSEC will have the largest impact to the root zone and is suggested that DNSSEC be added prior to the addition of IDNs, IPv6 and new TLDs. While the addition of new TLDs will have an increased entry of 1 per new TLD, the implementation of DNSSEC results in a increase of the root zone data by 4.

Another way of looking at impact of changes is:

• New TLDs and IDNs will increase the number of TLD entries in the root zone.

• New TLDs, DNSSEC, IPv6 and IDNs will, in their own right, will increase the size of the root file.

• DNSSEC, IDNs and IPv6 will increase the amount of data required for each TLD.

• DNSSEC and IPv6 will increase the number of variables per TLD.

• DNSSEC and IPv6 will increase the number of changes per TLD per year.

Click here for more information.

Security Just Got A Lot More Complicated

Remaining undiscovered for more than a year, security researchers stumbled across an new form of malicious software. Known as Induc, this innovative piece of malware performs its nasty business through the use of a compiler. Induc infects compiled code while leaving a program’s source code alone. So while the source code looks fine the malware resides in the unreadable compiled code. Induc currently operates upon Delphi, versions 4.0 to 7.0. What makes this harmful is the malicious code can reside in complied code that has been digitally signed since the source code has remained untouched.

Click here for more information.

Facebook app flaws create Trojan download risk

A Romanian hacker has discovered Facebook applications that have cross-site scripting vulnerabilities. Five applications developed by Newscloud have been discovered to have the vulnerability. At this point access to the five applications have been blocked by Newscloud.

Click here for more information.

FCC chairman proposes Net neutrality rules

Net neutrality is, “…not about government regulation of the Internet. It’s about fair rules of the road for companies that control access to the Internet” says FCC Chairman, Julius Genachowski.

October is the expected timeframe for when an FCC panel will vote on adopting general guidelines into official commission rules.

The six principles that may be turned into official commission rules are:

1. “Accessing content. The first rule states that consumers should not be limited in the content they choose to view online, as long as it’s legal.”
2. “Using applications. Internet users should be able to run any application they want as long as they don’t exceed service plan limitations or harm the provider’s network. ”
3. “Attaching personal devices. Consumers should be permitted to connect products they buy to their Internet connection, as long as the devices operate within the service plan and do not harm the network or enable theft of service. ”
4. “Obtaining service plan information. Customers should be able to easily review their options when buying Internet service plans and learn about how those plans protect against spyware and other invasions of privacy. ”
5. “New rule: Non-discrimination. Internet providers would be prohibited from selectively blocking or slowing Web content or applications. ”
6. “New rule: Transparency. Providers would be required to make their network management practices clear and available to consumers. ”

Click here for more information.

Tech Insight: How To Make Business Partner Security Work

In a study of 500 data breaches over the last 4 years, 57% involved partner networks used by an external attacker. Understanding what data partners need to have access to and at what times can allow access to be tightened, thus mitigating damage due to data breaches.

Click here for more information.

The Energy Department has started implementing Domain Name System Security Extensions (DNSSEC) on its high-performance Energy Sciences Network (ESnet), using a commercial appliance to digitally sign DNS records and manage cryptographic keys.

DNSSEC is a set of protocols for digitally signing records used by the DNS to translate numerical IP addresses into commonly used domain names. Because DNS transactions underlie most activity on the Internet, assuring the authenticity of this information is crucial to security. The .gov (TLD) top-level domain was digitally signed in February, and the Office of Management and Budget is requiring agencies to sign second-tier domains within .gov by the end of the year.

NIST, NTIA , ICANN, and VeriSign are all working on a practical scheme for deploying DNSSEC in the Internet’s authoritative root zone.

Resources:

The DNSSEC Deployment Initiative Official Website
GOVSEC Free Presentations about the Government’s Plan of Deployment

Provided by CommunityDNS, the information in this post consists of news items in the security-based Internet community.

DNS remains vulnerable one year after Kaminsky bug

One year after Kaminsky detailed DNS’ design flaw that allows for cache poisoning at the Black Hat conference, DNS remains more vulnerable than before. Even though most have patched DNS for this specific issue, DNS it thought to be more vulnerable because hackers are more aware of DNS vulnerabilities since Kaminsky’s presentation. Cache poisoning attacks continue with the most recent one aimed at an Irish ISP only 7 days ago.

Click here for more information.

Skype singled out as threat to Russia’s security

Earlier this year Russia’s president said foreign Internet companies not based in Russia could serve as a threat to Russia’s national security. Russian telecom executives have portrayed the more popular VoIP programs such as Skype and Icq as foreign firms encroaching on Russian territory, thus much fall under government control. “Protect investments and fight VoIP services.” was one of the messages used by the group of telecom executives. The executive’s proposal was to create their own VoIP services that may “safely” be delivered to Russian citizens. They are expecting 40% of calls to be made via VoIP by 2012. Meeting delegates said it was impossible for the police to spy on current VoIP conversations.

Click here for more information.

UAE cellular carrier rolls out spyware as a 3G “update”

Seen by security experts as the next great frontier for distributing malware the mobile phone market is ripe for such malware infusion. However, will all malware be from the malicious/hacker community? Earlier this week blackberry users in the UAE received a text asking them to follow the link to download software that will improve the handoff between 2G and 3G networks. The main issues here are:

• The software was not known by RIM, makers of Blackberry.

• The premise that the download would improve cellular communications was wrong.

• The software installed was from the local network service provider, thus not from a source that should be untrusted.

• The software was actually spyware that would send copies of e-mails to the service provider.

Click here for more information.

Shoot-to-kill policy targets Hull’s P2P users

As countries struggle with implementing a 3-Strikes law of disconnecting users after 3 attempts of downloading copyrighted material, one ISP in the UK has taken matters into their own hands. Citing violation of the provider’s Acceptable Use Policy users are disconnected after the first time. Users can only have connectivity reinstated once they sign a form admitting their guilt.

Click here for more information.

Last July I wrote about a serious security flaw in the domain name system (DNS). It was discovered by researcher Dan Kaminsky and got a lot of coverage: It’s Tuesday — Must be Time to Fix DNS

There was two parts to the DNS vulnerability that quickly became known as the Kaminsky flaw. One was related to poor port number randomization, making it easier for criminal elements to hijack DNS queries and redirect them to fraudulent sites. That problem could be addressed with a software patch, and most of the coverage last year focused on the concerted efforts made by companies like Microsoft, Sun, Cisco and many others to distribute the patches.

But there was another part to the flaw that could not be patched, since it was fundamental to the DNS protocol itself. Internet consumers are still at risk of being redirected through something called cache poisoning, which fools a DNS server into thinking a fraudulent site is authentic. Until recently there was little public acknowledgement of this happening, because most companies are loathe to discuss security breaches.

But in April there was a major breach of a Brazilian IPS Virtua and one of its big customers, the Brazilian back Bradesco. Here’s coverage of the incident from the The Register.

Last week my client NeuStar announced Cache Defender, a way for ISPs to protect their customers from this fundamental Internet vulnerability. ISPs can deploy this solution to create a secure DNS link between their customers and the domains NeuStar is authoritative for, including some of the largest Internet brands such as Amazon, Advertising.com, Oracle and Zappos. Cache Defender is designed to be an interim solution until DNSSEC, a more secure version of DNS can be implemented by the global Internet community.

Here’s some coverage of the announcement:

Network World

Telephony

Venture Beat

CIO

Dark Reading

I’ve worked on DNS issues previously in my career, so this news was very exciting and fun to promote. If you’d like to know more, check out a discussion going on over at CircleID, a top online forum for Internet infrastructure discussions. Not surprisingly, some negative comments about Cache Defender are coming from NeuStar competitors. But the company already has one announced ISP deployment, with more in the works.

DNSSEC is no doubt the definitive answer, but probably won’t be widely deployed until 2011 for a number of technical and political reasons. Until then, Cache Defender is an excellent way for ISPs to show they are doing all they can to protect their customers.

The next generation of the internet WEB3.0

When designing the future infrastructure, companies should take the following trends really serious.

IPv6 – Though not booming yet, companies that have no presence on the IPv6 network yet, will definitely be missing out on something and -depending on how heavily she depends on the internet for promotion, showcase, webapps- will lose revenue. By investing now in IPv6 capable network equipment, training and internal IPv6 segments, companies will gain the needed knowledge and will avoid steep migrations and life production failures.

DNSSEC - Secure DNS – Already, SSL is a must for companies that depend on trust. The next danger ahead (already exploited here and there) is DNS poisoning: DNSses are infected by records that point to criminal servers, aimed to steal (account) information. Companies should arm them selves against this by stepping in to DNSSEC as soon as possible, making a) demand higher and thus speeding up adoption time b) gain the needed knowledge and skills to safely, securely and seamlessly operate in the new environment.

Secure e-mail - Now that e-mail has a legal status in many countries, it is time to adopt PGP and GPG and globally start signing and encrypting e-mail messages. To know that a message has not been read and came from who it claims to have come is of the utmost importance.

The web of Trust, Secure e-mail, DNSSEC and IPv6 will become WEB3.0: Ensuring trusted content on trusted sites over the next generation internet.

Lock up your servers and run for the hills for DNSSEC is coming.

DNSSEC is, simply, DNS Security (“shouldn’t that be DNSSec then?” “shut up”), security for the Domain Name System.

Domain Name System? Whazat?

DNS is one of the underpinning internet protocols that allows you to access donkey pron and lolcats when you are pretending to be working.

Every machine on t’internet has a thing called an Internet Protocol (IP) address. This is a special number representing your specific connection to t’internet (you may well have seen one of these, they are usually represented in dotted quad form e.g. 12.47.46.35).

When you try and access an internet address such as www.donkeylols.com the first thing your computer does is look up the host www.donkeylols.com via DNS and turn it into an IP address.

It then contacts this IP address and requests the page you have asked for. Simple.

Well, maybe not.

What actually happens (and this is an over-simplified example) is that the DNS lookup is actually a recursive process.

In the first instance we need to know who actually runs donkeylols.com and therefore who can give us the IP address for it.

The Root Zone

This is where the root zone comes in. It is effectively the internet zone above all others, sometimes referred to as “.”.

The root zone is served by a set of root servers which are located all around the world and use anycast to get a response from the nearest (quickest) server.

So the process to resolve donkeylols.com would probably break down as follows:

• Ask a root server who is responsible for .com
• Ask the .com server who is responsible for donkeylols.com
• Ask the donkeylols.com server for the IP address of www.donkeylols.com

Voila.

Security and the Like

DNS is an old-school protocol from the earliest days of t’internet and subject to a number of potential security issues.

The most pressing one is DNS Spoofing. This is where a nasty third-party responds to your DNS queries pretending to have the right answer which your computer trusts and connects to.

In this way I could redirect requests to donkeylols.com to my offshore hosted Rick Astley Appreciation site thus Rick Rolling you (or I could just be less nasty and direct you to a malware or phishing site).

By signing the root zone you can be (fairly) sure the answers you’re receiving are the correct ones and you will therefore be accessing the legit face of donkeylols.com.

There are other potential benefits such as opportunistic encryption which might also at least give t’internet the appearance of being a safer place for a little while.

How Does This Affect You (The Reader)?

It doesn’t really, it will all happen behind the scenes in dark rooms filled with flashing terminal sessions.

It’s just one less excuse when it turns out you’re given your credit card details over to a site specialising in gender reassignment operations.

How Does It Affect Me (Dave)?

Good question and I’m glad you asked. Well… it only really affects me if the lower zones (the types of zone I am responsible for the DNS admin of) decide to jump aboard the good ship DNSSEC.

At that point I will probably have to start generating some keys and maybe reading a HOW-TO or three. Maybe even upgrading BIND from the 1983 vintage I use (I fear change).

Oh and I suppose I’ll eventually have to account for it and verification in my PHP DNS implementation.