Hi, Managers;
This a great list. I appreciate your help:
Richard Lacroix <Richard.Lacroix@sisca.com>
Claude Charest <charest@chou.CANR.Hydro.Qc.Ca>
Michael J. Connolly <mjconnly@newton41.ckcorp.com>
Timothy P. Peterman <timothy.p.peterman@lmco.com>
Ali q8@sunuio.comwarehq.com.ec
Mark Hargrave <hargrme@wisdom.maf.nasa.gov>
Franczyk, Gary <gfranczyk@carbomedics.com>
Peter Laws <plaws@enterprise.nssl.noaa.gov>
Michael Kriss <kriss@fnal.gov>
Larry Chin <larry@sprint.ca>
Jim McVey <jmcvey@nhgri.nih.gov>
Gustavo A. Lozano <glozano@Colinter.net>
Douglas Palmer <palmer@nyed.uscourts.gov>
Sergey Mokryshev <mokr@child.ru>
Roger Fujii <rmf@lookhere.com>
Dan Anderson <dana@dtn.com>
Dennis Martens <MARTENSD@health.qld.gov.au>
Carlo Musante <carlo@hub.eng.wayne.edu>
Chris Wheeler <chris.wheeler@wcom.com>
Chad Price <cprice@molbio.unmc.edu>
Karl Baker <Karl.Baker@matrox.com>
Sean Quaint <squaint@provide.net>
Nikos George <nikos@jimmy.harvard.edu>
Luc Lauwers <luc.lauwers@eds.com>
Justin.Stringfellow@barclays.co.uk
Wolf Schaefer <schaefer@wolfe.llnl.gov>
Jeff Waldron <jeffdw123@hotmail.com>
And following are the very helpful/interesteing replys:
-----------------------------------------------------------------
From: jerry lu <oxygen@helix.nih.gov>
Hi,
If you run "man in.telnetd" you'll see the answer:
==================================================================
The banner printed by in.telnetd is configurable. The
default is (more or less) equivalent to "`uname -sr`" and
will be used if no banner is set in /etc/default/telnetd.
To set the banner, add a line of the form
BANNER="..."
to /etc/default/telnetd. Nonempty banner strings are fed to
shells for evaluation. The default banner may be obtained
by
BANNER="\\r\\n\\r\\n`uname -s` `uname -r`\\r\\n\\r\\n"
and no banner will be printed if /etc/default/telnetd con-
tains
BANNER=""
==================================================================
The same rule applies to in.ftpd (file /etc/default/ftpd). Run "man
in.ftpd" for details.
FYI, disabling the banner would probably give you a little help on
securing your machine, but not too much! There are lots of hacking tools
available on the Internet which can tell the OS of your machine by
analysing the responsive packets. Check out the Phrack magazine, volume
8, issue 54, article 9: "Remote OS detection via TCP/IP Stack
Fingerprinting" for more information.
Jerry
------------------------------------------------------------------
From: Sergey Mokryshev <mokr@child.ru>
/etc/default/telnetd
BANNER="\n\n Amstrad 128K Microcomputer (v3)\n (C) 1985 Amstrad Consumer
\
Electronics plc\n and Locomotive Software Ltd.\n BASIC
1.1\n\n"
Sincerely,
==============================
Sergey Mokryshev <mokr@child.ru>
Moscow Children Computer Club
Network Administrator
http://www.child.ru/
==============================
----------------------------------------
From: Luc Lauwers <luc.lauwers@eds.com>
Subin,
the 'SunOS 5.6' message is the default message printed by the telnet
daemon.
>From Solaris 2.6 on this message is customizible.
Create a file 'telnetd' in /etc/default, and put in a line with:
BANNER="Your message here".
If you make that BANNER ="", you won't get any extra info from telnetd.
See man telnetd (1M) for all the details.
Hope this helps,
Luc.
----------------------------------------
From: dana@dtn.com
Here is some basic Solaris Security stuff I generally do. The answer you
are looking for is in #2 and #6.
Dan Anderson
1. Action: Disable direct root logins (telnet)
Procedure: Uncomment the line in /etc/default/login that reads
#CONSOLE=/dev/console
Results: It now requires 2 logins to have root access (telnet), a
valid
user, and the root password
2. Action: Modify the telnet greeting from disclosing the operating
system
Procedure: Create a file named /etc/default/telnetd. In this file
place the
line BANNER=?_______________\\r\\n? (Where _____ is whatever message
you
want)
Results: Not knowing what OS a server is running makes breaking into
it MUCH
more difficult.
3. Action: Disable root ftp login
Procedure: Create/edit the file named /etc/ftpusers. Ensure the root
user
is listed. Also consider other
Users who do not REQUIRE ftp access.
Results: It now requires 2 logins to have root access (FTP), a valid user,
and the root password
4. Action: Set umask for FTP
Procedure: Edit /etc/default/ftpd and make the umask the most
restrictive
that you can. Consider 027 or 077.
Results: New files transferred in are more secure, reduces incidents
of
Trojan Horses, and Viruses.
5. Action: Set system umask
Procedure: Edit the /etc/profile and make the umask the most
restrictive
that you can. Consider 027 or 077.
Result: New files created are more secure, the user must explicitly
give away
rights for their files.
6. Action: Modify the FTP greeting from disclosing the operating system
Procedure: Create a file named /etc/default/ftpd. In this file place
the
line BANNER=?_______________\\r\\n? (Where _____ is whatever message
you
want)
Results: Not knowing what OS a server is running makes breaking into
it MUCH
more difficult.
7. Action: Make sure you are not running anonymous ftp (unless you want
it)
Procedure: Make sure that there is NOT a user named ftp listed in the
/etc/passwd.
Result: Disables anonymous ftp
8. Action: Ensure all unused services are disabled.
Procedure: Edit the /etc/inetd.conf and comment out the lines for
services
you do not NEED.
Result: With each removed service you have removed a potential
security
hole.
9. Action: Disable processes that are not needed
Procedure: Look through the /etc/rc2.d and /etc/rc3.d directories for
files
with the name S______. These files are scripts that are executed when
init
changes run levels (2 is multiuser and 3 is multiuser with exported
file
systems). Any/all of these can be shut off by renaming them to ?_____
(where
? is any character but S or K (S ? Start K ? Kill).
? is any character but S or K (S ? Start K ? Kill).
Results: Less processes not only increases performance, but also
reduces the
security risks (i.e. sendmail)
10. Action: Verify that you are ONLY exporting the file systems you NEED
to,
and then only with VERY restricted rights.
Procedure: Edit the /etc/dfstab
Results: Enhances security by ensuring unauthorized personnel do not
have
access to data.
11. Action: Change the default message of the day (motd) so it does not
disclose the OS.
Procedure: Edit/remove the /etc/motd file.
Results: Not knowing what OS a server is running makes breaking into
it MUCH
more difficult.
12. Action: Extend the minimum password length to 8 characters
Procedure: Modify the /etc/default/passwd so that the pass length = 8
Results: Eight characters is now recommended by government security
experts.
Longer passwords = more capability to be secure passwords
13. Action: If acceptable set up password aging (Most useful for
interactive
users (i.e. not automated processes).
Procedure: Modify the MINWEEKS and MAXWEEKS parameters in
/etc/default/passwd file
Results: By forcing users to periodically change their passwords
compromised
passwords will expire
14. Action: Keep OS current and document Patch/fix versions
Procedure: Routinely download and install recommended patch clusters
from
sunsolve.sun.com
Result: Bug fixes/Security fixes are distributed via this means. If
well
documented then you will be able to quickly ascertain if a security
advisory
affects you.
15. Action: Ensure logging is setup to log su?s and the information is
stored
on at least 1 other machine.
Procedure: Edit the /etc/default/su file to ensure that the SULOG is
set to
/var/adm/sulog and the SYSLOG is set to YES. Then edit the
/etc/syslog.conf
to send a copy of ALL messages to another host.
Result: It is critical to know who is su?ing. When logged
appropriately it
is a good indicator for security. It is also important to have another
copy
of the log files so that it is more difficult to hide a break in.
16. Action: Disable X connections to the server.
Procedure: Add xhost ? to the CDE startup file
(/usr/dt/config/sys.dtprofile
or better /etc/dt/config/.dtprofile
Result: Unauthorized users will not be able to display to your X
server.
17. Action: Consider restricted/no shell for users
Procedure: If a user does not require a full featured shell account
then
give them a shell (In /etc/passwd) of either /bin/rksh for a severly
limited
shell or /bin/false for no shell. Do this for system accounts as well
if
possible.
Result: Less users will have expanded access to your systems.
18. Action: Strongly consider installing a TCP/IP wrapper such as
TCPWrap or
IPFilter
Procedure: Varies by system selected
Results: TCP/IP access is logged and/or blocked as necessary.
19. Action: Disable all ?Trusts? setup
Procedure: Write a script that finds all hosts.equiv and .rhosts
files,
notes their location and removes them. Run this script daily from
cron, and
examine what it finds.
Result: The system will not automatically trust other systems. Your
users
will not be able to easily decrease your security.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:17 CDT