I'm using snmp to go through a switch and get some info.
i use:
for searching Names :
Oid: iso.3.6.1.2.1.2.2.1.2
for searching a Single Vlan:
Oid: iso.3.6.1.4.1.9.9.68.1.2.2.1.2
What i want is for multiple Vlans what is the oid.
Does anyone knows?
The Cisco OID referred to in your post will give you the VLAN-id associated on each interface on the device. For example snmpwalk yields following (so you can get all VLANs associated with the interfaces on the device)
# snmpwalk -v2c -c public 172.23.219.36 1.3.6.1.4.1.9.9.68.1.2.2.1.2
..
SNMPv2-SMI::enterprises.9.9.68.1.2.2.1.2.436217344 = INTEGER: 101
Taking ifIndex from VLAN 101 one can find the associated interface
# snmpwalk -v2c -c public 172.23.219.36 1.3.6.1.2.1.2.2.1.2.436217344
..
IF-MIB::ifDescr.436217344 = STRING: Ethernet1/20
However if you are only interested in getting VLANs on the system you may want to consider looking at Q-BRIDGE-MIB (https://www.rfc-editor.org/rfc/rfc4363). Any of these OIDs will get all the VLANs on the system whether associated with an interface or not via Q-BRIDGE MIB (dot1qFdbTable)
snmpwalk -v2c -c public 172.23.219.36 1.3.6.1.2.1.17.7.1.2
SNMPv2-SMI::mib-2.17.7.1.2.1.1.2.1 = Counter32: 0
SNMPv2-SMI::mib-2.17.7.1.2.1.1.2.101 = Counter32: 0
SNMPv2-SMI::mib-2.17.7.1.2.1.1.2.201 = Counter32: 0
SNMPv2-SMI::mib-2.17.7.1.2.1.1.2.301 = Counter32: 0
Related
I am trying to develop a Traps receiver for SNMPv1 and SNMPv2c with OpenVPN. I have used the PURESNMP and PYSNMP libraries with Python. PYSNMP can receive SNMPv1 and SNMPv2c Traps, while PURESNMP only works with SNMPv2c. My project works as follows: the OpenVPN file is loaded into a Router so that it can connect, and several devices are connected behind the Router to be monitored by SNMP.
OpenVPN Router IP: 10.8.0.18,
LAN Router IP: 192.168.2.1
Team A IP: 192.168.2.3
OpenVPN Server IP: 10.8.0.1
Client2 IP: 10.8.0.10
I manage to receive the Traps, but I cannot distinguish where the information comes from, if in the LAN behind the Router how is it possible to identify from which the alarm came. This is the Team's SNMPv1 Trap response:
Agent is listening SNMP Trap on 10.8.0.10 , Port : 162
-------------------------------------------------- ------------------------
SourceIP: ('10.8.0.18', 49181)
----------------------Received new Trap message------------------------ ---
1.3.6.1.2.1.1.3.0 = 910296
1.3.6.1.6.3.1.1.4.1.0 = 1.3.6.1.4.1.1918.2.13.0.700
1.3.6.1.6.3.18.1.3.0 = 10.168.2.3
1.3.6.1.6.3.18.1.4.0 = public
1.3.6.1.6.3.1.1.4.3.0 = 1.3.6.1.4.1.1918.2.13
1.3.6.1.4.1.1918.2.13.10.111.12.0 = 1
1.3.6.1.4.1.1918.2.13.10.111.10.0 = 3
1.3.6.1.4.1.1918.2.13.10.111.11.0 = Digital Input 1
1.3.6.1.4.1.1918.2.13.10.111.14.0 = 4
1.3.6.1.4.1.1918.2.13.10.10.40.0 = System Location
1.3.6.1.4.1.1918.2.13.10.10.50.0 = SiteName
1.3.6.1.4.1.1918.2.13.10.10.60.0 = SiteAddress
1.3.6.1.4.1.1918.2.13.10.111.13.0 = Input D01 Disconnected.
In “IP Source”, a function is used to obtain the source IP, but it shows me the IP of the Router and not of the device that is alarmed. If you look at the third line of the traps, it indicates a source IP that the SNMPV1 protocol itself has incorporated:
1.3.6.1.6.3.18.1.3.0 = 10.168.2.3
But it is not from the device or from the Router, it is as if the Router's network segment had been mixed with the device's hots segment. This is the response when receiving SNMPv2c Traps:
Agent is listening SNMP Trap on 10.8.0.10 , Port : 162
-------------------------------------------------- --------------------------
SourceIP: ('10.8.0.18', 49180)
----------------------Received new Trap message------------------------ -----
1.3.6.1.2.1.1.3.0 = 896022
1.3.6.1.6.3.1.1.4.1.0 = 1.3.6.1.4.1.1918.2.13.20.700
1.3.6.1.4.1.1918.2.13.10.111.12.0 = 1
1.3.6.1.4.1.1918.2.13.10.111.10.0 = 3
1.3.6.1.4.1.1918.2.13.10.111.11.0 = Digital Input 1
1.3.6.1.4.1.1918.2.13.10.111.14.0 = 5
1.3.6.1.4.1.1918.2.13.10.10.40.0 = System Location
1.3.6.1.4.1.1918.2.13.10.10.50.0 = SiteName
1.3.6.1.4.1.1918.2.13.10.10.60.0 = SiteAddress
1.3.6.1.4.1.1918.2.13.10.111.13.0 = Input D01 Disconnected.
In Trap SNMPv2c, you can only get the source IP but it shows the IP of the Router, but it does not work for me since there are several devices behind the Router, and there is no way to identify which one the alarm came from. I am doing the tests from an OpenVPN client, and not yet from the server, it will be uploaded to the server once it works well.
Could you help me because that can happen. Since I thought it was a problem with the libraries and I used another trap receiving software and the answer was the same.
This is the Server configuration:
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh none
server 10.8.0.0 255.255.0.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
client-config-dir ccd
route 192.168.0.0 255.255.0.0
keepalive 10 120
tls-crypt ta.key
cipher AES-256-GCM
auth SHA256
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 3
explicit-exit-notify 1
This is the client configuration:
client
dev tun
proto udp
remote x.x.x.x 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-GCM
auth SHA256
key-direction 1
verb 3
<ca>
</ca>
<cert>
</cert>
<key>
</key>
<tls-crypt>
#
#
</tls-crypt>
Firewall configuration on the server:
# START OPENVPN RULES
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]
# Allow traffic from OpenVPN client to eth0 (change to the interface you discovered!)
-A POSTROUTING -s 10.8.0.0/8 -o eth0 -j MASQUERADE
COMMIT
# END OPENVPN RULES
This is the code to Receive SNMPv1 and SNMPv2c Traps:
from pysnmp.carrier.asynsock.dispatch import AsynsockDispatcher
#python snmp trap receiver
from pysnmp.entity import engine, config
from pysnmp.carrier.asyncore.dgram import udp
from pysnmp.entity.rfc3413 import ntfrcv
from pysnmp.proto import api
datosnmp = []
snmpEngine = engine.SnmpEngine()
TrapAgentAddress='10.8.0.10' #Trap listerner address
Port=162 #trap listerner port
print("Agent is listening SNMP Trap on "+TrapAgentAddress+" , Port : " +str(Port))
print('--------------------------------------------------------------------------')
config.addTransport(snmpEngine, udp.domainName + (1,), udp.UdpTransport().openServerMode((TrapAgentAddress, Port)))
#Configure community here
config.addV1System(snmpEngine, 'my-area', 'public')
def cbFun(snmpEngine, stateReference, contextEngineId, contextName,varBinds, cbCtx):
global datosnmp
#while wholeMsg:
execContext = snmpEngine.observer.getExecutionContext('rfc3412.receiveMessage:request')
print("IP Source: ", execContext['transportAddress']) #IP Origen del Trap
#print('snmpEngine : {0}'.format(snmpEngine))
#print('stateReference : {0}'.format(stateReference))
#print('contextEngineId : {0}'.format(contextEngineId))
#print('contextName : {0}'.format(contextName))
#print('cbCtx : {0}'.format(cbCtx))
print('{0}Received new Trap message{0}\n'.format('-' * 40))
for oid, val in varBinds:
datosnmp.append(val.prettyPrint())
print('%s = %s' % (oid.prettyPrint(), val.prettyPrint())) #name = OID, val = contenido de la OID
#print(datosnmp)
ntfrcv.NotificationReceiver(snmpEngine, cbFun)
snmpEngine.transportDispatcher.jobStarted(1)
try:
snmpEngine.transportDispatcher.runDispatcher()
except:
snmpEngine.transportDispatcher.closeDispatcher()
raise
Could you please help me if it could be a configuration error of the OpenVPN server, or maybe something else needs to be added. Have you seen a similar lake?
Any comment is appreciated.
I have wrote a small app to respond to ICMP, however it seems that the sender is ignoring the ICMP replies. Inspecting the packets in Wireshark they are missing the timestamp fields, and working ICMP replies from actual devices contain the timestamp fields, is it just a case I'm missing them in mine?
I've poisoned the ARP cache so it has a correct ARP mapping in the ARP table.
I've confirmed using TCPDump that the ICMP replies are at least hitting the interface, not sure if they are being processed beyond that - if anyone has any advice on where to check for that, it would be appreciated
def respond_to_icmp(self, icmp_packet):
if icmp_packet["IP"].dst == self.ip: # if this is my IP
eth = Ether(dst=icmp_packet["Ether"].src, src=self.mac)
ip = IP(src=icmp_packet["IP"].dst, dst=icmp_packet["IP"].src)
icmp = ICMP(type=0, id=icmp_packet['ICMP'].id, seq=icmp_packet['ICMP'].seq)
icmp_reply = eth/ip/icmp
sendp(icmp_reply, iface=self.interface) # eth0 (on which it is received)
ICMP Reply Packet
###[ Ethernet ]###
dst = de:ad:be:ef:ee:ff
src = aa:bb:cc:dd:ee:ff
type = IPv4
###[ IP ]###
version = 4
ihl = None
tos = 0x0
len = None
id = 1
flags =
frag = 0
ttl = 64
proto = icmp
chksum = None
src = 192.168.3.46
dst = 192.168.3.1
\options \
###[ ICMP ]###
type = echo-reply
code = 0
chksum = None
id = 0x6b86
seq = 0x19f
ICMP activity from sender
21:14:06.487711 IP 192.168.3.46 > 192.168.3.1: ICMP echo reply, id 0, seq 0, length 8
21:14:07.417939 IP 192.168.3.1 > 192.168.3.46: ICMP echo request, id 27526, seq 52, length 64
21:14:07.487494 IP 192.168.3.46 > 192.168.3.1: ICMP echo reply, id 0, seq 0, length 8
21:14:08.441948 IP 192.168.3.1 > 192.168.3.46: ICMP echo request, id 27526, seq 53, length 64
21:14:08.548995 IP 192.168.3.46 > 192.168.3.1: ICMP echo reply, id 0, seq 0, length 8
Actual ICMP Result
From 192.168.3.1 icmp_seq=368 Destination Host Unreachable
From 192.168.3.1 icmp_seq=369 Destination Host Unreachable
From 192.168.3.1 icmp_seq=370 Destination Host Unreachable
From 192.168.3.1 icmp_seq=458 Destination Host Unreachable
From 192.168.3.1 icmp_seq=459 Destination Host Unreachable
From 192.168.3.1 icmp_seq=460 Destination Host Unreachable
Turns out when Linux is responsible for ICMP, it includes a nice little data payload, without adding this payload to the reply, Linux must think that there was an error or malformation of packet.
def respond_to_icmp(self, icmp_packet):
if icmp_packet["IP"].dst == self.ip:
eth = Ether(dst=icmp_packet["Ether"].src, src=icmp_packet["Ether"].dst)
ip = IP(src=icmp_packet["IP"].dst, dst=icmp_packet["IP"].src)
icmp = ICMP(type=0, id=icmp_packet['ICMP'].id, seq=icmp_packet['ICMP'].seq)
raw = Raw(load=icmp_packet["Raw"].load)
icmp_reply = eth/ip/icmp/raw
sendp(icmp_reply, iface=self.interface)
I tried to execute:
snmpwalk -v 3 -u snmpv3username -A <passphrase> -a MD5 -l authNoPriv localhost .1.3.6.1.4.1.334.72.1.1.6.2.1.0
However, I got the following error:
Error in packet.
Reason: authorizationError (access denied to that object)
I have already define the following in /etc/snmp/snmpd.conf:
createUser snmpv3username MD5 <passphrase> AES <passphrase>
Question is:
1. What is the meaning of this error? I thought I have defined the user in the config file
2. How to solve this issue?
If I execute:
snmpwalk -v 1 -c public -O e 127.0.0.1
I got this result:
SNMPv2-MIB::sysDescr.0 = STRING: Linux ip-10-251-138-141 2.6.32-358.14.1.el6.x86_64 #1 SMP Mon Jun 17 15:54:20 EDT 2013 x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (615023) 1:42:30.23
SNMPv2-MIB::sysContact.0 = STRING: Root <root#localhost>
SNMPv2-MIB::sysName.0 = STRING: ip-10-251-138-141
SNMPv2-MIB::sysLocation.0 = STRING: aws-west
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORID.1 = OID: SNMP-MPD-MIB::snmpMPDMIBObjects.3.1.1
SNMPv2-MIB::sysORID.2 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance
SNMPv2-MIB::sysORID.3 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.4 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.5 = OID: TCP-MIB::tcpMIB
SNMPv2-MIB::sysORID.6 = OID: IP-MIB::ip
SNMPv2-MIB::sysORID.7 = OID: UDP-MIB::udpMIB
SNMPv2-MIB::sysORID.8 = OID: SNMP-VIEW-BASED-ACM-MIB::vacmBasicGroup
SNMPv2-MIB::sysORDescr.1 = STRING: The MIB for Message Processing and Dispatching.
SNMPv2-MIB::sysORDescr.2 = STRING: The MIB for Message Processing and Dispatching.
SNMPv2-MIB::sysORDescr.3 = STRING: The SNMP Management Architecture MIB.
SNMPv2-MIB::sysORDescr.4 = STRING: The MIB module for SNMPv2 entities
SNMPv2-MIB::sysORDescr.5 = STRING: The MIB module for managing TCP implementations
SNMPv2-MIB::sysORDescr.6 = STRING: The MIB module for managing IP and ICMP implementations
SNMPv2-MIB::sysORDescr.7 = STRING: The MIB module for managing UDP implementations
SNMPv2-MIB::sysORDescr.8 = STRING: View-based Access Control Model for SNMP.
SNMPv2-MIB::sysORUpTime.1 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORUpTime.2 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORUpTime.3 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORUpTime.4 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORUpTime.5 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORUpTime.6 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORUpTime.7 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORUpTime.8 = Timeticks: (2) 0:00:00.02
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (562693901) 65 days, 3:02:19.01
End of MIB
Thanks in advance
You do the snmpwalk with seclevel authnopriv but your user has seclevel authpriv configured.
Try:
snmpwalk -v 3 -u snmpv3username -A <passphrase> -a MD5 -x AES -X <passphrase> -l authNoPriv localhost .1.3.6.1.4.1.334.72.1.1.6.2.1.0
Besides creating the user, you must also "authorize" it to see data. Users can exist without any permissions to see data (its part of the SNMPv3 specifications).
For Net-SNMP, you can do this easily by granting it read-only access using this line in your snmpd.conf file:
rouser snmpv3username
or for write access to everything:
rwuser snmpv3username
Edit: Additionally, you should put the create user line in /var/net-snmp/snmpd.conf instead so it gets replaced by a private, localized key that can't be stolen and used in other devices.
If I generate an Ethernet frame without any upper layers payload and send it at layer two with sendp(), then I receive the "Mac address to reach destination not found. Using broadcast." warning and frame put to wire indeed uses ff:ff:ff:ff:ff:ff as a destination MAC address. Why is this so? Shouldn't the Scapy send exactly the frame I constructed?
My crafted package can be seen below:
>>> ls(x)
dst : DestMACField = '01:00:0c:cc:cc:cc' (None)
src : SourceMACField = '00:11:22:33:44:55' (None)
type : XShortEnumField = 0 (0)
>>> sendp(x, iface="eth0")
WARNING: Mac address to reach destination not found. Using broadcast.
.
Sent 1 packets.
>>>
Most people encountering this issue are incorrectly using send() (or sr(), sr1(), srloop()) instead of sendp() (or srp(), srp1(), srploop()). For the record, the "without-p" functions like send() are for sending layer 3 packets (send(IP())) while the "with-p" variants are for sending layer 2 packets (sendp(Ether() / IP())).
If you define x like I do below and use sendp() (and not send()) and you still have this issue, you should probably try with the latest version from the project's git repository (see https://github.com/secdev/scapy).
I've tried:
>>> x = Ether(src='01:00:0c:cc:cc:cc', dst='00:11:22:33:44:55')
>>> ls(x)
dst : DestMACField = '00:11:22:33:44:55' (None)
src : SourceMACField = '01:00:0c:cc:cc:cc' (None)
type : XShortEnumField = 0 (0)
>>> sendp(x, iface='eth0')
.
Sent 1 packets.
At the same time I was running tcpdump:
# tcpdump -eni eth0 ether host 00:11:22:33:44:55
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:33:47.774570 01:00:0c:cc:cc:cc > 00:11:22:33:44:55, 802.3, length 14: [|llc]
I would like to know if there is a way to count the number of TCP retransmissions that occurred in a flow, in LINUX. Either on the client side or the server side.
Looks like netstat -s solves my purpose.
You can see TCP retransmissions for a single TCP flow using Wireshark. The "follow TCP stream" filter will allow you to see a single TCP stream. And the tcp.analysis.retransmission one will show retransmissions.
For more details, this serverfault question may be useful: https://serverfault.com/questions/318909/how-passively-monitor-for-tcp-packet-loss-linux
The Linux kernel provides an interface through the pseudo-filesystem proc for counters to track the TCPSynRetrans
For example:
awk '$1 ~ "Tcp:" { print $13 }' /proc/net/snmp
Per documentation:
* TCPSynRetrans
This counter is explained by `kernel commit f19c29e3e391`_, I pasted the
explanation below::
--
TCPSynRetrans: number of SYN and SYN/ACK retransmits to break down
retransmissions into SYN, fast-retransmits, timeout retransmits, etc.
You can also adjust these settings also through the pseudo-filesystem procfs but under the sys directory. There is a handy utility that does this short-hand for you.
sysctl -a | grep retrans
net.ipv4.neigh.default.retrans_time_ms = 1000
net.ipv4.neigh.docker0.retrans_time_ms = 1000
net.ipv4.neigh.enp1s0.retrans_time_ms = 1000
net.ipv4.neigh.lo.retrans_time_ms = 1000
net.ipv4.neigh.wlp6s0.retrans_time_ms = 1000
net.ipv4.tcp_early_retrans = 3
net.ipv4.tcp_retrans_collapse = 1
net.ipv6.neigh.default.retrans_time_ms = 1000
net.ipv6.neigh.docker0.retrans_time_ms = 1000
net.ipv6.neigh.enp1s0.retrans_time_ms = 1000
net.ipv6.neigh.lo.retrans_time_ms = 1000
net.ipv6.neigh.wlp6s0.retrans_time_ms = 1000
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300