Hacked? IP address changes in Event Log?

I've got a problem where brand new (and not on our network)
secondary IP addresses and gateways have suddenly showed up
on a Windows 2003 Server. It's not on the Internet, but on
a private network that does have web access via http proxy
to the outside world. I suspect I've either been hacked via
a workstation trojan somewhere on the internal network or
one of my co-workers is clandestinely sabotaging this machine.

Do system IP address changes show up in the Event Log to
see who did them, and from where? And if so, how do I look
for them?

 

Is it set to DHCP? Are you seeing a 169.x.x.x. address?

 

Even if I "hacked a machine silly" there would never be any point in adding
a secondary address to the thing,...especially if it was on a different
subnet. Short of VLANs, all IP#s on a nic must all be from the same
subnet,....any number that isn't in the same subnet would be worthless.

Most likely someone with physical access to the machine who either wasn't
paying attention to what they were doing, or didn't know what they were
doing has added that number manually.

 

No, we never use DHCP, all IP addrs in our organization
must be fixed, and set manually, by our internal
administrative policies.

Is there something special about a 169.x.x.x address that
we should know about?

BTW, I did find out that a co-worker that had physical
access to the machine was indeed monkeying around with the
network configs without my permission, but my PHB gave him
the Admin password and let him mess with the server behind
my back. (Grrrrr) That problem has been fixed with a new
staff policy this morning.

 

So I guess the answer must be 'NO'. The event log doesn't
track who changed the network configs when and from where???

Then all I can say is what a huge gaping oversight in lack
of security design that presents. You'd think that
tracking/auditing any changes in the network configs should
be deemed absolutely crucial to minimal fundamental system
security.

 

No,.... with minimal fundemental security it wouldn't have happen to begin
with. Minimal fundemental security includes keeping servers in a locked
room and not letting anyone else know the admin credentials. As I indicated
in my other post,..I think this was done by someone who didn't know what
they were doing by physically sitting at the machine itself and doing it
manually.

 

The 169 address space is reserver for AIPA. Automatic Ip addressing. If a
machine is set to DHCP but cannot locate a DHCP server it will assign itself
a 169. something address.

 

Ok. I didn't see the post where he indicated that address till after. But in
the first post it was called a secondary address. Maybe the terminology was
just used loosely, but an actual real "secondary address" cannot come from
DHCP (or even attempt to, then fail and get a 169.* address) to my
knowledge. Only a primary address can come from DHCP. Isn't that the case?

 

Minor correction. 169.254.0.0/16 is reserved for APIPA, not 169.0.0.0/8.
At least this is what all my Microsoft documentation states.

 

in message
:
message
: : > The 169 address space is reserver for AIPA. Automatic Ip addressing. If
a
: > machine is set to DHCP but cannot locate a DHCP server it will assign
: itself
: > a 169. something address.
:
: Ok. I didn't see the post where he indicated that address till after. But
in
: the first post it was called a secondary address. Maybe the terminology
was
: just used loosely, but an actual real "secondary address" cannot come from
: DHCP (or even attempt to, then fail and get a 169.* address) to my
: knowledge. Only a primary address can come from DHCP. Isn't that the case?

Correct. You cannot have a static IP address and also tell your client to
use DHCP to grab and use as a secondary address an address from a DHCP pool.

The security model is flawed and is the source of the issue here. I also do
not see the need of a policy meeting when a swift kick to the knee will
reinforce the current policy.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Online Support for IT Professionals -
http://support.microsoft.com/servicedesks/technet/default.asp?fr=0&sd=tech
How-to: Windows 2000 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;308201
FAQ W2K/2K3 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;291382

 

: No, we never use DHCP, all IP addrs in our organization
: must be fixed, and set manually, by our internal
: administrative policies.
:
: Is there something special about a 169.x.x.x address that
: we should know about?

Not if you're not using DHCP unless this co-worker also enabled a DHCP
scope.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Online Support for IT Professionals -
http://support.microsoft.com/servicedesks/technet/default.asp?fr=0&sd=tech
How-to: Windows 2000 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;308201
FAQ W2K/2K3 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;291382

 

: The 169 address space is reserver for AIPA. Automatic Ip addressing. If a
: machine is set to DHCP but cannot locate a DHCP server it will assign
itself
: a 169. something address.

Scott ole boy...

As an MVP, you should probably be aware it is APIPA, Automatic Private IP
Addressing and that the address range is 169.254.0.1 - 169.254.255.254/16
[255.255.0.0].

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Online Support for IT Professionals -
http://support.microsoft.com/servicedesks/technet/default.asp?fr=0&sd=tech
How-to: Windows 2000 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;308201
FAQ W2K/2K3 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;291382

 

: So I guess the answer must be 'NO'. The event log doesn't
: track who changed the network configs when and from where???
:
: Then all I can say is what a huge gaping oversight in lack
: of security design that presents. You'd think that
: tracking/auditing any changes in the network configs should
: be deemed absolutely crucial to minimal fundamental system
: security.

By default, no. You can set it to track certain modifications to your
settings however, if they login with the Administrator account, then it will
show the Administrator did it. See a problem here?

As Phillip mentioned, the security, or lack thereof, is the issue, not to
mention policies and procedures need to be looked at. The verbal security
model is flawed and a full security model ALWAYS includes written and signed
policies and procedures, including but not limited to, online notification
for each logon. A security model is to not only protect you
physically/virtually but also legally. If there are no consequences for
violating policy, your security model is flawed. If your security model
will not stand up in a court of law, it's flawed.

Yoda said it best. Either do or do not. There is not try.

Nobody should be using the administrator's logon and nobody should have
administrative rights with their everyday user account. There is more to
security rights than just user and administrative level access. Support
personnel should have an everyday user account, like everyone else. This
will also help when there are global issues because they should see them
before the users do. If your user finds a global issue before the support
personnel, then there is room for improvement. If changes are made in
production without first testing them in a test environment, then there is
room for improvement. Fail to plan, plan to fail.

They [support personnel] should also have another account for administrative
duties that require additional rights/access. This will provide more
information and shorten your investigation when breaches occur. Breaches
can and will occur. A good security model is to minimize the threat, not
eliminate it.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Online Support for IT Professionals -
http://support.microsoft.com/servicedesks/technet/default.asp?fr=0&sd=tech
How-to: Windows 2000 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;308201
FAQ W2K/2K3 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;291382