>>Garl Grigsby wrote:
>>Not worried about the script kiddies. This machine is behind a
firewall and only sees the light of the Internet through the light of
yum, ftp, and maybe wget.
Actually you should be .. in almost every recent case I've seen - the
path to the servers is through the workstations - NOT through a direct
internet connection. If your workstations can touch the internet the
servers need bascially the same levels of protections. The most common
approach is to get some user to open or install .. or even simply visit
a web page that plants a small exe or root kit that simply acts as a
springboard. I've seen metasploit used to pass through several
firewalls via workstations for example .. and this is a relatively easy
tool for script kiddies as it has a point and click exploit interface.
There was an event like this as recent as last weekend in this area ( as
well as some DOS attacks apparenlty ).
Mark
Jacob Meuser wrote:
On Wed, Apr 05, 2006 at 08:19:35PM -0700, Michael Miller wrote:
Well I would give the 64-bit version of the CentOS Kernel. I should
say give RHEL X 64-bit Kernel another year. If you only have two GB
of ram and no upgrades to four GB of ram for 6 months. I would go
with 32-bit for another 6 months while all 64-bit compiling gotchas
are fixed in GCC and any 64-bit kernel security issues are fixed.
what? "all 64-bit compiling gotchas are fixed in GCC"? please
tell, what "64-bit compiling gotchas" are in gcc? I've been using
gcc on an amd64, in 64-bit mode, for over a year. I haven't
seen any "gotchas".
now, if you are talking about _libtool_ issues with /usr/lib and
/usr/lib64 (or /usr/lib32), that is a whole other problem that has
nothing to do with gcc. these could be elimitated by ditching
32-bit support and going 64-bit all the way.
Where have you run into problems with libtool? I've seen many a post
about problems with firefox and its plugins, but nothing about the
server side of things ( like samba, bind, mysql, apache, etc.). Have
you seen or run into problems with these applications?
and then of course, there is software that makes 32-bit assumptions,
or only has assembly code for x86. again these have nothing to do
with "64-bit compiling gotchas" in gcc. the software, not gcc, has
"64-bit compiling gotchas".
Examples?
now, for "any 64-bit kernel security issues are fixed." you think
there are no 32-bit kernel security issues? if anything, going 64-bit
will buy you a small bit of security by obscurity (granted, worth
only maybe the $0.02 you put into this thread), as script kiddies
try their 32-bit `sploits.
Not worried about the script kiddies. This machine is behind a
firewall and only sees the light of the Internet through the light of
yum, ftp, and maybe wget.
_______________________________________________
EUGLUG mailing list
[email protected]
http://www.euglug.org/mailman/listinfo/euglug
_______________________________________________
EUGLUG mailing list
[email protected]
http://www.euglug.org/mailman/listinfo/euglug
