Sophos UTM ARP Table

Heute eine Firewall Migration gehabt, 1x ASA5510 raus, 2x Sophos UTM220 rein.

Die Firewall hat zwei DMZ Interfaces 
172.16.126.225/29 DMZ-Public VLAN500
172.16.126.250/29 DMZ-Private VLAN300

Nach der Migration lief ein FTP Server, welcher ein Interface in beide DMZ’s hat, nicht mehr so wie erwartet.

Im Zuge des Troubleshoots war es notwendig, die MAC Adresse des Servers herrauszufinden, da die Firewall das einzige Device ist, welches ein IP Interface in den entsprechenden Layer2 Broadcast Domains hat,  ist sie die einzige die die MAC Adresse des Servers kennt. Leider bietet das GUI der Sophos UTM keine Übersicht der ARP Table.

Challenge accepted 🙂
–> SSH auf Firewall

<M> loginuser@ssl:/ > arp -a
-bash: arp: command not found
<M> loginuser@ssl:/ > man arp
-bash: man: command not found
<M> loginuser@ssl:/ > man ip
-bash: man: command not found

 

Argh, auf das unterliegende Linux der Sophos UTM scheint abgespeckt zu sein.
Nun wie kommt man an den ARP cache!?

„Everything is a file“ <– let’s prove!

 

Meine verstaubten Linux Kenntnisse lassen erahnen, dass dies wohl im /proc liegen müsste, am besten mal grep’en

 

<M> loginuser@ssl:/proc > find * | grep arp
sys/net/ipv4/conf/eth2.500/arp_accept
sys/net/ipv4/conf/eth2.500/arp_announce
sys/net/ipv4/conf/eth2.500/arp_filter
sys/net/ipv4/conf/eth2.500/arp_ignore
sys/net/ipv4/conf/eth2.500/arp_notify
sys/net/ipv4/conf/eth2.500/proxy_arp

 

Tatsächlich, für das VLAN Interface auf eth2 gibt es eine Art subinterface .500

<M> loginuser@ssl:/proc/sys/net/ipv4/conf/eth2.500 > ls -lha
total 0
dr-xr-xr-x 1 root root 0 Oct 15 17:49 .
dr-xr-xr-x 1 root root 0 Oct 10 11:51 ..
-rw-r--r-- 1 root root 0 Oct 15 23:10 accept_local
-rw-r--r-- 1 root root 0 Oct 15 23:10 accept_redirects
-rw-r--r-- 1 root root 0 Oct 15 23:10 accept_source_route
-rw-r--r-- 1 root root 0 Oct 15 23:10 arp_accept
-rw-r--r-- 1 root root 0 Oct 15 23:10 arp_announce
-rw-r--r-- 1 root root 0 Oct 15 23:10 arp_filter
-rw-r--r-- 1 root root 0 Oct 15 17:49 arp_ignore
-rw-r--r-- 1 root root 0 Oct 15 23:10 arp_notify
<-Output omitted->
-rw-r--r-- 1 root root 0 Oct 15 23:10 rp_filter
-rw-r--r-- 1 root root 0 Oct 15 23:10 secure_redirects
-rw-r--r-- 1 root root 0 Oct 15 23:10 send_redirects
-rw-r--r-- 1 root root 0 Oct 15 23:10 shared_media
-rw-r--r-- 1 root root 0 Oct 15 23:10 src_valid_mark
-rw-r--r-- 1 root root 0 Oct 15 23:10 tag

 

Also erstmal den ARP-Cache füllen:

<M> loginuser@ssl:/proc/sys/net/ipv4/conf/eth2.500 > ping 172.16.126.227
64 bytes from 172.16.126.227: icmp_seq=1 ttl=128 time=1.28 ms
<M> loginuser@ssl:/proc/sys/net/ipv4/conf/eth2.500 > ping 172.16..126.241
64 bytes from 172.16.126.241: icmp_seq=1 ttl=64 time=0.122 ms

Die naheliegenste Tatsache als Linux Dau wäre wohl alles zu cat’en

<M> loginuser@ssl:/proc/sys/net/ipv4/conf/eth2.500 > cat *
0
0
<-Output omitted->
1
1
0

 

Ok das bringt rein gar nichts.

in google we trust

Scheinbar gibt es ein alternatives Command:

<M> loginuser@ssl:/proc/sys/net/ipv4/conf/eth2.500 > ip neighbor show 
172.16.126.227 dev eth2.500 lladdr x:x:x:x:x:x:21 REACHABLE
<-Output omitted->

 

 There we go… 

Samuel Heinrich
Senior Network Engineer at Selution AG (Switzerland)
Arbeitet in Raum Basel (Switzerland) als Senior Network Engineer mit über 15 Jahren Erfahrung im Bereich Netzwerk

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.