Tuesday Sep 05, 2006

Laptop Upgrade to Nevada - b47 - Security Settings

Today, I would like to go over a few of the changes that I made to my laptop in order to improve upon its overall security configuration. It should be noted that the list of changes made is relatively small (from the default) and is based upon how I plan to actually use the system. As a result, you may need more or different changes than those listed here based upon your specific needs. With that said, let's get into the details.

Nevada by default enforces the settings specified by the Secure by Default project. As a result, there were no network services listening on my laptop for external connections (with the exception of Secure Shell). This is a great start and significantly simplifies getting a desktop or laptop secured and ready for the network. Since I generally do not permit inbound access to my laptop, I also disabled Secure Shell:

blackhole$ pfexec svcadm disable ssh
blackhole$ svcs ssh
STATE          STIME    FMRI
disabled       21:30:12 svc:/network/ssh:default

At this point, there are literally no local services listening that an external person could access. As there is a need, I will temporarily enable services such as SSH or perhaps VNC (x11vnc), but the default is to leave them in a disabled state until they are required.

Next, I configured IP Filter - the firewall software built into Solaris. I have been a huge fan of IP Filter for years and was absolutely thrilled to see it integrated into Solaris 10. The configuration that I use is based upon a version for laptops that was developed by Darren Moffat. To be completely honest, I have a few different firewall policies that are automatically installed based on the network profile that I have selected. This allows me, for example, to have one firewall policy when I am connected via Ethernet on my home network and a different one when I am travelling.

Before installing the firewall policy, I needed to configure the file /etc/ipf/pfil.ap. Since I am working from a Toshiba Tecra M2, I had to uncomment the entry for the e1000g driver and add an entry for the ath driver as follows:

# egrep "e1000g|ath" /etc/ipf/pfil.ap
e1000g  -1      0       pfil
ath     -1      0       pfil

Next, I installed Darren's firewall configuration, /etc/ipf/ipf.conf. I will not provide my specific settings - leaving the firewall configuration as an exercise for the reader.

#
# ipf.conf
#
# IP Filter rules to be loaded during startup
#
# See ipf(4) manpage for more information on
# IP Filter rules syntax.

pass out quick all keep state keep frags

# Drop all NETBIOS traffic but don't log it.

block in quick from any to any port = 137 #netbios-ns
block in quick from any to any port = 138 #netbios-dgm
block in quick from any to any port = 139 #netbios-ssn

# Allow incoming IKE/IPsec

pass in quick proto udp from any to any port = ike
pass in quick proto udp from any to any port = 4500
pass in proto esp from any to any

# Allow ping

# pass in quick proto icmp from any to any icmp-type echo

# Allow routing info

# pass in quick proto udp from any to port = route
# pass in quick proto icmp from any to any icmp-type 9 # routeradvert
# pass in quick proto igmp from any to any

# Block and log everything else that comes in

block in log all
block in from any to 255.255.255.255
block in from any to 127.0.0.1/32

For the first time IP Filter configuration, there are a few other steps that I will not cover here now. Check out the documentation for the specifics.

With this complete, I turned my attention inward for a few additional configuration changes. You can read more about them in the Solaris 10 Benchmark published by the Center for Internet Security.

First, I modified the /etc/security/policy.conf file to set my default crypt(3C) algorithm to Sun MD5:

# The Solaris default is the traditional UNIX algorithm.  This is not
# listed in crypt.conf(4) since it is internal to libc.  The reserved
# name __unix__ is used to refer to it.
#
CRYPT_DEFAULT=md5

This is useful for a variety of reasons most notibly because it would freak out any script kiddy running stock versions of Crack and john in an attack to guess passwords. In their stock configurations (just download, compile and run), neither of these tools can successfully deal with the Sun MD5 password format. See the crypt_sunmd5(5) manual page:

     This module is designed to make it difficult to crack  pass-
     words  that  use brute force attacks based on high speed MD5
     implementations that use code inlining, unrolled loops,  and
     table lookup.

Moving on, I enabled the following coreadm configuration:

# coreadm
     global core file pattern: /var/core/core_%n_%f_%u_%g_%t_%p
     global core file content: default
       init core file pattern: core
       init core file content: default
            global core dumps: enabled
       per-process core dumps: disabled
      global setid core dumps: enabled
 per-process setid core dumps: disabled
     global core dump logging: enabled

This is nice in that the system will notify me (via syslog) of core dumps:

Sep  5 15:01:16 blackhole genunix: [ID 603404 kern.notice] NOTICE: core_log: sleep[5691] core dumped: /var/core/core_blackhole_sleep_101_101_1157482876_5691

and will store the core files in a protected directory, /var/core:

$ ls -ld /var/core
drwx------   2 root     root         512 Sep  3 21:13 /var/core

Moving along, I also set the following parameters:

# grep "noexec_user_stack" /etc/system
set noexec_user_stack = 1
set noexec_user_stack_log = 1

# grep nfs_portmon /etc/system
set nfssrv:nfs_portmon = 1

# grep TCP_STRONG_ISS= /etc/default/inetinit
TCP_STRONG_ISS=2

These are typical changes and are discussed in older Sun BluePrints as well as the CIS Benchmark. Next, I also created the loginlog file:

# ls -l /var/adm/loginlog
-rw-------   1 root     sys            0 Sep  3 21:16 /var/adm/loginlog

and enabled debug logging in syslog:

# grep '\*.debug' /etc/syslog.conf
\*.debug                                         /var/adm/debug

Be sure to create the /var/adm/debug file before restarting syslog. In addition, I also disabled login access on the laptop's serial ports:

# pmadm -d -p zsmon -s ttya
# pmadm -d -p zsmon -s ttyb
After installing a few basic warning banners in the typical places (see the CIS guide), I also changed root's home directory, converted root to be a Solaris role, and assigned the rights to assume root to only my local account:

$ getent passwd root
root:x:0:0:Super-User:/root:/sbin/sh

$ grep "\^root:" /etc/user_attr
root::::type=role;[...]

$ roles
root

Lastly, using the normal methods, I also enabled and configured Solaris auditing and BART so that I can keep tabs on what is going on. Of course, this is also in addition to BIOS and GRUB security changes that I will not cover in this post.

Is this all you need to do? Well, unfortunately - it depends. There are certainly lots of other things that I could do.

For example, I could disable rhosts authentication for the rsh and rlogin services. Recall however that each of those services is (1) disabled by default and (2) subject to the firewall policy in place. So, to successfully exploit this path, an attacker would need to change both of these settings - which require administrative privileges - enough to add rhosts entries back into /etc/pam.conf. So for me, it was about maximizing security while minimizing change. In this specific case, changes to those states or configuration files would be detected by BART and Solaris Auditing. Similarly, there is not much point (except as a reminder) for me to enable password aging, history or complexity rules when I am the only user on the system (and the system does not accept remote incoming connections - except in very limited cases).

You get the point... For another perspective, check out how John Clingan approached this problem.

My longer term hope is that we can further reduce the changes required out of the box by making many of the most common settings default Solaris values. That way, everyone could benefit from a stronger out of the box installation posture. SBD was a great step forward down this path. Let's look at a few examples of RFEs that are outstanding right now:

Would you like to see these implemented? If so, let us know! If you have a valid Solaris support contract, you can also contact support to have you added as a customer call record for one or more of these RFEs. Just as important - are there other security changes that you would like to see made by default in future versions of Solaris! If so, be sure to tell us! File bugs or RFEs! Talk with us! and (if you are so included) participate and help us make the changes!

Before I sign off, you may be wondering why not just use the Solaris Security Toolkit and be done with it? Certainly, I could have used the (currently unreleased) version that supports SBD and implemented these changes. In fact, most companies may want to go that route since SBD alone (as demonstrated above) covers just part of the problem space. The reason however is simple. I wanted to demonstrate what it would take for you to quickly and easily secure a new OpenSolaris or Nevada laptop from an out of the box state. All too often the tools and guides make people think that it is harder than it really is. Certainly, the Toolkit is essential for building repeatable, auditable configurations, but in the case of my one off - the time difference to implement is negligible.

Take care,

Glenn

Technorati Tag:

Saturday Sep 02, 2006

Laptop Upgrade to Nevada b47 - A Few More Things

[Read More]

Friday Sep 01, 2006

Laptop Upgrade to Nevada b47 - The Next Day

Several hours into day 1 of the upgraded laptop and no significant issues to report. The complete installation went smoothly and all of my productivity tools appear to have retained their settings and are working as expected including:

This is in addition to the other tools I mentioned in my previous post, including: frkit, Nvidia drivers, punchin, pkg_get, and inetmenu. The Nvidia drivers are correctly pushing my screen image (by default) to both the laptop LCD and my external flatscreen. What more count I ask for?

During the course of my new installation, I set aside enough space to install Trusted Extensions, so that will be my next big step, but before I do that, I am going to put the laptop through its paces for a few days to make ensure everything continues to work as expected.

You really have to love it when things just work!

Take care,

Glenn

Technorati Tag:

Thursday Aug 31, 2006

Laptop Upgrade to Nevada b47

Well, it has taken me quite a while but I finally have bitten the bullet and started upgrading my laptop to a newer version of Nevada. Given that my laptop is my office, I am always a little hesitant to change things when everything is working smoothly. An honestly, that has been the case for quite some time as is evidenced by the fact that I am still running (dare I say it) build 18!

While I have a number of other systems at home at build 42, I wanted to be able to showcase some of the latest and greatest technology found in the newer builds including (but certainly not limited to): SBD, ZFS, and Trusted Extensions. In fact, I have a number of conference sessions coming up (I will write about those later) where it will be great to highlight this great technology.

I will not go into the gory details, but for those interested, I did follow the usual procedures, namely (1) backup existing content, (2) download and burn the DVD ISO, (3) boot the DVD ISO and do the initial configuration, (4) click install and sit back. Well, that is exactly where I am right now... Sitting back - about 68% through the installation. I have also downloaded the latest essentials for my M2 including: frkit, Nvidia drivers, punchin, pkg_get, and inetmenu. With this and a "quick" download of StarOffice 8, I will be back in business in no time. Well, at 78% complete, I have enough time to go brew some tea, so I will bid you all good night.

Take care,

Glenn

Technorati Tag:

Solaris Package Companion on OpenSolaris.org

This note is to announce the new Solaris Package Companion OpenSolaris project page (child of the SVR4 packaging project page) at:

http://www.opensolaris.org/os/project/svr4_packaging/package_companion/

Check it out to get all of the latest and greatest information, usage instructions, code and examples.

Love to hear what you think!

g

Technorati Tag:

Wednesday Aug 23, 2006

New Solaris Secure by Default Presentation



Scott Rotondo just posted a new Solaris Secure by Default presentation that is being used to raise awareness of SBD including what it is, why it is important and how it is implemented and used. Check it out!

For more information check out these other SBD references:

References: Part 1 of 3 Part 2 of 3 Part 3 of 3

Technorati Tag:

Thursday Aug 17, 2006

Solaris 10 Security - Technical Presentation

A while back, I posted a version of my Solaris 10 technical deep-dive presentation. Well, I have finally had a chance to update it based on all of the latest goodies in Solaris 10 Update 1 and 2 as well as Nevada. I have also added a bunch of new examples and screenshots.

For those who may have missed it, the goal of this presentation is to provide a technical "deep dive" overview for those interested in learning more about the security capabilities and features of Solaris 10. This presentation serves as a bridge between the higher level marketing presentations and technical presentations that are specific to individual technologies.

I would like to thank Mark Thacker, Darren Moffat, Casper Dik, and Shawn Emery for their contributions to this presentation! So if this topic interests you, please download the latest version and send me your feedback! I will use the comments received to help guide future updates of the presentation. Also, be sure to let your sales team know if you would like to have someone from Sun come and talk with you about Solaris 10 security or any of the content in this presentation. Thanks in advance!

Take care!

Glenn

Technorati Tag:

Wednesday Jul 19, 2006

Solaris Secure by Default - Part 3



Before I begin, I would like to point everyone to a posting by Scott Rotondo, one of the architects behind the Secure by Default project. Check it out and let him know what you think of this new Solaris enhancement!

Today, SBD is an all or nothing proposition - it is either enabled or disabled using the new netservices(1M) command. For many organizations, this is not enough. Very often, they must configure their systems such that some services are "off" or in a "local only" mode while others must be enabled or "open" to support a business or technical requirement. It is important therefore to be able to understand exactly what SBD is doing so that you can better tune the security configuration of your systems based on your specific needs and requirements. As we have noted previously, a SBD configuration is created by (1) disabling services or (2) adjusting service properties to put the service into a "local only" mode.

The enabling and disabling of services is a trivial matter. Simply using the svcadm command with the enable or disable action to adjust the services that interest you. Since this is a very easy matter, this will not be the focus of this posting. For the third and final (for now) installment of Getting to Know - Solaris Secure by Default) (SBD), I would like to focus specifically on those services that are not disabled by default but instead are configured to accept only local connections (originating with the system itself).

Taking a look at the Secure by Default design document, you see that the list of services impacted are (expressed as FMRIs):

  • svc:/network/rpc/bind
  • svc:/system/system-log
  • svc:/network/smtp:sendmail
  • svc:/system/webconsole:console
  • svc:/application/management/wbem
  • svc:/application/x11/x11-server
  • svc:/application/graphical-login/cde-login
  • svc:/network/rpc/cde-ttdbserver:tcp
  • svc:/network/rpc/cde-calendar-manager
  • svc:/application/print/rfc1179:default
SMF property is used to set the Secure by Default behavior or to return the service to its traditional operating mode. In the table below, the property values set when operating in a SBD mode are presented in bold.

Solaris SBD SMF Properties and Values
ServiceFMRIPropertyValues
rpcbindsvc:/network/rpc/bindconfig/local_onlytrue, false
syslogsvc:/system/system-logconfig/log_from_remotetrue, false
sendmailsvc:/network/smtp:sendmailconfig/local_onlytrue, false
smcwebserversvc:/system/webconsole:consoleoptions/tcp_listentrue, false
wbemsvc:/application/management/wbemoptions/tcp_listentrue, false
X11svc:/application/x11/x11-serveroptions/tcp_listentrue, false
CDEsvc:/application/graphical-login/cde-logindtlogin/args[null], -udpPort 0
ToolTalksvc:/network/rpc/cde-ttdbserver:tcpprototcp, ticotsord
Calendarsvc:/network/rpc/cde-calendar-managerprototcp, ticlts
BSD Printingsvc:/application/print/rfc1179:defaultbind_addr[null], localhost

Pretty easy, right? So, let's say you were running in a SBD mode (after having run netservices limited) and you find that you want to be able to receive syslog messages from another host. All you would need to do is:

# svccfg -s system-log setprop config/log_from_remote = true
# svcadm refresh system-log

If you wanted this change to take effect immediately, you should also run:

# svcadm restart system-log

Another cool thing about this is that communication is prevented between non-global zones and the global zone since the service is either bound to localhost or simply will not accept external connections:

# ifconfig hme0
hme0: flags=1000843 mtu 1500 index 2
        inet 192.168.1.250 netmask ffffff00 broadcast 192.168.1.255
        ether 0:0:0:0:0:0

# rpcinfo -p 192.168.1.250
   program vers proto   port  service
    100000    4   tcp    111  rpcbind
    100000    3   tcp    111  rpcbind
    100000    2   tcp    111  rpcbind
    100000    4   udp    111  rpcbind
    100000    3   udp    111  rpcbind
    100000    2   udp    111  rpcbind

# zlogin time ifconfig hme0:2
hme0:2: flags=1000843 mtu 1500 index 2
        inet 192.168.1.240 netmask ffffff00 broadcast 192.168.1.255

# zlogin time rpcinfo -p 192.168.1.250
rpcinfo: can't contact portmapper: RPC: Authentication error; why = Failed (unspecified error)

Pretty neat! Well, that's all for this installment. Please let me know what you think or if you have any questions! We love to get feedback and your input is very important to us!

Take care,

Glenn

References: Part 1 of 3 Part 2 of 3

Technorati Tag:

Thursday Jul 13, 2006

Solaris Secure by Default - Part 2



For the second installment of Getting to Know - Solaris Secure by Default) (SBD), I would like to point you to the newly published Secure by Default OpenSolaris project page. In particular, please be sure to check out the very cool design document.

The design document goes a long way toward explaining exactly what was done by the SBD project when it integrated into Nevada in build 42. It provides a handy quick reference for what changes were made by SBD including the introduction of new service FMRIs, service state (enabled or disabled) as well as any properties that are being used to control service behavior.

So, please give it a look and let us know what you think!

Take care,

Glenn

References: Part 1 of 3 Part 3 of 3

Technorati Tag:

Monday Jul 10, 2006

Solaris Package Companion v0.6



Well, it is time for another update of the Solaris Package Companion. During the course of some additional testing, I found a few bugs which I have corrected in this new version. The biggest issue corrected in this update is the detection of packages versus clusters. I also added a check to avoid an exception case where a package is defined in a clustertoc(4) file but it cannot be found in the distribution (or on the local system when in local-only mode). For those interested, here is a diff:

blackhole$ diff spc-v0.5.ksh spc-v0.6.ksh
44,48c44,45
< BASEDIR=""
< REPOSITORY=""
<
< export BASEDIR REPOSITORY
<
---
> export BASEDIR=""
> export REPOSITORY=""
69c66,69
<    else
---
>    elif [ -d "`dirname ${fileName}`" ]; then
>       # GMB: This is a small hack to avoid generating an error message
>       #      when a package is listed in a "contents" file but it does
>       #      not otherwise exist (e.g., SUNWphx on snv_18)
88a89,94
>    if [ -z "${name}" ]; then
>       # This method should only be trusted when in "local only" mode.
>       if [ ${LOCAL_ONLY} -eq 1 ]; then
>          name="`pkgparam ${1} NAME 2>/dev/null`"
>       fi
>    fi
221c227
<             if [ `echo ${member} | grep -c "\^[A-Z]\*C"` -eq 1 ]; then
---
>             if [ -d ${C_DIR}/${member} ]; then

If you are interested in giving this version a whirl, please download version 0.6 and let me know what you think! Thank you to everyone who has provided feedback and ideas so far! Keep them coming!

Take care,

Glenn

Technorati Tag:

Friday Jun 30, 2006

Solaris Secure by Default - Part 1



Welcome to the first installment of Getting to Know - Solaris Secure by Default) (SBD).

Solaris Secure by Default or more simply SBD was a project introduced into Nevada in build 42. It is scheduled to also appear in an update to Solaris 10 real soon now! ;-) The goal of the SBD project was to reduce the network-facing attack surface of Solaris by either (1) disabling those services that were not absolutely necessary by default and (2) configuring the remaining services to only accept connections from the local system itself. The one exception to this rule is Secure Shell which is enabled and listening by default. This is very similar to (the network service) configurations traditionally generated by the Solaris Security Toolkit, but the big difference is that SBD is an integrated part of the Solaris OS.

The SBD effort has already been completed for the ON, X11, CDE and Admin/Install consolidations. Work is still progressing to make the JDS/Gnome consolidation SBD compliant. So far, however, it is looking pretty darn good!

Let's look at an example. The following is the output of netstat on a freshly installed Ultra 10:

# netstat -f inet -P tcp -a

TCP: IPv4
   Local Address        Remote Address    Swind Send-Q Rwind Recv-Q    State
-------------------- -------------------- ----- ------ ----- ------ -----------
      \*.\*                  \*.\*                0      0 49152      0 IDLE
      \*.sunrpc             \*.\*                0      0 49152      0 LISTEN
      \*.\*                  \*.\*                0      0 49152      0 IDLE
      \*.ssh                \*.\*                0      0 49152      0 LISTEN
localhost.smtp             \*.\*                0      0 49152      0 LISTEN
localhost.submission       \*.\*                0      0 49152      0 LISTEN

Note that this particular system did not have a "head" and was therefore not running any form of window manager. What you see left running is sshd, rpcbind, and sendmail. Clearly, sendmail will only accept incoming connections from localhost. rpcbind appears to be able to accept connections from the network, but in fact it will not.

A great side effect of this work is that there are now fewer network services started from run-control scripts as many were converted during this effort to use SMF. Some services were disabled by default using SMF while others now support SMF properties to control whether they should run in a "local only" mode or not. A "local only" SMF property is in fact how rpcbind is controlled in the example above.

In Nevada, SBD will be the default option for Solaris installations - no questions asked. For Solaris 10, you will still be given a choice, however, the SBD configuration will be the default. SBD will not have any impact on systems that are upgraded. Only initial installations will be able to take advantage of SBD out of the box.

That said, you can enable the SBD settings or revert back to the traditional Solaris settings at any point post-installation thanks to the handy, dandy, netservices command. Located in the /usr/sbin directory, this tool offers one stop shopping for switching network services between a traditional (open) and SBD state:

# /usr/sbin/netservices
netservices: usage: netservices [ open | limited ]

As you can see, the netservices command offers two options. The option open will change service states and properties to place a system into the traditional state. The option limited will place a system into the SBD state. Note that these commands are basically hammers that will forcibly change your state between the two values. If you have made service state customizations (e.g., disabling or enabling specific services), you may find that your settings will be modified.

TIP: It is best to use the netservices command immediately after installation (if you need to change values set during the installation of the system). If you need to make changes later on in the life of the system, you may be better off using the svccfg and svcadm commands to make those specific changes. That way, you should not run into any "surprises".

That is all for this installment. In our next Getting to Know - SBD article I will go into more detail regarding some of the service changes so that you can see for yourself not only how it was done but also how you will be able to adjust settings based on your requirements and policies. Take care,

Glenn

References: Part 2 of 3 Part 3 of 3

Technorati Tag:

Solaris Package Companion v0.5



A few days ago, I posted version 0.4 of the Solaris Package Companion. I had a little time today to do some tweaking based on the feedback that I have received so far. Today, I am pleased to announce that I have made version 0.5 available.

There is only two signficiant differences between versions 0.4 and 0.5. In version 0.5, you must specify that you want to create a working repository for the tool using the newly added -i option (which must be used with either the -l (local) or -s (source distribution) options. Once the repository has been created, the rest of the code should operate in the same manner as before.

The second difference is that during the creation of the repository, the tool will collect package names automatically. This way, you do not need to specify either the -l or -s options after the repository has been created. This makes the -v (verbose) mode a bit faster although the repository creation process (a one time event) is just a little bit longer.

You will still need to specify one of those two options if you want to try out the undocumented -f option to map a file name to a package (if possible). This functionality is still in development but feel free to try it out!

I did add a bunch of new exception handling code that should make it easier to know what is going on if there is a problem or if required arguments are not being passed in a way expected by the program. I hope that these updates will make this tool more easy for everyone to use. Please let me know what you think about the changes!

Thank you to everyone who has provided feedback and ideas so far! Keep them coming!

Take care,

Glenn

Technorati Tag:

Friday Jun 23, 2006

Solaris Interesting File Discovery Tool



Following up on my posting of the Solaris Package Companion yesterday, I would to post one more of my little utilities, called the Interesting File Discovery Tool (IFD). This tool is not taking on an overly grand challenge, but it does come in handy in a number of situations when you need to match up information being reported by the OS with information that is coming from the original distribution.

IFD is a simple utility that allows you to obtain a list of set-uid, set-gid, and world writable objects (including an option to just find world writable directories lacking the sticky bit). Certainly, there have been tools that have done this for ages. The Solaris Security Toolkit, for example, includes scripts (called print-suid-files.fin, print-sgid-files.fin, and print-world-writable-objects.fin) that pull this information directly from the filesystem.

IFD is different however. Rather than pull the information from the filesystem (which can be easily accomplished using just the find(1) command, the Interesting File Discovery tool collects information on these files from a number of different sources including: (1) the OS distribution, (2) the local system's /var/sadm/pkg directory and (3) the local system's /var/sadm/install/contents file. These are all interesting sources to collect this information since it can help an investigator.

For example, one could determine that there exists a program (shipped in the Solaris OS) that is set-uid on the filesystem and perhaps in the "contents" file, but it is not set-uid in the package repository or in the Solaris OS distribution. While this may not necessarily mean that there is a problem, it may point to an area requiring more investigation. This could be used in concert with tools such as the Solaris Fingerprint Database or even Solaris 10 BART to determine the authenticity of a given program and its permissions.

Before we give it a spin, let's take a look at how the tool is used and what options are available:

$ ./ifd-v0.3.sh -h

   ./ifd-v0.3.sh - Interesting File Discovery Tool

   ifd -[ugnw] [-q] { -c | -l | [Solaris Product Directory] }

      -c     Collect information from /var/sadm/install/contents
      -g     Print information on files with the set-gid bit set
      -h     Display this message
      -l     Collect information from /var/sadm/pkg
      -n     Print information on WW directories without sticky bit set
      -q     Quite mode.  Do not print headers.
      -u     Print information on files with the set-uid bit set
      -w     Print information on world writable files and directories
      -?     Display this message

So, let's see how this little tool works... In the first example, the tool is used to uncover set-uid files from a Solaris OS distribution:

$ ./ifd-v0.3.sh -u /export/install/images/s10u1/Solaris_10/Product

Set-UID Programs

4511   root       bin        usr/lib/lp/bin/netpr
4511   root       bin        usr/lib/print/lpd-port
4511   root       bin        usr/lib/pt_chmod
4511   root       lp         usr/bin/cancel
4511   root       lp         usr/bin/lp
4511   root       lp         usr/bin/lpset
4511   root       lp         usr/bin/lpstat
4511   root       lp         usr/sbin/lpmove
4511   root       uucp       usr/bin/ct
4511   uucp       bin        usr/bin/tip
[... other results removed for brevity ...]

Another way you can use this is to collect information from the local package repository. For this example, we will look for set-gid files:

$ ./ifd-v0.3.sh -g -l

Set-GID Programs

2511   root       mail       usr/bin/mail
2511   root       mail       usr/bin/mailx
2555   root       mail       dt/bin/dtmail
2555   root       mail       dt/bin/dtmailpr
2555   root       smmsp      usr/lib/sendmail
2555   root       sys        usr/platform/i86pc/sbin/eeprom
2555   root       sys        usr/sbin/amd64/prtconf
2555   root       sys        usr/sbin/amd64/swap
2555   root       sys        usr/sbin/amd64/sysdef
2555   root       sys        usr/sbin/i86/prtconf
[... other results removed for brevity ...]

Finally, let's look for world writable files (and directories) using just the local /var/sadm/install/contents file:

$ ./ifd-v0.3.sh -w -l

World Writable Files

0622   bin        bin        usr/oasys/tmp/TERRLOG
0666   root       bin        var/adm/spellhist
0666   root       root       var/dt/dtpower/_current_scheme
1777   root       bin        var/preserve
1777   root       bin        var/spool/pkg
1777   root       bin        var/spool/samba
1777   root       mail       var/mail
1777   root       root       var/dt/dtpower/schemes
1777   root       sys        tmp
1777   root       sys        var/krb5/rcache
[... other results removed for brevity ...]

So, there you have it. Nothing earth shattering, but a useful little tool nonetheless. Please let me know if you use it, like it, hate it, have ideas to improve it, etc. I always love to get feedback.

Take care,

Glenn

Technorati Tag:

Thursday Jun 22, 2006

Solaris Package Companion

[Read More]

Friday Jun 09, 2006

FREE Sun Beta Certification Exam for Security Admins



CALLING ALL SECURITY GEEKS!

Do you like free stuff? Do you enjoy helping others and sharing your wisdom and experience? Would you like to participate in an effort to help create a Sun certification exam? Do you assess, configure or manage security functions on Solaris 10 systems? If so, read on because we have a great opportunity for you!

If you are an expert security administrator, this is your opportunity to get involved
in the creation of the new Solaris 10 Sun Certified Security Administrator exam!  As 
a beta tester, you officially test the test and will be able to provide Sun with 
valuable comments and technical feedback about the questions. Sun beta exams count
towards official Security Certification!

Recommended prerequisites: 

Twelve months job-role experience administering security in a Solaris Operating System
and previous Solaris OS system and network administration.

If this sounds like fun to you and you would like to participate, then please check out the Solaris 10 Sun Certified Security Administrator beta program page and read all about it. Registration does not officially begin until July 3, 2006, so check out the program, the testing objectives and start getting ready today!

Technorati Tag:

About

gbrunett

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today