Re: ISA Monitor Shows Traffic from Computers that are powered off !

"Mourad" <Mourad@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:647484D5-4DE3-4BEA-A98F-4BA6E4AAB164@xxxxxxxxxxxxxxxx
I am an IT manager of a small company. We have a local domain server
(Win2003, Exchange) on which we have ISA 2004 installed.
Employees leave at 5:00pm and switch off their computers.
The last few days, I have been looking at the ISA logs, and I noticed that
there was traffic between some computers (on the internal network; and
they
are off !) and the server. This could be some weird worm/trojan that
spoofs
the IPs but I tried all kinds of anti-virus and I can't find anything. The
protocols I see in the logs are mostly RPC, Microsoft CIFS (TCP), and
NetBios.
I can't see the raw IP header in the logs (which is another question I
have
even though I configured ISA to log this as well)
Any ideas what that might be ?

Having used Checkpoint for about six years, and ISA now for about 18 months,
I can say for both products that they only rarely diagnose the cause of a
problem. Lack of direct MAC address inspection and filtering in ISA is a
weakness in the product.

The monitor in ISA should be used to suggest an area of interest for further
inspection by a sniffer. Ethereal (now Wireshark) is the most popular one,
and a very good one. Run the sniffer directly on the firewall, and target
the segment with the behavior that is abnormal. You will need to customize
the user interface of Wireshark. I find it very useful to add the source
and destination Mac address, and the source and destination ports. That
gives me a fuller picture and lets me quickly determine if someone is
spoofing the IP.

I will tell you right now that if you are looking for ISA to give you
definitive answers to the questions you are asking, it isn't going to do
that. Sniffers are intimidating and take a lot of time to learn to use
effectively. Welcome to state of networking, 2007. It's depressing.

Having been hacked twice now in the last six years, I've come to some basic
conclusions about the state of TCP/IP networking. Without getting into a
long winded philosophy discussion, the observations are:

- Client computers should never have exposed ports. You might make an
exception for RDP (3389) depending on your administration needs. But RPC
(135), the LANMAN Browsing protocols (137/138), the LANMAN file sharing
(139), SMB (445) are all the devil's tools. As soon as a single machine
gets cracked, the trojan starts to spread using the above ports. Given a
firewall in Windows XP and an excellent way to enforce its use by group
policy, no one has an excuse any more for not firewalling every damn port
that is exposed on a client computer. If you make one exception, you
should understand backwards and forwards what your risks are. I've
concluded for example that the agents used by many backup programs are
hopelessly insecure and exposing the agent port on clients just begs for
exploits against those (e.g., buffer overflows, using buffer overflows in
other services to get the backup account userid/password, etc).

- Users should never login as anything other than a normal User account, and
the file system should be severely tightened to limit write access to
sensitive areas. Never let users have read access to the SAM or the repair
directory that contains its backup. Never allow anyone into Power Users.
All of this is easy to say and hard to do without breaking the computer.

- Server computers should be protected on their own segments. You need to
do this in order to greatly restrict the traffic back out from those
machines. It's inevitable when exposing server ports that sooner or later
one gets cracked. When that happens you want to limit the collateral
damage by putting the server in a place where it cannot infect other
machines. While most people do this in a very crude way by putting
Internet exposed servers into a DMZ, I fully believe that the philsophy
applies to internal servers as well.

- Protecting the domain controllers is job number one. Once your DC is
cracked you are hosed and you can't really trust anything on your network
anymore since the trojan probably knows all of your accounts. The thing
is, this is a damn hard thing to do. Even if you firewall the domain
controller (very difficult to get the details right on that, even with the
recently published articles in Technet), anyone with the right credentials
can sail right in on the ports that *must* be exposed on a DC. You need to
1) create separate accounts for administering the DC; 2) make those separate
accounts incapable of being delegated; 3) restrict those accounts to only
logon from the console by using the Logon To button for the account profile;
4) Disable administrator; 5) Carefully inspect the file permissions on the
DC to make sure that nothing can be written to by any account that is not
one of the restricted accounts.

Doing a mostly-right implementation of the above four themes would block 95%
of all infections, or would at least limit their side effects incredibly.
It's rare to find a small company that does the above. That's why most
networks are target rich environments. I've paid dearly for sloppiness in
all of the above areas, and I'm not going to do that with new machines
again.

--
Will


.

Loading