Open-AudIT

Anyone else seeing this? I supply an SNMP community string either through configuring the default string or specifically stating in the discovery form, and the string is not used during discovery--in fact, the debug shows the SNMP status as FALSE.

[code]LOG - Apr 14 10:10:08 oae.somedomain.com 15709 C:discovery F:discover_subnet U:NMIS Discovery submitted for 10.0.0.1.

Command: /usr/local/open-audit/other/discover_subnet.sh subnet=10.0.0.1 url=http://10.0.0.11/open-audit/index.php/discovery/process_subnet submit_online=n echo_output=y create_file=n debugging=0 subnet_timestamp="2014-04-14 10:10:08"

Return Code: 0 (0 indicates success).
Output of the command (as an array):
<devices>
<device>
<subnet>10.0.0.1</subnet>
<man_ip_address>10.0.0.1</man_ip_address>
<mac_address></mac_address>
<manufacturer></manufacturer>
<type>unknown</type>
<os_name></os_name>
<description>
<![CDATA[]]></description>
<org_id></org_id>
<snmp_status>false</snmp_status>
<ssh_status>true</ssh_status>
<wmi_status>false</wmi_status>
<p80_status>true</p80_status>
<p443_status>false</p443_status>
<tel_status>true</tel_status>
<subnet_timestamp>2014-04-14 10:10:08</subnet_timestamp>
</device>
</devices>
DEBUG - Starting process_subnet.
DEBUG - Back to input page
DEBUG - Front Page
LOG - Apr 14 10:10:08 oae.somedomain.com 15709 C:discovery F:process_subnet Start processing 10.0.0.1.
DEBUG - find system_key: 708
DEBUG - SNMP Status: false
DEBUG - WMI Status: false
DEBUG - SSH Status: true
LOG - Apr 14 10:10:08 oae.somedomain.com 15709 C:discovery F:process_subnet WMI Status: false 10.0.0.1.
LOG - Apr 14 10:10:08 oae.somedomain.com 15709 C:discovery F:process_subnet SNMP Status: false 10.0.0.1.
LOG - Apr 14 10:10:08 oae.somedomain.com 15709 C:discovery F:process_subnet SSH Status: true 10.0.0.1.
DEBUG - Nmap update for 708
LOG - Apr 14 10:10:08 oae.somedomain.com 15709 C:discovery F:process_subnet Nmap update for 10.0.0.1 (System ID 708).
DEBUG - System ID 708
LOG - Apr 14 10:10:09 oae.somedomain.com 15709 C:discovery F:process_subnet No credentials supplied for SSH audit for 10.0.0.1 (System ID 708).
Finish processing 10.0.0.1
LOG - Apr 14 10:10:09 oae.somedomain.com 15709 C:discovery F:process_subnet Completed processing 10.0.0.1.[/code]

_________________
~R0cketman

Server Info:
OS : CentOS 6.x
Auditing: 1366 machines (and counting)
LDAP: OpenLDAP

discover_subnet.sh does this to determine snmp_status:
[code] # test for SNMP
snmp_status="false"
command=$(nmap -n -sU -p161 "$host" 2>/dev/null | grep "161/udp open")
if [[ "$command" == *"161/udp open"* ]]; then
snmp_status="true"
fi[/code]
So what does the following output?
[code]nmap -n -sU -p161 "10.0.0.1"[/code]

It shows as open:

[code][root@oae ~]# nmap -n -sU -p161 "10.0.0.1"

Starting Nmap 5.51 ( http://nmap.org ) at 2014-04-14 11:04 MDT
Nmap scan report for 10.0.0.1
Host is up (0.00074s latency).
PORT STATE SERVICE
161/udp open snmp

Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds[/code]

_________________
~R0cketman

Server Info:
OS : CentOS 6.x
Auditing: 1366 machines (and counting)
LDAP: OpenLDAP

From the OAE guest, I can even run an snmp walk to/from this device as well...

[code][root@oae ~]# snmpwalk -v2c -cattask 10.0.0.1 | head
SNMPv2-MIB::sysDescr.0 = STRING: Brocade Communications Systems, Inc. Stacking System FCX648S-PREM, IronWare Version 07.2.02eT7f3 Compiled on Oct 12 2011 at 15:18:01 labeled as FCXR07202f
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.1991.1.3.48.2.4
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (2740159404) 317 days, 3:33:14.04
SNMPv2-MIB::sysContact.0 = STRING:
SNMPv2-MIB::sysName.0 = STRING: core
SNMPv2-MIB::sysLocation.0 = STRING: AtTask Corporate Office
SNMPv2-MIB::sysServices.0 = INTEGER: 6
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORID.1 = OID: SNMPv2-SMI::zeroDotZero
SNMPv2-MIB::sysORDescr.1 = STRING:[/code]

_________________
~R0cketman

Server Info:
OS : CentOS 6.x
Auditing: 1366 machines (and counting)
LDAP: OpenLDAP

If this command requires root maybe Apache isn't seeing the same output?

Is the command actually being run as the apache user? It looks to me like the same return:

[quote]bash-4.1$ snmpwalk -v2c -cattask 10.0.0.1 | head
SNMPv2-MIB::sysDescr.0 = STRING: Brocade Communications Systems, Inc. Stacking System FCX648S-PREM, IronWare Version 07.2.02eT7f3 Compiled on Oct 12 2011 at 15:18:01 labeled as FCXR07202e
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.1991.1.3.48.2.4
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (2746969004) 317 days, 22:28:10.04
SNMPv2-MIB::sysContact.0 = STRING:
SNMPv2-MIB::sysName.0 = STRING: core
SNMPv2-MIB::sysLocation.0 = STRING: AtTask Corporate Office
SNMPv2-MIB::sysServices.0 = INTEGER: 6
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORID.1 = OID: SNMPv2-SMI::zeroDotZero
SNMPv2-MIB::sysORDescr.1 = STRING:

_________________
~R0cketman

Server Info:
OS : CentOS 6.x
Auditing: 1366 machines (and counting)
LDAP: OpenLDAP

You need to run the discovery script as root from a cron or something.

It looks like when you run the discovery from the web server the Apache process runs the discovery script which tries to see if the target is running SNMP but fails because NMAP doesn't have privileges for the type of scan it needs. The script then reports back to the server that a particular target does not support SNMP and thus the server does not probe SNMP when adding the target to the database.

The trick you may be missing is that the script does not use any SNMP information at all. It only reports back to the server if the target has something listening on the SNMP port. This is the snmp_status true/false you see in the log. If the script returns snmp_status= true then the server will probe for SNMP info using the community string when adding the system to the database.

Ultimately, running a cron job on the collector is really not a problem--we were planning on doing it anyway. However, I can't imagine I'm the only person running into this problem. I'm using the virtual appliance provided by Opmantek. Can you duplicate the issue?

Running the discovery script manually appears to work:

[code][root@oae other]# /usr/local/open-audit/other/discover_subnet.sh subnet=10.0.0.1 url=http://10.0.0.11/open-audit/index.php/discovery/process_subnet submit_online=y echo_output=y create_file=n debugging=0
Nmap scan report for 10.0.0.1
<devices>
<device>
<subnet>10.0.0.1</subnet>
<man_ip_address>10.0.0.1</man_ip_address>
<mac_address></mac_address>
<manufacturer></manufacturer>
<type>unknown</type>
<os_name></os_name>
<description><![CDATA[]]></description>
<org_id></org_id>
<snmp_status>true</snmp_status>
<ssh_status>true</ssh_status>
<wmi_status>false</wmi_status>
<p80_status>true</p80_status>
<p443_status>false</p443_status>
<tel_status>false</tel_status>
<subnet_timestamp></subnet_timestamp>
</device>
</devices>

<devices><device><subnet>10.0.0.1</subnet><subnet_timestamp></subnet_timestamp><complete>y</complete></device></devices>[/code]

_________________
~R0cketman

Server Info:
OS : CentOS 6.x
Auditing: 1366 machines (and counting)
LDAP: OpenLDAP

We run Windows here but I did try the nmap command on a Linux box and saw the root required message and guessed that is what is happening.

It would be up to the OpenAudit developers how to deal with this. I think the only way would be some sore of capabilities set up that allows non-root users the minimal capabilities necessary (raw packet access, etc.) I'm not a fan of the web scanning stuff and think it's easier just to set up cron jobs for full functionality.

[quote="jpa"]It would be up to the OpenAudit developers how to deal with this. I think the only way would be some sore of capabilities set up that allows non-root users the minimal capabilities necessary (raw packet access, etc.) I'm not a fan of the web scanning stuff and think it's easier just to set up cron jobs for full functionality.

_________________
~R0cketman

Server Info:
OS : CentOS 6.x
Auditing: 1366 machines (and counting)
LDAP: OpenLDAP

I am doing a horrible job of explaining how this works but....

The OpenAudit server does the SNMP scanning when a system is added to the database by the script. There are no scripts that use SNMP. So the discover subnet script scans the subnet and finds a system at 10.0.0.1, checks to see if something is listening on the SNMP port and posts back to the server that it found a system at 10.0.0.1 that seems to be listening to SNMP. The server accepts the post, sees that the system might have SNMP enabled and does it's own scan of 10.0.0.1 using the default SNMP community string, or the system specific one if the system is already in the database and has a custom community string defined.

Ha! No worries. What you've said clarifies things.

I'm running a scan now against an entire Class C subnet and it's been running now for almost 2 hours. Does that seem slow? The command I used was:
[code]/usr/local/open-audit/other/discover_subnet.sh subnet=10.0.0.0/24 url=http://10.0.0.11/open-audit/index.php/discovery/process_subnet submit_online=y echo_output=y create_file=n debugging=0[/code]

_________________
~R0cketman

Server Info:
OS : CentOS 6.x
Auditing: 1366 machines (and counting)
LDAP: OpenLDAP

I would set debugging=1 to see where it's going slow.

Quick post because I'm away with very limited internet. Install guide states to use the sticky bit on nmap. Look it up. Enables apache user to run nmap as if it's root.

_________________
Support and Development hours available from [url=https://opmantek.com]Opmantek[/url].
Please consider a purchase to help make Open-AudIT better for everyone.

[quote="Mark"]Quick post because I'm away with very limited internet. Install guide states to use the sticky bit on nmap. Look it up. Enables apache user to run nmap as if it's root.

_________________
~R0cketman

Server Info:
OS : CentOS 6.x
Auditing: 1366 machines (and counting)
LDAP: OpenLDAP