• Open a previously saved network. • Save the network.
• Save the network under a new name.
Loading and saving can also be performed through the menu labelled “VeriNeC” or with the typical keyboard shortcuts ctrl-n(ew), ctrl-o(pen), ctrl-s(ave), ctrl-shift-S(ave as). The “Prefer- ences” menu contains one entry named “Options”, which brings up a dialog to configure various aspects. Each aspect is grouped in a tab. After the Modules tab, the configuration panel for each module is added. As mentioned in Section 8.1.1, a module can provide a configuration panel, but does not need to. The Configurator module is the only one providing a configuration dialog.
Network Types allows to customise colours of wires and icons for interfaces and bind- ings.
View allows to change the defaults for zoom level, name display and snap to grid. The background colour of the draw area can also be modified.
Modules is used to manage the available modules. To add new modules, the button “Find all Modules in classpath” launches a process looking through all classes for those implementing the IVerinecModule inter- face. All new modules are added to the application.
The Distributor allows to specify a di- rectory in case translated configuration should be stored on the local machine in- stead of being automatically distributed. The “Help” menu finally contains only an “About” entry to bring up a window telling what Verinec is and who developped it.
9.2
Import
Figure 9.2: Progress dialog. The importer module was first put to examination. To import a
network, the “Importer” module has to be selected. The menu bar now shows an entry labelled Importer, containing the entries “Start Network Analysis” and “Read configuration files”. Choosing the network analysis allows to start traffic sniffing to detect the layout of an existing network.
Verinec was running on a laptop connected to the hub of the test network for five minutes. During that time, the computers where pinging each other, ssh connections opened and web pages retreived. The capturing worked fine and produced the network shown in Figure 9.3. If the hosts do not show up in the view, it
116 CHAPTER 9. CASE STUDY
9.4, but has been arranged by hand to improve readability. All hosts existing in the network have been detected. The machine running Verinec is shown too, to indicate from which point the network has been analysed. Because of the hub, most hosts are directly connected. 63-236-73-147 is the Internet server, reached through the router. Its name is the converted IP number, because reverse DNS was not configured for it. There is one notable problem and one mistake.
Figure 9.3: After traffic analysis.
Figure 9.4: Rearranged layout to improve readability.
The problem is that the gateway has been duplicated. Although the Cisco router was set up to use 172.16.1.254 for its internal interface, the Internet seems to be connected through a server with IP 10.10.10.1. The reason for the confusion is that the time exceeded message from the Cisco router still used the IP of 10.10.10.1 instead of the one the router was set to. Examining the traffic, it would be hard to determine that this is the same device. In this situation, looking at the MAC
9.2. IMPORT 117
address would solve the problem, but as soon as such a device is not the first in the line and thus connected to a different segment, the MAC address can no longer be used.
The error is that the broadcast address 172.16.255.255 had been mistaken for a normal address. Although in most cases, an address ending with 255 is a broadcast address, this cannot be taken for sure. It is up to the human operator to detect and remove the address. The situation also illustrates the output when no response on the traceroute is received. To correctly interpret the result, we need to remember that the maximum number of non-responding hosts is 4. As there are four unkown-host nodes, the trace was interrupted, and the final target added for information. It might well be closer to the host running verinec than the four nodes shown – or even further away. Would the target be an existing host in network 172.16, the most probable explanation is that either the host does not respond to the trace packets, or a firewall is silently dropping packets or responses. If there are only three or less unkown nodes, the meaning is quite different. The last host in the line is separated by exactly this number of nodes from the sniffing machine, as from that TTL on, it replies to the packets, altough intermediate stations do not report when they dropped a packet due to TTL dropping to 0.
Figure 9.5: The final network with the incorrect hosts deleted.
Cleaning up the problems and errors of the network in Figure 9.4, the user should get to a network as shown in Figure 9.5. The gateway has been reduced to one single node, the broadcast address is deleted and the Internet host is named “internet”. The verinec-root-host has been left to facilitate orientation, although it normally will not be part of the network.
Warning: All techniques used in the import module can collide with network usage regulations inside an institution. For port scanning, particular care is required. The author recommends to only test this feature in experimental networks or when explicitely granted permission from network responsibles. The initial scanning phase gathers traffic from the network. This does not generate traffic, but can still be forbidden by usage policy.
Figure 9.6: Start the port scan.
One more kind of information can be gathered: the services running on a host. A click with the right mouse button on a host pops up the context menu shown in Figure 9.6. After a last question to confirm whether the user really wants do a port scan, the Nmap application is launched. It is told to scan the host with the selected name and to output the scan results in XML. The scan is run in the background. Information is added to the node after it finished, and the user is informed of the successful port scan.
On the first try, scanning veri-serv took a very long time and produced no information at all. It turned out that iptables successfully blocked the scan attempt. After running the
118 CHAPTER 9. CASE STUDY
command /etc/init.d/iptables stop on the machine, the scan produced a more interesting result and took only a couple of seconds. The output file is parsed and integrated into the Verinec configuration. Currently, all services appear as generic-service elements. Listing 36 shows a snippet of a resulting configuration. The importer could be improved to use the correct service element instead of generic-service if there is one available in the Verinec configuration. The service ‘domain’ for example would be represented by the <dns> element.
Listing 36: A sample node ...
<generic-service protocol="tcp" portid="53"> <port-state state="open" />
<port-service name="domain" method="probed" conf="10" /> </generic-service>
...
The port scan of the machine veri-serv reveals that there are many services running. Table 9.1 lists the services. The administrator should close all services that are not really need. ‘vmware- auth’ for example remains from a vmware installation that was previously done, but later removed. It is currently not even used, but presents a security risk.
22 ssh 53 domain 80 http 111 rpcbind 443 ssl (https) 825 status 904 vmware-auth
Table 9.1: Open ports on the veri-serv machine.
9.2.1
Import configuration information
The structure of the network has been established in the previous section. Now it is time to parse the configuration of a machine. Clicking the second option labelled “Read configuration files” in the menu from Figure 9.6 pops up a dialog to import configuration. This dialog is shown in Figure 9.7. As has been mentioned in Section 8.8.2, import has only been implemented for a couple of services running on Linux. The dialog contains three areas. At the top, the user can choose whether to import configuration from the local machine, from a remote machine over the network or from configuration files. The third option is a last resort if connecting to the remote machine does not work and one has to copy the configuration to a portable media or send from the remote machine. The middle area lists all services and allows for each of them to select whether to import it or not. Importing the host name is useful as the DNS entries do not necessarily match the internal name of the host. For Ethernet, the location of the configuration files can be changed if needed. The iptables command can also be modified - but if the parameters change the output, the parser might no longer work correctly. The bottom part is used to specify the connection to the remote host. Host can either be a DNS name or an IP. In the test, no ssh key file has been used, so the keyfile and passphrase fields remain empty.
The configuration of veri-serv was imported to test the features. Importing the Ethernet interfaces produced two warnings but otherwise got all information correctly from the remote machine. Red Hat used two settings named userctl and ipv6init which are not known by the importer. User control tells whether a normal user has the right to bring the interface up or not. The prefix ipv6 indicates the setting is related to IP version 6, which is not supported by Verinec anyway. Distributing the configuration built exactly the same configuration files as the original import, except the two fields userctl and ipv6init are omitted. One minor problem is that existing
9.2. IMPORT 119
interfaces are never replaced. The new interfaces are added to the configuration even if an interface with the same name already existed. We did not want to risk overwriting existing configuration and prefer to leave merging to the user.
Iptables import worked almost perfect. As the firewall had been disabled for the Nmap port scan, /etc/init.d/iptables start had to be called before running the import. The only warn- ings are about the protocols ‘esp’ (Encapsulating Security Payload) and ‘ah’ (Authentication Header). Both protocols are related to the IPSec standard. The firewall would accept all packets belonging to those standards. In the Verinec packet-filter configuration, those protocols are not supported and thus cannot be imported. Contrary to the interfaces, the packet-filter is replaced if it is already defined on the node. The XML Schema allows only one packet-filter element.
Both for Ethernet and iptables, there is a report dialog to tell about problems on import, as shown in Figure 9.8. It also shows the original configuration to facilitate locating the source of import problems. The output can also be saved to a file for later use.
120 CHAPTER 9. CASE STUDY
Figure 9.8: Report of iptables import.