I am doing host discovery only (-sn) option, trying to determine active hosts that are up and running.
My first command was:
nmap -sn -PS21,22,25,53,80,443,3389,8000,8080,42000 -PA80,443,8080,42000 -PU53 xxx.xxx.xxx.xxx/27
I am scanning public IP's and the above command produces a result stating that 18 hosts are up.
However, when I run the above command with --data-length "option" (either 32 or 56), it produces a result with only 8 hosts up.
I was expecting to see more hosts, if anything... but not less. (The data-length option adds a bytes of data to every packet to simulate the ping tool and it may help evade firewall rules set to drop 0 byte packets).
I am reading Fydors book however I am having trouble understanding the behavior above.
Any ideas?
Thanks
--data-length adds data to every packet. Your TCP discovery options (-PS, -PA) are sending packets that do not usually contain data. In this case, these packets are more likely to be dropped or ignored since they are unusual. The case where --data-length is useful is for the -PE (ICMP Echo Request) discovery option. ICMP Echo Request datagrams are usually sent with some data payload, but Nmap defaults to empty probes, so IDS products like Snort will sometimes block or alert on these probes.
Related
I need to hit a http server every second for an ack reply once every second repeatedly for various lengths of time, and to output the replies into a textfile with information such as the response time in ms. this is basically to check for latency, but for my purposes i need to do it with a syn/syn-ack.
I've gotten somewhere with
nmap -sS 1.1.1.1 -p 80 -o test.txt -v
this outputs well on screen, but not into the text file -- how do i get all the output that nmap runs into the file?
also, not sure how to run this every second - does nmap have a flag for repeating? or shall i just put it in a bash script?
This command is probably doing more than you want. Each time you run it, Nmap does the following:
Does a reverse-DNS (PTR) lookup of your target
Sends a host-discovery probe to make sure the target is "up." If you are root, this is a set of 4 ICMP and TCP probes. If not, it is 2 TCP connect calls.
Sends a TCP SYN probe to port 80. If you are running as root, the sequence is SYN, SYN/ACK, RST. Otherwise it is SYN, SYN/ACK, ACK, RST/ACK.
So instead, you can use some helpful flags to reduce this overhead and be more specific with what you are asking for.
nmap -n -sn -PS80 1.1.1.1
This command will skip the reverse-DNS lookup (-n) and use the host discovery phase to find the latency. -sn skips the port scan and -PS80 says to use TCP SYN to port 80 to do host discovery. Whether the TCP handshake is completed depends on whether you have root privilege or not.
nmap -n -Pn -p 80 1.1.1.1
This command will send the exact same probes as the previous, but will show the output as a port scan, not just a host discovery scan.
To repeat the scan, you'll have to put it in a shell loop. It would be better to use a dedicated tool for this, but I don't know which one would be best. Nmap comes with a tool called Nping that can send repeated probes and report the round-trip time, but I can't get it to display it per-packet; it just gives a summary at the end. You may have better luck with hping.
Traceroute is an application to trace the path from A to B. (A is your location and B is the server you want to trace). In Windows, you can type tracert. The main algorithm is:
send UDP with TTL = 1
Server A1 received, and return ICMP packet to A because TTL is expired.
--> know first machine between. For example A1.
send UDP with TTL = 2
Server A1 received, and send this UDP to server A2.
Server A2 received, and return ICMP packet to A because TTL is expired
--> know second machine between. In this example is A2.
Do it until to B. we can track down: A -> A1 -> A2 -> ... ->B
Does this algorithm work correctly? Because at different time, an intermediate server can send a message to different server. For example, at first time, UDP message is sent to A1, but at a later time, it can send to another server, for example, B1. So, trace route will not work properly.
Did I misunderstand something?
From the man page :
traceroute tracks the route packets take from an IP network on
their
way to a given host
So if you are trying to find one of the possible paths your packet may take, you'll find a friend in traceroute .
Now because routing tables do not change every minute, the packets that you send will most probably take the same path as traced by traceroute.
Another important point that cannot be missed is the record route option in the IP v4 header.
Once you specify that you want to use this option, every router in the path will add it's ip address to the options in the header. You can read more about it here. The catch being that the destination gets to know about the intermediate hops , not the source.
I see that you missed the role of icmp echo request and reply messages in the description of traceroute. In case this was not intentional , take a look.
Update : You can see the record route option in action by doing a ping -R
ping -R Turns on route recording for the Echo Request packets, and
display the route buffer on returned packets (ignored by many
routers).
The algorithm works properly. Indeed, routing may change due to considerations of different servers along the way, such as server load or availability. Let's say you want to send message from A to B. If the route is not changeable, what will happen if some server on the route is down? If the routing couldn't be adjusted dynamically, that would result in inability to deliver the message to the destination in this example. Here is a different example: let's say you have a server that is used for some heavy computation during the day but it's idle during the night. It's possible to allow it to pass traffic only during the night, so any routing using it will need to be changed at day.
To conclude all this we can definitely say that without dynamic routing the internet couldn't have existed in its' present form.
Addition:
Tracert sends message from A to B. It shows hops along the way. These hops constitute a valid route from A to B at the time of the execution. There is no guarantee that connection between 2 adjacent points along the way is valid after the hop has been completed. The only thing guaranteed is that for each hop there was a link between it's 2 endpoints when the message sent by tracert passed there.
I know what SNMP is and I know what ping is. What is meant by a 'SNMP ping'? SNMP can be used to see if devices on a network are still alive.. what does it use to do this? I wouldn't have thought an SNMP ping is the same as an ICMP ping?
As you correctly suspected SNMP "ping" is definitely not the same as ICMP ping. What it does is to try to retrieve some basic information through SNMP like DNS name, system name, location, system type, system description etc. and if successful the "ping" is deemed to be successful too.
But this is not any kind of standard the way ICMP Ping (echo) is. There is no special "ping" command in SNMP - it's just a name for a tool used to scan whether SNMP is alive at some target device (by retrieving some common MIB values). So as you would expect the implementation differs too as a consequence of it being a useful tool rather than a standard.
But that has little effect in practice as there is a set of 'mandatory' SNMP records so if a device does not respond to those, you can be pretty sure it doesn't run SNMP. For an SNMP "ping" to work SNMP MUST be enabled on the target device of course ... which isn't the case by default most of the time in general so that's a big difference to ICMP Ping which can be used almost universally.
I hope I answered your question
Ping was "Packetized Internet Node Groper", originally a tool that implemented an ICMP echo response. "Ping" is now commonly used to convey an abstraction of checking whether a device is online, available, responding.
There are MIB options to ask a device to ping or trace route something -- which seem to be asking a device to ICMP to a third party and indicate success/failure -- but the colloquial use of "snmp ping" is to check responsiveness by asking a simple SNMP question of a static data point and get a response.
Most devices offer some response to requests in the 1.3.6.1.2 subtree, but it's not a hard/fast requirement. For example, on a Unix (-like) command line, one may try "snmpget -v 1 -c public 192.168.0.1 1.3.6.1.2.1.1.1.0" to ask "192.168.0.1" what its name is. The device may respond; it typically will not NAK if the access (version 1, community string "public", in this case) is incorrect. The switch(es) in between may choose to alert the requestor "unreachable", but may not. In this case as others, if there is no response, the messages or hints aside from "no response" may be helpful.
It is typical for an SNMP ping to be equivalent to an ICMP echo. IBM states, for example, that it issues a single ICMP echo (to the SNMPD on the receiving end) and returns the minRTT. If a response times out, then it sends another raw echo packet after 1 second, and another again after 2 seconds. If there is yet no reponse, -1 is returned.
Cisco also has a sort of similar implementation (SNMP GET/SET/PING-MIB). It is definitely implementation-specific, however.
Source
"ping" is just a generic term for sending a message for the purpose of seeing whether you get back a response.
ICMP is the most common method of "pinging" a host on an IP network. If you get an ICMP echo response from an IP address, then you know that something out there is able and willing to receive and reply to at least some network traffic for that address. Receiving a reply to an ICMP ping does not tell you anything about the state of any other network services. Not receiving a reply does not tell you anything at all: there are dozens of reasons why you might not receive a response to an ICMP ping at any particular moment.
The concept of a "ping" applies to any mechanism of communication. Some network protocols have specific standards for performing a "ping". For most, "pinging" just means trying to perform some basic operation to see if it works. For example, you could "ping" an HTTP server by just connecting to port 80 and doing "HEAD / HTTP/1.0". If you get back an HTTP response, then you know there's an HTTP server operational. The same idea applies to SNMP or any another network application.
In most contexts I have heard 'SNMP Ping' used, it was referring to a DISMAN PING. This method allows you to use SNMP to control a device or host remotely and tell it to 'ping' another device. Typically, this would be a traditional ICMP ping.
For example, imagine you are on your laptop, and you have a webserver which seems to be taking a long time to load a page. You can't quickly tell if it is a problem with the network between you and the webserver, the network between the webserver and the database, or something with one of the servers themselves. You want to eliminate network first, so you first ping the webserver from your laptop. No loss, and the latency looks reasonable. You ping the database server from your laptop, and it looks good too. The problem with the laptop-database ping test is it doesn't tell you what is going on between the webserver and the database. Ideally, you'd log into the webserver and ping the database, but you don't have a shell account. You do, however, have a read/write SNMP access. So, you decide to use 'snmpset' from your laptop to the webserver to create a table (for ping results) and specify a target (database server) to ping. The webserver snmpd initiates an ICMP ping from the webserver to the database and stores the results in a table. You then do a 'snmpget' from the laptop to pull the webserver-database ping results.
The other contexts you might see 'snmp ping' may be simply a snmpget from a SNMP client to a SNMP daemon to confirm SNMP is working.
In my understanding, an SNMP ping is the one defined in RFC 2925
https://www.rfc-editor.org/rfc/rfc2925
If the SNMP agent vendor indicates that a device supports this RFC, then you can use SNMP ping to monitor it. Otherwise, it won't work.
This is completely different from the "normal ping" (ICMP based).
Like ICMP ping, SNMP ping, just a form of a SNMP getrequest, is used to check the aliveness of any equipment that has standard SNMP agent running for monitoring. It is useful when the management systems that manage these equipments to query for the auto discovery. Any sysOid can be used to query the equipment as part of the request.
I have FreeBSD host (some sort of HTTP Proxy) with spikes of retransmitted packets number. Is there any way to track were host loosing them (per incoming connection).
I usually capture a bunch of them with tcpdump or similar; and then post process them elsewhere. In your case that should not be hard - as you just need the header.
Something like tcpdump (without; or a < 200 byte -s fly) would do on the target machine.
Compress/move this file then off to a desktop machine to work on it. I'd start with something like wireshark (simply use the filters).
Beyond that - simple grep-ing/wc-counting or a small perl script may be called for. To save you re-inventing histograms; consider http://snippets.aktagon.com/snippets/62-How-to-generate-a-histogram-with-Perl or do a quick google.
I am working on a project involving correlations in distance of the server in relation to pings and traceroutes. So I am getting the number of hops and the average ping time for different web sites. I am using puTTy and unix code to achieve this, when I traceroute the website (traceroute australia.gov.au -m 255) I allow for the maximum number of hops. I get about 18 hops, and then i get 237 numbers with three asterisks next to them. At first I assumed that this was a result of the -m 255 extension to the command, but it doesn't occur with websites like youtube or google. Is this timed out hops/connections? Also when i ping this website (ping australia.gov.au -c 25), I get no respsonse for about a minute (near 2000ms) and then the print out says that 25 packets were sent and 0 were received, what is the explanation for this?
Lots of places all over the internet block ICMP, meaning that australia.gov.au might have a valid routable IP, but just doesn't send back echo reply.
Three asterisks line from traceroute, as far as I can remember, means a packet with given TTL did not get a reply. That again probably indicates that the host/router does not want to be bothered replying to arbitrary ICMP and/or UDP packets.