I am receiving traps from the device and want to forward it. Before forwarding I want to set peer address of the source system.
Your SNMP manager could for example add the variable binding snmpTrapAddress.0 to the trap, setting its value to the address of the originating host.
But this is a bit of a hack. If you're writing custom software just to forward traps, I'd suggest that you're reinventing the whell. Consider instead installing net-snmp and letting it forward the traps for you.
Related
In my network, I want to scan for snmp enabled devices. So is there any single line snmp command, to get list of snmp enabled devices in specific range of IP Address like 172.26.1.1 to 172.26.1.255.
I found a link which says it is possible but it does not mention the command.
https://support.panorama9.com/hc/en-us/articles/203568188-Test-if-SNMP-devices-are-responding-correctly-to-SNMP-queries
Is there any generic OID to achieve this or single snmp command ?
Well, you can try to use the subnet broadcast address but from the SNMP FAQ most devices have this turned off. So this probably won't work very well.
http://www.snmp.com/FAQs/snmp-faq-part2.txt
2.60.12
SUBJECT: How should an agent respond to a broadcast request?
When an SNMP request is sent with a broadcast address, Who is
supposed to respond? Ideally every host in the subnet should respond.
But I notice that it doesn't happen. What is the expected behaviour when
a directed broadcast is done?
Depending on how the agent is written, it may respond, or
just drop the message. Many agents just drop the message.
I believe that is what the SNMP agent in cisco product do.
Another alternative is to try to use nmap to scan for hosts that respond to SNMP as well as attempt to see what community strings they respond to.
https://www.vanstechelman.eu/networking/scanning_for_snmp_services_with_default_community_strings
also
https://nmap.org/nsedoc/scripts/snmp-brute.html
In want to modify the TCP/IP portion of the Linux kernel where i can to intercept every packet going out to each interface. I need to intercept them and modify the IPv6 destination Options header. I am not sure how to start with this. Any pointers would be greatly appreciated.
Regards,
N
You can modify packets using a Python library called scapy. It is not necessary to modify kernel code in order to do so. However, keep in mind that you must set up a Man-in-the-middle in order to sniff a communication.
http://www.secdev.org/projects/scapy/
I like to send packet to a device with only MAC address associated to it and also connecting to my local LAN.
Is there anything in ruby / gem library that I can use to perform such task?
I want to do something like tcpreplay but in ruby instead. Thanks!
MACs are the addresses used on OSI layer 2, the package type you are using on this layer are e.g Ethernet frames. IP Sockets live on layer 3/4, thus if you are using an IP socket, you are sending IP packet.
So if you want to send something "to a MAC address", you need to send raw Ethernet frames which need to be understood on the other side. Given the really low level of this stuff, this is rarely what you really want to do.
Instead, you should try to get the proper IP addresses of the remote device in your local network (technically the broadcast domain) with either a broadcast/reply mechanism or with multicast (which is used e.g. by Bonjour). That way you can always use the much more supported IP layer. For that, your device needs to have an IP address of course. You can establish those with mechanisms like DHCP or address auto configuration for IPv6.
As for your question, I'm not aware of any library for Ruby to send raw Ethernet frames. But given you would need to invent a new protocol besides IP anyway (which is hard, really hard), sending the package is probably the least of your concerns.
I suppose there are a couple of approaches. You didn't say whether you wanted to send an IP packet of some kind, and if so you didn't say which IP protocol. (I can tell you want to send an ethernet frame but ... what encapsulated protocol?)
Anyway, you can open a SOCK_RAW with Ruby, something like:
Socket.open(Socket::PF_INET, Socket::SOCK_RAW, Socket::IPPROTO_RAW)
Another approach might be to just pick a link-local IP and then establish an IP/MAC mapping in your local ARP cache with something like:
system "arp -s host hw_addr"
Then you could communicate with it using more familiar socket ops using the link-local IP address.
You need to be root for all of these things.
I discovered almost accidentally that my machine was sending and receiving UDP packets to a machine in Poland. Not that I have any problem with Poland, I just don't know why my laptop has the need to communicate with a server there. Reverse DNS shows just the ISP providing the address to some end user. Using Wireshark, I can monitor the messages, which were indecipherable as they were probably encrypted. All packets sent from my machine had the same source port, so clearly the application that sent them opened this UDP socket to use it. I am searching for ways to:
1) enumerate all current sockets open in the system, including the process that created it and, for both TCP and UDP, what ports and addresses they are current bound to.
2) because applications can open these sockets, use them, and close them right away, I would love to find (or perhaps even write) a program that once started would somehow get notification each time a socket gets created, or really more importantly when bound to a source and/or destination address and port. For UDP, I would love to also be able to monitor/keep track of the destination IP addresses and ports that socket has sent messages to.
I don't want to monitor the traffic itself, I have Wireshark if I want to view the traffic. I want to be able to then cross reference to discover what application is generating the packets. I want to know if it is from a process I trust, or if it is something I need to investigate further.
Does anybody know of any applications (for the Windows platform) that can do this? If not, any ideas about a .NET or Windows API that provides this capability, should I want to write it myself?
Edit:
After further research - looks like the APIs to use are GetExtendedUdpTable and GetExtendedTcpTable, CodeProject.com has some samples wrapping these in .NET (see http://www.codeproject.com/Articles/14423/Getting-the-active-TCP-UDP-connections-using-the-G). So a combination of this API and some sniffer code would be needed to monitor and keep track of what hosts at what ports using what protocol any particular application on your machine is talking to. If I ever get some free time, I'll consider creating this, if you know of an app that does all this, please let me know.
Try SysInternals TCPView. Despite its name, it handles UDP as well.
netstat -b to enumerate all ports along with the process names.
You can try using SysInternals' Process MOnitor (ProcMon.exe or ProcMon64.exe).
It allows for filtering of Processes by "UDP Send" Operation - and provides detailed UDP Connection data, including source and destination addresses(IP) and ports etc.
I'm writing an IPsec implementation for a microcontroller and I want to test it using a standard Linux box running Debian Lenny. Both devices should secure the communication between them using IPsec ESP in tunnel mode. The keys are setup manually using setkey. There's no (or at least should be no) user space program involved in processing an IPsec packet. Now I want to see how my created packets are processed by the Linux kernel. To see the raw packets I capture them using tcpdump and analyze them using wireshark.
What's the best way to obtain debug information about IPsec processing?
How can I figure out whether the packet is accepted by the kernel?
How can I view the reason for a packet to be dropped?
You can instrument the XFRM (or perhaps ipv4/esp.c) kernel code to print out debug messages at the right spots.
For example, in net/ipv4/esp.c there exists a function esp_input() which has some error cases, but you'll see most the interesting stuff is in the xfrm/*.c code.
That said, I didn't have a problem interoperating a custom IPSec with Linux. Following the 43xx specs and verifying the packets came out correctly via wireshark seemed to do well. If you're having issues and don't want to instrument the kernel then you can setup iptables rules and count the number of (various type of) packets at each point.
Finally, be sure you've actually added a security policy (SP) as well as a security association (SA) and setup firewall rules properly.