chr.istoph, der Blog

Um mal zu verdeutlichen welche ICMP Anfragen an meinen Server gestellt werden, habe ich folgende Typenbeschreibung als Kommentar in iptables ausgeben lassen.

iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT -m comment --comment "ICMP  Echo Reply"
#iptables -A INPUT -p icmp --icmp-type 1-2 -j ACCEPT -m comment --comment "ICMP  Reserved"
iptables -A INPUT -p icmp --icmp-type 3 -j ACCEPT -m comment --comment "ICMP  Destination Unreachable"
iptables -A INPUT -p icmp --icmp-type 4 -j ACCEPT -m comment --comment "ICMP  Source Quench"
iptables -A INPUT -p icmp --icmp-type 5 -j ACCEPT -m comment --comment "ICMP  Redirect"
iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT -m comment --comment "ICMP  Echo Request"
iptables -A INPUT -p icmp --icmp-type 9 -j ACCEPT -m comment --comment "ICMP  Router Advertisement"
iptables -A INPUT -p icmp --icmp-type 10 -j ACCEPT -m comment --comment "ICMP  Router Solicitation"
iptables -A INPUT -p icmp --icmp-type 11 -j ACCEPT -m comment --comment "ICMP  Time Exceeded"
iptables -A INPUT -p icmp --icmp-type 12 -j ACCEPT -m comment --comment "ICMP  Parameter Problem"
iptables -A INPUT -p icmp --icmp-type 13 -j ACCEPT -m comment --comment "ICMP  Timestamp (erleichtert die Zeitsynchronisation)"
iptables -A INPUT -p icmp --icmp-type 14 -j ACCEPT -m comment --comment "ICMP  Timestamp Reply"
iptables -A INPUT -p icmp --icmp-type 15 -j ACCEPT -m comment --comment "ICMP  Information Request"
iptables -A INPUT -p icmp --icmp-type 16 -j ACCEPT -m comment --comment "ICMP  Information Reply"
iptables -A INPUT -p icmp --icmp-type 17 -j ACCEPT -m comment --comment "ICMP  Address Mask Request"
iptables -A INPUT -p icmp --icmp-type 18 -j ACCEPT -m comment --comment "ICMP  Address Mask Reply"
iptables -A INPUT -p icmp --icmp-type 19 -j ACCEPT -m comment --comment "ICMP  Reserved (for Security)"
#iptables -A INPUT -p icmp --icmp-type 20-29 -j ACCEPT -m comment --comment "ICMP  Reserved (for Robustness Experiment)"
iptables -A INPUT -p icmp --icmp-type 30 -j ACCEPT -m comment --comment "ICMP  Traceroute"
iptables -A INPUT -p icmp --icmp-type 31 -j ACCEPT -m comment --comment "ICMP  Datagram Conversion Error"
iptables -A INPUT -p icmp --icmp-type 32 -j ACCEPT -m comment --comment "ICMP  Mobile Host Redirect"
iptables -A INPUT -p icmp --icmp-type 33 -j ACCEPT -m comment --comment "ICMP  Ursprünglich IPv6 Where-Are-You (ersetzt durch ICMPv6)"
iptables -A INPUT -p icmp --icmp-type 34 -j ACCEPT -m comment --comment "ICMP  Ursprünglich IPv6 I-Am-Here (ersetzt durch ICMPv6)"
iptables -A INPUT -p icmp --icmp-type 35 -j ACCEPT -m comment --comment "ICMP  Mobile Registration Request"
iptables -A INPUT -p icmp --icmp-type 36 -j ACCEPT -m comment --comment "ICMP  Mobile Registration Reply"
iptables -A INPUT -p icmp --icmp-type 37 -j ACCEPT -m comment --comment "ICMP  Domain Name Request"
iptables -A INPUT -p icmp --icmp-type 38 -j ACCEPT -m comment --comment "ICMP  Domain Name Reply"
iptables -A INPUT -p icmp --icmp-type 39 -j ACCEPT -m comment --comment "ICMP  SKIP"
iptables -A INPUT -p icmp --icmp-type 40 -j ACCEPT -m comment --comment "ICMP  Photuris"
iptables -A INPUT -p icmp --icmp-type 41 -j ACCEPT -m comment --comment "ICMP  ICMP messages utilized by experimental mobility protocols such as Seamoby"
#iptables -A INPUT -p icmp --icmp-type 42-255 -j ACCEPT -m comment --comment "ICMP  Reserved"

Mit iptables -L -vn kann man sich dann die anzahl ausgeben lassen.
Quelle: wikipedia.org

OpenVPN nutzt zur Bestimmung der Maximum Transmission Unit (MTU) ICMP Pakete des Typs 3. Dafür ist es dringend erforderlich das man diese auch an der Firewall zulässt.

If a software or hardware firewall is in place (especially if the firewall is whitelisting connections), make sure it is allowing ICMP Destination Unreachable: Fragmentation Needed (ICMP Type 3, Code 4) into your network. Windows Firewall, by default, has this rule configured, and there is no need to add this rule explicitly on Windows machines.
Quelle: docs.openvpn.net

Wenn man sich das auf dem VPN Server anschaut sieht das so aus:

tcpdump -i eth0 -p icmp
11:01:01.298080 IP 1.1.1.1 > vpn.chr.istoph.de: ICMP 1.1.1.1 unreachable - need to frag (mtu 1418), length 36
11:01:01.298084 IP 1.1.1.1 > vpn.chr.istoph.de: ICMP 1.1.1.1 unreachable - need to frag (mtu 1418), length 36

Als Empfehlung gebe ich mit mindestens die folgende Pakete freizuschalten.

iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT -m comment --comment "ICMP  Echo Reply"
iptables -A INPUT -p icmp --icmp-type 3 -j ACCEPT -m comment --comment "ICMP  Destination Unreachable"
iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT -m comment --comment "ICMP  Echo Request"
iptables -A INPUT -p icmp --icmp-type 11 -j ACCEPT -m comment --comment "ICMP  Time Exceeded"

Mit verschiedenen Werkzeugen ist es möglich über die in RFC 1323 Section 3.2 Spezifizierte Option die Uptime eines Rechners zu ermitteln. Der Theorie nach soll man so Angriffe gegen ungepachte Kernel / Sicherheitsupdates fahren können.
Hier ein nmap Beispiel:

sudo nmap -O -v 10.0.0.1

Starting Nmap 6.25 ( http://nmap.org ) at 2013-10-17 22:21 CEST
Initiating ARP Ping Scan at 22:21
Scanning 10.0.0.1 [1 port]
Completed ARP Ping Scan at 22:21, 0.00s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 22:21
Completed Parallel DNS resolution of 1 host. at 22:21, 0.05s elapsed
Initiating SYN Stealth Scan at 22:21
Scanning 10.0.0.1 [1000 ports]
Discovered open port 22/tcp on 10.0.0.1
Completed SYN Stealth Scan at 22:21, 0.17s elapsed (1000 total ports)
Initiating OS detection (try #1) against 10.0.0.1
Nmap scan report for 10.0.0.1
Host is up (0.0011s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
MAC Address: B8:27:EB:00:00:00 (Raspberry Pi Foundation)
Device type: general purpose
Running: Linux 2.6.X|3.X
OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3
OS details: Linux 2.6.32 - 3.6
Uptime guess: 17.048 days (since Mon Sep 30 21:12:28 2013)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=255 (Good luck!)
IP ID Sequence Generation: All zeros

Read data files from: /usr/local/bin/../share/nmap
OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 2.00 seconds
           Raw packets sent: 1023 (45.806KB) | Rcvd: 1015 (41.282KB)

Die „Schätzung“ von nmap von 17.048 Tagen liegt mit der Tatsächlichen Uptime 17 days, 1:14 gut überein.

Um dies nun zu Unterbinden kann eine der beiden Möglichkeiten gewählt werden:
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
sysctl net.ipv4.tcp_timestamps=0

oder direkt in der /etc/sysctl.conf eingetragen werden:
net.ipv4.tcp_timestamps=0

Dann bekommt nmap keine sinnvollen antworten mehr:
(mehr …)

Es passiert immer wieder das irgendein Depp im Wohnheimnetz einen DHCP Server anschließt. Dies kann zur folge haben das Bewohner aufgrund einer falschen IP und default route kein Internet haben, im schlimmsten Fall kann man dadurch man in the middle attacken fahren.

Mittels dhcping bekommt man heraus welche DHCP Server im Netz antworten verteilen. So ist schnell ein Übeltäter lokalisiert.
dhcping -s 255.255.255.255 -r -v

Um dieses Problem aber generell in den Griff zu bekommen haben ich auf dem Cisco Switch DHCP snooping eingerichtet. Dafür habe ich erst alle möglichen Server Ports freigeschaltet. So kann es nicht Passieren das bei Umbauarbeiten am Netzwerk keiner mehr eine DHCP Adresse bekommt. Anschließend habe ich für das gesamte 240 VLAN das dhcp snooping aktiviert.

switch(config)#interface range GigabitEthernet 2/1-48
switch(config-if-range)#ip dhcp snooping trust
switch(config-if-range)#exit
switch(config)#ip dhcp snooping vlan 240
switch(config)#do show ip dhcp snooping

Switch DHCP snooping is disabled
DHCP snooping is configured on following VLANs:
none
Insertion of option 82 is enabled
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Interface Trusted Rate limit (pps)
------------------------ ------- ----------------
GigabitEthernet2/1 yes unlimited


Oft sind veraltete Passwörter oder Accounts ein Einfallstor für Hacker Angriffe. In meiner auth.log finden sich hierfür fiele Beispiele. Um Herauszufinden welche User einen Account mit Passwort zugriff haben, habe ich folgende Überprüfung gemacht:

grep '\$' /etc/shadow | awk -F: '{print $1}'
root