NETWORK EMBEDDED SECURITY:NEW SCENARIOSStefano Brusotti, Marco Gazza, Dario Lombardo

2 3

SECU

RITY

2 3

SECURITY

The evolution of the network devices is dramatically in-creasing the capabilities of routers and switches, which are changing from closed and strongly specialized devices to open and programmable objects for the most diverse ap-

plications and services needs. Software and hardware architec-tures, while maintaining peculiarities of the network context, are more and more similar to those of a high-performance IT system. We have an interesting result: power, specialization, flexibility, and programmability all in a single network device. The adoption of these technologies, used for both infrastruc-tures and information security, allows realizing innovative scenarios, giving network embedded security a new meaning. This article explores these concepts and describes the specific Telecom Italia’s project for DNS platforms protection, jdshape.

When it comes to technology and ser-vice innovation, it’s always hard to tell who moves first: is the former influ-encing the latter or rather an increas-ing demand for innovative services pushes manufacturers for building cleverer devices, ready to fit new ap-plications’ needs?This is undoubtedly a present chal-lenge in the field of networks and telecommunications services, in par-ticular for everything related to the IP protocol, which is the Internet. It’s from the mutual stimulation between technology producers and service pro-viders that spring the best conditions for the sector growth. The next-generation Internet requires an increase in control, manageability,

The Evolution of Network Devices1 reliability, performance and security features of network elements. Tradi-tional router and switch architectures, as well as related network models, are no longer able to answer to these new calls. The evolution path has been taken some years ago when, in 2001, the IETF has formed a special working group called ForCES, in charge of standardizing new and open architec-tures for the realization of the future network elements. The main features of these new router architectures should be: reconfigura-bility – in order to provide new applica-tion functionalities, scalability – using hardware modules easily updatable allows for an increase in processing power and overall performances. Essentially, a separation had been im-posed between control and forward-

ing operations in order to have more flexibility and scalability. Similarly, network processors’ evolution made it possible to have easily program-mable systems, able to give protocol forwarding wire-speed performance, quality of service and security features on high speed interfaces, well beyond 10 Gbit/s. If open architectures and segregation of functionalities are router evolu-tion’s key factors, so is the evolution of their software development models. Here the goal is to enable a modular approach that allows creating special-ized software according to function, achieving distributed routing calcula-tion in order to exploit physical archi-tectures with several processing units. Implementing network protocols and their related management features through dedicated processes and sys-tems contributes to the undertaking of scalability and openness. With all of this, the purpose is to bring advanced applications inside network elements, namely inside the elements that allow and ensure network opera-tions. That’s the idea of the network acquiring more intelligence, becom-ing able to operate beyond the level 3/4 of the ISO/OSI model, not only providing an increase in performance, but also a different and more effective user experience and better content sharing. Just think of the increasingly specialized CDN (Content Delivery Network) and the emerging models supporting P2P networks (Peer to Peer), such as those emerging from

SECU

RITY

4 5

the work of groups like the P4P (Pro-active network Provider Participation for P2P) or ALTO (Application-Layer Traffic Optimization), created with the aim of bringing the needs of tel-ecommunications operators close to those of P2P end-users.Such networks allow for a much more rapid exchange of data and infor-mation, improving download speed while ensuring a significant reduction in congestion.When network devices perform ad-vanced tasks that go into the details of the transported content, the whole processing chain is greatly enhanced, because the logic of analysis and pro-cessing mechanisms get in close con-tact with the components involved in the transportation. Routers, as we said earlier, maintain the features of typical networking equipment, but they also mix with the flexibility of IT systems; here that it becomes possible to merge the high specialization achieved in the management and routing of network packets with the most diverse com-puting needs. Among them, the very important ones connected to security operations; and, by the way, what bet-ter place than the router to analyze and manage the different network flows and related application proto-cols for security purposes?All the features described so far wouldn’t be enough, on their own, to explain the great interest expressed in Juniper’s technology by those who deal with security. In fact, the whole picture blurs if another important fac-tor is missing, the routers’ software development platforms, the so-called router SDK that must be made avail-able to customers.

The Router SDK2The opening of the development platforms to the customers by router

vendors offers great possibilities for customizing these devices. The separa-tion, once clear, between commercial and customized products tapers, and a strong link can be found between cus-tomer needs and solutions stability.Particularly strong is the link between the developed product and the normal router operation: the vendor wishes customers to develop their own appli-cations, but wants to keep its systems stable, so that their correct functioning is not vitiated. That’s why applications developed in this kind of environment are not completely unconstrained, but must obey some rules that allow for a sound insertion into the host system. These rules can be very strict, for in-stance when they refer to the router CLI (Command Line Interface) inte-gration, or they can be loose, or even guidelines only, when they refer to the coding style.The development of router SDK appli-cations is undoubtedly profitable. The decrease in the number of devices in the network is an important example, especially for an operator that manag-es huge networks. In this way it can re-duce the number of points-of-failure, the amount of power-consumption, the physical space in PoPs and Data Centers. Another advantage is the abil-ity of realizing applications whose ob-vious positioning is inside the network and not at its edge.Some examples could be QoS appli-cations, CDN (Content Delivery Net-works) and security applications such as firewalls. Using regular appliances, putting this kind of applications into operation requires major or minor changes in the network, or you should own a very complex network that transparently allows you to add pieces of equipment without any interven-tion. ISPs, unlike content providers, can take advantage of SDK applica-tions even more since they own the network. This is of key importance and gives network owners chances to real-

ize services that others can't. A content provider such as Google offers an un-believable amount of services to their customers, but there are things they won't ever be able to offer, because they would need to modify the net-work. The development of SDK appli-cations makes network development more flexible and further improves the network value.Of course there aren’t only positive aspects in the SDK development bal-ance. A difficult one concerns com-plexity in the development process. Even if main vendors give a C program-ming language development platform, developing an application that runs on a router requires a completely different approach. A usually very important as-pect, but that for a router is fundamen-tal, is performance. Poor performance is not acceptable for a router, the faster device in packets routing par excel-lence, so it should not run applications that process packets at a very low rate. Applications must be fast enough so that router speed with or without the application board could be compara-ble. Another difficult aspect concerns the novelty of this technology. A recent technology without a history is always more difficult to use. Moreover, lack of real code examples and lack of docu-mentation suitable for new program-mers slows the development down, especially in the very first phase.

The Vendors3The three main router vendors in the world, Cisco, Juniper and Huawei, al-low having custom features built on their devices, but at different levels.Cisco gives a complete SDK (called Cis-co AXP) based on Linux, which allows developing complete applications. It requires adding an expansion card, but it works on low-end routers only (up to the 3000 series). It is also available a

SECURITY

4 5

program called CDN (Cisco Developer Network), designed for companies that want to develop on this platform.Juniper gives a complete SDK [2], based on FreeBSD (like the JunOS), that allows a complete flexibility in development. It also requires the in-stallation of an expansion card (Mul-tiService PIC [1]), in Figure 1), and is provided with powerful libraries for packet processing. The strength of the solution is that the card is available (in different models, but all compati-bles), for all the M-series models (as the M7i, in figure 2) as well as the T-series models.The Juniper solution was the one se-lected to start, in Telecom Italia, the project for the development of new functionalities on routers. The choice has been determined by different fac-tors. The first one was that there is just one JunOS software release for

Figure 1 - Multiservice PIC 100

Figure 2 - Router Juniper M7i

all the router models, and that is also true for the SDK applications. From an ISP point of view that dramatically decreases the amount of work needed for testing different versions. Another point was the Juniper SDK project ma-turity: Juniper had already defined the training, the support and a partner-ship model to support the companies that invested in developing applica-tions.

The Juniper Opportunity3.1Juniper launched the PSDP (Partner Solution Development Platform) in December 2007, and has recently re-named it as JUNOS SDK. This develop-ment program includes partners from different fields of application such as network operators, content provid-

ers, customers, system integrators, re-search and development institutions. Overall, in October 2009, Juniper had 35 partners involved in the JUNOS SDK program, including Telecom Ita-lia (who joined in June 2008).Possibilities of using the JUNOS SDK are many: as a partner, the interest could be in developing critical ca-pabilities for exclusive use and con-sumption. For example, a government agency could write proprietary exten-sions of network protocols in order to enhance overall security. Or the ap-plication being developed could pos-sibly be sold to Juniper or a partner, which becomes owner and maintainer, or you still can find an agreement on revenue sharing, so that Telecom Italia or a chosen partner remains owner and maintainer and the Juniper’s role is to certify the software on the devices.

Security Issues with DNS3.2The network portion chosen by the Security Innovation Group of Telecom Italia for the application of Juniper technology was the DNS. This choice stems from different reasons. First, the DNS infrastructure is critical to the functioning of the network: all Inter-net browsing is premised on its proper operation and a disservice to the DNS is immediately perceived as a total quality of service degradation. Second, the DNS is a victim of security attacks that may affect its operation and cause a more or less important disruption. A third reason concerns the traffic vol-ume at stake: the amount of DNS traf-fic, in fact, is not very high compared to other services, making it possible to use low cost equipment with Gigabit interfaces both in development and production environments. We spe-cifically installed the PIC Multiservice 100 (entry level).

SECU

RITY

6 7

The main types of attack involving DNS, studied and documented in the literature [3]: DNS DoS and DDoS; DNS Cache Poisoning; DNS Covert Channel; Buffer Overflow; Zone Transfer Hijacking; Dynamic Update Corruption; Unauthorized Registry Changes.

In particular: Buffer Overflow [9], Dy-namic Update Corruption [4, 10, 11] and Unauthorized Registry Changes [12] are specific attacks taken against specific vulnerable DNS servers, and require the attacker to use a very lim-ited amount of traffic. Regarding Zone Transfer, these transactions are considered harmful to the domain in-volved (information leakage) and are usually restricted by white-list and / or black-list. Moreover, these opera-tions are usually carried out using the TCP transport protocol, unlike nor-mal DNS requests that use UDP in-stead. Zone Transfer requests can be used by any attacker attempting a DoS on the victim server, since servicing them usually requires a considerable computational load. These situations, however, fall within the more general series of DoS attacks. The DoS or DDoS attack [6, 14, 16] oc-curs when one or more attackers who control one or more devices (common-ly via botnets) throw massive amounts of queries to one or more DNS serv-ers. If the sources of the messages are distributed (for example, a botnet), the attack is difficult to control and track. In addition, the DNS response packets are larger than the queries, and this feature can be used to amplify the traffic generated in the attack us-ing spoofed source IP addresses [17]. In this case, the spoofed source IP ad-dress is the target of the attack and the attacker sends forged DNS queries to a DNS server, which then responds to the spoofed IP address. A DDoS attack

can then be directed straight to the DNS servers, or use the DNS servers to hit another spoofed IP address. More-over, an attack directed to a DNS serv-er can use protocols other than DNS itself, such as the ICMP echo replay at-tack brought to the thirteen root serv-ers of the Internet in 2002 [13], and the subsequent attack of 2007 [18]. DNS cache poisoning [4, 15, 19] is an attack that aims to change the name server cache content, that is the asso-ciation between IP address and server name. This allows you to redirect a web domain name (such www.enter-prise.com) to a different IP address than the original one. In this way you can divert all traffic to the web domain required without the user noticing anything. The technique involves de-ceiving a DNS server authorized to do recursion, into believing that it receives truthful information, when in reality information is created on purpose to change its behavior. The information received is also stored in the cache for a certain period of time and spreads the effect to all the users of the server. Fa-mous worldwide attack known as "The Kaminsky bug" was discovered by Dan Kaminsky and presented at BlackHat in 2008 [23]. The dynamics of the at-tack is as follows: the attacker sends a query to the local server that initiates a recursive search. At the same time the attacker sends fake responses (with a spoofed source address) that come to the attacked server before the authori-tative server responses. A variant of the attack is to send the answers directly to the client resolver. The local DNS server sends back false responses to the client and stores the corresponding record in its cache. Fake answers must seem cor-rect to the server, thus their sequence numbers must be within the acceptable window (birthday attack) [15].Another type of attack can be carried out using a covert channel [7, 8] or tunnel [21, 22], where the DNS proto-col is used to transmit information of

a different nature than that for which it was designed (i.e. a remote shell I/O stream). This attack is usually used to circumvent the perimeter protec-tion or as a means to make more dif-ficult the reconstruction of a malicious activity. A DNS server can be used to convey this attack even without any specific action taken against it, and then without having to exploit its vul-nerabilities. The means by which this result is obtained are usually recursive queries made to a domain under the control of the attacker. To maximize the bandwidth made available by the DNS server used, Covert Channel and Tunnel typically use very large packets, changing the average size of query and answer that passes through the server. These changes can be identified either by direct analysis of statistics on the packet size, or with the analysis of his-tograms of distribution of this meas-ure and its entropy [3, 5, 14, 20]. Also in order to maximize the bandwidth available, Covert Channel and Tun-nel usually produce an increase in the number of requests and responses on the server; again, the anomaly is de-tectable with the statistical analysis of the quantities involved. It should be noticed that in general it is still possible for an attacker to cre-ate a covert channel that does not change significantly any of these traf-fic measures, at the expense of lower bandwidth. In this scenario, however, the impact on the functionality of the server used is definitely zero.

The jdshape Project4The jdshape project was started with the goal of addressing the need that has never been more urgent, of making the DNS system more secure. There are many initiatives going on in this di-rection covering different DNS aspects (DNSSEC is one of them), but in order

SECURITY

6 7

Administrator

jdshape-mgmt

jdshape-data

InternalCommunication

DNSTraffic

DNSTraffic

CLI

ConfigurationManager

CommandManager

DNSDecoder

ForwardDropped PKT

Stats

FQDN BlackListprofiler

Drop RedirectRateLimit

SyntaxCheck

StatefulCheck

A2A Communication(SNMP/DP/SOAP/Etc.)

Figura 3 - Jdshape Software Architecture

to protect the current DNS infrastruc-ture it is necessary to act by targeted and short-term actions, for instance by interposing between DNS servers and possible attackers a new system, with the ability of recognizing attack traffic patterns and filter them out. The use of closed source, black box proprietary technologies was actually a possible option, but our choice fell over the Ju-niper SDK, because of the related ex-pected benefits. The outstanding de-sired features, a low explicit cost due to the use of internal staff, a complete coherence with the company policies (owning the source code makes the insertion of new functionalities very flexible), the reduction of the number of vendors and the number of network devices, are some of the key benefits.

The Software Architecture4.1The software developed under the pro-ject is called jdshape (acronym for Juni-per DNS traffic Shaper). Its main goal is to give the router filtering capabilities, based on logics belonging to the DNS world. The software is composed of two

main components (as seen in figure 3), jdshape-mgmt and jdshape-data. The jdshape-mgmt component resides on the routing engine and adds new con-figuration and operational commands to the standard CLI of a Juniper Router. It is in charge of storing the configura-tion and to transmit it to the jdshape-data software component, which resides on the MS-PIC board. The enriched CLI can also execute commands that give information about the jdshape software itself and about traffic flowing through the router; in fact jdshape-mgmt re-ceives periodical statistics from the MS-PIC. The jdshape-data component is the heart of the jdshape software. It is composed of a bundle of modules that can be classified as “enforcers” or “tools”. Enforcers can drop a packet, so they re-ally provide security functionalities, while tools are “service” modules since they collect statistics as well as data of different kind, but they can't modify the normal flow of packets.The modules that jdshape makes avail-able are:

DROP (enforcer)It's a DNS firewall; it can block pack-ets according to configured rules. The

available rule fields are the following: source (ip/netmask), destination (ip/netmask), QR (see [25]), QTYPE (see [25]), domain name (a string that rep-resents a site/domain, possibly with a '*' wild card).Here is an example rule for this mod-ule:

rule 1 from 1.2.3.4 to 2.3.4.5 qr Q qtype T-MX domain *.mydomain.com

RATELIMIT (enforcer)It has the same syntax as the drop en-forcer, but instead of blocking, it lim-its the number of packets per second. It has an additional field option that corresponds to the number of allowed packets per second.An example rule for this module is as follows:

Rule 1 from 1.2.3.4 to 2.3.4.5/24 qr Q qtype T-MX domain *.mydomain.com rate 40

STATEFUL CHECK (enforcer)It's a protection shield for spoofing at-tacks. It only forwards a response if it has seen its corresponding query. All the reflection attacks are blocked by this module.

SYNTAX CHECK (enforcer)It verifies the syntactic correctness of the packets, preventing them from moving on in case of negative check. In normal network operation such “weird” packets should not show up, so they are probably hand-crafted by an attacker and eventually dropped. Syntax check is composed of a bundle of sub-modules that can be singularly activated; they refer to packets: not decoded DNS with multicast ip address packet over a certain size unsupported qtypes with a trailer fragments with same source and destination

SECU

RITY

8 9

with martians IP wrong checksum

REDIRECT (enforcer)This module is used to block some for-bidden DNS resolutions. It is useful when access to certain sites has to be blocked (such as some gambling sites forbidden by the Italian law): in this case the client is redirected towards a captive-portal that gives the user a warning. The enforcer may be activat-ed by defining rules where source IP addresses can also be specified.

rule 1 from 1.2.3.4/16 domain *.forbidden.domain.it redirect-to captive-portal.mydomain.com

It is furthermore provided with a sys-tem that hijacks NXDOMAIN (non existent domain) responses to adver-tisement portals, for example when the user enters a wrong address in the browser’s URL bar.

nxdomain redirect-to advertisement.mydomain.it

REGEX (enforcer)It checks packets in transit against a regular-expression and blocks them if they match. It is a system suitable for blocking all the non-traditional at-tacks, that don’t fall under the scope of the previous enforcers.The main applicable scenario is block-ing of packets carrying a shellcode (the module acts like an antivirus).

STAT (tool)It allows collecting statistics about the overall flow of packets that pass across the router. In addition, it gives users the possibility to specify rules (flows) for which specific statistics are to be collected.

rule 1 from 1.2.3.4/24 domain *.google.com

FORWARD DROPPED (tool)Using this module it is possible to avoid that packets marked by the rout-er as droppable, are actually dropped. They can be forwarded to an external system for troubleshooting, through IPIP encapsulation (see [24]). In this way the jdshape operator can monitor at any time what the router is blocking and counteract possible unwanted be-havior with proper tuning.

SNMP (tool)The router extends the enterprise MIB to allow some of its info to be queried. In particular, it is possible to read the actually configured rules as well as their related counters, and the global counters (all coming from the STAT module).

Network Deployment4.2There are basically two ways to create a network that hosts jdshape, depend-ing on whether we can design the ar-chitecture from scratch, or we inter-vene on an existing infrastructure. The positioning of the router that houses the PIC must be "in-line", i.e. the traffic

Jdshape 2

L3 Switch FE

Internet

L3 Switch FE

L3 Switch BE

Jdshape 1

L3 Switch BE

DNS Farm

Figura 4 - Network Deployment (case #1)

must pass through the router, for traffic enforcement to be effective. This clari-fication is a must since it is not enough to provide jdshape with replication of DNS traffic using, for example, the ac-tivation of a span port, as is the case for intrusion detection systems. jdshape is mounted on a router, and then is Level 3 architecture that must be designed or modified in a timely manner. Fig-ure 4 shows the architecture designed from scratch to host jdshape. The rout-ers "jdshape 1 "and "jdshape 2" host the MS-PIC board, and carry both the standard routing functions and the specialized ones provided by jdshape. It is assumed that the two devices are configured in high availability using VRRP protocol in hot / standby mode, and therefore the traffic flow traverses a single jdshape indeed. This point is very important, because the two jd-shape do not have a high availability protocol, and therefore their configu-rations must be done separately on each router. Figure 5 describes the integration into an existing network infrastruc-ture, which includes L2/L3 network equipment for both the front-end (FE L3 Switch) and the Back-End (BE L3 Switch). In this scenario, the routing

SECURITY

8 9

Internet

Jdshape 1 Jdshape 2

Switch 1

DNS1 DNS3 DNS5 DNS2 DNS4 DNS6

Network 1 Network 2

Mgmt

Switch 2

Figura 5 - Network Deployment (case #2)

plan must be amended so as to give priority to the routes that pass through "jdshape 1 "and "jdshape 2 ". Fault tol-erance in this case is obtained by the routing protocol itself, typically with OSPF. The premise in this case is that front-end routers implement VRRP / HSRP in hot / standby mode, so a sin-gle jdshape is to be crossed by the DNS traffic stream. As in the previous sce-nario, the configurations of the two jd-shapes must be kept aligned manually.

Experimental Results5The jdshape software underwent tests in the Be-Secure Security Lab of Tel-ecom Italia in order to prove its non-intrusiveness, its functionalities and to measure its performances. For this purpose we have realized a test-bed with both standard systems (DNS clients and Bind servers) and spe-cific testing equipment (Spirent Test-Center) that can generate structured

and non-structured traffic. This is the standard approach for the conform-ance tests of the security devices in Telecom Italia, and it allowed us to go into all the details of the software, and to solve its bugs. Moreover, we ap-proached testing by keeping the devel-opment and the testing teams sepa-rate. This allowed us to have a mixed approach: black-box (for bug hunting) and white-box (for bug solving).The first test set aimed at verifying the software’s non-intrusiveness. This is a key step, since adding a new system to the network requires that its normal behavior must be preserved. This is easily achieved with the Juniper tech-nology; in fact, once the card and the software have been installed, the traf-fic is steered to the card only if a con-figuration command for this purpose is intentionally issued. Tests ensured that with or without the steering ac-tive, the router keeps working as usual. It is obvious that the steering and the activation of the new jdshape features cost something in terms of perfor-

mance. The development router (an M7i model) is able to process about 1.200.000 packets per second without routing the traffic to the MS-PIC. Acti-vating the steering toward the MS-PIC that rate is reduced to 800.000 packets per second. The jdshape DNS decoder doesn't reduce this rate further, so the software can process up to 800.000 packets per second without any en-forcer or tool active. A very useful feature of the Juniper router is the “deactivate” command for traffic steering; by issuing this com-mand from the router CLI, the normal flow of packets can be easily re-estab-lished very quickly (let's say a couple of seconds) bypassing the MS-PIC. This gives the operator a “security last re-sort tool”, should the jdshape software cause any serious traffic slowdown, without any downtime in the network. From an ISP point of view that is obvi-ously greatly beneficial, since a down in the DNS system has a big impact on the network and their users.The second test set aimed at verifying the functionalities of the system. En-forcers have been put under unit tests, activating a specific configuration for each of them, in order to isolate and display every single enforcer’s behav-ior. Each and every enforcer’s feature has been tested, verifying whether the expected and observed results agreed or differed, thus creating some test-cases if the latter happens. This ap-proach led us to solve bugs very quick-ly. Later, modules have been tested simultaneously, activating them one after another, until creating a configu-ration with all modules active. All the modules passed all kind of tests.The last test set was system perfor-mance. Every module has a cost, in terms of throughput, and as the num-ber of active modules increases, per-formance degrades.In order to have meaningful measures, we tested many modules together un-til all are active. Anyway, we want to

SECU

RITY

10 11

stefano.brusotti@telecomitalia.itmarco.gazza@telecomitalia.it

dario.lombardo@telecomitalia.it

The jdshape project has now entered its final phase concerning technologi-cal development. Next steps include the creation of field trials and the consequent delivery into the DNS do-mains of interest, lead by the Security Engineering Group of Telecom Italia. At the same time together with Juni-per, we need to investigate commer-cial and collaboration aspects further, in order to bring the Telecom Italia jd-shape application to the international market.For completeness, remember that jd-shape is a component of a larger pro-ject conceived to protect the DNS, which envisions an architecture where the network includes monitor-ing systems, human operators that analyze their output data in order to verify the proper operation of devices, analytical engines able to detect any noise in the functioning of DNS and, of course, enforcement equipment.In this scenario, a complementary technology to the jdshape also de-veloped by the Security Innovation Group is given by the proprietary sys-tem Ludmilla, which provides a tool for monitoring and analyzing DNS traffic from a security point of view. This system makes use of anomaly detection techniques and is able to report a suspicious event to human operators, providing at the same time information on possible configura-

tions to be deployed on the enforce-ment machinery, specifically the Juni-per router equipped with the jdshape technology. The suggested configura-tion will eventually be accepted and applied by the operator, and here is the complete picture, that is the full spectrum DNS protection service.Among the upcoming features that Ludmilla and jdshape will be capable of, there will be modules for analy-sis and protection from phenomena that carry, or are vehiculated by, DNS traffic. For example botnets, which represent a growing problem with significant impact on infrastructure and network users. These are not, in fact, real attacks to the DNS, but it’s possible to stem them effectively by developing appropriate protections at that level ■

Acronimi

Bibliografia[1] www.juniper.net/us/en/local/pdf/ datasheets/1000199-en.pdf[2] www.juniper.net/us/en/productsservices/ nos/jun os/junos-sdk/[3] Anestis Karasaridiris: Detection of DNS

Traffic Anomalies, http://ewh.ieee.org/r1/ njcoast/DNSTraffic.ppt[4] Why is securing DNS zone transfer neces-

sary?, www.sans.org/reading_room/ whitepapers/dns/868.php[5] Extrusion Detection Illustrated, http:// searchsecuritychannel.techtarget.com/ searchSecurityChannel/downloads/ Bejtlich_Ch3.pdf[6] Domain Name System Denial of Service Attacks, www.ciac.org/ciac/bulletins/

j-063.shtml[7] Dan Kaminsky, Attacking Distributed Systems: The DNS Case Study, www.doxpara.com/slides/BH_EU_05- Kaminsky.pdf[8] Covert Channel Invisibility Theorem,

www.springerlink.com/content/ p5003w3w12264884/fulltext.pdf[9] DNS Service Buffer Overflow Vulnerability,

http://secunia.com/advisories/24871[10] DNSAPI Error and corrupt DNS records, www.itnewsgroups.net/group/microsoft.

public.windows.server.networking/top-ic22566.aspx

[11] http://compsec101.antibozo.net/papers/ dnssec/dnssec.html

Conclusion

emphasize that a configuration with all enforcers on is very unlikely to have in operation, because modules are thought to be used to face an ongoing attack, so they should be deactivated thereafter. It is not forbidden anyhow, provided that system performance is high enough; that’s why this kind of configuration has also been taken into account.

CDN: Content Delivery NetworkCLI: Command Line InterfaceDNS: Domain Name SystemDOS: Denial of ServicesDDOS: Distributed Denial of ServicesISP: Internet Service ProviderP4P: Proactive network Provider

Participation for P2P P2P: Peer to PeerQoS: Quality of ServiceSDK: Software Development Kit

SECURITY

10 11

Dario LombardoHe’s a Computer Engineer with a Master Degree in Telecommunications and joined Telecom Italia in 2001. The first work experiences were on vulnerability assessment and continued with the software development of innovative systems in the security field, with particular attention to routing protocols, VoIP, and DNS. Now he is Senior Security Expert in Telecom Italia and is the jdshape project manager.

Marco GazzaHe got a degree in Computer Science and received the COREP (Politecnico of Torino) Post-Graduate Master Degree in Telecommunications in 2000. He joined Telecom Italia in 1996 working on Artificial Intelligence and Billing Systems and then started developing software prototypes in the network simulation and anomaly detection areas, with particular emphasis on the DNS protocol. He is currently Senior Security Expert in Telecom Italia.

StefanoBrusotti After getting his degree in Computer Science, he joined Telecom Italia in 1996, dealing with payment systems and electronic money; he received the COREP (Politecnico of Torino) Post-Graduate Master Degree in Telecommunications in 1997 and then started developing research and development initiatives targeting network, systems and ICT services security. He acquired extensive experience in this field and is now head of the Security Innovation Group in Telecom Italia.

[12] DNS resolution path corruption: Guard your registry, http://it.toolbox.com/blogs/

adventuresinsecurity/dns-resolution- path-corruption-guard-your-regis-

try-22422[13] Ryan Naraine, Massive DDoS Attack Hit DNS Root Servers, www.cs.cornell.edu/People/egs/beehive/ rootattack.html[14] Yasuo Musashi, Ryuichi Matsuba, and Kenichi Sugitani, Detection and Preven-

tion of DNS Query PTR record-based Distributed Denial-of-Service Attack [15] J. Stewart: “DNS Cache poisoning - The Next Generation”, 2003 [16] US-CERT: “The Continuing Denial of Service Threat Posed by DNS Recursion”,

2006 [17] R. Vaughn, G. Evron: “DNS Amplification

Attacks”, marzo 2006[18] ICANN: “Root server attack on 6 February

2007”, ICANN (The Internet Corporation for Assigned Names and Numbers) Factsheet, 2007 [19] D. Sax: “DNS Spoofing (Malicious Cache

Poisoning)”, SANS Institute 2002 [20] H-J Shin (KORNET): “A DNS Anomaly Detection and Analysis System”, NANOG 40, 2007 [21] M. Van Horenbeeck: “DNS tunneling”,

2007, www.daemon.be/maarten/dnstun-nel.html

[22] J. Plenz: “DNStunnel.de”, 2006, http://dnstunnel.de/ [23] Multiple DNS implementations vulnerable

to cache poisoning, www.kb.cert.org/vuls/id/800113

[24] C. Perkins “IP Encapsulation within IP”, RFC 2003[25] P. Mockapetris, “Domain Names - Implementation and Specification”, RFC 1035