In wireshark I can see Membership Query, general IGMPv2 requests coming over and over from 0.0.0.0 source which suggests ( according to RFC ) machine that hasn't received address yet. My question is how in Linux environment I can find such machine. This query triggers many answers and causes significant network communication slowdown.
When a machine is connected to a network for the first time, it will try to find the DHCP servers in order to get an IP address configuration. Untill then, as you already said, it has no IP address and the only identifier it has is it's MAC address, which is used to keep a comunication alive while it negotiates with the DHCP server (during this period it does not have an IP address until the very last).
Answering your question, you'd find the machine you are looking for making use of the MAC address. If you are on a small network, a manual check (ifconfig) will do it but, if you are on a big one, you better check the ARP table of your switch(es) to have a better idea where it could be.
Related
Is it possible to ping mininet ip? I found mininet's ip starts with 10.0.2.15 . I can ping from mininet to others. However, I failed to ping other place to mininet. How can I setup this?
10.0.0.0/8, which is 10.0.0.0 - 10.255.255.255 are IP addresses used only locally, they are not accessed from the internet (other networks). Here is some info from IANA:
These addresses are in use by many millions of independently operated networks, which might be as small as a single computer connected to a home gateway, and are automatically configured in hundreds of millions of devices. They are only intended for use within a private context and traffic that needs to cross the Internet will need to use a different, unique address.
These addresses can be used by anyone without any need to coordinate with IANA or an Internet registry. The traffic from these addresses does not come from ICANN or IANA. We are not the source of activity you may see on logs or in e-mail records.
I'm working on a program that tracks when search engines cannot find important files on my server.
From my computer I typed:
nslookup google.com
and I received 11 IP addresses in return all beginning with 74.125.226
I then tried:
dig google.com
and I still receive the same IP addresses.
When I navigate to here through searching: http://www.iplists.com/google.txt, the number of IP addresses is greater than 10 and that list includes ones starting with 64.249 which also appears in my server log.
Am I using the wrong linux tools to find every IP address associated with google? If so, what tools should I use?
I want to generate the IP address database myself rather than rely on someone's post of IP addresses just in case IP addresses are updated in the future.
The keyword here is GeoDNS: When website/service has many servers around the world (with the main purpose of providing the lowest possible latency to user requests), using GeoDNS it can respond with different IP addresses to DNS queries for the same hostname, based on the locaton of the DNS client that is making the query (of course it will try to respond with the IP address of the closest server).
Basically, there is no way you can retrieve all possible addresses just by querying DNS from one location. Also, google can add/remove/change addresses/servers on daily basis so you probably can never have the definite list (unless google publishes it somewhere).
The real-time example, this might help you:
https://www.whatsmydns.net/#A/www.google.com
Additional reading:
What is the difference between Anycast and GeoDNS / GeoIP wrt HA?
I want to detect number of online (which has ping successful) machines in network.
with two conditions
1) Don't know its workgroup/Domain (there may be possibility two machines have different workgroups)
2) Don't know its IP address or MAC address.
In short, it should returns all machines (ip addresses) in same networks (say same LAN).
Try using nmap you can give it a rang and even port
Edit: plan of attack would be running the ping command on an IP range and mark the IP's that responded. Hope that's not stating the obvious. There's a Ping Class in .Net, as seen here: https://github.com/Simran/nmap-csharp/blob/master/nmap-csharp/Main.cs
It's a lot of code so didn't post it.
The other comment suggesting nmap is on the money. It uses many different techniques to determine if a host is online or not. A ping can fail on otherwise "online" hosts depending on firewall settings. If the criteria for "online" is "responds to ping", please check this out: find all ip address in a network
I am doing some penetration testing, and im trying to find out, if i can get the IP address of an router if i got the bssid, or any i can get with the AIR tools?
I use Linux Kali with the Air tools atm.
I would say this is pretty damn bad if its possible. Basicly most people´s rounters can be reached through their outside IP. Even companies. :O
So far i tried:
- Passive TCPDUMP
- Active scanning
So basicly, is there a way, if so please give me a hint or the answer :-)
I am 100% refering to some sort of scanning. All kind of cracking, bruteforce, password guessing, access stealing is not what im asking about :-)
You can't do that if target access point is protected with WPA/WPA2.
This is why. Getting WiFi to work involves following steps:
Associate with target access point. If access point is using WPA/WPA2 and you don't know the password, then you cannot proceed to further steps, and certainly cannot know anything about IP address of target access point.
After association, your client (which is typically configured to use DHCP) has no IP address assigned (its IP address is 0.0.0.0). Technically, you can use sniffer at this stage to scan the network and find out IP addressed used, but most sniffers don't like to work with 0.0.0.0 address. To proceed further, your client sends DHCP request, which is served by access point. After getting successful DHCP ack with new IP address, client can proceed to next step.
After getting IP address, client can talk to access point and finally knows its IP address (it was served as default router in DHCP ack) - and that would be the answer to your question (yes, that late in the game!). However, even at that point, full network connectivity cannot be assumed. If access point implements captive portal, then your network access may be restricted until you open up web browser and (depending on wireless provider) either accept usage terms, provide some credentials or pay with credit card.
After passing captive portal, it is possible (but not common) that access point automatically re-associates and gives you completely different IP address (and access point also has different IP address now, from completely different subnet). This would mean that IP address you learned in previous steps was completely useless to you in terms of knowing actual network infrastructure.
You would need a Firewalking tool to get past the 0.0.0.0 you would essentially also need a password cracker that attempts different brute forcing to get the matching wep password for example, if there are not max tries it could work.
Imagine a user sitting at an Ethernet-connected PC. He has a browser open. He types "www.google.com" in the address bar and hits enter.
Now tell me what the first packet to appear on the Ethernet is.
I found this question here: Interview Questions on Socket Programming and Multi-Threading
As I'm not a networking expert, I'd like to hear the answer (I'd assume it is "It depends" ;) ).
With a tool like Wireshark, I can obviously check my own computers behaviour. I'd like to know whether the packets I see (e.g. ARP, DNS, VRRP) are the same in each ethernet configuration (is it dependent on the OS? the driver? the browser even :)?) and which are the conditions in which they appear. Being on the data-link layer, is it maybe even dependent on the physical network (connected to a hub/switch/router)?
The answers that talk about using ARP to find the DNS server are generally wrong.
In particular, IP address resolution for off-net IP addresses is never done using ARP, and it's not the router's responsibility to answer such an ARP query.
Off-net routing is done by the client machine knowing which IP addresses are on the local subnets to which it is connected. If the requested IP address is not local, then the client machine refers to its routing table to find out which gateway to send the packet to.
Hence in most circumstances the first packet sent out will be an ARP request to find the MAC address of the default gateway, if it's not already in the ARP cache.
Only then can it send the DNS query via the gateway. In this case the packet is sent with the DNS server's IP address in the IP destination field, but with the gateway's MAC address on the ethernet packet.
You can always download wireshark and take a look.
Though to spoil the fun.
Assuming, the IP address of the host is not cached, and the MAC address of the DNS server is not cached, the first thing that will be sent will be a broadcast ARP message trying to find out the MAC address of the DNS server (which the router will respond to with its own address).
Next, the host name will be resolved using DNS. Then the returned IP address will be resolved using ARP (again the router will respond with its own address), and finally, the HTTP message will actually be sent.
Actually, it depends on a variety of initial conditions you left unspecified.
Assuming the PC is running an operating system containing a local DNS caching resolver (mine does), the first thing that happens before any packets are sent is the cache is searched for an IP address. This is complicated, because "www.google.com" isn't a fully-qualified domain name, i.e. it's missing the trailing dot, so the DNS resolver will accept any records already in its cache that match its search domain list first. For example, if your search domain list is "example.com." followed by "yoyodyne.com." then cached resources matching the names "www.google.com.example.com." "www.google.com.yoyodyne.com." and finally "www.google.com." will be used if available. Also note: if the web browser is one of the more popular ones, and the PC is running a reasonably current operating system, and the host has at least one network interface with a global scope IPv6 address assigned (and the host is on a network where www.google.com has AAAA records in its DNS horizon), then the remote address of the server might be IPv6 not IPv4. This will be important later.
If the remote address of the Google web server was locally cached in DNS, and the ARP/ND6 cache contains an entry for the IPv4/IPv6 address (respectively) of a default router, then the first transmitted packet will be a TCP SYN packet sourced from the interface address attached to the router and destined for the cached remote IPv4/IPv6 address. Alternatively, the default router could be reachable over some kind of layer-2 or layer-3 tunnel, in which case, the SYN packet will be appropriately encapsulated.
If the remote address of the Google web server was not locally cached, then the host will first need to query for the A and/or AAAA records in the DNS domain search list in sequence until it gets a positive response. If the first DNS resolving server address in the resolver configuration is in one of the local IPv4 subnet ranges, or in a locally attached IPv6 prefix with the L=1 bit set in the router advertisement, and the ARP/ND6 cache already contains an entry for the address in question, then the first packet the host will send is a direct DNS query for either an A record or a AAAA record matching the first fully-qualified domain name in the domain search list. Alternatively, if the first DNS server is not addressable on-link, and a default router has an ARP/ND6 cache entry already, then the DNS query packet will be sent to the default router to forward to the DNS server.
In the event the local on-link DNS server or a default router (respectively, as the case above may be) has no entry in the ARP/ND6 cache, then the first packet the host will send is either an ARP request or an ICMP6 neighbor solicitation for the corresponding address.
Oh, but wait... it's even more horrible. There are tweaky weird edge cases where the first packet the host sends might be a LLMNR query, an IKE initiation, or... or... or... how much do you really care about all this, buckaroo?
It depends
Got that right. E.g. does the local DNS cache contain the address? If not then a DNS lookup is likely to be the first thing.
If the host name is not in DNS cache nor in hosts file, first packet will go to DNS.
Otherwise, the first packet will be HTTP GET.
Well, whatever you try to do, the first thing happening is some Ethernet protocol related data. Notably, Ethernet adapters have to decide whether the Ethernet bus is available (so there's some collision detection taking place here)
It's hard to answer your question because it depends a lot on the type of ethernet network you're using. More information on Ethernet transmission can be found here and here