Hi Gurus,
I got lots and lots of replies with different opinions
and suggestions implementing the security issues.
Below are the summaries,Please bear with this long summary.
Most of them suggested to subscribe to lists like SUnsolve Early_Notifier
PatchClub and www.cert.org updates.
Thanks again,
Venu.
"Jamie A. Lawrence" <jal@thirdage.com> Wrote:
---------------------------------------
The real question is, "What is the cost of a break in?".
All security is economics. You cannot guarantee a machine will not be
broken in to without disconnecting it from the net, powering it off and
locking it in a vault. Even then, the cost of breaking in to that vault
may be worth the value of the data... You can analyse the cost of a break
in (loss of confidential data, use that as a guideline for the sorts of
measures you should take (all of which cost money), and take them.
I know that isn't what you are asking, but that is the way to think
about security.
As far as general things you have to do, here are some starters:
- Apply all applicable patches
- Turn off all unneeded services in /etc/inetd.conf. Install
TCP_Wrappers.
Better yet, replace inetd with one of the secure variants.
- Set up scripts to watch logs. Better yet, replace syslog with a more
secure variant and stream logs to a (very) secured log management host
and build your watcher scripts there.
- Limit accounts to people who need to have them. Enable password expiry
and make it annoyingly frequent.
- Turn off telnet and ftp and install ssh. If you're automating any kind
of remote access, use RSA keys so that a password never crosses the local
LAN.
- In general, make sure plaintext passwords never are used.
- Make sure your sendmail is well locked down and extremely current
(8.9.1,
at least, preferably newer).
- Make sure your web server doesn't have any holes. You don't mention
what
you are running.
- Make sure any CGIs are safe. Ditto for your application server's apps.
- Make sure you can't get to Oracle from the outside world. Make sure the
Oracle password can be changed frequently. Remove the SUID bit from many
of the Oracle utilities - there have been exploits published for them
recently that can escalate the cost of a breakin.
- Make sure anything that accesses Oracle can't be abused to do unwanted
things
from your HTML forms.
- Think like an attacker. How would you try to get in?
- Make sure your router is secured.
If you're paranoid,
- Lock down the switch ports with the MAC address of the hosts.
- Lock down the switch to only allow console access.
- Check for ways to come in over your VPN that you may not expect.
- Let your mind wander here...
Security is hard. There's no way to say, "It is secure."
Anonymous Wrote:
----------------------
Well, this is a kind of broad question, as the true answer(s) will
likely come from your head and will apply to your unique environment. A
couple of the major things I do for Web (not Oracle) servers are:
- Build the boxes as if they are going to be firewalls themselves.
Check out http://www.enteract.com/~lspits/armoring.html for a good
start.
- Patch, patch, and patch some more. Pay attention to BUGTRAQ and the
like to help get an idea of the nasties that are out there. (There
are plenty).
- Add set noexec_user_stack=1 to /etc/system (and set
noexec_user_stack_log=1 to log such attempts). Look this up on Sunsolve
for the full specifics
- Plan on these things getting broken into (as they quite possibly will
at some point). Don't store ANY critical or sensitive information on
these things. This especially includes data from any sort of
e-commerce business you may be running from them, i.e. don't store
customer credit card numbers, names and addresses, etc. on these
machines. These machines WILL get broken into, and that data WILL be
used maliciously, and YOU will be responsible. Ask yourself,
"When this data gets stolen, what will bad people be able to do with
it? Also, when somebody breaks into this box and does an rm -rf / on
it, what are the ramifications of my not having that data?" I don't
do backups of any of my boxes in the DMZ; I have several boxes that
are all exact mirrors of each other - the only thing unique on them
(besides the obious hostname/ip/etc.) are the log files and those are
sucked in behind the firewall once a day for statistical work. When
one of these machines gets broken into, I'll 1) figure out how they
got in and plug that hole in the next iteration, and 2) rebuild it
(actually, probably all of them, as I'm then not going to trust the
assumption that nobody got into any of the others) from scratch.
- The username the server daemon runs under shouldn't have write access
to anything more than it absolutely must have to function. In
particular, don't let that username have write access to your doc
root. When some kiddiez/hackerz find a way to remotely exploit a
vulnerability in a cgi script or app you may be running, they can do
far less damage if they can't write anywhere.
- Take a look at and follow the security-related recommendations of the
various gurus out there. I think CERT has got some stuff, there's
things on ensuring your Perl programming is safe (always run perl
with the -T option is one of 'em) and advisories along these lines.
- Comment out ALL unneeded entries in /etc/inetd.conf and run the
remaining through tcpwrappers. Just having a firewall is no excuse to
not plan for that firewall ever being misconfigured. A firewall is
one component used to secure a system but shouldn't be the only one.
- Don't fool yourself into thinking you will ever have a 100% secure
system. No such system exists; all you can do is make it harder to
break into.
"Muller, Ester" <emr@wcomp.gov.za> Wrote:
--------------------------------------------
Have a look on http://www.sunworld.com/. There is some Technical FAQ's
which
includes a Solaris Security FAQ which migth be worth your while.
Dave McFerren <mcferren@colltech.com> Wrote:
--------------------------------------------
You may want to have a bastion mailhost outside the VPN. Lock it down
securely. Then funnel your mail out of the VPN to this mailserver, and
only
let mail from this server into your vpn. Look at
http://users.solve.net/~davem to see how I had set this up.
Make sure your firewall/router is set to stop spoofing and ping attacks.
"ERICKSEN, LEIF H. (AIT)" <LEIF.H.ERICKSEN@msg.ameritech.com> Wrote:
-------------------------------------------------------------------
http://www.cert.org/nav/securityimprovement.html
http://www.ciac.org/
http://www.insecure.org
http://www.l0pht.com
http://www.enteract.com/~lspitz/pubs.html
http://www.sun.com/blueprints/1299/network.html
http://www.cdc.com I believe that is it
http://www.rootshell.com
http://www.slashdot.org I believe that is it
http://www.defcon.org I believe that is it
I could go on but I think you will have more than enough to try and digest
here with this information.
Matt McClung <mmcclung@ndwcorp.com> Wrote:
-------------------------------------------
I would perform a security audit and assessment of each server.
Further, you should look into the updates for the software/OS to make sure
you have the latest versions running.
Also, a firewall is a good start, but you should think about an Intrusion
Detection System which will watch for attacks and alert you to them. The
firewall will not look at valid traffic (which you allow through - i.e.
HTTP, FTP, SMTP, etc) but the IDS system will analyze the traffic for
embedded attack signatures, etc.
Make sure you have an Incident Response Plan and Team in place to deal
with
problems.
On Mon, 21
Feb 2000, Venu M Middela wrote:
> Hi Gurus,
> Im looking for a list of security measures to be taken
> before launching a web site.
> heres my scenario..
>
> We have our website hosted at a remote site with 5 servers
> managed by the ASP. 2 E 250s running webserver,application server,
> mail server
> and 2 E4500s running oracle. The data is stored in a HP X256 SAN.
> The entire network is protected by firewall. Connectivity to the
> datacenter is managed thru VPN.
> My question is
> what necessary steps need to be taken apart from implementing the firewall
> to ensure that there are no security holes in it. The http port and the
> smtp are open to the internet. All other services are restricted behind
> the firewall.
> Any input would be appreciated. Will summarise,
>
> Thanks,
> Venu.
>
>
>
>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:03 CDT