Ad Widget

Collapse

SSH Port Discovery

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • innovot
    Junior Member
    • Nov 2013
    • 15

    #1

    SSH Port Discovery

    Hello all:

    we are getting further with our Zabbix understanding but not sure how to resolve the following. We have SSH listening on both standard TCP/22 and none standard TCP ports dependent on the type of system/location.

    If we create net.tcp.service[] items for each of them, within a template, then they are all created when a host is discovered and the template is assigned. One boolean would be '1' and the rest would be '0'. Have tried with a discovery rule for each item, but then that is expecting item prototypes to be available, when in-fact this is the item.

    What we would like is that each host only has the correct SSH item for the SSH port assigned to it so we can trigger when it is UP/DOWN.

    How may we achieve that please ? Thank you.
    Last edited by innovot; 03-06-2015, 16:20.
  • Parasin
    Member
    Zabbix Certified Specialist
    • Dec 2014
    • 53

    #2
    If you are using Zabbix version 2.4.4 or greater, there is an SSH template that comes included with your installation. You can simply apply this template to the desired host and it will automatically setup the item to monitor port 22.

    I would then validate that the trigger associated with this item is properly set for your concerns; by default the trigger is an average severity, but you may wish to create a second trigger that is of greater severity if the port remains in a "not listening" state for greater than 3 - 5 minutes.

    This is the type of setup I have on my monitoring network.

    Comment

    • innovot
      Junior Member
      • Nov 2013
      • 15

      #3
      Hello Parasin:

      Appreciate your reply

      As I mentioned in the thread "standard TCP/22 and none standard TCP ports" we have to be able to discover multiple SSH port definitions.

      Any thoughts ?

      ps. typo in the main thread so will update

      Comment

      • Parasin
        Member
        Zabbix Certified Specialist
        • Dec 2014
        • 53

        #4
        You could create a discovery rule, similar to the ones that come out-of-box for things like Network interfaces, then apply it to the relevant hosts.

        Depending on the system, this command would be different; b/w linux hosts and windows hosts.

        I don't know the exact format of such a discovery rule, but that would be my approach.

        The Zabbix User manual has a section about it here

        Comment

        • innovot
          Junior Member
          • Nov 2013
          • 15

          #5
          That is the point of the thread, and what I have done, that a discovery rule feeds the prototypes in a template IIUC. So, if you discover say TCP/922 (alternate SSH port) it does not add it but then looks at what prototypes it has. If you create a general item then it will either set the boolean as zero or one dependant on whether it finds the TCP service. What am trying to achieve is that it finds and records TCP services which are listening, and not just record their listening state.

          Comment

          • Parasin
            Member
            Zabbix Certified Specialist
            • Dec 2014
            • 53

            #6
            Sorry for the misunderstanding


            However, I'm not sure if you had seen this script that Zabbix made to do, seemingly with some modification, what you need.

            Join the friendly and open Zabbix community on our forums and social media platforms.

            Comment

            • innovot
              Junior Member
              • Nov 2013
              • 15

              #7
              Hey no problem at all and appreciate your help

              Though we know the ports and do not wish to perform a 'scatter gun' approach to finding what we wish to monitor. We are able to do this with OpenNMS, which has its own idiosyncrasies, but love the flexibility of Zabbix.

              Will dig a little deeper. Again, thank you.

              Comment

              • zabanist
                Junior Member
                • Jun 2015
                • 16

                #8
                If it were me...

                There are a few ways I can think of doing it, depending on your access to the host... All use an External Check and Discovery Rule.

                If you have _NO_ access to the host (re: it's not running zabbix_agent), I'd create a discover rule which, yeah, uses an External Check.

                1) Pull host ips from the template that houses the discovery rules via zabbix api.
                2) Make a script that is called by cron to run an nmap -sV against each IP, outputting to individual files and XML. We do this because running nmap can take longer than 30 seconds, and your discovery rules will fail.
                3) Have an External Check script that parses the file for the appropriate IP, finds "ssh" running and then spits out the appropriate json response for your discovery rule.

                Here, you basically have to do this as your NMAP can take a long time to run, and 30 seconds is the max execution time.

                If you have access to the host via zabbix agent, make a discovery rule that utilizes zabbix agent. Setup a UserParamater that greps Port out of /etc/ssh/sshd_config. Add sudo rights for zabbix as appropriate. You could get the same data out of a netstat, but would require elevated rights to get sshd process name:

                sudo netstat -tulpn sshd | grep sshd
                tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 487/sshd
                tcp6 0 0 :::22 :::* LISTEN 487/sshd


                Originally posted by innovot
                Hey no problem at all and appreciate your help

                Though we know the ports and do not wish to perform a 'scatter gun' approach to finding what we wish to monitor. We are able to do this with OpenNMS, which has its own idiosyncrasies, but love the flexibility of Zabbix.

                Will dig a little deeper. Again, thank you.

                Comment

                Working...