We Are Under Attack!!!!!!!
IMPORTANT: NO COPYRIGHT WAS BROKEN IN DOING THIS TUTORIAL PROVIDED, WRITTEN AND POSTED BY ME FOR ANTIONLINERS ONLY.
Started Writing 13/05/2003 ended writing 15/05/2003
Let's see how to make the life a hell to whom tries to invade our "computer garden".
This Post describes the three phases in which a following intervention can be divided to a computer attack.
This is the first question to which is necessary to answer when an attack is suffered:
" What is Happening? ".
In fact, not always from the symptoms of malfunction it is possible to immediately individualize the formality and the target of the attack, above all if we find us in a net of averages or great dimensions.
The first thing to be done is to effect a trap and trace to individualize what stings of our system it is under attack.
The trap and trace consists in the analysis of the traffic of passing net for a single host or for a whole segment of net if this last is endowed with hub broadcast, that is hub that transmits the same packets to all the connected hosts; they will be then the recipients to effect a selection on the packets.
The Tools that can be used are tcpdump for Linux or WinDump (the correspondent of tcpdump for Windows), that are to command line.
If you prefer to use a program with graphic interface, you can always use netmon for Windows. The use of these Tools for the intrusion detection it is surely few practical but necessary when the automatic IDS are not effective, or because the IDS comes completely bypassed. Some techniques of planning of virus and trojan are in fashion in this period, the purpose of this techniques is the disattivation or inhibition of the antivirus and IDS's services .
TO USE AND TO UNDERSTAND TCPDUMP
For our example we will use tcpdump. once installed on Linux with the usual procedure (. / configure,make, make install), tcpdump can simply be on its way from a shell of root.
If it is used without options, the application visualizes on the shell's window the whole traffic that crosses the card of net. This can be useful in the first phase.
To do so that the output is more easily consultable text file, all it takes is starting tcpdump in this way:
. / tcpdump > textfile
The output of the tcpdump not are anything else other than the first N byte (default 68) of every packet dates.
Approximately this corresponds to something more than the headings of the packets that it varies from the 28 byte for those UDP to the 40 byte for the TCP.
16:38:23.355032 dec0der.declab.com.1308 > 216.239.57.99.http: p 1:502 (501) ack 1 win 5840 (DF)
The first field (16:38:23.355032), that is the TIMESTAMP, it points out the exact instant in which the packet has been built; we immediately find later the source's addresses (dec0der.declab.com.) and destination one (216.239.57.99.) with the relative used doors (1308 ) (you notice the symbol " > " that it points out the direction of the connection).
After we have the flags TCP that gives us information on the type of packet (all the flags with the relative meanings you are able in a suitable site among the links). you can see besides the field that tells us of how many packets it is constituted the communication and the ID of the present packet. Finally, the index of fragmentation tells if the packet is entire. This can be useful to individualize certain types of attacks said note to fragmentation of packet generally used for overcoming the firewalls. After this, with the purpose to effect an effective analysis without losing yourselves in the infinity of the data it is opportune I handed the following questions:
The fields of the headings Ips are suspicious? Or rather do address IP of origin it is suspicious (we will see then as to verify its origin)? There are anomalous fragmentations of the packets? Is The dimension of the packet excessive?
Are the fields of the headings suspicious TCP? doesn't the door of destination correspond to an active service on your system?
Is the traffic conforming to the norms of that particular protocol?
If we for example see a series of packets with flag consecutive SYN related to the same communication it is probable that we are us of forehead to a SYN flooding since the normal Handshake is not respected.
THE LOG OF THE ATTACKED SERVICES
If in this way succeeded in individualizing the attacked service, then you can pass to the following phase and that is to the analysis of the Log of the single service, not without however first to be to you annotated the Ip or the Ips you suspect. If we are for example using a server Windows 2000, and we know that the attack has struck IIS, we can find its log in the directory winnt/system32/logifes. Here through a simple search on the text of the Ips previously found, we can reconstruct all the operations developed by the attackers, to discover what vulnerability has been used and we can easily cover the hole applying the appropriated Patch.
We suppose to have some logs as these:
20003-04-17 15:25:58
192.168.0.10 - 192.168.0.280 GET
/ scripts /.. /.. winnt/system32/cmd.exe / c+dir+c :\ 200 - 2003-04-17 15:25:58
192.168.0.10 - 192.168.0.280 GET
/ _vti_bin /.. /.. /.. /.. /.. /.. / winnt/system32/cmd.exe
/ c+dir+c :\ 200 -
These are two attempts succeeded to access the visualization on browser of the directory c :\ of the server through the vulnerability Unicode of IIS (you notice the restitution of the code 200 "OK" from the server instead of the 404 " NOT FOUND ").
TO GO UP AGAIN AT THE ORIGIN
Once individualized the ip of origin of an attack it finds again himself in front of two possibilities:
if the attack it is type DOS (how SYN flooding, the attacks to fragmentation of packet) and therefore not it always asks for the completion of the handshake of connection, it is very probable that the ip is fake.
If you have suffered an attack of other type instead, as for example the attacks to the single services (Web, FTP, E-mail, Etc.) then you have an ip from which the attack has departed or is passed and that it is existing.
In the first case unfortunately to go up again to the origin is very difficult if not impossible even if the entity of the damage provoked in reality is a lot of redoubt.
In the second case you can be started effecting a traceroute to individualize the geographical area to which the ip belongs. For the traceroute you can use the command traceroute (for Linux) or tracert (for Windows) followed by the ip that you have found in the file of log. The crossed hosts generally have in their DNS an indicative of the place in which they are found.
To make the most comfortable tracing however is possible to use visual tool that points out on a map the position of the various hosts, as for example VISUALROUTE (www.visualware.com). Once individualized the geographical area of origin of the ip, then you can effect an interrogation whois to the RIR (Regional Internet Registry) in base to the geographical area to which your target belongs: the RIPE (Réseaux Ip Européens) for Europe, part of Africa and of Middle East; the ARIN (American Registry Internet of Numbers) for the North America and South America, the Caribbean and Africa sub-Saharianan; finally the APNIC (Asia Pacific Network Information Center) for the rest of Asia and the Pacific. If you use systems Microsoft you can directly consult the sites of these three corporate body or to use some utilities as SAM Spade. For the consumers Linux is enough the utility whois of which the operating system is gifted.
At this point you have to pick up the material of your investigation (log and various amenity) and to send it to the address [email protected]. They will be them to verify if the attack was born from their net or it has crossed only her. I add that in general, almost for convention, the mails of reference in cases of this type are always abuse@domainprovider. Generally, if the attack has not been intrusive, to actions of this type it follows a simple warning from the provider to the consumer. To this however it can follow the suspension of the service in the case in which the guilty one is recidivous or the report to the magistracy if the attack has brought a damage.
LInkS:
Tcpdump
http://www.tcpdump.org
An article in which are indicated the TCP Flag
http://linux.oreillynet.com/pub/a/li...tools_two.html
Windump
Http://netgroup-serv.polito.it/windump
ARIN
http://www.arin.net
RIPE
http://www.ripe.net
APNIC
http://www.apnic.net
Sam Spade
http://www.samspade.org
VisualRoute
http://www.visualware.com
sorry for my english
