TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems!
----------------------------------------------------------------------------
In order to conduct a rough system identification footprint type of scan
from Internet Security Scanner. Start your scan off utilizing the L1
Inventory scan.
An L1 Inventory scan will provide information about the target hosts, which
then can be later used to identify the operating system.
If you conducting a scan on a large network (i.e. not a Class 'C') break up
the scan into multiple parts, therefore eliminating the amount of time a
scan may take for those troublesome hosts on particular networks.
Another suggestion is create a Custom Policy and disable RPC scanning which
will provide a workaround for this finicky AIX and SGI boxes that is
running portmapper due to a default installation of the operating system
(i.e. portmapper 111)
(/start ad naseum)
Many services based on Remote Procedure Call (RPC) do not listen for
requests on a ``well-known'' port, but rather pick an arbitrary port when
initialized. They then register this port with a Portmapper service running
on the same machine. Only the Portmapper needs to run on a well-known port;
when clients want access to the service, they first contact the Portmapper,
and it tells them which port they should then contact in order to reach the
service. This second port may be for TCP or UDP access (depending on which
the client requests from the Portmapper).
The Portmapper service is itself built on top of RPC, which in turn uses
the XDR External Data Representation Standard Furthermore, one can use RPC
on top of either TCP or UDP, and typically the Portmapper listens on both a
well-known TCP port and a well-known UDP port (both are port 111).
This last generates six pairs of events, one for each request and reply for
the six actions the Portmapper supports: a null call; add a binding between
a service and a port; remove a binding; look up a binding; dump the entire
table of bindings; and both look up a service and call it directly without
requiring a second connection.
(/end ad naseum)
http://www.ciac.org/ciac/bulletins/g-16.shtml G-16: SGI rpc.statd Program
Security Vulnerabilities
http://www.networkice.com/Advice/Intrusions/2001728/default.htm for some
light reading on RPC ..
/hope this helps..
Chris R.. - your turn. :)
At 12:16 PM 07/20/2001 -0400, Dan Ozdowski wrote:
>TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
>[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems!
>----------------------------------------------------------------------------
>
>[EMAIL PROTECTED] wrote:
>
> > Got a complaint from an SA about the impact of Internet Scans.
> > Is this a known issue, if so is there a fix or work around?
>
>In numerous instances we have noted the System Scanner (6.1 in our case)
>messing with machines. In many cases, a printer will lock up and just
>need a touch of the "reset" button - in other cases the portmapper will
>hose. There are a variety of instances where we've seen consistent
>crashes on older AIX machines, and some SGIs - our only workaround has
>been to try to identify which check was causing the issue and either
>eliminate that check or use hostfiles with the susceptible machines
>removed.
>
>On a somewhat related issue, I would like to reiterate the request that
>I've heard on here before: termination of single machine scans. It is
>endlessly frustrating to see a scan run almost to completion, only to
>lose it and need a complete "redo" because one particular machine hangs
>its scan. It has been happening more and more to me recently, and I've
>been able to note no patterns in which machines are causing trouble.
>There have been WinNT, 2000,AIX, and Solaris machine all "hung" - and
>machines that hang once will be fine the next scan through!!! Another
>machine may act up, of course - but again, to no discernible pattern.
>
>The ability to stop a single machine's scan yet keep you bulk results is
>(in my world) the single most important feature that could be added to
>this program.
>
>Thanks,
>Dan Ozdowski
>
>UVA Network Systems
