## Monday, May 20, 2013

### Fedora 18, WebEx, Java and sound...

I just tried to use WebEx in order to participate in a conference and I was unable to do so. There are a lot of different pages on the Internet that show you what to do. In the end, everything boils down to the fact that WebEx doesn't support 64-bit versions of Linux so all the solutions actually describe how to install 32 bit version of Firefox and Java. Some of those recipes uninstall 64-bit versions of Firefox/Java, some install them in addition to the existing ones. I think the second approach is better, and here is an example of the latter approach.  Note that there isn't problem with sound in Java thanks to the transparent support of ALSA applications by PulseAudio so there is no need to do something like this.

What I found by reading all the recipes is that they assume two things that might catch you:

1. Sun's Java is installed somewhere in the /opt directory. In case you used RPM archive, it will be in /usr/java.
2. People hardcode Java versions, e.g. 1.6.0_21. I don't know why they don't use /usr/java/latest or /usr/java/default because those are valid links on all installations.
In the end I gave up on trying to make WebEx work. Maybe I'll return to it some day and then I'll extend this post...

## Tuesday, March 26, 2013

### Periodically scan network with nmap...

I think that it is a good idea to periodically scan network using nmap in order to take a snapshot of a current state, and to be able to track changes in the network. For that purpose I wrote the following quick and dirty bash script:
#!/bin/bash

# Interface on which scan should be performed. Multiple interfaces
# should be separated with spaces!
SCAN_INTERFACES="eth1"

# Network that should be scanned. If empty, or undefined, automatically
# deduce network attached to interface. Note that if you specified
# multiple interfaces than this variable should be undefined!
SCAN_NETWORKS=

#######################################################################
# THERE ARE NO MORE CONFIGURABLE PARTS AFTER THIS LINE
#######################################################################

TIMESTAMP=date +%Y%m%d%H%M
START=date +%Y%m%d%H%m%S.%N

cd /var/log/nmap || exit 1

for if in \$SCAN_INTERFACES do # Find network to scan if it isn't specified... [ -z "\$SCAN_NETWORKS" -o "\$if" != "\$SCAN_INTERFACES" ] && SCAN_NETWORKS=/sbin/ip ro sh dev \$if | grep -v via | cut -f1 -d" " # Find addresses on the output interface so that we don't scan them EXCLUDE_LIST=/sbin/ip addr sh dev \$if | awk '/inet / {print "--exclude ", substr(\$2, 1, index(\$2, "/")-1)}'
[ -z "\$SCAN_NETWORKS" ] && continue # Start scanning nmap -n -Pn -sS -O -sV -T4 -vv \${EXCLUDE_LIST} -oA nmap-\$if-\${TIMESTAMP} -e \$if${SCAN_NETWORKS} >& nmap-scan-\$if-\${TIMESTAMP}.log
done

echo "START \$START END date +%Y%m%d%H%m%S.%N" >> /var/log/nmap-scan.log exit 0 Note that some lines are wrapped due to the shortage of space. This script assumes several things in order to run properly: 1. You have a directory /var/log/nmap where all the result files will be placed. 2. nmap is version 6, but definitely not 4 because version 4 has some weaknesses. 3. You want to scan networks assigned to your interfaces. 4. The script is run under root user. Now, after each run of this script you'll have four files left in /var/log/nmap each with the following extension: 1. nmap - this is a standard nmap output file 2. gnmap - greppable nmap output 3. xml - XML output file 4. log - Log file into which stdout and stderr were redirected during nmap's run. It is also necessary to configure script to be run periodically. cron is ideal for that purpose. To achieve that, you can add the following entry to root's crontab: 0 */2 * * * full_path_and_name_to_your_script Obviously, you'll have to change full_path_and_name_to_your_script with exact path and filename. In this case, you'll get the script to be run every two hours. ## Thursday, March 21, 2013 ### Detecting hosts that cross connect two networks... There are different scenarios in which you can have a situation where some of your clients are connected in the same time to two different networks of different trust levels. This is dangerous because effectively they can be used as a staging point for potential attackers or malware to "jump" from less trusted network to more trusted one. For example, suppose that you have protected internal wired LAN, and in the same time you have wireless LAN that is used for guests and allowed unrestricted access to the Internet, as shown in the figure below. Someone, from your internal and protected network, might intentionally or accidentally connect to the wireless network too, and in that case he/she will shortcut the two networks. If you thought that you can use MAC addresses to detect such hosts, you can not, for a simple reason that in one network host is connected using wired ethernet card with one MAC address, and in the second network it is connected using WLAN network card with another MAC address.  Hypothetical situation to illustrate how internal host might shortcut two networks of different trust levels So, how to detect those hosts that shortcut two networks? Actually, there is an easy and elegant way. Namely, you can send ARP requests on one network for IP addresses on another network. ARP module, by default, doesn't know or care for routing tables so that it knows on which interface it should respond with specific addresses. If we look again on the figure above, this means that you can run the following command from the proxy host (the host above firewall): arping -I eth1 10.0.0.250 I assume in that command that eth1 is the interface connected to AP. What will happen is that broadcast will be sent on the wireless network and the client will respond with its wireless MAC address even though that address is not used on the wireless network. So, I hope the idea is clear now. To detect if there is some host cross connecting two networks I send arp request on a host (i.e. proxy host) for each possible IP address used on the the other network (i.e. local protected network in the figure above). Note that it is possible to disable such behavior on Linux machines using sysctl variable /proc/sys/net/ipv4/conf/*/arp_filter. You can find more information, for example, here. nmap games Now, there is another problem. How to scan the whole network without manually trying each possible IP address. The first solution is, obviously, to use nmap. Nmap is a great tool for network scanning, but in this case it has a problem, I tried to run it in the following way, but unsuccessfuly: # nmap -PR -Pn -e eth1 10.0.0.0/24 Starting Nmap 5.51 ( http://nmap.org ) at 2013-03-21 10:07 CET nexthost: failed to determine route to 10.0.0.0 QUITTING! Option -PR requires ARP scan, -Pn disables ping scan, and -e eth1 tells nmap to send packets via interface eth1. The problem is that I'm trying to scan network 10.0.0.0/24 on interface eth1 and there is no route in routig tables that tells kernel/nmap that network is really connected on interface eth1. So, nmap refuses to scan those addresses. One solution is to temporarily add that route: ip route add 10.0.0.0/24 dev eth1 But this isn't an option if the route already exists in order for the hosts on the protected network to be able to access proxy, i.e. if there is route similar to the following one: # ip ro sh ... 10.0.0.0/24 via 172.16.1.1 dev eth0 ... Again, I'm making a lot of assumptions here (network between proxy and firewall, IP addresses and interfaces) but I hope you understand the point. The given route is in the routing tables and removing it isn't an option. Next try was using -sn switch, i.e. to disable port scan: # nmap -PR -Pn -sn -e eth1 10.0.0.0/24 Starting Nmap 5.51 ( http://nmap.org ) at 2013-03-21 10:07 CET Well, now nmap worked, sort of, because it showed all the hosts are up. Using tcpdump I found that it didn't send anything to the network. Reason: it thinks this is remote network, pings are disabled, arp cannot be used, and finally, because of -Pn, assumes all the hosts are up. So, I was again at the beginning. Simple arping solution Until I figure out how to force nmap to send arp probes without worrying about routing tables here is a simple solution using arping command: #!/bin/bash TIMEOUT=4 for i in {1..254} do if arping -q -f -w \$TIMEOUT -I eth2 10.0.0.\$i then echo "10.0.0.$i is up"
fi
done
There are three problems with this solution:
1. In case your network has netmask other than /24 you'll have to change this script, i.e. it is a bit more complicated. How much, depends on the network mask.
2. The problem with this solution is that it is slow. For example, to scan 254 addresses and with timeout of 4 seconds, it will take about 17 minutes to scan the whole address range assuming no address is alive (what is actually desired state on the network).
3. Finally, timeout value is a bit tricky to determine. Majority of the responses are really quick, i.e. under a second. But some devices respond slower, i.e. when they entered some kind of a sleep state.
Still, it is a satisfactory solution until I find a way to use nmap for that purpose. If you know how, please, leave a comment.