× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Steven:

On Wed, 12 September 2001, steven.donnellan@simonjersey.com wrote:

> Well, if it helps, the job reporting it is QZSOSIGN and our report says
> it's the AS/400's *SIGNON Server.  I don't think it's trying to TELNET,
> just make a connection.

Unfortunately, IBM does not pass a lot of useful info from the *SIGNON server 
to the exit point. Remote address is an example of info not passed.

If really necessary, I can think of three possible ways to track it down though.

First is simple reasoning. The *SIGNON server doesn't really do much. It's 
primary function is to handle authentication and return a connection handle to 
the client if successful. (Most of this is from observation, NOT from official 
IBM documentation.) This server is most often used by Client Access so that the 
various CA components can share a connection handle rather than needing to all 
authenticate separately. If you have other connectivity clients from other 
vendors, they often do not use this server. It isn't especially difficult to 
create a client sockets type function that tries to connect to the server, but 
there's little likelihood it's coming from anything but a CA client PC just 
trying to connect using the ADMIN profile. (Creating a function that _tries_ to 
connect is easy; actually succeeding is much more difficult.) So, look for 
whatever PC is out there that's being signed on to as ADMIN. If more than one 
exists, see if one has Client Access.

Second is a TCP/IP comm trace. Look for traffic to/from the *SIGNON server 
ports: 8476 for TCP, 9476 if SSL and maybe 32476 if SPX. Much of the data will 
be left out of the trace because the conversation is intended to be secure, but 
you can still see source addresses.

Finally, you can try the native "firewall" support available through OpsNav. 
You can set up packet rules and journal the events that result from a filter. 
By setting a filter against the appropriate *SIGNON port(s) and also making 
sure to include a filter rule that explicitly _allows_ all unfiltered traffic, 
you can get journal entries that will indicate source IP addresses. This can be 
a VERY tricky option, so be sure to understand it well before setting _ANY_ 
rules at all. Especially learn the RMVTCPTBL command from a direct-attach 
terminal first. I haven't looked at entries resulting from *SIGNON, so it might 
not be easy to isolate the entry you want.

Tom Liotta



--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788
Fax  253-872-7904
http://www.400Security.com


___________________________________________________
The ALL NEW CS2000 from CompuServe
 Better!  Faster! More Powerful!
 250 FREE hours! Sign-on Now!
 http://www.compuserve.com/trycsrv/cs2000/webmail/






As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.