Dan Kaminsky has discovered a new vulnerability in the DNS protocol that affects most of the implementations. The exact nature of the flaw still stays a secret until August, however, even until then it's advisable to install the patches. By the way, the DNS protocol is bleeding from several wounds, you can read about several problems here:

http://www.kb.cert.org/vuls/id/800113

With the questions and answers below I try to make the whole problem clear:

Q: What is the cache poisoning attack?
A: The attacker can inject false entries into the DNS server, and the server provides these false entries later. With the false entries the attacker may achieve his goal that the victims connect to the system controlled by the attacker instead of the one they originally wished to reach.

Q: How does the cache poisoning attack work?
A: There are several known methods of this, and some old methods aren't working any more. The most current method is when a DNS server issues a query, instead of the genuine reply, the attacker sends back fakes ones very quickly following each other, that way one of them may get in with a good chance (the DNS server thinks that it got the reply to the question it asked).

Q: Why is it recommended to disable recursive mode?
A: Recursive mode means that for a client request the DNS server will play the complete multi staged question/reply process. If this mode is forbidden, then the DNS server does not issue queries instead of the client, therefore it is not attackable.

Q: Does this flaw affect only the DNS servers?
A: The flaw can be found in the protocol, the individual clients can be attacked in a similar way themselves.

Q: When can the recursive mode be blocked?
A: On the internet it is practical to do it in the DNS servers, in case of intranet it's not always obvious. If the clients want to manage the requests themselves, that may come with several disadvantages: with increased network traffic and a bigger delay (because the clients usually aren't caching), the client resolver can be equally attackable (if not even more so). It is practical to create the intranet such that that there are forwarding DNS servers which are recursive. In case there are other DNS servers, recursive requests should be disabled there. We should provide the forwarding servers to clients, if possible.

Q: What makes the replies so easy to fake?
A: Back then the DNS protocol wasn't prepared against the attacks. The protocol contains a 16 bit transaction identifier, whose sole purpose is the matching of the requests and the replies. In normal cases it is perfectly enough, but against attacks it's too small. With the increase of bandwidth it became obvious that it's easy to brute-force (sending 32768 false replies on average is absolutely not impossible to carry out).

Q: Can it be any worse than this?
A: In case the transaction id generator works inefficiently, then instead of the average 32768 fake replies 8-10 can be enough. That is already a really serious problem (the chance of a successful attack increases unbelievably).

Q: Why is it dangerous when the forwarding DNS server requests the same record several times, while the previous reply hasn't arrived?
A: In these cases the chances of the attacker may significantly increase because of the so-called Birthday paradox (http://en.wikipedia.org/wiki/Birthday_problem).

Q: Is it possible to protect the system at all?
A: Choosing random source ports for the requests may help, since it takes cca. 16 bit randomness to the game (with the help of the transaction identifier that's already 32 bit). Even if it is not impossible to trick out, but it's much better than the original situation was. Using the DNSSEC would be a solution, but it's still not widely spread enough.

Q: Why didn't they use it until now?
A: At the implementation of the clients they didn't pay attention to it (they always used the first free port there), and the DNS servers often sent requests from a fixed port.

Q: Why was it good that the request was sent from a fixed port?
A: If we weren't using stateful packet filters, then filtering DNS requests from a dynamic port was a nightmare. All external UDP traffic to all the 1024-65535 ports of the DNS server had to be permitted, so for example if NFS was running, it was accessible from the outside as well.

Q: What is recommended as defence?
A: Primarily the patch must be installed, second it's practical to disable recursive requests for unknown clients where possible. Where the request port was fixed (for example in case of bind with the query-source parameter), then it's practical to remove it (but attention must be payed to the the proper firewalling too).

Peter Mato, Janos Farago, Marcell Zambo, Laszlo Zrubecz

May 2004

Troubleshooting on Linux and Unix systems

It happens sometimes that we experience abnormal operations while using a server or workstation. The computer freezes irregularly, or it's making clicking sounds, the sound card is moaning, a program doesn't want to start, just stops and doesn't do anything, or on the contrary, it does something, only not what we expect it to do. It happens that a server should accept a connection, but it doesn't. Annoying. Less experienced users ask for help in cases like this, or in worse case, they give up and don't use the given program. Although usually there is a solution, it just requires troubleshooting experience. Sadly it's not really taught at schools, although maybe that would be one of the most important topic to be discussed. The study summarizes what type of problems may occur on a system and what tools and methods can be used for detection and resolution.
The study is an accompanying material to the lecture voted the best by the audience at the GNU/Linux conference in 2004. We highly recommend it to everyone who uses Linux or other Unix systems. It saves everyone lots of annoyance ...

Zoltan Borbely, Janos Farago, Marton Torok

2002

Typical programming mistakes

The study was made as a supplementary material to one of the lectures of the course called "Introduction to IT security" held at Budapest Polytech on a yearly basis. The study is a general introduction to the nature of the security flaws caused by programmers due to thoughtlessness or ignorance. It mentions program independent security flaws, the most commonly made mistakes of compiled languages and some of the typical errors of interpreted languages. Because of its size the study can't introduce readers to all possible errors, but the listed errors give a really good outline and approach. It's an obligatory reading for program developers.

Among several other authors Peter Mato

2004

The security risks and controls of the IT network infrastructure

This study is a part of the research project titled 'Developing the structure of the internet defence system' (Serial number: E4, Registration number: 4671/4/2003) made within the frames of the IHM-MTA Research Program. The complete document is a great volume and in its making several people, who are acclaimed and illustrious experts of their fields participated. Mato Peter had the honour to participate in the creation of the study by writing two chapters. The complete list of the authors can be found in the document.

Peter Mato

1999-2003

How to become a Linux guru

From the short and absolutely quintessential summary the people who are interested may learn what a beginner needs to become an intermediate Linux guru. Even the parameters of necessary commands are indicated, that way the beginners don't have to look through hundreds of switches of every command and hoping that he manages to remember the more important ones. Naturally, such a proposition can't be complete, but according to the author's experience if someone is capable of using the listed switches of the collected commands, and reads the recommended books, they must be independently capable of the solution of the also recommended tasks, and that way gaining a certain type of proficiency. The deep knowledge of Linux naturally requires serious experience, but one can acquire it with time.