How our system works?


For admins only!
ADOS frontend
DHA query engine
virusflags report-query engine
Server side


In result of growing number of uninvited mails,viruses spreading in mails and other malwares people tend to think it twice who they give their e-mails to. They have another think whether they should take the risk to use their e-mail on an online forum, or even to leave it on their own web page or calling card. Cause of the reasons above, the users usually keep an other one-time e-mail address, often at some free service provider, which in case of flooding of uninvited mails, it can be leaved to its own devices.
The root of the problem in DHA is in the SMTP protocol itself: the e-mail servers, if they got the mail to a proper address, would not respond, simply accept it. If the server got a mail to a non-existent address, then it would give a response either immediately or later whether the post office box exists or not. This process gives information about the e-mail addresses which are maintained by the server. The attackers use this information, sending huge amount of messages to the e-mail server. The addresses from which do not arrive response (so the server accepts the e-mail without negative signal) are gathered to a list. These addresses should belong to valid user accounts, so it is worthy to send uninvited mails to it.
Beside of getting out of our address, the other problem may the DoS like attack of the mail server. For the sake of gathering the e-mails, the attacker (or even more than one) sends huge amount of misaddressed e-mails, which can result in the overloading of computing and network capacity of the server.

Denial of Service attack

During a Distributed Denial of Service attack the target is an Internet server and the attacker's aim is to exhaust the server's resources in order to prevent authorized access to services or degrade the quality of service. The attacker utilizes more attacking clients and acts organized to multiply the impact of the attack and to avoid being discovered and filtered. It is a fairly easy task to deploy a DDoS attack. Various prewritten tools are available on the Internet. Protection against DDoS attacks highly depends on the model of the network and the type of attack. Although several solutions and methods have been proposed, most of them have weaknesses and fail under certain circumstances. We provide a simple and robust protection algorithm based on easily accessible information at the server. This is done in such a way that the server host cannot be disabled by an attacker and as soon as the overload disappears, the normal service quality resumes automatically (e.g. without restarting the server). Simultaneously we wanted to minimize the number of legitimate sources blocked by the server as it is typically needed in a real-life scenario. This criterion is not met by many of the current commercial solutions. Our approach does not need to modify network elements outside the victim server.

ADOS-DHA query engine

The basic SMTP system is extended with a general TCP wrapper, a DoS front-end client and a DoS front-end engine. The TCP wrapper is a simple wrapper that first asks the DoS frontend if the sender is permitted to send e-mails. After that it simply forwards the data through the connection towards the mail transport agent (MTA). The DoS front-end client is a simple application, its duty is to communicate with the DoS front-end engine and depending on the decision of the engine, send the result back to the wrapper application. The DoS front-end engine consists of a statistical engine that measures the traffic and maintains the statevariables of the DoS front-end and a decision engine that decides if a sender should be filtered out preventing to send any e-mails. If our system considers a state as an attack state, it simply sends back a regular SMTP temporary error to the sender. If the system decision is a false detection, then the sender is not able to send the message immediately, but due to the way SMTP works, after some time-out the senders SMTP server will try to send the message again. This way we can set an efficient protection against the attackers without harming the regular traffic (as we do not filter all the traffic only the attacking traffic), and we do not cause intolerable problems even if the decision is a false-positive. Our prototype is currently in the programming phase, we plan present the results of the prototype system at the conference.
This frontend has been extended with the function which allows for us to ban IP-addresses involved in DHA attack on this level. After the regular statistical checks (mentioned above) which every IP-address has to be passed, comes the DNS query to the DHA RBL-list, where the frontend examine the address in connection with DHA.

How to install?

  1. Download it and copy the adosd file to /usr/sbin, and the config file to /etc.
  2. Set up the configuration file to use valid name and password!
    This means that you have to register your modul on the DHA-admin page to get valid authentication name and password!
  3. Set up the firewall rules to forward port 25 to port 2225. This can be seen in a script called adosexim.
  4. Then you can start the daemon by typing: 'ados.init start'

Directory Harvest Attack

We suggest a system built up by components, which infiltrates besides our current system and halts these types of attacks. This system consists of a syslog analyzator, a spam detector, and a virus searching portion. The results are summerised in a centralized registration list, so we keep the list of those computers which are involved in the DHA attack. With the help of the centralized registration list, all member of the system using our components gain information even from each others problems, so the attacker can be banned not only from one place but it can not do any harm for the others as well.

Syslog checker-DHA report engine

The syslog analyzing system looks up in the e-mail server notifications that where the misaddressed e-mails are coming from (which IP address), and makes a detailed report to the central database. In favour of the low number of misaddressed mails, we introduce a method that the discrete missaddressed e-mails can be divided from the real attackers. Our system can also be connected with spam-recognition softwares and virus scanners. The solution makes savings possible by mails, coming from known DHA attackers, are not subjected to resource consuming content filtering methods, just simply forbidden. Our system combined with other methods can improve their efficiency as well.

How to install?

  1. Simply download and set vaild parameters to the configuration file.
  2. Set up according to your system built up whether you use exim or sendmail.
    This means that you have to register your modul on the DHA-admin page to get valid authentication name and password!
    You can use the same one your ADOS modul uses.
  3. You can set the IP-addresses which belongs to you and do not have to be reported.
  4. Then type in 'perl log.pl'

Amavis-virusflags report, query engine

The other important component which is the developed in the VIRUSFLAGS project, gives a solution to the problem in connection with the arriving of a virus infected mail from a falsified sender. In this case there is no point in sending a virus alert to the falsified sender, because this is just misleading. But if the virus (for example a Word macro virus) did not falsify the sender, our machine deletes the letter, but the sender is not notified, then legal problems may occur: if our business neither accepted the resignation of a contradiction, because it is infected with a macro virus, nor notified anyone, would cause a legal problem. The virus scanners may know this information, but taking into consideration the system and component theory, a system component can be more efficient which deals with only this question whether a virus falsifies the sender or not. As an add-in of the VIRUSFLAGS current software components, it make it possible to do statistical data collection about the spread of different viruses, which has the same importance level, if it was not more important.

How to install?

  1. Set up amavis as you always do...
  2. ...except changing amavisd and amavis.conf by the one you have downloaded from here.
  3. Set up the configuration file to use valid name and password!
    This means that you have to register your modul on the DHA-admin page to get valid authentication name and password!
  4. Restart amavis by typing '/etc/init.d/amavisd restart'


The component which serves the queries incoming from the other components, and which stores the statistic data is called the virusflags-server.
The model in case of the DHA protection is the following: our proposed solution is based on filtering but with a centralized approach. Parties of the protection are the following: the attacking computer, the attacked server host and the centralized DHA RBL (Real-time blacklist) server.
If an attacker sends an email to an unknown address on the attacked server, the attacked server will send an error report to the central DHA RBL server. The error report contains the offending IP address, the recipient address tried, and the time of the attack. The centralized server collects the reports from the protected servers. If the number of trials exceeds a limit, the server inserts the address of the attacker in the blacklist. The server also stores the time when the last e-mail observed from the given attacker with unknown recipient. As usual, the RBL list can be queried by sending an address as a request to the server questioning if an address exists in the list. The server does not publish addresses on the list, instead it simply answers with yes or no. (Fig. \ref{query}) In case of the viruses, the model and it's working mechanism is nearly the same apart from the naturally significant differences in the database. Our prototype system uses the DNS protocol for transferring queries and reports to the server and also to transfer the answer from the RBL server. The DNS protocol is widely used in RBL environment as it is very robust and the inherited caching mechanism of the DNS servers can help lowering the workload of the server.

How to install?

Fortunately you don't have to bother about this! We have done it and so just you have to use the client side components.

The complete built up of the system:


This site is © Copyright Geza Szabo 2004-2005, All Rights Reserved.