spread the knowledge
Installation MRTG & vnStat
“Übersicht“
Mit MRTG monitore ich z.B. den System Load, Server Temperatur, Memory Usage, Apache Usage, MySQL Usage etc. Mit vnStatkann ich den Server Traffic auslesen.
Installation MRTG
pkg install mrtg
Ich möchte meine Monitoring Files aller Server auf derselben (gesharten) Festplatte haben. In meinem Fall liegt das /monitoring Directory auf einer gesharten Platte. Die Logfiles werden dann einfach unter dem entsprechenden Hostnamen (in diesem Fall FreeBSD9) abgelegt. Wenn man keine gesharte HDD hat, kann man die Daten natürlich auch mit rsyncableichen.
mkdir -p /monitoring/mrtg/FreeBSD9
chown -R mrtg:mrtg /monitoring/mrtgBei Server Move, bestehendes mrtg.cfgin dieses Verzeichnis kopieren:
/usr/local/etc/mrtg
Oder selber von Grund auf neu machen / Erstinstallation:
cd /usr/local/etc/mrtg cp /usr/local/etc/mrtg/mrtg.cfg.sample /global/monitoring/mrtg/mrtg.cfg
ln -s /global/monitoring/mrtg/mrtg.cfg .
Folgendes anpassen:
vi mrtg.cfg
WorkDir:/monitoring/mrtg/FreeBSD9Und dann natürlich alle Checks, die benötigt werden. MRTG beim Startup aktivieren:
vi /etc/rc.conf
Add:
#-----------------------------------------------# # MRTG # #-----------------------------------------------# mrtg_daemon_enable="YES"
Starten:
/usr/local/etc/rc.d/mrtg_daemon start
Cronjob
vi /usr/local/cronjobs/mrtg.sh
Paste
/usr/local/bin/mrtg /usr/local/etc/mrtg/mrtg.cfg --logging /var/log/mrtg.log /usr/local/bin/vnstat -u
crontab -e */5 * * * * /usr/local/cronjobs/mrtg.sh
Scripts
Die Scripts in /monitoring/mrtg/scriptgenerieren die gewünschten Informationen, die in der Statistik angezeigt werden sollen. In diesem Verzeichnis sind folgende Scripts gespeichert:
Einfach runterladen, ev. anpassen, umbenennen und executable machen. * Beim MySQL Script ist wichtig, dass man den $host entsprechend anpasst. Ausserdem muss man noch das mysql.php File entsprechend raufladen für den korrekten Output. Ich habe das mysql.php für meine Bedürfnisse angepasst. Das Original File gibt es hier: ApacheStats-MySQL-Add-on.zipmysql.php
Der Output der Scripts ist wie folgt:
- 1 + 2 Line sind die Zahlen.
- 3 + 4 sind strings.
Line 1
current state of the first variable, normally 'incoming bytes count'
Line 2
current state of the second variable, normally 'outgoing bytes count'
Line 3
string (in any human readable format), telling the uptime of the target.
Line 4
string, telling the name of the target.free
Damit der Linux Command „free“ auch unter FreeBSD geht:
fetch http://www.cyberciti.biz/files/scripts/freebsd-memory.pl.txt cp freebsd-memory.pl.txt /usr/local/bin/free chmod +x /usr/local/bin/free
Wenn man free nun ausführt, erhalten wir folgenden Output:
# /usr/local/bin/free
SYSTEM MEMORY INFORMATION:
mem_wire: 430620672 ( 410MB) [ 10%] Wired: disabled for paging out
mem_active: + 1478701056 ( 1410MB) [ 35%] Active: recently referenced
mem_inactive:+ 1942753280 ( 1852MB) [ 46%] Inactive: recently not referenced
mem_cache: + 86753280 ( 82MB) [ 2%] Cached: almost avail. for allocation
mem_free: + 187002880 ( 178MB) [ 4%] Free: fully available for allocation
mem_gap_vm: + 16994304 ( 16MB) [ 0%] Memory gap: UNKNOWN
————– ———— ———– ——
mem_all: = 4142825472 ( 3950MB) [100%] Total real memory managed
mem_gap_sys: + 141967360 ( 135MB) Memory gap: Kernel?!
————– ———— ———–
mem_phys: = 4284792832 ( 4086MB) Total real memory available
mem_gap_hw: + 10174464 ( 9MB) Memory gap: Segment Mappings?!
————– ———— ———–
mem_hw: = 4294967296 ( 4096MB) Total real memory installedSYSTEM MEMORY SUMMARY:
mem_used: 2078457856 ( 1982MB) [ 48%] Logically used memory
mem_avail: + 2216509440 ( 2113MB) [ 51%] Logically available memory
————– ———— ———– ——
mem_total: = 4294967296 ( 4096MB) [100%] Logically total memory
mailstats
Das sendmail.pl Script arbeitet mit dem mailstats Programm von Sendmail. Das mailstats Programm arbeitet wiederum mit den Daten, die im sendmail.st File gespeichert sind.
Hierbei kann es vorkommen, dass sich die Daten summieren. Wenn das MRTG vom Local Mail Traffic (bzw. Message Count) plötzlich so aussieht:
die Maillogs jedoch komplett normal aussehen und keine besonderen Auffälligkeiten aufweisen, sollte man das sendmail.st File resetten.
Output mailstatus:
# /usr/sbin/mailstats Statistics from Sun Mar 25 10:00:03 2012 M msgsfr bytes_from msgsto bytes_to msgsrej msgsdis msgsqur Mailer 1 0 0K 40872 197519K 0 0 0 *file* 3 199624 778435K 0 0K 0 0 0 local 5 122 337K 143473 550114K 254 0 0 esmtp ===================================================================== T 199746 778772K 184345 747633K 254 0 0 C 1526 288679 254
Hier kann man nun sehen, dass es anscheinend sehr viele lokale Mails gibt. (In der Regel an Root) – doch im Maillog ist nichts dergleichen zu finden… esmtp wären die externen Mails.
Die Statistik kann man nun so zurücksetzen:
true > /var/log/sendmail.st
Mailstats ist nun geresetted:
# mailstats Statistics from Sat Mar 31 09:37:48 2012 M msgsfr bytes_from msgsto bytes_to msgsrej msgsdis msgsqur Mailer ===================================================================== T 0 0K 0 0K 0 0 0 C 0 0 0
Sollte sowas öfters vorkommen, kann man natürlich für das Resetten auch einen Täglichen Cronjob einrichten.
Weitere Infos dazu gibts hier.
Installation vnStat
vnStat installieren für den ServerTraffic
pkg install vnstat
Bei den Options: ohne GUI Installieren. Configfile:
cd /usr/local/etc cp vnstat.conf.sample vnstat.conf
Edit
Darauf achten, dass das Interface stimmt (gemäss ifconfig) eth0, xl0, ..?
Nun noch DB Verzeichnis erstellen:
mkdir /var/db/vnstat
Starten:
vnstat -u -i xl0
kommen zuerst ein paar fehlermledungen, da es der erste run ist. Crontab:
*/5 * * * * /usr/local/bin/vnstat -u
Helpfile
vnStat 1.11 by Teemu Toivola
-q, –query query database
-h, –hours show hours
-d, –days show days
-m, –months show months
-w, –weeks show weeks
-t, –top10 show top10
-s, –short use short output
-u, –update update database
-i, –iface select interface (default: em0)
-?, –help short help
-v, –version show version
-tr, –traffic calculate traffic
-ru, –rateunit swap configured rate unit
-l, –live show transfer rate in real timeSee also „–longhelp“ for complete options list and „man vnstat“.
Aktueller Traffic (live traffic) kann man so angucken:
vnstat -l
das sieht dann etwa so aus:
rx: 9.51 kB/s 86 p/s tx: 61.16 kB/s 80 p/s
Legende:
RX - Receive - das empfangen wir TX - Transmit - das senden wir
vnstat Frontend
Jetzt kann man einfach über ein PHP Frontend die vnstat Daten im Webbrowser anzeigen lassen. Ich nutze dazu das vnstat PHP frontend.
vnstat Upgrade zu Version 2.x
Nach einem Upgrade sind plötzlich Fehler aufgetaucht wie
- Error: The „-u“ parameter is not supported in this version.
- Error: Unable to open database „/var/db/vnstat/vnstat.db“: No such file or directory
In der 2.x Version wurde der -u Flag abgeschafft, ausserdem wird noch der vnstat Daemon benötigt. Damit vnstat wieder wie gewohnt läuft, folgende Anpassungen machen:
vi /etc/rc.conf
folgendes hinzufügen:
vnstat_enable="YES"
Jetzt noch die Berechtigungen vom Datenbankverzeichnis korrigieren:
chown -R vnstat:vnstat /var/db/vnstat/
Jetzt den Daemon starten, beim ersten Start werden auch die alten Datenbank Files Importiert:
$ service vnstat start
Starting vnstat.
Importing data from legacy database "vtnet0".
Aus dem Cronjob noch die Line
vnstat -u
löschen, dies wird jetzt nicht mehr benötigt, dank dem Daemon.
Probleme & Fehlermeldungen
Error: Database load failed even when using backup. Aborting.
Dieser Fehler kann z.B. nach einem Server Absturz auftauchen beim Befehl.
/usr/local/bin/vnstat -u
Lösung heisst, Datenbank löschen und neu erstellen.
rm -rf /var/db/vnstat/; mkdir /var/db/vnstat/ vnstat -u -i vtnet0
Error: Unable to read database "/var/db/vnstat/vtnet0". Info: -> A new database has been created.
Nun kann man
/usr/local/bin/vnstat -u
wieder ausführen.
Info: Traffic rate for „vtnet0“ higher than set maximum 100 Mbit (60->825, r1776 t0), syncing.
Zuerst muss man abklären, ob das normaler Traffic ist. Wenn das Interface mehr als 100Mbit handeln kann und sollte, kann man im vnstat.conf die MaxBandwidth anpassen – oder generell abschalten (MaxBandwidth 0). Wenn der Fehler plötzlich auftaucht, sollte man sich das genauer anschauen:
# vnstat --top10
vtnet0 / top 10
# day rx | tx | total | avg. rate
-----------------------------+-------------+-------------+---------------
1 01/18/16 472.37 GiB | 32.29 MiB | 472.40 GiB | 45.87 Mbit/s
2 01/17/16 417.98 GiB | 211.20 MiB | 418.19 GiB | 40.60 Mbit/s
3 01/16/16 381.87 GiB | 35.70 MiB | 381.90 GiB | 37.08 Mbit/s
4 01/15/16 343.88 GiB | 30.88 MiB | 343.91 GiB | 33.39 Mbit/s
5 01/19/16 292.63 GiB | 34.53 MiB | 292.67 GiB | 28.42 Mbit/s
6 01/20/16 135.07 GiB | 29.87 MiB | 135.10 GiB | 13.12 Mbit/s
7 08/14/15 65.45 GiB | 147.41 MiB | 65.59 GiB | 6.37 Mbit/s
8 08/15/15 31.46 GiB | 41.27 MiB | 31.50 GiB | 3.06 Mbit/s
9 06/18/16 29.69 GiB | 35.50 MiB | 29.72 GiB | 2.89 Mbit/s
10 01/14/16 23.15 GiB | 37.55 MiB | 23.19 GiB | 2.25 Mbit/s
-----------------------------+-------------+-------------+---------------
Das gibt die letzten Top 10 aus, wo der Traffic sehr hoch war. Nun noch die letzten Tage anzeigen:
# vnstat -d
vtnet0 / daily
day rx | tx | total | avg. rate
------------------------+-------------+-------------+---------------
08/01/16 599.23 MiB | 20.73 MiB | 619.96 MiB | 58.78 kbit/s
08/02/16 3.22 GiB | 30.77 MiB | 3.25 GiB | 315.21 kbit/s
08/03/16 700.43 MiB | 209.75 MiB | 910.18 MiB | 86.30 kbit/s
08/04/16 1.08 GiB | 35.10 MiB | 1.11 GiB | 107.90 kbit/s
08/05/16 879.02 MiB | 245.66 MiB | 1.10 GiB | 106.64 kbit/s
08/06/16 621.67 MiB | 18.19 MiB | 639.85 MiB | 60.67 kbit/s
08/07/16 525.74 MiB | 23.14 MiB | 548.88 MiB | 52.04 kbit/s
08/08/16 3.02 GiB | 68.75 MiB | 3.09 GiB | 299.72 kbit/s
08/09/16 9.98 GiB | 75.03 MiB | 10.05 GiB | 975.82 kbit/s
08/10/16 2.04 GiB | 33.36 MiB | 2.07 GiB | 201.37 kbit/s
08/11/16 4.59 GiB | 32.74 MiB | 4.62 GiB | 448.79 kbit/s
08/12/16 632.28 MiB | 24.11 MiB | 656.39 MiB | 62.24 kbit/s
08/13/16 610.04 MiB | 69.78 MiB | 679.82 MiB | 64.46 kbit/s
08/14/16 568.40 MiB | 25.02 MiB | 593.42 MiB | 56.27 kbit/s
08/15/16 558.61 MiB | 33.04 MiB | 591.65 MiB | 56.10 kbit/s
08/16/16 969.06 MiB | 20.94 MiB | 990.01 MiB | 93.87 kbit/s
08/17/16 591.29 MiB | 27.31 MiB | 618.60 MiB | 58.65 kbit/s
08/18/16 616.10 MiB | 98.37 MiB | 714.47 MiB | 67.74 kbit/s
08/19/16 546.12 MiB | 20.45 MiB | 566.57 MiB | 53.72 kbit/s
08/20/16 518.55 MiB | 26.33 MiB | 544.88 MiB | 51.66 kbit/s
08/21/16 501.14 MiB | 23.69 MiB | 524.84 MiB | 49.76 kbit/s
08/22/16 528.38 MiB | 25.87 MiB | 554.25 MiB | 52.55 kbit/s
08/23/16 526.61 MiB | 27.70 MiB | 554.32 MiB | 52.56 kbit/s
08/24/16 715.07 MiB | 66.46 MiB | 781.54 MiB | 74.10 kbit/s
08/25/16 626.29 MiB | 19.52 MiB | 645.82 MiB | 61.23 kbit/s
08/26/16 598.23 MiB | 22.40 MiB | 620.64 MiB | 58.85 kbit/s
08/27/16 576.14 MiB | 29.39 MiB | 605.53 MiB | 57.41 kbit/s
08/28/16 569.90 MiB | 35.26 MiB | 605.16 MiB | 57.38 kbit/s
08/29/16 5.21 GiB | 109.50 MiB | 5.32 GiB | 516.28 kbit/s
08/30/16 20.84 GiB | 9.89 MiB | 20.85 GiB | 5.23 Mbit/s
------------------------+-------------+-------------+---------------
estimated 53.87 GiB | 23 MiB | 53.89 GiB |
Man sieht, dass sich am 29.08. und 30.08. der RX Traffic massiv erhöht hat. (RX = Incoming, TX = Outgoing Traffic). Es ist also nichts von der Serverseite, das das Problem verursacht (z.B. massiver outgoing Mailtraffic etc.), sondern irgendwelche Abfragen, die von aussen kommen.
Weiter Abklären mit
iftop
sockstat -4
systat -netstat 1
systat -ifstat
netstat
etc. Lohnen tut sich auch oft der Blick ins /var/log/auth.log
Mit iftop kann man die incoming Requests sehr gut filtern. Sortieren nach Bandwidth geht mit den Tasten 1, 2 und 3
iftop -i vtnet0 -f "dst host <meine server ip>"
Ich hab zwar Denyhosts installiert, welches den Zugriff von verdächtigen IP Adressen automatisch blockiert / refused, die Anfragen kommen jedoch trotzdem bis zum Server durch.
In meinem Fall war es so, dass es 3 Hauptangreifer waren. Denyhosts erkannte und blockierte die Loginversuche zwar (auth.log)
Aug 30 13:42:29 patsy sshd[15502]: refused connect from 116.31.116.11 (116.31.116.11)
Aug 30 13:43:27 patsy sshd[15539]: refused connect from 116.31.116.11 (116.31.116.11)
Aug 30 13:44:24 patsy sshd[15636]: refused connect from 116.31.116.11 (116.31.116.11)
Aug 30 13:45:21 patsy sshd[15682]: refused connect from 116.31.116.11 (116.31.116.11)
Aug 30 13:46:19 patsy sshd[15724]: refused connect from 116.31.116.11 (116.31.116.11)
Aug 30 13:47:17 patsy sshd[15764]: refused connect from 116.31.116.11 (116.31.116.11)
Aug 30 13:48:15 patsy sshd[15806]: refused connect from 116.31.116.11 (116.31.116.11)
Aug 30 13:49:14 patsy sshd[15883]: refused connect from 116.31.116.11 (116.31.116.11)
Aug 30 13:50:12 patsy sshd[15932]: refused connect from 116.31.116.11 (116.31.116.11)
Aug 30 13:51:08 patsy sshd[15976]: refused connect from 116.31.116.11 (116.31.116.11)
Aug 30 13:52:06 patsy sshd[16009]: refused connect from 116.31.116.11 (116.31.116.11)
Aug 30 13:53:03 patsy sshd[16019]: refused connect from 116.31.116.11 (116.31.116.11)
doch wie gesagt, die Anfragen kamen trotzdem bis zum Server durch. Das Eintragen im Server Firewall ipfw bringt somit auch nicht viel mehr als Denyhosts bereits getan hat. Der Server ist zwar geschützt, das Netzwerk Interface aber trotzdem überlastet.
Ich musste hier also die Angreifer eine Stufe höher abwehren. Bei Cloudsigma kann man glücklicherweise Policies einrichten, um die Server so zu schützen, dass die Anfragen gar nicht erst bis zu unserer Maschine gelangen.
Dazu einfach im Cloudsigma unter „Networking“ -> „Policies“ eine neue Rule erfassen und alle Inbound connections der Angreifer IPs (=Source) blockieren (Destination=Any). Danach muss man nur noch die Rule dem Server zuweisen (Server muss dazu kurz runter gefahren werden). Fertig. Der Traffic hat sich wieder beruhigt.
# vnstat -l
Monitoring vtnet0... (press CTRL-C to stop)
rx: 52 kbit/s 101 p/s tx: 8 kbit/s 4 p/s
# vnstat -h
vtnet0 16:17
^ r
| r r
| r r r
| r r r r
| r r r r
| r r r r r r
| r r r r r r r
| r r r r r r r r r r r r
| r r r r r r r r r r r r r r r
| r r r r r r r r r r r r r r r r r r r
-+--------------------------------------------------------------------------->
| 17 18 19 20 21 22 23 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16
h rx (KiB) tx (KiB) h rx (KiB) tx (KiB) h rx (KiB) tx (KiB)
17 261668 932 01 2397223 212 09 4269166 211
18 638426 542 02 825498 440 10 1957552 465
19 1154359 555 03 1188312 450 11 3695158 290
20 22977 863 04 1059935 500 12 1676845 296
21 384258 906 05 2803773 247 13 840973 478
22 883690 687 06 4750367 529 14 1434059 922
23 1516606 360 07 1619549 260 15 26737 998
00 4327526 3795 08 1554659 3653 16 7545 230
.
