At first glance that appears to be an easily hacked site. Maybe
with deep thought one can imagine security working for a while...
On second glance, security on that configuration still appears hackable.
That said, most of what goes on in this list is what I called
in my L.A. Street racing days as 'bench racing' ("yea, I added
a chrome shift knob and got five more horsepower"). When the
pink slips come out, you know there's some serious hardware
inside, but until then, it's mostly theoretical talk about
what works and what doesn't until you get a F-WOS (Fed.-Web
Oh Sh_t). The following contains bench racing. ;)
It is not easy to lock all of the incoming services from
a specific port. Disabling IP forwarding is a start, but if a
system gateways to other systems inside, or to itself without
a strong authentication mechanism, it is still vunerable. You
also need code smart enough to recognize trusted addresses
coming in from the wrong port.
Maybe your 7500 has a weak point, a vty password that actually is
a word. The Cisco is close enough to successfully spoof trusted ip
addresses.
Lets say someone on your internal network xxx.185.2.0(?) opened a
HTTP connection out to a site. Wouldn't an Active-X/Java/Javascript
application - 'some script' be able to write to/collect data
on a NFS-mounted drive which happens to be your webserver?
A script could run commands to view network connections on an
internal DOS or UNIX client, send the data back as cookies, processes
that data (grep for '/docs', or '/ns-home', or '/wwwroot') then have
the browser background cache a new index.html document to that location.
Maybe that new Trek screensaver from usenet does the same thing, or
runs a '90s' version of 'Jive' on your index.html/default.htm page.
An outside programmer could see some instant gratification from your
home page.
Point is, I think your configuration needs more protection.
Bill Stout
On Thursday, January 02, 1997 10:41 AM, mcnabb @
argus .
cu-online .
com
wrote:
<snip>
> The web server has two network connections, but has IP forwarding
> disabled. Processes coming in from one network see all file systems
> as read-only (making /tmp RO is an option), and there is no mechanism
> for bypassing that, even if the process is root. All device special
> files are complete inaccessible to all processes and all users -- also
> mknod(2) is disabled. If a user comes in from the other network,
> he/she can access the system normally, except that UID 0 (root) is
> treated as a normal account in terms of OS privilege, so attacks from
> this direction are also more tightly controlled (special programs
> are provided to manage the system instead of using a special account
> such as root).
>
> +------------+
> <-------------->| Secured |<-------------->
> internal network | Web Site | Internet/PublicNet
> (RW file systems) +------------+ (RO file systems)
>
> When a Solaris host (x86 or SPARC) has been updated with this level
> of security, you can still use the r* commands, telnet, ftp, and
> even NFS from either side. You can have the RO restriction be done
> on a per-file basis as well, so you can be creative about your setup.
<snip>
|
|
