Arch Linux

SNMP-Zugriff auf USV

Greg

Ein Kollege von mir hat mir eine Mail geschickt:

From: derda <derda@ibm.com>
To: "Greg" <greg@ibm.com>
Subject: Re: SNMP-Zugriff auf USV
Date: Tue, 20 Mar 2012 07:57:03 +0100
user-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 (baa)
Thunderbird/11.0

Ich habe mir gerade die Log-Datei der USV angeschaut und festgestellt,
dass heute bereits ein Zugriff stattgefunden hat:

2012-03-19 08:14:01 System: Detected an unauthorized user attempting to
access the SNMP interface from 134.94.128.153
2012-03-19 08:14:01 System: Detected an unauthorized user attempting to
access the SNMP interface from 134.94.128.153

2012-03-16 12:33:08 System: Detected an unauthorized user attempting to
access the SNMP interface from 134.94.128.153
2012-03-16 12:33:08 System: Detected an unauthorized user attempting to
access the SNMP interface from 134.94.128.153
2012-03-15 08:15:13 System: Detected an unauthorized user attempting to
access the SNMP interface from 134.94.128.153
2012-03-15 08:15:13 System: Detected an unauthorized user attempting to
access the SNMP interface from 134.94.128.153
2012-03-14 15:39:27 System: Detected an unauthorized user attempting to
access the SNMP interface from 134.94.128.153
2012-03-14 15:39:27 System: Detected an unauthorized user attempting to
access the SNMP interface from 134.94.128.153
2012-03-13 10:13:54 System: Detected an unauthorized user attempting to
access the SNMP interface from 134.94.128.153
2012-03-13 10:13:53 System: Detected an unauthorized user attempting to
access the SNMP interface from 134.94.128.153
2012-03-12 11:26:21 System: Detected an unauthorized user attempting to
access the SNMP interface from 134.94.128.153
2012-03-12 11:26:21 System: Detected an unauthorized user attempting to
access the SNMP interface from 134.94.128.153

und heute:
07:39 - An- bzw. Rundruf von 134.94.128.153 mit SMNPv3

Die Frage ist, wie kann ich feststellen was meine Kiste an Netzwerkverbindungen getätigt hat. Und was für ein Programm das ist.
In den cronjobs habe ich bereits gesucht... nichts.
Sonstige Software oder Daemons gibt es nicht. Sendmail oder ähnliches auch nicht.
Ich habe mit der USV nichts zu tun.
In allen Logdateien habe ich nichts auffälliges erkennen können.

Ich bedanke mich schon mal!!

Bis denn...
Greg

GerBra

134.94.128.153 ist dein Rechner?
Irgendwas an Conky,gkrellm,nagios/icinga installiert/genutzt? Avahi aktiv?
Wären die normalen snmp-tools (net-snmp) überhaupt installiert? pacman -Qs snmp
Die Zeitpunkte über die Tage sind ja nicht sehr regelmäßig ,das würde einem cronjob o.ä. widersprechen.... Könnten die zeitpunkte Rechnerstarts sein?

Zum Prüfen, ob deine Maschine/IP auf den SNMP-Teil der USV zugreifst bzw, mit was würde ich:
a) per iptables den Output überwachen lassen (gehen Pakete von dir raus?)
b) und per lsof versuchen den Verursacher zu finden
Beide Methoden benötigen Root-Rechte an deinem PC!

Per iptables:
Loggt dir nach /var/log/everything.log und /var/log/iptables.log jedes Paket was an "normalreservierte" SNMP-Ports geht. So kannst du sehen, ob die Pakete wirklich von deiner MAschine kommen.
iptables muß installiert sein (pacman -S iptables), dieses kleine Skript erstellt dir Regeln für die meistgenutzten SNMP-Ports

#!/bin/sh
#
for p in snmp snmpssh snmptls; do
        iptables -A OUTPUT -p tcp --dport $p -j LOG
        iptables -A OUTPUT -p udp --dport $p -j LOG
done

Mit:

iptables -nvL

kannst du prüfen ob die Regeln in der OUTPUT chain aktiv sein, müßten 6 Regeln sein...
Es werden keine Pakete geblockt o.ä., lediglich ausgehende Pakete an die Ports 161,5161,10161 werden geloggt.
Wenn der SNMP-Daemon bei der USV auf einem anderen Port lauscht müßtest du diesen ggf. beim Admin erfahren.
Eine typische iptables-LOG Ausgabe sieht im Logfile so aus:

Mar 20 15:34:48 ws01 kernel: [ 3512.498982] IN= OUT=eth0 SRC=192.168.1.10 DST=82.94.223.16 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=32186 DF PROTO=TCP SPT=37440 DPT=80 WINDOW=232 RES=0x00 ACK URGP=0

Per lsof:
lsof zeigt dir welcher Prozeß übers Netzwerk eine Verbindung zu den SNMP-Ports aufbaut. (pacman -S lsof wenn noch nicht installiert)
Du kannst lsof in einem Terminal oder auch im Hintergrund laufen lassen (und die Ausgabe noch in ein Logfile). lsof schaut jede Sekunde nach aktiven bzw. getätigten Verbindungen, allerdings *muß* es wegen der "großen" Zeitspanne von 1s nicht jede erwischen. Aber die Wahrscheinlichkeit (v.a. wenn über TCP) ist sehr groß. Außerdem hast du ja noch das iptables-Logfile von oben....

lsof -i:snmp -i:snmpssh -i:snmptls -r1 | tee /var/log/lsof_snmp.log

Zeigt die Ausgaben einmal im Terminal (wobei sekündlich eine Dummy-zeile mit ====== kommt wenn nichts gefunden wird...) und loggt gleichzeitig nach /var/log/lsof_snmp.log. Das kannst du ja dann durchforsten ob dort Prozesse geloggt werden, bei COMMAND wird auch die Anwendung gezeigt. Eine typische lsof-Ausgabe sieht so aus:

COMMAND  PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
firefox 1443 gerhard   52u  IPv4  13553      0t0  TCP ws01.my.lan:48034->server.archlinux.de:https (ESTABLISHED)

Greg

Vielen Dank GerBra für deine Tips.
Ich werde das mal abarbeiten.

GerBra schrieb134.94.128.153 ist dein Rechner?

Ja, das ist meiner. Wird bis gestern noch per dhcp erteilt. Das Ganze wird irgendwie über die Macadresse gemacht. Hier im Intranet gibt es einen Oberguru der das entsprechend verwaltet.

GerBra schrieb Irgendwas an Conky,gkrellm,nagios/icinga installiert/genutzt? Avahi aktiv?

Nein nichts.
In der everything.log gibt es diese Ausgabe zu avahi:

Mar 21 08:01:42 localhost dbus[571]: [system] Failed to activate service 'org.freedesktop.Avahi': timed out

GerBra schriebWären die normalen snmp-tools (net-snmp) überhaupt installiert? pacman -Qs snmp

net-snmp ist installiert, läßt sich nicht deinstallieren weil sane das braucht.
Den Scanner allerdings habe ich seit ewigen Zeiten nicht benutzt und auch nicht eingeschaltet. Die snmp Tools sind von mir nicht wissentlich benutzt worden.

GerBra schrieb Die Zeitpunkte über die Tage sind ja nicht sehr regelmäßig ,das würde einem cronjob o.ä. widersprechen.... Könnten die zeitpunkte Rechnerstarts sein?

Es sind immer nur 2 Anfragen an die USV kurz nachdem der Rechner gestartet wurde. Bei den cronjobs habe ich schon nachgesehen. Ausser Lokale Anwendungen bei Daily ist da nichts drin.
cron.daily:
file:///etc/cron.daily/logrotate
file:///etc/cron.daily/man-db
file:///etc/cron.daily/shadow
file:///etc/cron.daily/updatedb
In diesen Scripts die ich nicht verändert habe steht auch nichts auffälliges drin.
Ich habe noch mit dem Admin gesprochen, der gab mir den Tip statt per dhcp die Adressen statisch einzugeben. Das habe ich jetzt eben gemacht. Eintragsänderungen in der rc.conf durchgeführt.
Falls es daran liegen würde müßte man noch verstehen warum ausgerechnet mein Rechner als Einziger von 2000 auf einer USV Anfragen macht. Aber ich hoffe mit deinen genannten Ansätzen eine gezielte Fehlersuche machen zu können.

Bis denn erst mal.

GerBra

Greg schrieb
GerBra schrieb Die Zeitpunkte über die Tage sind ja nicht sehr regelmäßig ,das würde einem cronjob o.ä. widersprechen.... Könnten die zeitpunkte Rechnerstarts sein?
Es sind immer nur 2 Anfragen an die USV kurz nachdem der Rechner gestartet wurde.

Gut, dann kommst du natürlich mit der Art/Zeitpunkt was ich dir vorschlug nicht weiter. Du mußt die iptables-Regeln und den lsof-Teil dann schon während des Systemstarts unterbringen, die Dinge müssen also schon greifen bevor rc.conf->DAEMONS->network gestartet werden. Ich gehe jetzt einfach mal davon aus, das du weißt wie du das wo unterbringen kannst...

Ohne tiefere Einblicke in euer Netzwerk ist das sowieso nicht debugbar (Ist die USV voll verwaltbar oder hängt diese an einem Server? SNMP-managementconsole: ist das nun ein smnp-Daemon der USV, des Servers oder ggf. "nur" eine HTTPD-Console über die USV-Daten nach Auth abgefragt/einegstellt werden können... Um es also wirklich rauszukriegen wäre zumindest der/die Ports derjenigen Anwendung wichtig, von der die o.a. Logauszüge stammen...
//Edit: Zur Lösung beitragen könnten auch die Zeitpunkte der Logeinträge: Schlagen die an der USV-Seite auch auf wenn/nachdem du deinen Rechner nur gebootet hast (ohne dich anzumelden) oder ist der Zeitpunkt immer wenn du angemeldet bist und mit deinen Programmen/Vorgängen deine Arbeit machst? (Also Frage: System(einstellung) oder User(verhalten)? Also einfach mal booten, runterfahren und wenn diese Connetcts wirklich *jedesmal" reproduzierbar passieren nachfragen ob es in dem Fall auch "passiert" ist...

Erster Vorgang beim Netzwerk in deiner Konfig wäre das Ermitteln und Anfragen an einen DHCP-Server im Netz, das geschieht über UDP/67 und ggf. über Broadcasts. Ist der Server mit dem die USV verbunden ist nun ggf. auch der DHCP-Server? Das wäre so ein Anhaltspunkt... Aktiviertes (und im Netz nicht korrekt behandeltes) IPv6 wäre noch eine Möglichkeit, wie Anfragen deinerseits überhaupt noch an den "ominösen" Port der "ominösen USV" kommen...
Bist du unter 2000 Clients der einzige mit einem Linux? ;-)

Du kannst natürlich gerne nochmal deine rc.conf->DAEMONS posten, und: nutzt du networkmanager o.ä. für die netzverbindung?
Auch ein Blick nach rc.local wäre was wert, da vergißt man gerne mal "Leichen" die man irgendwann mal für irgendetwas eingerichtet hätte...

Wenn sich das "Problem" durch Verwendung von statischer IP-Zuweisung statt DHCP löst, dann liegt aber bei eurem Netzwerk etwas im Argen wenn im Zuge der DHCP-Vermittlung Connects an anderen Rechnern/Ports "aufschlagen"....

Greg

Ich danke dir nochmals!!
Heute hat sich der Kollege nicht gemeldet. Entweder es ist Ruhe von meinem Rechner, oder er ist nicht da. Ich warte bis er sich meldet.
Mit iptables habe ich mich mal befaßt und nach dem Wikiartikel Firewalls diese iptables angewendet. Klar könnte ich das da reinbringen. Kein Problem.
Wo die USV dranhängt kann ich Dir leider nicht sagen. Das kann eine 1PC USV sein oder auch eine USV in der Größe eines Gebäudes mit n' paar Diesels und Batteriepacks. Ist hier alles möglich. Warum das Ding am Netz hängt, keine Ahnung. Ist ja auch egal. Falls das wichtig ist kann ich das mal erfragen. Muß ich mal rüberfahren.
Hier ist mal etwas von der rc.conf seit heute mit statischer Einstellung.

# NETWORKING
# ----------
HOSTNAME="abtzat4711"

interface=eth0
address=134.94.129.154
netmask=255.255.254.0
broadcast=134.94.129.255
gateway=134.94.128.1
..
DAEMONS=(hwclock syslog-ng dbus preload !network @acpid @fcron @alsa @iptables @privoxy !netfs @cupsd @cpufreq)

„! network“ ist schon richtig, der wird am Xfce4-Desktop per Icon mit /etc/rc.d/network start und /etc/rc.d/privoxy start gestartet.
Ich habe mal die Zeiten festgehalten wann genau ich ans Netz gegangen bin und wann wieder raus.
Es gibt hier einige Linuxleute mit Fedora, Radhat, Debian, Suse. Gut, ich werde vielleicht der Einzige mit Arch sein. Am Sonsten noch so ein Jugene mit Radhat drin. https://de.wikipedia.org/wiki/JUGENE
http://www.fz-juelich.de/portal/DE/Forschung/Informationstechnologie/Supercomputer/JUGENE.html;jsessionid=7EBF3C3C89071926D976A0BA43E30636?nn=363164

So, jetzt warte ich bis morgen. Bis man sowas raus hat dauert noch was. Mit Geduld und Spucke + Deinem Rat wird das schon zu machen sein.
Bis denn...

Greg

Nachtrag:

Wenn sich das "Problem" durch Verwendung von statischer IP-Zuweisung statt DHCP löst, dann liegt aber bei eurem Netzwerk etwas im Argen wenn im Zuge der DHCP-Vermittlung Connects an anderen Rechnern/Ports "aufschlagen"....

Genau das wird dann für unsere Admins sehr interessant sein.

Greg

Der Kollege hat sich wieder gemeldet. An dhcp liegt es nicht.
Er bekommt immer noch kurz nach dem Einschalten 2 Anfragen von meiner Kiste.

> 2012-03-23	08:13:56	System: Detected an unauthorized user attempting to
> access the SNMP interface from 134.94.128.153
>  2012-03-23	08:13:56	System: Detected an unauthorized user attempting to
> access the SNMP interface from 134.94.128.153
>  2012-03-22	08:18:09	System: Detected an unauthorized user attempting to
> access the SNMP interface from 134.94.128.153
>  2012-03-22	08:18:09	System: Detected an unauthorized user attempting to
> access the SNMP interface from 134.94.128.153

GerBra ich werde jetzt Deine genannten Tools anwenden.
Ob es dann geklappt hat wird sich erst später rausstellen da der Kollege im Urlaub geht.

Bis denn..
Greg

GerBra

Greg schrieb GerBra ich werde jetzt Deine genannten Tools anwenden.

Bei deinem Setup bzgl. Netzwerk würde ich den lsof-lauf und die iptables-LOG-Regeln wohl im /etc/rc.d/network-Skript unterbringen (Backup des Skripts machen ggf.). Das ist der IMHO beste Zeitpunkt, Regeln plus lsof müssen halt vor dem Start des Netzwerkes passieren.
Ich würde es auch mal vorher mit anderen Ports testen, z.B. https noch mit reinnehmen. So kannst du sehen, ob lsof und iptables richtig arbeiten in deinem Setup wenn du dann auf eine https-Seite gehst. Du mußt also sicher sein, daß deine Methode der Prüfung auch funktioniert selbst wenn nach "Scharfsschaltung" eben nichts gefunden würde bzgl. SNMP...

Greg

.....Und wieder ein Dankeschön GerBra!!
Mit iptables kenn ich mich nur soweit aus, dass ich eine firewall nach dem wiki benutzt habe. Ist schon ewig her. Das Thema iptables ist ja leider nicht gerade klein.
Dein Script:

for p in snmp snmpssh snmptls; do
        iptables -A OUTPUT -p tcp --dport $p -j LOG
        iptables -A OUTPUT -p udp --dport $p -j LOG
done

habe ich unten an iptables-save drangehängt. iptables-save ausgeführt das es mit in die rules übernommen wird.
Hier ist mal iptables-save:

#!/bin/bash
 
 #Ports: Hier eintragen welche Ports geöffnet werden sollen
 SERVICES_UDP="" #freigegebene UDP-Ports 
# SERVICES_TCP="22 80" #freigegebene TCP-Ports (Hier sshd und http)
 SERVICES_TCP="20 21 22 25 80 110 123 443" #freigegebene TCP-Ports Hier:
#ftp-data ftp-command ssh smtp http pop3 ntp https
 
#Alle vorhandenen Regeln löschen
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
iptables -t nat -X
iptables -t mangle -X

#Grundregeln
iptables -P OUTPUT  ACCEPT
iptables -P INPUT   DROP
iptables -P FORWARD DROP

#Sicherheit
iptables -N other_packets								#Tabelle "other_packets" erzeugen
iptables -A other_packets -p ALL -m state --state INVALID -j DROP			#Kaputte Pakete verwerfen
iptables -A other_packets -p icmp -m limit --limit 1/h -j ACCEPT			#ICMP auf max. 1 Paket/Sekunde limitieren
iptables -A other_packets -p ALL -j RETURN						#Tabelle "other_packets" verlassen

iptables -N service_sec								#Tabelle "services_sec" erzeugen
iptables -A service_sec -p tcp --syn -m limit --limit 1/h -j ACCEPT			#SYN-Flood Attacken
iptables -A service_sec -p tcp ! --syn -m state --state NEW -j DROP			#TCP-SYN-Pakete ohne Status NEW verwerfen
iptables -A service_sec -p tcp --tcp-flags ALL NONE -m limit --limit 1/h -j ACCEPT	#Portscanner ausschalten
iptables -A service_sec -p tcp --tcp-flags ALL ALL -m limit --limit 1/h -j ACCEPT	#Portscanner ausschalten
iptables -A service_sec -p ALL -j RETURN						#Tabelle "services" verlassen

iptables -N reject_packets								#Tabelle "reject_packets" erzeugen
iptables -A reject_packets -p tcp -j REJECT --reject-with tcp-reset			#TCP Pakete(Protokoll) zurückweisen
iptables -A reject_packets -p udp -j REJECT --reject-with icmp-port-unreachable	#UDP Pakete(Protokoll) zurückweisen
iptables -A reject_packets -p icmp -j REJECT --reject-with icmp-host-unreachable	#ICMP Pakete(Protokoll) zurückweisen (bei mehr als 1Paket/Sekunde [s.o.])
iptables -A reject_packets -j REJECT --reject-with icmp-proto-unreachable		#Alle anderen Pakete(Protokolle) zurückweisen 
iptables -A reject_packets -p ALL -j RETURN						#Tabelle "reject_packets" verlassen

#Dienste
iptables -N services									#Tabelle für die Dienste erzeugen
for port in $SERVICES_TCP ; do								#Für jeden TCP Port (oben definiert) folgendes tun:
       iptables -A services -p tcp --dport $port -j service_sec			#Bei Verbindungen auf TCP Port "$port in die Tabelle "services_sec" springen
       iptables -A services -p tcp --dport $port -j ACCEPT				#Bei Verbindungen auf TCP Port "$port Verbindung zulassen
done
for port in $SERVICES_UDP ; do								 #Für jeden UDP Port (oben definiert) folgendes tun:
       iptables -A services -p udp --dport $port -j service_sec			#Bei Verbindungen auf UDP Port "$port" in die Tabelle "services_sec" springen
       iptables -A services -p udp --dport $port -j ACCEPT				#Bei Verbindungen auf UDP Port "$port Verbindung zulassen
done
iptables -A services -p ALL -j RETURN							#Tabelle "services" verlassen

#INPUT
iptables -A INPUT -p ALL -i lo -j ACCEPT						#Alle Pakete vom Loopback Interface zulassen
iptables -A INPUT -p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT		#Bereits vorhandene Verbindungen zulassen
iptables -A INPUT -p ALL -j other_packets						#In die Tabelle "other_packets" springen
iptables -A INPUT -p ALL -j services							#In die Tabelle "services" gehen
iptables -A INPUT -p ALL -m limit --limit 1/m -j reject_packets			#Nicht erlaubte Pakete zurückweisen, max 10Pakete/Sekunde (Tabelle "reject_Packets")
iptables -A INPUT -p ALL -j DROP							#Alles andere verwerfen

#OUTPUT:
iptables -A OUTPUT -p ALL -j ACCEPT							#Ausgehende Pakete erlauben

#/var/log/everything.log und /var/log/iptables.log snmp Daten loggen:
for p in snmp snmpssh snmptls; do
        iptables -A OUTPUT -p tcp --dport $p -j LOG
        iptables -A OUTPUT -p udp --dport $p -j LOG
done

#Speichern
/etc/rc.d/iptables save

Müßte so funktionieren oder?
Die Daemonzeile von rc.conf sieht jetzt etwas anders aus:

DAEMONS=(hwclock syslog-ng acpid dbus preload !network @fcron @alsa @iptables @privoxy !netfs @cupsd @cpufreq)

Ich meine irgendwo gelesen zu haben, dass acpid vor dbus sein soll und mal ohne dem„@“.

Bis denn...
Greg

GerBra

SERVICES_TCP="20 21 22 25 80 110 123 443" #freigegebene TCP-Ports Hier:
Das sind alles Dienste (ftp,pop3,httpd,...) die du auf deinem Rechner anbietest?

Ich meine: wenn du bisher ohne iptables auskamst, warum dann jetzt wieder etwas sehr "kompliziertes" reinbringen? Warum nicht einfach nur die 6 LOG-Regeln in ein abgeändertes /e/rc.d/network-Skript?

Und wie gesagt: Um zu prüfen ob das lsof-Logging (geht dann im Hintergrund nicht mit pipen über tee!) und die Regel greifen: Pack zu den snmp Angaben jeweils noch ein https dazu und schaue, ob nach einem Zugriff deinerseits sowohl das lsof-Logfile als auch in iptables.log diese Zugriffe vermerkt sind. Nur su kannst du dir sicher sein, daß deine Methode auch die Zugiffe auf smnp erfassen würde - wenn sie denn passieren...

Daemons: Die logische Reihenfolge wäre für mich acpid dann dbus, beides nicht im Hintergrund starten lassen, ja...

Greg

GerBra schriebSERVICES_TCP="20 21 22 25 80 110 123 443" #freigegebene TCP-Ports Hier:
Das sind alles Dienste (ftp,pop3,httpd,...) die du auf deinem Rechner anbietest?

Ist schon sehr lange her das es hier weiter geht. Erst hatte ich Urlaub dann hatte mein Kollege Urlaub und so vergeht die Zeit.
Nochmal an Dich GerBra ein Danke!!
services freigegebene Ports, ist natürlich jetzt geändert. Auch das mit iptables ist schon ewig her.
Überhaupt die Firewallregeln habe ich komplett zunächst rausgemacht und nur zum loggen wie oben beschrieben eingesetzt.
Die Logs haben bei mir keine Auffälligkeiten gezeigt. Bis auf 2 Netzwerkdrucker die über das snmp Protokoll angesprochen sind war da nichts zu sehen. Hinundwieder mal ein update durchgeführt wie üblich.
Dann endlich eine Rückmeldung vom Kollegen, seit dem 12.04. keine Zugriffe von mir auf die USV. Sonstige Infos von Administrator oder Solchen gibt es nicht.
Das Problem ist gelöst wenn auch unwissend wie es gelöst ist.

Bis denn..
Gruß aus DN!!
Greg