Showing posts with label networks. Show all posts
Showing posts with label networks. Show all posts

07 May 2020

Linux Firewalls by Michael Rash

Linux Firewalls: Attack Detection and Response with iptables, psad, and fwsnort is a quite interesting book about iptables features to be configured as an UTM device through its integration with Snort specific iptables plugins for log correlation, traffic access control.
This book has many real examples and detailed configurations. I could not test those configurations in a lab so I cannot see them running, but expect this tool and its way to be configured evolve with time.

In my humble opinion, tools detailed in this book are useful for home usage and SOHO environments only able to afford free open source tools. For more exigent corporate environments, I feel this solutions loosely integrated, with a difficult maintenance if your network is big and heterogeneous  and besides nowadays there are many commercial tools with a reduced price for almost every firm.

I felt more interesting explanations given by author for many networks attacks. Those explanations are very detailed but easily understandable. Nevertheless, most part of those attacks are known at the public domain for long time, so hardened security engineers won't learn anything new here.

Summarizing: This book is correct but only really useful for those who are making their first steps in security engineering world.  

23 February 2014

Violent Python

Python is widely used in many fields including maths, physics, engineering, scripting, web programming and, of course, security. Its power to be a glue between many tools and programming languages make it the perfect option for pentesting.

"Violent Python" scratches the surface of python in the world security tools programming world. It's a correct book, actually a correct cookbook. Correct because although the example programs are short and simple they show python in action in many security fields: geolocation, obfuscation, exploit development, network analysis and forgery, web scrapping and a long etcetera.

Problem is that the book is just correct because example program are not very pythonic. Although code is simple and clear, python offers smarter ways to do that things. Besides example programs are unambitious and don't go further of mere curiosities. In my opinion, examples could have been more spectacular and many more fields in security could have been covered.

I don't regret having bought "Violent Python", but maybe I'm a bit dissapointed because book is geared to people in a more initial point than me in the learning journey into security engineering. For that people this book is a fun and a direct approach to security tools development.

20 October 2013

Creating virtual laboratories with Netkit (II)

In my previous article about Netkit, we saw a simple example of its ability to simulate a network with multiple devices. The possibilities are almost endless, but we do need some kind of automation if we want to simulate complex topologies, with many nodes and especially if we pass these topologies to other researchers to experiment with them. Netkit provides this level of automation by laboratories, directory structures containing files to configure each of the nodes automatically. The good thing is that we can compress this directory tree and pass it to other researchers who can boot the lab and have all nodes configured and running with just a single command. In addition, this compressed file is really little since the configuration files on each node are text only.

We are going to prepare an example of a laboratory to simulate a scenario in which Alice is connected to the Internet from the switched network in your organization. What she doesn't know is that an intruder has gained access to the network and intends to launch a arp-spoofing attack against Alice to find out which internet pages she visits.

First of all we set Netkit to work properly in our operating system in  laboratory mode. First step is setting global variables used by Netkit. In the previous article we configured those variables correctly, problem is that when you start a laboratory in which one of the computers is to be connected to the Internet you have to use sudo which, for security, ignores most of the global variables, including those that we configured and used as normal users. A workaround is to configure sudo to not ignore Netkit variables by editing /etc/sudoers. In the "Default" of this file we must write:

Defaults:dante env_keep+="NETKIT_HOME", env_keep+="MANPATH"

Of course, instead of dante your own username must be used. You should set PATH and common sense says that you should be able to configure the sudoers as the other two ... the problem is that  sudo does not work that way and continues to ignore the user's PATH although we we configure in sudoers that way. It is something that is already reported in the Ubuntu launchpad as a bug long dragged. The solution is to create an alias that includes the user PATH every time we use sudo. To do this edit the file .bash_aliases in our home directory and write:


alias sudo="sudo env PATH=$PATH"

With that Netkit has all the necessary variables, whether we use sudo as if we run it as a normal user.

Besides, version 2.6 has a bug that prevents the virtual machine that acts as a gateway to Internet to run properly, the solution is a patch that one of the authors of the application wrote on the mailing list:

diff -Naur netkit-old/bin/script_utils netkit-new/bin/script_utils
--- netkit-old/bin/script_utils 2007-12-19 10:55:58.000000000 +0100
+++ netkit-new/bin/script_utils 2008-02-02 12:48:46.000000000 +0100
@@ -317,8 +317,8 @@
# This function starts all the hubs inside a given list
runHubs() {
- HUB_NAME="$1"
while [ $# -gt 0 ]; do
+ HUB_NAME="$1"
BASE_HUB_NAME="`varReplace HUB_NAME \".*_\" \"\"`"
"$BASE_HUB_NAME" ]; then
# This is an Internet connected hub
@@ -328,7 +328,7 @@
# This is a normal hub
- startHub "$1"
+ startHub "$HUB_NAME"
One way to apply this patch is to create a text file in $ NETKIT_HOME /bin/ called patch2_6_bug patch with the patch text and immediately do: 
dante@Hades:/usr/share/netkit/bin$ sudo patch script_utils patch2_6_bug patching file script_utils dante@Hades:/usr/share/netkit/bin$

This ends the worst part: Netkit preconfiguration . The good thing is that you just have to do it only once, from now on you will only have to worry about creating good laboratories .

To begin with ours, we have to create a folder to contain the directory tree and the configuration files. In that folder you create the main configuration file of the laboratory: lab.conf. We can store in that file all those parameters we would use with vstart to define a single machine . We can define how many interfaces have every node and to which collision domain would belong each one ( we must remember that, unlike hubs , switches define a different collision domain for each of its ports ). Another element that can be defined is the RAM used by every machine. You can also include information to identify the laboratory for its author, a , version, etc.. In our example, lab.conf file is as follows:

dante@Hades:~/netkit_labs/lab_sniffing_sw$ cat lab.conf LAB_DESCRIPTION="Laboratorio para simular un ataque de ARP-Spoofing" LAB_VERSION="0.1" LAB_AUTHOR="Dante" LAB_EMAIL="" LAB_WEB="" PC-Alice[mem]=100 PC-Sniffer[mem]=100 Router[mem]=100 Switch[mem]=100 PC-Alice[0]=CD-A Switch[1]=CD-A PC-Sniffer[0]=CD-C Switch[2]=CD-C Router[1]=CD-B Switch[0]=CD-B Router[0]=tap,

The last line sets the eth0 interface of the router as tap. That is equivalent to establish a point to point line between the virtual machine Router ( and our real PC ( through which your router can go to the Internet using your PC as a gateway. In fact, when we start the lab if we do a ifconfig on your PC you will see that it has created an interface called nk_tap_root with IP As the default route is concerned, Netkit puts a static route on Router pointing to This allows Router go to Internet normally but if we also want to let the rest of the virtual network PCs go to Internet (using Router and real PC as gateways) we add a path in our real PC to the virtual network:

dante@Hades:~$ sudo route add -net netmask gw

Now, inside the lab folder of the lab we are going to create a subdirectory for each virtual machine to be used.
dante@Hades:~/netkit_labs$ mkdir lab_sniffing_sw dante@Hades:~/netkit_labs$ cd lab_sniffing_sw/ dante@Hades:~/netkit_labs/lab_sniffing_sw$ mkdir Routerdante@Hades:~/netkit_labs/lab_sniffing_sw$ mkdir Switch dante@Hades:~/netkit_labs/lab_sniffing_sw$ mkdir PC-Alice dante@Hades:~/netkit_labs/lab_sniffing_sw$ mkdir PC-Snifferdante@Hades:~/netkit_labs/lab_sniffing_sw$ ls PC-Alice PC-Sniffer Router dante@Hades:~/netkit_labs/lab_sniffing_sw$

The subdirectories of the virtual machines can stay empty or be used to deposit files to make then appear in the virtual machine. For example if we wanted to Alice PC-X to have the script in /usr/bin, we would create the folder "/netkit_labs/lab_sniffing_sw/PC-Alice/usr/bin" and we wold leave there a copy of the script. In our case what we qould put in the /etc/ from each team the necessary files for configuration of network resources properly.

For the case of Alice, be as follows:
dante@Hades:~/netkit_labs/lab_sniffing_sw$ cat ./PC-Alice/etc/network/interfaces auto lo eth0 iface lo inet loopback address netmask iface eth0 inet static address netmask gateway

The PC-Sniffer will have the following network configuration:
dante@Hades:~/netkit_labs/lab_sniffing_sw $ cat ./PC-Sniffer/etc/network/interfaces auto lo eth0 iface lo inet loopback address netmask iface eth0 inet static address netmask gateway
The router will have the following network configuration:
dante@Hades:~/netkit_labs/lab_sniffing_sw $cat ./Router/etc/network/interfaces auto lo eth1 iface lo inet loopback address netmask iface eth1 inet static address netmask

Also, if we want our virtual machines perform DNS resolutions (essential if we install packages with apt or browse using lynx), we have to include a file /etc/resolv.conf on each of the virtual machines like hicimo s with /etc/network/interfaces. A copy of the contents of the file /etc/resolv.conf of our real PC will be enough.

The final step is to configure the switch and decide which services are to be started on each virtual machine. For that, Netkit lets define which commands are run during startup and shutdown of virtual machines using the startup and shutdown scripts respectively. For our lab we will create the following scripts:
dante@Hades:~/netkit_labs/lab_sniffing_sw$ cat Switch.startup ifconfig eth0 up ifconfig eth1 up ifconfig eth2 up brctl addbr br0 brctl addif br0 eth0 brctl addif br0 eth1 brctl addif br0 eth2 brctl stp br0 on ifconfig br0 up

This script configures a bridge after Switch machine boot by incorporating the bridge ports eth0, eth1 and eth2 and also activating the spanning-tree (unnecessary in this case because there is only one switch but it is a habit we should have) .

Startup commands of the rest of the machines are easier because all they do is start the network service:
dante@Hades:~/netkit_labs/lab_sniffing_sw$ cat Router.startup /etc/init.d/networking start dante@Hades:~/netkit_labs/lab_sniffing_sw$ cat PC-Alice.startup /etc/init.d/networking start dante@Hades:~/netkit_labs/lab_sniffing_sw $ cat PC-Sniffer.startup /etc/init.d/networking start

This example is very simple, but thanks to these scripts we can do that a laboratory configures itself without the end user having to do anything. In fact, the best is to configure the IP addresses of the interfaces and routes through these scripts instead of copying the configuration files in the /etc of each machine, but taking that detour gave me the opportunity to explain how to input files in the directory tree of virtual machines.

Now, finally, it's time to start our laboratory. The laboratories are started with the order lstart and stopped with lhalt. Let's see what happens in our case:
dante@Hades:~/netkit_labs/lab_sniffing_sw$ sudo lstart [sudo] password for dante: 033[1m======================== Starting lab ===========================033[0m Lab directory: /home/dante/netkit_labs/lab_sn iffing_sw Version: 0.1 Author: Dante Email: Web: Description: Laboratorio para simular un ataque de ARP-Spoofing 033[1m=================================================================033[0m 033[1mStarting "PC-Alice" with options "-q --mem=100 --eth0 CD-A --hostlab=/home/dante/netkit_labs/lab_sniffing_sw --hostwd=/ho me/dante/netkit_labs/lab_sniffing_sw"... 033[0m 033[1mStarting "PC-Sniffer" with options "-q --mem=100 --eth0 CD-C --hostlab=/home/dante/netkit_labs/lab_sniffing_sw --hostwd=/hom e/dante/netkit_labs/lab_sniffing_sw"... 033[0m 033[1mStarting "Router" with options "-q --mem=100 --eth1 CD-B --eth0 tap,, --hostlab=/home/dante/netkit_labs/lab_sniffing_sw --hostwd=/home/dante/netkit_labs/lab_sniffing_sw"... 033[0m 033[1mStarting "Switch" with options "-q --mem=100 --eth1 CD-A --eth2 CD-C --eth0 CD-B --hostlab=/home/dante/netkit_labs/lab_sniffing_sw --hostwd=/home/dante/netkit_labs/lab_sniffing_sw"... 033[0m 033[1mThe lab has been started.033[0m 033[1m===================== ============================================033[0m dante@Hades:~/netkit_labs/lab_sniffing_sw$

To check that the resulting network works we can try surfing the Internet with lynx from PC-Alice:

Now that we have checked that our network works we can give our laboratory an use performing the experiment mentioned at the beginning of the article: An ARP -Spoofing attack against Alice from PC - Sniffer .

As you can see in the photo above, PC - Sniffer has activated a tcpdump , but only see the traffic spanning tree (STP) issued by the switch. Unlike previous article network in which I simulated a hub, this switch does not replicate traffic on all ports but only on the port that connects the destination of the data.

To spy traffic between Router and PC- Alice we will have to place ourselves between them making them believe they talk each other when actually they do with PC- Sniffer .

We will use Ettercap tool, which is installed by default in Debian that brings Netkit (if not, you could install it with a simple " #aptitude install ettercap" , as we would in our real PC) . Ettercap allows interception on switched networks . It really is a little wonder that deserves an article to itself . Here we will use Ettercap from PC-sniffer to spy Alice web traffic . To activate an ARP -Spoofing attack (also called ARP- Poisoning) with Ettercap the order would be:

PC-Sniffer# ettercap -M arp:remote -T / /

Immediately PC-Sniffer screen start draining the contents of the data exchanged between PC-Alice and her gateway, Router, while browsing the Internet:

To stop the lab you just have to do "sudo lhalt " from the root directory of the lab (where we formerly launched  lstart ) . If we wanted to relaunch the laboratory we must take into account the need to put back the path to the virtual network which disappeared when lhalt disabled the tap interface. On the other hand, lstart created .disk files in the lab folder to not to lose the programs you have installed on virtual machines or any other changes we have made. That means that the folders where we placed configuration files are no longer read so if you want to put new files there first you have to delete the .disk files and do a Netkit lstart to re-read those folders. There is another useful option to transfer files to and from virtual machines using the /hosthome folder that there is in all virtual machines which mounts the user's home that launched the Netkit .

In another article I will explain how Ettercap works and other interception techniques . This article  served to demonstrate the utility of Netkit to simulate the complex networks that make computer security experiments possible with a considerable saving in both effort and money and space. It is also an invaluable aid for those who intend to teach the art of computer security, allowing us to offer our readers preconfigured laboratories to let student focus exclusively on the techniques explained without having to waste time setting up a test network on their own. Thats why, my further articles will include links to Netkit laboratories especially designed to train in a way fast and simple what is explained in them.

12 October 2013

Creating virtual laboratories with Netkit (I)

Progress in the field of security engineering requires constant learning in multiple disciplines . This learning is largely theoretical but to be fully effective need to be implemented. A security engineer should be able to put himself in an attacker boots and foresee with reasonable certainty what could be his next step . But this is difficult because an engineer can not go around attacking networks with the excuse that he is learning how bad guys work .

Until recently, the only option available for students of security was to set up a laboratory at home collecting low-cost computers and network equipment . Unfortunately this was expensive , consuming an increasingly scarce space in modern homes and placed your partner / spouse / father / mother against you because they didn´t understand the utility of that. Fortunately , the era of virtualization came to the rescue so today is possible to assemble complex virtual laboratories within our computer.

The easiest option are VMWare or VirtualBox, which are ideal for testing tools, rootkit, vulnerability, etc. on different operating systems without endangering our own computer. Starting several of these virtual machines can test simulating a LAN network. Even there are tutorials to simulate more complex topologies using VMWare. However, at that point carry such tools may require consume an amount of computer resources that may not count on.

The other option is called Netkit , developed at the University of Rome. The focus is not so much the specific equipment emulation but complete networks . Netkit allows us to define a network topology and test with it. To do that we would begin a series of nodes that are only light Debian Linux virtual instances and we would configure them as the role they play within the network we want to simulate ( router , switch or end device ) .

Installation is very simple . First, download three files :

Once downloaded must be unzipped all together in the directory of your choice ( we assume that /usr/share/netkit ) ( see update at end of article ) and then prepare a few environment variables to record where we installed the Netkit . To do this, it is best to add at the end of /etc /profile the following lines :
Once this is done you have to restart the computer to run the environment variables you just configured. And that it is, to check if anything fails test run a script that includes netkit:
dante@Hades:/usr/share/netkit$ ./ > Checking path correctness... passed. > Checking environment... passed. > Checking for availability of man pages... passed. > Checking for proper directories in the PATH... passed. > Checking for availability of auxiliary tools: awk : ok basename : ok date : ok dirname : ok find : ok getopt : ok grep : ok head : ok id : ok kill : ok ls : ok lsof : ok ps : ok readlink : ok wc : ok port-helper : ok tunctl : ok uml_mconsole : ok uml_switch : ok passed. > Checking for availability of terminal emulator applications: xterm : found konsole : found gnome-terminal : not found passed. [ READY ] Congratulations! Your Netkit setup is now complete! Enjoy Netkit!

At this point begins the really interesting.

Let's start two virtual machines connected to the same collision domain (it is like they were connected to the same hub) and we will do ping between them:
dante@Hades:~/netkit_labs$ vstart --eth0=CD-A -M 100 PC-1 dante@Hades:~/netkit_labs$ vstart --eth0=CD-A -M 100 PC-2 dante@Hades:~/netkit_labs$ ls -l total 1136 -rw-r--r-- 1 dante dante 1074012160 2008-09-11 23:26 PC-1.disk -rw-r--r-- 1 dante dante 470 2008-09-11 23:25 PC-1.log -rw-r--r-- 1 dante dante 1074012160 2008-09-11 23:26 PC-2.disk -rw-r--r-- 1 dante dante 470 2008-09-11 23:26 PC-2.log

With the --eth0 parameter that interface is assigned to CD-A collision domain (we call them as we wish), and with the --M one  we are gping to give 100 MB of RAM to the machine. You can see that Netkit creates a .disk file for each virtual machine created, that disk is where you keep your file system. Each file system uses default 1'1GB so you better make sure you have free disk space before starting an experiment with many machines.

By doing vstart each xterm window appears with the virtual machine console that has been launched.

Here is where we are going to configure every machine:
PC-1:~# ifconfig eth0 netmask up PC-2:~# ifconfig eth0 netmask up

If now we ping between the two machines you  can see their reply .

Now let's do a simple experiment, so they do not say that this article has not been addressed security. Let's go back to over 10 years ago , when networks were based largely on hubs , ie when all the PCs on the network are connected to the same collision domain. In those days it was very easy to eavesdrop ( sniffing ) as hubs replicate everything they received from one port to other ports so if someone put the interface in promiscuous mode could prevent his network card to drop off packets not addressed to it and display them in a program like tcpdump. To simulate what an attacker would have done in those days we are going to create your PC in the same way as above but calling PC-3 and assigning the IP address . This would be like connecting the PC the hub of spied victims. Now you start a tcpdump in PC -3 and see if we can capture the ping we are launching from PC-2 to PC-1:

As you can see from the picture we gave time to PC-2 to send two ping PC-1 and this has answered correctly. And what PC-3 has seen?, answer is all: the arp of PC-2, the response of PC-1, the ICMP-request of PC-2 (round pings) and ICMP-reply of PC-1 (pings back). In fact PC-3 has heard the whole "conversation" between PC-2 and PC-1. If this had not been a mere ping but a telnet session, PC-3 might have heard of the username and password of the person you passed from PC-2 to PC-1. Hence the importance of encrypting SSH terminal sessions.

To shut down the virtual machines, you can make a halt from within each of them or with vhalt from our actual command line:
dante@Hades:~/netkit_labs$ vhalt PC-1 Halting virtual machine "PC-1" (PID 29271) owned by dante [.... ] dante@Hades:~/netkit_labs$ vhalt PC-2 Halting virtual machine "PC-2" (PID 30824) owned by dante [.... ] dante@Hades:~/netkit_labs$ vhalt PC-3 Halting virtual machine "PC-3" (PID 28568) owned by dante [.... ] dante@Hades:~/netkit_labs$

If you would like to restart the machines then we should only use the command vstart (provided you have not deleted the .disk file) . For example, to boot PC-1 we would do: vstart PC-1

Well, not bad for a start, we have assembled an experiment with three PCs and a hub without having any of the four things ... Could not ask for more , does it? . In my next (or next ones ) article I'm going to delve into Netkit possibilities to develop more complex and interesting experiments .

Update 2010-01-01 : In his new version, Netkit has changed the file system ( Debian image that is loaded with each of the virtual machines ) to a 10 GB filesystem. Fortunately , if we use partitions with serious filesystems ( ext , ReiserFS , XFS , JFS and NTFS ) not to worry because it will treated as a sparse file and will not take even a fraction of that size. The only thing you should do is extract all files downloaded from the web of Netkit in /user/share/netkit using the command: sudo tar - xjSf being the S precisely to treat stracted files as sparse ones.

06 April 2012


man-in-the-middle attack occurs when a third is located between two principals, whether individuals or some type of equipment, and deceives them into believing that each of them he is the other principal. It acts as an interface for modifying the flow of information exchanged. The only solution to this type of attack is the encryption of communications using a protocol that involves a key exchange through a secure channel, so that even if an attacker could intervene communication would be unable to understand or to modify it without being detected by integrity checks. 

So much for theory. The practice supports several variations, which have been made throughout history. One of the most spectacular I have found during the reading of Security Engineering , of Ross Anderson. To illustrate the dissertation on man-in-the-middle attacks, the author tells the disaster suffered by the South African troops because of an attack variant that the time has come calling MIG-in-the-middle. 

Article's author note: As Zooko commented, Ross Anderson admitted in the second edition of his book that he recently discovered this history is unfounded. However it could have happened (change the actors) in other wars in other places, so I think it's still interesting.

In the late 80, South Africa was involved in a war in northern Namibia and southern Angola. His goal was to keep the white government of Namibia and to the puppet government of UNITA in Angola. As the South African army was composed exclusively of white recruits and these did not represent a very large population segment, it was essential to maintain a casualtie rate as low as possible.So the South African army preferred to concentrate on maintaining order in Namibia and support with its air force to the UNITA troops in Angola. To prevent the Angolan rebel troops and their Cuban allies to counter strike against Namibia, South Africa deployed a powerful barrier of anti-aircraft batteries. To prevent the so-called "friendly fire," South African aircraft were equipped with IFF (Identify-friend-or-foe), common today, which responded according to a predetermined algorithm to the signals from anti-aircraft batteries so that these identify themselves as friends to the South African aircraft.

The defensive system seemed unbeatable, and yet one day a squad of Cuban MiGs crossed the line of defense and bombed one of the main camps of Namibia. South African anti-aircraft batteries didn't shoot a single missile. Casualties were terrible and led the South African government to decide to withdraw troops from Namibia, which eventually led to the fall the white government of that country. 

Time passed until the discovery (and confession) of the causes of that monumental failure in the South African defense. It appears that the Angolan intelligence learned that the South Africans, perhaps due to overconfidence, left switched on their IFF devices while conducting missions over Angolan territory. What they did was to situate a MIG waiting near the border of Namibia to a South African squadron (SAAF in the figure) headed to bomb Angola.When South Africans were present on Angola to carry out their respective missions, the MIGs entered the territory of Namibia. Of course, the South African air defenses detected the MIGs and launched the IFF signals to determine whether they were friend or foe aircrafts. The MIGs lacked the necessary keys to correctly answer the IFF signals, so their plan was to forward the signals to their radio stations in Angola and make them send that signals to the South African squadron which was flying over that country at that time. The plan worked because South African airplanes had turned on their IFF and when Angolan radio stations broadcast the signals sent by the MIGs, the South Africans began to reply to them automatically without knowing that these responses were being forwarded to the MIG squadron so that they can serve it to  the South African batteries in Namibia. Thus, South African air defenses in Namibia thought that those MIGs were friendly aircrafts, letting them pass. 

That attack forced them to rethink deeply technology, protocols and operating procedures used for the IFF. To begin with, at the operational level South African prohibited pilots to let their IFFs on when they flew over enemy territory. At the protocol level the solution was much harder to find and certainly was not definitive, as they began include the aircraft identification in the response returned by the IFF so that they could correlate the data offered by control towers to find differences. Another method tried was to measure the delays of the responses so that if any came "later" than usual they could suspect that the IFF was generated by a plane that was farther away than the plane detected. Keep in mind that at this particular attack the encryption of communications is not useful as MiGs did not need to break the confidenciality or integrity of IFF signals, since they needed only to "reflect them" for their radio stations . All these answers are far from perfect and much less viable in battle areas crowded with air traffic of the two sides, which is why IFF techniques is a field in constant development to avoid disasters like that caused by the attack MIG- in-the-middle.

18 October 2011

Silence on the wire

The problem with many security books is that they simply list a series of attacks against vulnerabilities in systems services. What happens to these books is that they lose validity as patches appear for vulnerabilities  explained, so that when book reach printers actually is outdated. 

But there are others who choose to be more conceptual and describe the risks caused by the designs rather than implementations. These books are much more didactic and useful to delve into the nature of the protocols and systems. Besides, its effect is much longer because the problems of an standard remains until the advent of the following standard (think for example in system security issues WEP). Silence on the wire belongs to this second set of books.

In it, author Michal Zalewski made a study of passive recognition techniques and indirect attacks on a fairly eclectic way, covering topics ranging from the deduction of passwords based on the timing of keystrokes, the parasitic use of processing power of entire networks of computers without permission from their owners, and other interesting topics like the use of the same network infrastructure as a means of hidden and anonymous mass storage, among others. Some of the chapters are strongly speculative and at first glance may seem hardly feasible but the truth is that they are all vectors of attack rarely  noticed and they serve as demonstration that until the last bit in the system design can be used by an attacker to compromise motivated enough. Other chapters in this book were before author's papers very well received in the Net for its innovative approach and the risk of alerting, as is the case of his study of implementations of pseudorandom number generators (PRGN) of most widely used operating systems, which used a mathematical transformation that allowed spatially represent the values ​​that were taking these generators and thus show that many of them drew statistically predictable values.

For all the above and more this is an excellent book should be indispensable in the library of any student of computer security warning that reading this book presupposes knowledge already acquired about networks and protocols such  that can be obtained through Kurose & Ross , Tanenbaum or Stallings .