Untraceable IP Address

Hi,

How do you know that this IP number accessed that webserver?

You can't perform network forensics unless you've a body of evidence to examine. Network traffic is by definition transient, so you've got to collect that traffic in order to proceed.

Your computer can lie to you - logs can be falsified, rootkits will hide their presence, etc. By contrast, you cannot lie to the network - this is where you will find the truth.

One of the ways you can do this is by application of Network Security Monitoring principles, whereby you collect and analyse every single byte of traffic crossing certain points on your network. Now this isn't going to be feasible in every scenario, but where you can do it it's massively beneficial.

I've written a bit about it here

http//wirewatcher.wordpress.com/2009/05/29/collection-is-king-part-one/

And here are some accounts of how it's useful

http//wirewatcher.wordpress.com/2009/06/19/prevention-eventually-fails-part-one/
http//wirewatcher.wordpress.com/2009/06/25/listening-for-the-grasshopper/

You may also like to look at SGUIL

http//www.sguil.net/

For instance, do you mean it maybe a spoofed IP and therefore the genuine IP is not know?

It's actually quite hard to do anything useful with a spoofed IP address when you're using TCP, due to the exchange of initial sequence numbers. If the randomness of the victim host's ISN is "random enough", the attacker will have a hard time guessing what it is. Even if they do manage to guess it (at odds of 12^32 against), they will never see the replies from the server. Like I say, using spoofed IP addresses with TCP isn't impossible, it's just really hard to do anything useful once you've done it.

I ran a WHOIS and a traceroute. For the traceroute all I got was timing dots on the screen waiting for the response. No response was received.

WHOIS data cannot be relied upon for accuracy. traceroute works by sending either ICMP echo requests or single UDP packets to a high destination port, depending on the implementation. The lack of responses you received were probably due to this traffic being filtered (firewalled) somewhere along the path. This kind of traffic (and ping, etc.) is often used during the reconnaissance phase of an attack, and is therefore usually denied by a firewall device.

hth,
alec

For the noobs that may be reading this thread

Keep in mind that ping and tracert (incremented ping) communicate via ICMP Echo Request/Echo Reply packets. It is common practice to block these at the firewall in an effort to reduce the likelihood of DoS/DDoS attacks as well as reducing just plain unwanted traffic.

HTTP/HTTPS use TCP packets. This may explain why a site may be un-pingable, but will respond to HTTP "get" requests.

Of course, this does not rule out deliberate methods of obscuring true IP addresses as mentioned in the previous posts.

Roland, sorry I missed your earlier comments and belatedly respond. I do hope in this intervening period you did manage to get some sleep )

Thanks, I did, but it's night again, and guess who can't sleep 😉

How do you know your visitor came through securityfocus? (I would guess you'd see the http-refer in the logs?)

Yes, you are right, that is what I chose to use at first instance, because it was the first obvious lead I had.

OK, the reason I've asked is that I've seen spoofed http-referer headers lately. I'm not sure what causes them, although I do know there are some firefox ectentions like refspoof and refcontrol that can create them on demand.

How do you know that this IP number accessed that webserver?

I am not sure I would actually know how to answer this question because the question hits on so many levels I couldn't be sure I would be responding to the question. For instance, do you mean it maybe a spoofed IP and therefore the genuine IP is not know? Or do you mean, beause the IP address is displayed in the stats therefore that is why you think it must have accessed the webserver or, or, or… Your question is most likely clear and it is possibly me, the way I have analysed your question, that has added these variables.

The reason I asked the question was that I was wondering if it was possible the logfiles and/or agent-headers had been tampered with. I have had cases in which IP adresses were changed in the logfiles (on unix-systems).

Like Alex wrote, spoofing raw two-way(!) TCP-connections is extremely difficult, and even if you succeed, you'd have to be "in the neighbourhood" of the victim. Reason being, that the TCP-packets that the answering server is sending, will be routed to the machine with the real IP-address.

Hijacking (W)LANs is another option (very popular right now w/ wireless lans), but even that would not explain that reserved IP address in your logfiles!

One possible solution could be that the server that produces the logfiles is somehow connected to a non-public (private) network that uses the IP addresses you mentioned. Not very good networkmanship, but you can get away with it on private LANs..

Would that make sense?

Roland

Digintel, LarryDaniel and Jamie, thanks for your replies.

Update
Here is another one, this time came through Forensic Focus

www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=3053

14.153.130.253 - Whois Information

Heh.
I just run a google query on "14.153.130.*", and lo & behold, some results popped up. It a .cz and a .cn site. Both have a guestbook/forum function, where the ip address is shown. The software the sites use seem to be totally different, so I'm still thinking this is maybe some private network connected to that server? VPN, terminating at that point, maybe?
(or some nifty function that permits local users to post as if they are remote?)

Interesting!

[edit]
As far as I can tell, the whole 14.0.0.0/8 range was supposed to be reserved for private data networks (datanets, X25, etc) in accordance with RFC 3330.
If they were used in X.25-to-IP gateways, that might explain something.

However, I just read that in 2007 the ranges were reclaimed by IANA, and I can't find any reference to what happened after IANA reclaimed the addresses.

So it's possible that some parties are still using the 14.0.0.0 range, even after IANA reclaimed it. It is also possible that IANA distributed the addresses to newcomers, without updating their WHOIS data..

Roland

How do you know that this IP number accessed that webserver?

I am not sure I would actually know how to answer this question because the question hits on so many levels I couldn't be sure I would be responding to the question. For instance, do you mean it maybe a spoofed IP and therefore the genuine IP is not know? Or do you mean, beause the IP address is displayed in the stats therefore that is why you think it must have accessed the webserver or, or, or… Your question is most likely clear and it is possibly me, the way I have analysed your question, that has added these variables.

The reason I asked the question was that I was wondering if it was possible the logfiles and/or agent-headers had been tampered with. I have had cases in which IP adresses were changed in the logfiles (on unix-systems).

Like Alex wrote, spoofing raw two-way(!) TCP-connections is extremely difficult, and even if you succeed, you'd have to be "in the neighbourhood" of the victim. Reason being, that the TCP-packets that the answering server is sending, will be routed to the machine with the real IP-address.

Hijacking (W)LANs is another option (very popular right now w/ wireless lans), but even that would not explain that reserved IP address in your logfiles!

One possible solution could be that the server that produces the logfiles is somehow connected to a non-public (private) network that uses the IP addresses you mentioned. Not very good networkmanship, but you can get away with it on private LANs..

Would that make sense?

Roland

It would and does make sense what you have said. Thank you for helping and making it clear. Thanks.

I think maybe there are a few errors leading you all down the garden path to speculating about spoofing and such like when the answer is much more simple.

Here is another one, this time came through Forensic Focus

www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=3053

14.153.130.253 - Whois Information

OrgName Internet Assigned Numbers Authority
OrgID IANA
Address 4676 Admiralty Way, Suite 330
City Marina del Rey
StateProv CA
PostalCode 90292-6695
Country US

—/snip/—

14.153.130.253 isn't in the ARIN database as it is an APNIC address ARIN covers the North American continent.

https://www.arin.net/knowledge/rirs/ARINcountries.html

If you stick that IP address in -

http//wq.apnic.net/apnic-bin/whois.pl

and use the -d option you'll get the answer.

The same applies to 1.1.111.33

I think you were a bit unlucky when you tried the IP address at http//en.utrace.de/?query=1.1.111.33 as it worked for me and showed me it was APNIC.

H

I think maybe there are a few errors leading you all down the garden path to speculating about spoofing and such like when the answer is much more simple.

14.153.130.253 isn't in the ARIN database as it is an APNIC address ARIN covers the North American continent.

https://www.arin.net/knowledge/rirs/ARINcountries.html

If you stick that IP address in -

http//wq.apnic.net/apnic-bin/whois.pl

and use the -d option you'll get the answer.

The same applies to 1.1.111.33

I think you were a bit unlucky when you tried the IP address at http//en.utrace.de/?query=1.1.111.33 as it worked for me and showed me it was APNIC.

H

It does now, pointing to China, but it didn't before!
I used the ole whois command at the unix prompt, and it gave me crap..
Mayby APNIC woke up & fixed things?

-Roland

digintel, it doesn't work that way.

IPs are like trees, you can move the leaves with no problem (4th octet), the branches are much harder, and the first octet is extremely complicated, and most likely may involve some international diplomacy. mrgreen

digintel, it doesn't work that way.

IPs are like trees, you can move the leaves with no problem (4th octet), the branches are much harder, and the first octet is extremely complicated, and most likely may involve some international diplomacy. mrgreen

So you're saying that the first octects (class-A networks)? are bound by country/region? Or by registry?

- Roland

The IP Address 217.41.10.191 is among a block of IP addresses that have been assigned by RIPE to BT, the RIPE database contains registration information of this network and related contact details.

Information related to '217.41.0.0 - 217.41.63.255'

inetnum 217.41.0.0 - 217.41.63.255
remarks *******************************************************
remarks * Please send abuse reports to abuse@btopenworld.com *
remarks *******************************************************
remarks * USED FOR CUSTOMERS WITH SINGLE STATIC IP ADDRESSES *
remarks *******************************************************
netname BT-ADSL
descr Single Static IP Addresses
country GB
admin-c BTOW1-RIPE
tech-c BTOW1-RIPE
status ASSIGNED PA
mnt-by BTNET-MNT
mnt-lower BTNET-MNT
mnt-routes BTNET-MNT
source RIPE # Filtered

role BT OPENWORLD OPERATIONAL SUPPORT
address BT
address Openworld
address UK
abuse-mailbox abuse@btopenworld.com
admin-c NPT14-RIPE
tech-c DY128-RIPE
nic-hdl BTOW1-RIPE
mnt-by BTNET-MNT
source RIPE # Filtered

% Information related to '217.32.0.0/12AS2856'

route 217.32.0.0/12
descr BT Public Internet Service
origin AS2856
mnt-by BTNET-MNT
source RIPE # Filtered