List Info

Thread: IP address impersonation




IP address impersonation
user name
2006-09-28 22:53:36
We have a remotely hosted 6.0 server that has apparently
been 
impersonated by a colocated server. The provider allows root
access and 
we have set up our server from a base 6.0 installation. We
were 
allocated an ip address and mostly we have had a good
experience with 
this setup. However, twice in three weeks we have had
difficulty in 
logging in and have had to crash boot the server. Analysis
of the logs 
revealed that another machine on the hoster's network had
assigned 
itself our ip address. Even when we provided the suspect mac
address it 
seemed the hoster had trouble in finding out/appreciating
what the 
problem was.

I have little experience of this sort of thing, but can
anyone else 
offer some advice on

1) is this a recognized form of attack? I can see that it
could be used 
for password harvesting and traffic interception, but are
there other 
implications.

2) Are there ways to mitigate this kind of problem? We have
other hosted 
servers on machines with similar (root) access. They
presumably could 
also be impersonated. We found this out by inspection of our
own log 
files; could the provider be doing something more to prevent
this?
-- 
Robin Becker
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"
IP address impersonation
user name
2006-09-28 23:26:54
Taking over an IP is a known way to inspect traffic. 
Essentially if done 
well the spoofing server will act like a proxy server,
inspecting the data 
and sending it along to the correct server.  Another way,
particularly at a 
data center is to setup a server running the NIC in
promiscuous mode so 
that nic will catch any packets on the netowrk.

Is the data center bringing up a server with a duplicate IP?
 Or are they 
attempting to change your server's IP when they bring up a
server on your 
assigned address?

It also could be just bad book keeping on the data center's
part, having 
re-used an IP and not taken it completely out of another
server's 
configuration files.

         -Derek

At 05:53 PM 9/28/2006, Robin Becker wrote:
>We have a remotely hosted 6.0 server that has apparently
been impersonated 
>by a colocated server. The provider allows root access
and we have set up 
>our server from a base 6.0 installation. We were
allocated an ip address 
>and mostly we have had a good experience with this
setup. However, twice 
>in three weeks we have had difficulty in logging in and
have had to crash 
>boot the server. Analysis of the logs revealed that
another machine on the 
>hoster's network had assigned itself our ip address.
Even when we provided 
>the suspect mac address it seemed the hoster had trouble
in finding 
>out/appreciating what the problem was.
>
>I have little experience of this sort of thing, but can
anyone else offer 
>some advice on
>
>1) is this a recognized form of attack? I can see that
it could be used 
>for password harvesting and traffic interception, but
are there other 
>implications.
>
>2) Are there ways to mitigate this kind of problem? We
have other hosted 
>servers on machines with similar (root) access. They
presumably could also 
>be impersonated. We found this out by inspection of our
own log files; 
>could the provider be doing something more to prevent
this?
>--
>Robin Becker
>_______________________________________________
>freebsd-questionsfreebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
>To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"
>
>--
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
>MailScanner thanks transtec Computers for their support.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.

_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"
IP address impersonation
user name
2006-09-29 07:40:02
Robin Becker wrote:

> 1) is this a recognized form of attack? I can see that
it could be used 
> for password harvesting and traffic interception, but
are there other 
> implications.

ip spoofing is a well known attack.

> 2) Are there ways to mitigate this kind of problem? We
have other hosted 
> servers on machines with similar (root) access. They
presumably could 
> also be impersonated. We found this out by inspection
of our own log 
> files; could the provider be doing something more to
prevent this?

All hosts and routers hold a local dynamic table of arp
addresses and 
their corresponding ip addresses. Since the ip may change,
these are 
held only for one minute and each node only keeps the
addresses they 
actually communicate with.

When some node need to communicate with another node it does
not know 
the arp address of it sends out an arp request
"WHO-HAS" to all nodes on 
the network.

If two nodes uses the same ip, they will both respond and it
is somewhat 
random who "wins". But one can use an attack
called "arp cache 
poisoning" to make a particular arp address appear.

There is a solution to this problem: Static arp-tables. This
requires 
that your provider in the router adds machines arp addresses
and their 
ip addresses in a static table. Static by nature these are
not flushed 
so the spoofing will fail.

Only the nodes that maintain a static arp table will ignore
the 
spoofing, so if you need to communicate with other hosts on
the network 
these need also to have the static table.

It is likely that your provider don't want to do the trouble
of 
maintaining a static table. To prove the problem to them you
can use 
arpwatch to monitor changes and document the problem.

You may also use arping to ping arp addresses, this may help
you claim 
your ip - like the arp cache poisoning attack. This means
that the other 
host will loose connection and maybe make the admin aware
that there are 
problems.

But the real solution is to get to the administrator of the
offending 
host and make him change the ip. Your provider should keep
track of who 
has been assigned which ip. If someone else in error uses
your ip, some 
other ip must be free and the provider should be able to
identify who it is.

Unfortunately, AFIAK there is no way of identifying which
machine is 
offending from analysing the network traffic, but the arp
address is 
normally printed on the network interfaces so physical
inspection will 
do it.

Things get complicated, because it is possible to change the
arp 
address. This means that you can set your arp address to the
same as the 
offending host.

If you're connected by a hub or a wireless network, both
will get 
traffic to both hosts and it really becomes a mess if both
try to 
respond. If you're on a switched network no one knows who
gets the packets.

This arp spoofing is the ultimate way of hiding yourself
behind someone 
else (or the other way round).

I once had ip's static assigned on a network, but users
couldn't figure 
out what these numbers were and every once in a while
someone would use 
the routers ip as their own ip taking down the entire
network. That was 
when I learned about dhcp! (and all the arp spoofing stuff).

Note, ARP is the protocol, the network interface address is
often called 
MAC.

Cheers, Erik
-- 
Ph: +34.666334818                      web: http://www.locolomo.org
X.509 Certificate: http
://www.locolomo.org/crt/8D03551FFCE04F0C.crt
Key ID:
69:79:B8:2C:E3:8F:E7:BE:5D:C3:C3:B1:74:62:B8:3F:9F:1F:69:B9
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"
[1-3]

about | contact  Other archives ( Real Estate discussion Medical topics )