Examensarbete Nätverksövervakning

Total Page:16

File Type:pdf, Size:1020Kb

Examensarbete Nätverksövervakning Examensarbete Nätverksövervakning En jämförelse av Sensu och op5 Monitor Författare: Kristoffer NILSSON & Ashour SHAMOUN Handledare: Marcus WILHELMSSON Examinator: Jacob LINDEHOFF Termin: VT2014 Ämne: Datavetenskap Nivå: G1E Kurskod: 1DV41E Sammanfattning Rapporten beskriver arbetet och resultaten av en jämförelse mellan Sensu och op5 Monitor, vilka är verktyg som används för att övervaka enheter i nätverk, så kallade network monitoring systems. Arbetet har utförts för att utbudet av nätverksövervak- ningsverktyg ständigt växer och det ansågs värdefullt att jämföra en ny aktör med ett äldre verktyg som är byggd på ett annat tankesätt. Det som ansågs intressant att testa var hur dessa verktyg hanterade de rapporter som skapades och samlades in, om det slutgiltiga resultatet från detta skulle skilja sig åt eller inte. För att testa detta sattes en virtuell testmiljö upp, där Sensu och op5 Monitor rullade parallellt med varandra och övervakade samma system och använde sig utav samma plugin för övervakningen. Experimenten utfördes på två stycken tjänster, BIND9 samt Apache2, i och med att de två pluginen som användes var uppbyggda på olika sätt konstruerades även olika experiment. Under dessa experiment samlades information in om hur de två över- vakningsverktygen hanterade de rapporter de fick in, vilket sedan sammanställdes och analyserades. Slutsatsen av det hela var att Sensu och op5 Monitor hanterar sina insamlade rapporter på ett likvärdigt sätt, de rapporterade resultaten blev i samtliga fall detsamma, således fungerade de två övervakningsverktygen på ett jämgott vis. Nyckelord: Sensu, op5 monitor, Nagios, nätverksövervakning, nms Abstract The report describes the work and results of a comparison between Sensu and op5 Monitor, which are both tools used to monitor devices in a network, more commonly known as network monitoring systems. The subject was chosen due to the fact that there is such a wide range of network monitoring systems, and it is constantly ex- panding. It was considered valuable to compare a newcomer with an older tool that is built with a different mindset. It was considered interesting to test how these tools handled the reports created and collected by them, to see if the final results from this would differ or not. To test this a virtual testing environment was built, where Sensu and op5 Monitor were run in parallel to each other and monitored the same systems and used the same set of plugins. The experiments were conducted on two services, BIND9 and Apache2, since the plugins were constructed in different ways, so were the various experiments. In these experiments information was gathered about how the two monitoring tools handled the reports they received, which was then compiled and analysed. The conclusion of it all was that Sensu and op5 Monitor handles the collected information in a similar manner. The reported results were in all cases the same, thus the two monitoring tools behave in the same fashion. Keywords: Sensu, op5 Monitor, Nagios, Network Monitoring system, nms i Förord Sedan en gästföreläsning har vi fått upp ögonen för nätverksövervakning och när tiden kom önskade vi att skriva vårt examensarbete om just detta ämne. Då Nagios är en jätte i sammanhanget föreföll det sig naturligt att använda op5 Monitor som den ena halvan i vårt arbete, där den andra hälften föll på Sensu. Vi vill rikta ett stort tack till Marcus Wilhelmsson, som under arbetets gång givit oss värdefull handledning. ii Innehåll 1 Introduktion 1 1.1 Inledning . .1 1.2 Tidigare forskning . .1 1.3 Frågeställning och syfte . .2 1.4 Avgränsningar . .3 2 Bakgrund 4 2.1 Ordlista . .4 2.2 Nätverksövervakning . .4 2.2.1 Simple Network Management Protocol . .4 2.3 Sensu . .5 2.3.1 RabbitMQ . .5 2.3.2 Redis . .5 2.4 Op5 Monitor . .6 2.4.1 Ninja . .6 2.4.2 Merlin . .6 2.4.3 Naemon . .6 2.5 VMware ESXi . .7 2.6 Httperf . .7 3 Metod 8 3.1 Genomförande . .8 3.2 Testmiljö . .8 3.3 Testverktyg . .9 3.3.1 Httperf . .9 3.4 Experiment . .9 3.4.1 BIND9 . 10 3.4.2 Apache . 10 4 Resultat 12 4.1 BIND9 . 12 4.2 Apache . 13 5 Analys och slutsats 15 5.1 BIND . 15 5.2 Apache . 15 5.3 Slutsats . 15 5.4 Förslag till fortsatt forskning . 16 1 Introduktion Under detta kapitel presenteras ämnesområdet, tidigare forskning kring ämnet, problem- beskrivningen, undersökningens avgränsning samt motiveringen till valet av undersök- ningen. 1.1 Inledning Nätverksteknikernas främsta uppgift är underhållet av nätverken och se till att det fungerar optimalt och effektiv. Nätverken kan bestå av routrar, switchar, servrar, datorer, trådlösa enheter och applikationer. Det är många olika tekniker, enheter och kommunikationslän- kar som behöver samverka för ändamålet. Att övervaka nätverken och samla information för analys ger teknikern insikt i hur de olika delarna samverkar och hur hotbilden ser ut. Hoten kan vara allt från skadlig mjukvara till överbelastningar, men även fysiska faror som exempelvis en brand. [1] IT-systemen blir allt mer affärskritiska och företagen är väldigt beroende av ett välfun- gerande och tillgängligt system. IT-infrastrukturen är numera verksamheten, eftersom om vissa essentiella tjänster går ned kan det orsaka driftstopp som i sin tur kan leda till stora ekonomiska förluster och företaget förlorar sitt anseende. Ett exempel på det kan vara en anställd som inte kan komma åt sina filer på grund av att de inte är tillgängliga och or- saken till problemet är en överbelastad server. Den anställde är inte längre produktiv och kan inte utföra sina arbetsuppgifter. Med ett Network Monitoring System (NMS) kunde problemet fångats upp tidigare och den obalanserade lasten inom infrastrukturen korri- gerats och därmed undvikit ett potentiellt förödande driftstopp. Att övervaka nätverken möjliggör att personalen fokuserar på att utföra sina arbeten och möjliggör många ekono- miska fördelar för organisationen, därmed är nätverksövervakningen en kritisk funktion som inte bör underskattas. [1] Datorns snabba utveckling har lett till att dagens nätverk är allt större och mer komplexa, och det är därmed betydligt svårare att förutse beteendet. Dessa faktorer har lett till NMS- rollens betydelse inom större organisationer. [2] NMS är ett väldigt brett område och täcker allt från Ping-verktygen till mer komplexa lösningar och oftast är det öppna källkodslösningar som fungerar lämpligast tack vare möjligheten att modifiera mjukvaran och anpassa det till miljön, och det till ett mer till- fredsställande pris. Öppen källkodsvarianterna bygger på att samla informationen och an- vänder sig av SNMP-protokollet för att skicka värden till egenskrivna grafiska lösningar. [3]. Arbetet behandlar nätverksövervakningssytem som används för att övervaka de olika or- ganisationernas nätverksinfrastrukturer och kommer att vara fokuserat på Sensu och op5 Monitor. 1.2 Tidigare forskning Det finns ett tidigare stort antal forskningspublikationer i ämnet nätverksövervakning. I och med att Sensu är ett så pass nytt verktyg finns det däremot ingenting som är direkt inriktat på detta verktyg. 1 I artikeln Nagios Based Enchaned IT Management System beskriver författarna hur det inte finns någon fri och öppen lösning som täcker alla de områden och funktioner som krävs för att på ett bra sätt kunna övervaka ett nätverk. Författarna tar även upp hur de proprietära lösningarna är dyra och ofta även kräver en dyr utbildning för att kunna han- teras och administreras. Författarna pekar ut Nagios oförmåga till att sköta konfiguration av de underliggande tjänster på en maskin som en av dess största nackdelar. På grund av detta lägger författarna fram ett eget förslag på en Nagiosbaserad lösning och uppvisar hur denna skulle kunna täcka upp allt som tidigare påpekats att sakna i de fria lösningarna. [4] I uppsatsen En kartläggning av nätverksövervakningssystem, skriven år 2010 av Robin Rudeklint, där författaren lägger fram en kartläggning av en rad, vid tiden, tillgängliga övervakningssystem. Författaren har valt ett brett spann av verktyg, dels giganter så som Nagios och OpenNMS som används för att övervaka stora nätverk, samt verktyg som är lättare att använda och implementera, så som Munin. Arbetet fokuserar på tre stycken delfrågor, vilka tjänster systemen kan övervaka, hur hög prestanda respektive system har, samt hur hög användbarhet varje system har. [5] Året därpå gjordes ett fortsättningsarbete på Robin Rudeklints uppsats, då på B-nivå och av Peter Sandqvist, Övervakningsverktyg: En jämförelse mellan Zabbix och op5 Monitor. Här fokuserade författaren istället på två stycken verktyg och ställde dem mot varandra. Utöver de avgränsningar författaren gjorde var utförandet likvärdigt mot vad Rudeklint hade i sitt arbete. Däremot valde författaren att lägga till tjänsterna DNS och IMAP och därmed möjliggöra notifieringar via e-post. [6] 1.3 Frågeställning och syfte Arbetet ämnar undersöka hur två stycken olika nätverksövervakningsverktyg hanterar de rapporter som genereras i systemen. Verktygen som valdes är Sensu och op5 Monitor. Valet föll på dessa på grund av att Sensu är ett så pass nytt och intressant övervaknings- verktyg, som till skillnad från många andra övervakningssystem inte bygger på en Nagi- oskärna. I den andra ringhalvan placerades ett övervakningsverktyg baserat på Nagios, baserat på att Nagios länge varit en av de ledande öppen källkodslösningarna [7]. Op5 Monitor, som är baserat på Nagios, valdes för att den levereras som en komplett lösning, där endast minimala åtgärder krävs för att den ska vara färdig att köras. Således är frågeställningen: • Hanterar olika övervakningskärnor rapporter genererade av samma plugin på sam- ma sätt? Detta arbete kommer att behandla de skillnader som kan uppstå när olika nätverksöver- vakningsverktyg genererar rapporter om samma händelse. Arbetet syftar till att undersöka hur olika nätverksövervakningsmjukvaror hanterar samma sorts rapporter, där fokus lig- ger på om de under några omständigheter ger olika varning när avbrott i tjänster simuleras. Undersökningen kommer ge en djupare förståelse för hur de två mjukvarorna agerar när de får en rapport från sina agenter. 2 1.4 Avgränsningar Undersökningen tar inte hänsyn till eventuella prestandaoptimeringar som manuellt kan göras i Sensu eller op5 Monitor.
Recommended publications
  • Naemonbox Manual Documentation Release 0.0.7
    NaemonBox Manual Documentation Release 0.0.7 NaemonBox Team September 16, 2016 Contents 1 Introduction 3 1.1 Target audience..............................................3 1.2 Prerequisite................................................3 2 About Naemonbox 5 2.1 Project..................................................5 2.2 Features..................................................6 3 Installation Guide 7 3.1 System requirements...........................................7 3.2 Recommended system requirements...................................7 3.3 Client Operating Systems........................................7 3.4 Openvz VPS installation.........................................8 3.5 GNU/Linux Debian 7 (or later) Installation...............................8 3.6 Installing Naemonbox..........................................8 4 Getting Started 9 4.1 Step one.................................................9 4.2 Step two................................................. 10 4.3 Step three................................................. 10 4.4 Step four................................................. 10 5 Configuring Naemon 11 5.1 Introduction............................................... 11 5.2 Actions.................................................. 11 5.3 Hosts Definition............................................. 12 5.4 Services.................................................. 13 5.5 Commands................................................ 14 5.6 Time periods............................................... 15 5.7 Contacts................................................
    [Show full text]
  • Josh Malone Systems Administrator National Radio Astronomy Observatory Charlottesville, VA
    heck What the #%!@ is wrong ^ with my server?!? Josh Malone Systems Administrator National Radio Astronomy Observatory Charlottesville, VA 1 Agenda • Intro to Monitoring • Internet protocols 101 • • Nagios SMTP • IMAP • Install/Config • HTTP • Usage • Custom plugins • Packet sniffing for dummies • Intro to Troubleshooting • Tools • telnet, openssl • grep, sed • ps, lsof, netstat 2 MONITORING 3 Automated Monitoring Workflow 4 Monitoring Packages: Open Source • • Pandora FMS • Opsview Core • Naemon • • • • • • Captialware ServerStatus • Core • Sensu All Trademarks and Logos are property of their respective trademark or copyright holders and are used by permission or fair use for education. Neither the presenter nor the conference organizers are affiliated in any way with any companies mentioned here. 5 Monitoring Packages: Commercial • Nagios XI • Groundwork • PRTG network monitor • CopperEgg • WhatsUp Gold • PRTG network monitor • op5 (Naemon) All Trademarks and Logos are property of their respective trademark or copyright holders and are used by permission or fair use for education. Neither the presenter nor the conference organizers are affiliated in any way with any companies mentioned here. 6 Why Automatic Service Monitoring? • Spot small problems before they become big ones • Learn about outages before your users do • Checklist when restoring from a power outage • Gives you better problem reports than users • Problems you might never spot otherwise • Failed HDDs in RAIDs • Full /var partitions • Logs not rotating • System temperature rising 7 Why Automatic Service Monitoring? • Capacity planning • Performance data can generate graphs of utilization • RAM, Disk, etc. • Availability reports - CAUTION • Easy to generate -- even easier to generate wrong • Make sure your configurations actually catch problems • Will also include problems with Nagios itself :( • If you’re going to quote your availability numbers (SLAs, etc.) make sure you understand what you’re actually monitoring.
    [Show full text]
  • Market Impact Report Juniper Networks’ Appformix: Intent-Driven Cloud-Scale Infrastructure
    Market Impact Report Juniper Networks’ AppFormix: Intent-Driven Cloud-Scale Infrastructure EXECUTIVE SUMMARY Today, we live in a cloud-centric world with cloud-native applications and services reaching hundreds of millions of users globally via massive data centers located KEY FEATURES around the world. Until recently, the cloud has been the domain of a relatively • Autonomous, intent-driven small number of web-scale giants, cloud computing platforms, cloud-native infrastructure operation for businesses and global software companies. However, enterprises are now workload and resource migrating IT applications to hybrid clouds and network service providers are optimization reducing costs and increasing service agility by deploying cloud-scale platforms to • Smart agents streamline support Network Functions Virtualization (NFV). infrastructure monitoring by applying machine learning to Cloud-scale infrastructure presents significant operational challenges that arise metrics local to each node because of the massive scale, software-driven complexity and highly dynamic nature of applications deployed in run-time environments supported by the • Analytics modules monitor Docker, Kubernetes and Openstack frameworks, in which workloads and SLAs and correlate anomalies and events across the entire resources fluctuate constantly. infrastructure Traditional monitoring solutions rooted in legacy infrastructure are not well • Policy-driven controller suited to the real-time, full stack monitoring requirements of today’s cloud-scale assures pre-defined
    [Show full text]
  • Forcepoint Appliances Command Line Interface (CLI) Guide
    Forcepoint Appliances Command Line Interface (CLI) Guide V Series, X Series, & Virtual Appliances v8.4.x ©2018, Forcepoint All rights reserved. 10900-A Stonelake Blvd, Quarry Oaks 1, Suite 350, Austin TX 78759 Published 2018 Forcepoint and the FORCEPOINT logo are trademarks of Forcepoint. Raytheon is a registered trademark of Raytheon Company. All other trademarks used in this document are the property of their respective owners. This document may not, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine- readable form without prior consent in writing from Forcepoint. Every effort has been made to ensure the accuracy of this manual. However, Forcepoint makes no warranties with respect to this documentation and disclaims any implied warranties of merchantability and fitness for a particular purpose. Forcepoint shall not be liable for any error or for incidental or consequential damages in connection with the furnishing, performance, or use of this manual or the examples herein. The information in this documentation is subject to change without notice. Contents Topic 1 Forcepoint Appliances Command Line Interface . .1 Conventions . .1 Logon and authentication . .2 CLI modes and account privileges . .2 Basic account management . .3 Command syntax. .9 Help for CLI commands . .9 System configuration . .10 Time and date . .11 Host name and description . .14 User certificates. .15 Filestore definition and file save commands. .16 Appliance interface configuration. .18 Appliance vswitch configuration . .29 Content Gateway Decryption Port Mirroring (DPM) . .29 Static routes. .31 Appliance status . .35 SNMP monitoring (polling) . .35 SNMP traps and queries . .38 Module-specific commands .
    [Show full text]
  • Monitoring Im 21. Jahrhundert
    Monitoring im 21. Jahrhundert Sebastian ‘tokkee’ Harl <[email protected]> collectd core developer Grazer Linuxtage 2014 04. April 2014 Graz • Wer verwendet Performance-Daten seines Monitoring-Systems? • Wer basiert (den Großteil) sein(es) Monitorings auf Performance-Daten? • Wer kennt collectd? • Wer kennt Riemann-Monitoring? Uberblick¨ • Wer verwendet Nagios/Icinga/Naemon/OpenNMS/etc.? c 2014 Sebastian ‘tokkee’ Harl Monitoring im 21. Jahrhundert – Folie 2 • Wer basiert (den Großteil) sein(es) Monitorings auf Performance-Daten? • Wer kennt collectd? • Wer kennt Riemann-Monitoring? Uberblick¨ • Wer verwendet Nagios/Icinga/Naemon/OpenNMS/etc.? • Wer verwendet Performance-Daten seines Monitoring-Systems? c 2014 Sebastian ‘tokkee’ Harl Monitoring im 21. Jahrhundert – Folie 2 • Wer kennt collectd? • Wer kennt Riemann-Monitoring? Uberblick¨ • Wer verwendet Nagios/Icinga/Naemon/OpenNMS/etc.? • Wer verwendet Performance-Daten seines Monitoring-Systems? • Wer basiert (den Großteil) sein(es) Monitorings auf Performance-Daten? c 2014 Sebastian ‘tokkee’ Harl Monitoring im 21. Jahrhundert – Folie 2 • Wer kennt Riemann-Monitoring? Uberblick¨ • Wer verwendet Nagios/Icinga/Naemon/OpenNMS/etc.? • Wer verwendet Performance-Daten seines Monitoring-Systems? • Wer basiert (den Großteil) sein(es) Monitorings auf Performance-Daten? • Wer kennt collectd? c 2014 Sebastian ‘tokkee’ Harl Monitoring im 21. Jahrhundert – Folie 2 Uberblick¨ • Wer verwendet Nagios/Icinga/Naemon/OpenNMS/etc.? • Wer verwendet Performance-Daten seines Monitoring-Systems? • Wer basiert (den Großteil) sein(es) Monitorings auf Performance-Daten? • Wer kennt collectd? • Wer kennt Riemann-Monitoring? c 2014 Sebastian ‘tokkee’ Harl Monitoring im 21. Jahrhundert – Folie 2 Uberblick¨ Warum Monitoring auf Performance-Daten basieren? Umdenken: Was passiert?“ statt Wie ist der Status?“ ” ” • Mehr Information als f OK, WARNING, CRIT g • Push statt Poll → besser skalierbar • Einfache(re) Aggregierung → z.B.
    [Show full text]
  • Automated System Monitoring
    Automated System Monitoring Josh Malone Systems Administrator [email protected] National Radio Astronomy Observatory Charlottesville, VA https://blogs.nrao.edu/jmalone 2 One night, about 8 or 9 years ago, the chiller in our DC failed. Co-worker arrive in the morning to find room was 90F ambient. Quickly set up fans to vent the room. Checked servers - found that main web server had lost both disks in its OS RAID mirror. (15k disks, ran hot) Main page was being served from memory, but the OS was freaking out. We had minimal monitoring scripts. No environment monitoring. No disk health checks. Failure caught us completely by surprise. We decided that we weren’t going to let this happen ever again. Over the next year or so we implemented 2 independent monitoring systems - one for servers/ services and one for environmentals. Set up each system to also monitor the other. WHAT IS AUTOMATED MONITORING? 7 Some sort of dedicated, automatic instrumentation to check services and/or servers Detect and report service problems, server hardware issues Usually provides a central “dashboard” to track problems Can be distributed; but still under control of a central daemon * Diferentiates it from “a bunch of scripts” used to check on things; that doesn’t have the ability to determine cause or eliminate false alarms. Automated Monitoring Workflow 8 Most packages implement this type of workflow Not all packages provide event handlers ack’ing page is important - let’s other admins know that someone is working on the problem so they don’t step on each other’s toes Monitoring Packages: Open Source • • Pandora FMS • Opsview Core • Naemon • • • • • • Captialware ServerStatus • Core • Sensu All Trademarks and Logos are property of their respective trademark or copyright holders and are used by permission or fair use for education.
    [Show full text]
  • Mysecureshell Documentation Release 1.33 Pierre Mavro
    MySecureShell Documentation Release 1.33 Pierre Mavro & Sebastien Tardif November 28, 2016 Contents 1 Introduction 3 2 Quick Try 5 3 Installation 13 4 Configuration 21 5 Usages 61 6 Frequently Asked Questions 67 7 Contribute 71 8 Third Party and Others 75 i ii MySecureShell Documentation, Release 1.33 Contents 1 MySecureShell Documentation, Release 1.33 2 Contents CHAPTER 1 Introduction 1.1 What is MySecureShell? MySecureShell is a solution which has been made to bring more features to sftp/scp protocol given by OpenSSH. By default, OpenSSH brings a lot of liberty to connected users which imply to thrust in your users. The goal of MySecureShell is to offer the power and security of OpenSSH, with enhanced features (like ACL) to restrict connected users. MySecureShell was created because of the lack of file transfer features in OpenSSH. OpenSSH was not designed as a file transfer solution, that’s why we made MySecureShell. MySecureShell is not a patch for OpenSSH, it’s a shell for users. It has the advantage to: • Avoid including security holes in OpenSSH • No dependency on against an OpenSSH version • No OpenSSH recompilation is required So MySecureShell remains easy to install, secure and easy to configure. 1.2 Why SFTP and not FTP? If you’re wondering why you should take MySecureShell as an SFTP server instead of a classical FTP, there are several reasons: 1. You do not have to open some dedicated firewall ports for file transfers 2. You are using one of the most used and secure protocol (SSH) 3. You do not have to manage SSL certificates to guaranty the security 4.
    [Show full text]
  • Using XMPP for System Monitoring and Administration
    Die approbierte Originalversion dieser Diplom-/ Masterarbeit ist in der Hauptbibliothek der Tech- nischen Universität Wien aufgestellt und zugänglich. http://www.ub.tuwien.ac.at The approved original version of this diploma or master thesis is available at the main library of the Vienna University of Technology. http://www.ub.tuwien.ac.at/eng Using XMPP for System Monitoring and Administration DIPLOMARBEIT zur Erlangung des akademischen Grades Mag.rer.soc.oec. im Rahmen des Studiums Informatikmanagement eingereicht von Adi Kriegisch Matrikelnummer 9625495 an der Fakultät für Informatik der Technischen Universität Wien Betreuung: Univ.-Prof. Dipl.-Ing. Dr. Werner Purgathofer Wien, 15.11.2015 (Unterschrift Verfasser) (Unterschrift Betreuung) Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Using XMPP for System Monitoring and Administration MASTER’S THESIS submitted in partial fulfillment of the requirements for the degree of Mag.rer.soc.oec. in Informatics Management by Adi Kriegisch Registration Number 9625495 to the Faculty of Informatics at the Vienna University of Technology Advisor: Univ.-Prof. Dipl.-Ing. Dr. Werner Purgathofer Vienna, 15.11.2015 (Signature of Author) (Signature of Advisor) Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Erklärung zur Verfassung der Arbeit Adi Kriegisch Leystrasse 23/11/27, 1200 Wien Hiermit erkläre ich, dass ich diese Arbeit selbständig verfasst habe, dass ich die verwende- ten Quellen und Hilfsmittel vollständig angegeben habe und dass ich die Stellen der Arbeit - einschließlich Tabellen, Karten und Abbildungen -, die anderen Werken oder dem Internet im Wortlaut oder dem Sinn nach entnommen sind, auf jeden Fall unter Angabe der Quelle als Ent- lehnung kenntlich gemacht habe.
    [Show full text]
  • Mysecureshell Documentation Release 1.33
    MySecureShell Documentation Release 1.33 Pierre Mavro & Sebastien Tardif Dec 10, 2018 Contents 1 Introduction 3 2 Quick Try 5 3 Installation 11 4 Configuration 19 5 Usages 65 6 Frequently Asked Questions 71 7 Contribute 75 8 Third Party and Others 81 i ii MySecureShell Documentation, Release 1.33 Contents 1 MySecureShell Documentation, Release 1.33 2 Contents CHAPTER 1 Introduction 1.1 What is MySecureShell? MySecureShell is a solution which has been made to bring more features to sftp/scp protocol given by OpenSSH. By default, OpenSSH brings a lot of liberty to connected users which imply to trust in your users. The goal of MySecureShell is to offer the power and security of OpenSSH, with enhanced features (like ACL) to restrict connected users. MySecureShell was created because of the lack of file transfer features in OpenSSH. OpenSSH was not designed as a file transfer solution, that’s why we made MySecureShell. MySecureShell is not a patch for OpenSSH, it’s a shell for users. It has the advantage to: • Avoid including security holes in OpenSSH • No dependency on against an OpenSSH version • No OpenSSH recompilation is required So MySecureShell remains easy to install, secure and easy to configure. 1.2 Why SFTP and not FTP? If you’re wondering why you should take MySecureShell as an SFTP server instead of a classical FTP, there are several reasons: 1. You do not have to open some dedicated firewall ports for file transfers 2. You are using one of the most used and secure protocol (SSH) 3. You do not have to manage SSL certificates to guaranty the security 4.
    [Show full text]
  • Graphite Documentation Release 1.2.0
    Graphite Documentation Release 1.2.0 Chris Davis Apr 19, 2021 Contents 1 Overview 1 2 FAQ 3 3 Installing Graphite 7 4 The Carbon Daemons 35 5 Feeding In Your Data 39 6 Getting Your Data Into Graphite 41 7 Administering Carbon 43 8 Administering The Webapp 45 9 Using The Composer 47 10 The Render URL API 49 11 The Metrics API 71 12 Functions 73 13 The Dashboard User Interface 105 14 The Whisper Database 113 15 The Ceres Database 117 16 Alternative storage finders 121 17 Graphite Events 125 18 Graphite Tag Support 129 19 Graphite Terminology 137 20 Tools That Work With Graphite 139 i 21 Working on Graphite-web 145 22 Client APIs 147 23 Who is using Graphite? 149 24 Release Notes 151 25 Indices and tables 207 Python Module Index 209 Index 211 ii CHAPTER 1 Overview 1.1 What Graphite is and is not Graphite does two things: 1. Store numeric time-series data 2. Render graphs of this data on demand What Graphite does not do is collect data for you, however there are some tools out there that know how to send data to graphite. Even though it often requires a little code, sending data to Graphite is very simple. 1.2 About the project Graphite is an enterprise-scale monitoring tool that runs well on cheap hardware. It was originally designed and written by Chris Davis at Orbitz in 2006 as side project that ultimately grew to be a foundational monitoring tool. In 2008, Orbitz allowed Graphite to be released under the open source Apache 2.0 license.
    [Show full text]
  • Cyberx Documentation Release Latest
    CyberX Documentation Release latest Aug 26, 2021 Contents 1 About 1 2 Introduction 3 2.1 Elasticsearch...............................................4 2.2 Kibana..................................................4 2.3 Logstash.................................................4 2.4 ELK...................................................5 3 Data source and application management7 3.1 Data source................................................7 3.2 System services.............................................7 3.3 First configuration steps.........................................8 3.4 First login................................................. 14 3.5 Index selection.............................................. 16 3.6 Changing default users for services................................... 17 3.7 Custom installation the CyberX..................................... 18 3.8 Plugins management in the Elasticsearch................................ 22 3.9 ROOTless management......................................... 23 3.10 CyberX Elasticsearch encryption.................................... 24 3.11 Transport layer encryption........................................ 26 3.12 HTTP layer encryption.......................................... 26 3.13 Browser layer encryption......................................... 28 3.14 Index rollover............................................... 29 3.15 Default home page............................................ 29 4 Discovery 31 4.1 Time settings and refresh......................................... 31 4.2 Fields..................................................
    [Show full text]
  • Appliance CLI Guide
    TRITON® Appliances Command Line Interface (CLI) Guide V-Series, X-Series, & Virtual Appliances v8.3.x ©1996–2016, Forcepoint LLC 10900-A Stonelake Blvd, Quarry Oaks 1, Suite 350, Austin, TX 78759, USA All rights reserved. Published 2017 Revision C Printed in the United States and Ireland R170417830 The products and/or methods of use described in this document are covered by U.S. Patent Numbers 5,983,270; 6,606,659; 6,947,985; 7,185,015; 7,194,464 and RE40,187 and other patents pending. This document may not, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine- readable form without prior consent in writing from Forcepoint LLC. Every effort has been made to ensure the accuracy of this manual. However, Forcepoint LLC, makes no warranties with respect to this documentation and disclaims any implied warranties of merchantability and fitness for a particular purpose. Forcepoint LLC shall not be liable for any error or for incidental or consequential damages in connection with the furnishing, performance, or use of this manual or the examples herein. The information in this documentation is subject to change without notice. Trademarks Forcepoint is a registered trademark and TRITON is a trademark of Forcepoint LLC, in the United States and certain international markets. Forcepoint has numerous other unregistered trademarks in the United States and internationally. All other trademarks are the property of their respective owners. Microsoft, Windows, Windows NT, Windows Server, and Active Directory are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
    [Show full text]