how to protect a non-expiring application id with direct log on?

[Crystal_1]

It is necessary to creat this id, however, from the security's perspective, how to secure the system?

Thanks

[Michael Tully]

Hi,

If your system is 'trusted' you can change
the security information of any user. All
you need to is modify the user account and
change the security policy for that user.

sam --> accounts for users and groups
users --> select the user
From the actions pull down menu select
modify security policy and make your
changes.

In other words you can still secure your
system and still have application login
id's that don't have expiring passwords.

To set you system as 'trusted' all you need
to do is run:

# /usr/lbin/tsconvert

Be aware that after running this command all
user accounts will have their passwords set
to a force change.

HTH
-Michael

[Steven Sim Kok Leong]

Hi,

I hope I get your question right.

If you wish to prevent remote logons for this application id, you can block the user from host access and file transfers in your sshd configuration file sshd_config (if you are using SSH communication's ssh ie. ftp://ftp.ssh.fi/pub/ssh)

If you wish to restrict remote logons, don't use one-factor authentication of simply password alone, assign minimal privileges to this account and adopt good accounting mechanisms.

Authentication:

Restrict in your sshd_config by username and source IP address.

Minimal privileges:

You can configure restricted SAM for this user such that this user can only perform restricted actions listed in this menu. man sam for more information. You can insert this in /etc/profile within the traps (trap "" 1 2 3 and trap 1 2 3) so that the user cannot break out /etc/profile.

Convert your system to trusted (TCB) via tsconvert. This allows access control measures to be taken.

# sam -r

Accounting:

Ensure proper accounting mechanisms for this user. Enable acct ie. man acctcom and runacct.

Hope this helps. Regards.

Steven Sim Kok Leong.

[Crystal_1]

Thanks for your ideas...

I am thinking that this application id is used 24 hours everyday to collect the data from other servers. Although I know some security policies can be set up through sam, they are not enough. If others know this id and its password, the system can be attcked any time. The most important thing is that it is non-expiring, in other words, one password can be used forever. I am looking for a solution to protect our critical business data/severs, such as any restricted shell environment, etc...

[Steven Sim Kok Leong]

Hi,

I would suggest that you use restricted SAM and give the user very limited access to your server.

In your /etc/profile:

trap "" 1 2 3
if [ "$LOGNAME" = "nonexpiringuser"
then
/usr/sbin/sam -r
exit 0
fi
trap 1 2 3

Also, restrict by IP address so that only specific clients (IP addresses) can login to this user account. If you use the SSH implementation from ftp.ssh.fi, you can bind IP address to username.

In your /etc/profile,

trap "" 1 2 3
if [ "$LOGNAME" = "nonexpiringuser" ]
then
if echo $SSH2_CLIENT|awk '{print $1}' | grep 1.2.3.4 >/dev/null 2>&1
then
echo access from valid client
else
echo access from invalid client
exit 1
fi
fi
trap 1 2 3

Hope this helps. Regards.

Steven Sim Kok Leong

[Deepak Extross]

If you want to allow the user to execute only one command or call up only one executable, try adding a
exec
in the user's startup file (.profile or .login)
This will automatically invoke when the user logs in and log him off when terminates.

If, however, the user really does need access to the command-line, consider the use of rsh or rksh.

Good Luck!

[K.Vijayaragavan.]

Hi,

If that account is "root" then you can use the file is "/etc/securetty" file to restrict it atleast to one terminal.

-Vijay

[harry d brown jr]

Crystal,

Instead of having a server going out and collecting data, wouldn't it be easier to have the servers send the data? If it's system info, you could easily use syslog. If it's true data, then you could easily have those servers push their data via ftp using perl's ftp modules. It's always been my standard because serverA (the processes) know when they have the data collected, but the collecting server has no idea if the data is ready, and having it poll the data servers can be costly. Plus, by having the data collectors push the data, they can detect when the data collector is unavailable, and then they can send off the proper alerts.


live free or die
harry

[Darrell Allen]

Hi Crystal,

One of the nicest things you can do for a hacker is to have accounts with a password that never change.

That said, how is the data "collection" to be done? ftp, rcp, scp, client/server program? Where is the data collection/transfer originated? That is, where are the connections being originated? From the server with the non-expiring account? From the other systems?

In some cases you could lock the password for the application id.

It's kind of hard to address your issue without a better idea of what you are doing. Perhaps you could share a brief overview.

Darrell