Hi I am new to Snort and i simulated arp scan attack. I am trying to detect this attack in Snort. No preprocessors detected this attack so i wanted to write a rule for it. But i find out that snort rule does not support arp protocol.
This scan is sending arp request on all possible addresses from subnet 192.168.92.0/24 and waits for an answer which means that host is up. Is it possible to detect these attack using snort rules?
Here is the example of scan from wireshark.
Arp Scan in wireshark
Related
Can you send data to a UDP receiver without your IP address or location visible to the receiver?
Yes. It's possible to create and send UDP packets with a spoofed IP address using a raw socket.
Raw sockets allow applications to create their own IP headers including the source address fields. Look around for examples in whatever language you write in.
However, creating and sending such a packet doesn't mean that the networks along the way to the recipient will actually deliver it. Some networks employ defensed like Reverse path forwarding to protect against IP spoofing. There's CAIDA a research project that tests for IP spoofing in networks around the world, you can find an up to date report here.
When using Avi Networks controller, is it possible to
receive SSL/TLS traffic from the client,
decrypt the traffic (maybe selectively),
divert the traffic through an active L2 device (such as IPS for filtering)
receive cleaned traffic back,
re-ecnrypt it,
send it forward to the destination server?
The decryption/encryption part is sometimes referred to as SSL Forward Proxy.
Here's an example of this feature https://devcentral.f5.com/articles/divert-unencrypted-traffic-through-an-ips-with-local-traffic-manager
After talking with Avi Networks SE, it turns out this feature is not supported at this time.
Running on a Linux system, getting UDP packets from another computer address to let's say 192.168.0.2 from another address let's say 192.168.166.66, I can see the UDP packets coming in with tcpdump. However, if I use netcat I don't actually receive the packets.
If I create an interface on 192.168.166.XXX network, then netcat is able to receive the packets no problem.
What basic networking concept am I missing? Why do I need to have an interface on the network of the sending IP when I can see with tcpdump that they are being delivered correctly?
tcpdump per default puts the interface into promiscious mode, which lets you see all the packets arriving at your network interface. But, your operating system only processes packets destined for the local system, e.g. either having the local or a broadcast address as destination.
The final solution to this problem was to disable Reverse Path Forwarding (RPF) on the interface. There are security implications here, but after careful review this was the correct path forward in this particular case.
RPF was turned off by modifying /etc/sysctl.conf:
net.ipv4.conf.eth0.rp_filter=0
Some more information on RPF:
Wikipedia - Reverse path forwarding
Linux kernel rp_filter settings
If i send ARP request sent to a find the MAC address of a machine in a LAN. But among the group of hosts in the LAN, two hosts having the same IP address, then how the ARP reply works.
The same situation with the RARP, if the two machines inside the LAN with same MAC address. If i send RARP request to find IP address, then how the RARP reply works.
If it receives 2 different ARP or RARP responses, it knows something wrong.
Further reading: gratuitous ARP.
Primarily IP address is unique within a network and MAC is unique globally and so there should not be any confusion.
But incase if multiple devices have same IP or MAC then (probably) the first ARP or RARP will be accepted as valid response. Because once a request is obtained the information is written in to kernels ARP cache and so for subsequent needs the cache will be used (till the cache expires).
I am trying to find out the type of the tunnel used for a vpn.. I am trying to determing if the tunnel is tcp or udp.. how do I do that? When I observe the tunnel traffic I am not able to observe anything! In the sense that packets are sent as such..
You need to observe the traffic on the physical network connection, not the traffic in the tunnel itself:
Setup a network packet capture program, such as Wireshark, to capture the traffic on the "real" network interface e.g. your cabled Ethernet connection. On Linux it would be something along the lines of eth0.
(Optional) Shutdown as many processes that use the network as possible.
Cause as much traffic through the VPN tunnel as possible - e.g. download a large file.
Watch in your capture program for any change - the tunnel traffic should now stand out due to sheer volume.
Keep in mind that if you are using an IPSec tunnel, the packets will be ESP, which is neither TCP nor UDP.