I agree with the comment that the intention is not to exploit a the host, but as I stated earlier, I believe this was simply a port scan to determine which services may be running based on the ports that are listening. Although the attacker may have been attempting to determine the OS type based on the headers of the TCP response. The one thing that is for sure based on this trace is that the attacker would not have been able to determine the OS type because the victim host never replied back.
It's something of a toss-up whether they were trying to enumerate services or identify the OS/device. I lean towards the OS/device theory because if you googe the port numbers one seems to be associated with a checkpoint firewall/VPN, another seems to be some *nix based system etc. The services associated with the ports come from different OS'. If I was scanning for services then I would be scanning ports that would provide services on a single OS/device not multiple OS'/devices, hence I lean to OS detection rather than service enumeration.
In this case you are correct that no real info was gleaned because no reply was received, (assuming this was OS identification), - however that would depend on whether this system was firewalled or not. You can't say what services are avialable if a firewall blocks access to the machine on those ports. Furthermore, the absence of a reply from a known open port is sometimes the information you require to determine the app behind it and/or it's revision level..... though this is not true with simple SYN packets it is most certainly true with others such as a SYN/FIN - so the absence of a reply does not always mean no information was gathered.
Well...I think we are on the same page, we just have two different perspectives, and since there really is no right answer. Building on what you said, the fact that the ports don't seems to be associated with anything specific, means to me that it was trying to find an open port (any port) since a response from any port would be enough to determine the TCP stack type and therefore potentially the OS or the ability to narrow it down to a few OS's
Run an nmap scan for yourself (just a basic port scan) and you will get the same result.
By the way, when I say scanning for services, I do mean scanning for ports, because every open port would have an associated service. A service is not specific to the OS either. For example HTTP port 80 is obviously a standard web service. This can be IIS on a windows box, apache on a linux box, i-planet on a solaris box, and so on. There are very few services (relatively speaking) that are OS specific. If you run a port scan and you get back a report saying that the only open port is 21, it may not mean much because it can be any OS, but the TCP headers may give some other indication.
Now there is the situation you are talking about. If a port scan reveals that ports 21, 80, and 135 are open, you can probably guess it is a windows box. This however is not as good of a method of identifying the OS however because services can be changed to utilize different ports. TCP headers can not bea easily modified since it comes directly from the kernel level. Therefore more reliable of a guess.
I will check to see if I still have the trace archived or not? Don't think so though. The conclusion
that I came up with was that this was an nmap trace using the idle host scan technique against our network. Due to the ip of the originating scan I surmise this. It is a Win NT/2K box
which I am not sure without looking at all the metrics.
It was not stealty at all your right, however this was not a script kiddie either. As evidenced by
their usage of the tool ie: various ports done up in a file ahead of time, the speed of it...
What this was meant to stimulate was people looking at the tcp/ip headers which is why I used the -v switch.
I will post more of these if there is an interest. I came up with no definitive conclusion as to what tool was used here. It is possibly nmap or hping. It was a reconnaissance though. Also
there was no prior ping noted. Not in recent memory anyways :-)
Ok Don.... You confuse me!!!! (Not a dificult thing sometimes....<S>)
At the beginning of your last message you say "the conclusion I came up with was an NMap scan"...... Later you say "That's why _I_ used the -v switch"..... and lastly you say "I came up with no definitive conclusion"......
Did you set this up or is this a result of monitoring your network and this is by someone unknown using a tool unknown to you?
Also - don't restrict yourself to looking for ping scans as a way of determining whether or not you have been recce'd..... You could run ping scans all day on my network and find only the firewall and the external router replying..... I do not allow ICMP through the firewall from the outside..... To a ping scan it appears that I provide no public services whatsoever within the entire netblock.... You need to dig a little deeper to find all the perfectly normal services I run. But when you do that I can see you....<s> I don't even log the ping scans... I log the more "in-depth" searches otherwise my logs would be even bigger than they currently are.....
ICMP is not allowed thru the f/w. I used the -v switch on tcpdump so that all the tcp/ip fields
would show up. It appears that nmap is the tool, however that is not certain. This due to the
fact that as I alluded to earlier it may be the idle host scan being used due to the predictable
ip id #'s. Also the packets are fragmented which is done by design likely to try and get past
some liberal routers acl's no doubt.
This however could also be the work of hping. I have not checked to see how many dst ports
you can supply with hping to deny or verify this as a possibility.
This is why I am unsure as to exactly what tool it is. I can however venture a couple of educated guesses.
This trace was not set up by myself. This was done in the wild and directed at my company's
network. I most certainly don't restrict myself to ping scans as a precursor either ;-)
Don: Thanks..... Now I'm less confused....<s>
Didn't mean to imply that you limited yourself to pingscans as precursor to further activity - but sometimes it is hard to determine what level others are at from their posts. I have come across people who know a couple of things really well and still run other parts of their systems in a way that leaves me slapping my forehead wondering how they didn't know X, Y and Z..... Then again, I'm probably guilty of the same - I simply don't know what it is i don't know....... <s>
You are right it is hard to gauge peoples skill levels from their posts. It is also hard to speak
as some people interpret some computer terms differently or right out of whack. Including me
on occassion :-)
This is why I love packet forensics! > if forces you to learn how the stack works and ideally how to better defend it and lastly interpret the results of your f/w and or ids system.
How can you tell by this that these packets are fragmented? I don't see any clear evidence of that.
This does NOT show all the TCP header information, some of which may be extremely valuable. For example, it doesn't show which bits are set (SYN, ACK, DF, etc.) Nothing here is enough to make any conclusive decisions on what exactly was happening.
02:07:15.196281 xxx.xxx.xxx.xxx.50464 > xxx.xxx.xxx.xxx.929: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20442, len 40)
0x0000 4500 0028 4fda 0000 2906 6ba6 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c520 03a1 3464 7893 0000 0000 ........4dx.....
0x0020 5002 1000 53d9 0000 0233 3503 3xxx P...S....35.11
Look at the S after the port number 929. This denotes it is a Syn packet. If this packet was not
fragmented the (DF) field would be there. Or if it was (MF) more fragmented it would be there
as well. The person may have set a virtual mtu which was too low to purposely cause it to fragment and or the OS has "DF" off by virtue of it's stack.
What I just said above is "conclusive" evidence. Not trying to sound like a ***** here but you
may want to consult your tcp/ip book and or do some more forensics, check out SANS,...
I don't talk bullshit, I know what I know, and I admit it when I don't.