Installation MRTG & vnStat

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

cd /usr/ports
make search name=mrtg

 

Port:   mrtg-2.16.2_6,1
Path:   /usr/ports/net-mgmt/mrtg
Info:   The multi-router traffic grapher
Maint:  ports@subnets.ru
B-deps: expat-2.0.1_1 fontconfig-2.8.0,1 freetype2-2.3.12 gd-2.0.35_7,1 jpeg-8_2 perl-5.10.1_1 pkg-config-0.23_1 png-1.4.1_1 R-deps: expat-2.0.1_1 fontconfig-2.8.0,1 freetype2-2.3.12 gd-2.0.35_7,1 jpeg-8_2 p5-SNMP_Session-1.12 perl-5.10.1_1 pkg-config-0.23_1 png-1.4.1_1
WWW:    http://oss.oetiker.ch/mrtg/

cd /usr/ports/net-mgmt/mrtg
make install clean

wir tun bei den Options nix enablen (kein ipv6 und kein snmp)

############################################################################
# Please create a MRTG config file in /usr/local/etc/mrtg                  #
# A configuration file can be automatically generated with cfgmaker        #
# A sample configuration file is installed as mrtg.cfg.sample              #
#                                                                          #
# To enable MRTG in daemon mode, put the following to your /etc/rc.conf:   #
#      mrtg_daemon_enable="YES"                                            #
############################################################################

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/mrtg

Bei 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 /usr/local/etc/mrtg/mrtg.cfg

Folgendes anpassen:

vi mrtg.cfg
WorkDir:/monitoring/mrtg/FreeBSD9

Und 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 installed

SYSTEM 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

cd /usr/ports/net/vnstat
make install clean

Bei den Options: ohne GUIInstallieren. 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 time

See 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.

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 unterNetworking“ -> „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

.

Flattr this!

  • *

    Du kannst diese HTML tags verwenden: <a> <abbr> <acronym> <b> <blockquote> <cite> <code> <del> <em> <i> <q> <s> <strike> <strong>

  • Kommentar-Feed für diesen Beitrag
nach oben