Linux Getting Harder To Crack
AlanS2002 points out today's article from Iain Thomson on vnu.net, which says that "Linux systems are getting tougher for hackers to crack, security experts have reported today," summarizing "A study conducted by the Honeynet Project has found that it takes about 3 months before a unpatched Linux machine will be owned, compared with about 72 hours in the past. According to a report on the study default installations are now more secure with less services enabled by default, added to this is newer versions of software such as OpenSSH being more secure. Interestingly Solaris 8 and 9 did not fare so well."
I just read an article at the Register (linking to an old article on http://www.usatoday.com/money/industries/technolog y/2004-11-29-honeypot_x.htm about un-patched XP sp1 machines only surviving for 4 minutes when connected to a broadband connection. Within 10 hours the hackers had an IRC channel running on the machines.
Tongue: A variety of meat, rarely served because it crosses the line between a cut of beef and a piece of dead cow.
because a router will deter all but hackers with a reason to pwn your box, and there is little reason to do so to a home computer.
To create a zombie for a DDoS attack, to host child pornography or warez, to use as a spam relay. All of these and more are reasons home computers are attacked. All they want are more systems in their arsenal, to make them more resilient and more effective. It doesn't make much difference if it's a home PC or a workstation in some office somewhere.
Red Hat, on the other hand, has moved to both turning no remotely-accessible inetd/xinetd services on by default and offers an easy install-time firewall that works transparently on workstations and very simple servers. The difference in exposure of vulnerabilities to attackers is tremendous. The vulnerabilities may still be there, but the attacker often can't get to them or can't get the same level of privilege out of them. For instance, running OpenSSH in privilege-separated mode the way most Linux distros do now means that some exploits don't work, while others only grant the attacker non-root access.
Linux vendors/creators have led the commercial Unix world in pre-install hardening - I like to think this is due in part to the success of Bastille Linux, a hardening program for SuSE, Red Hat/Fedora, Debian, and Mandrake Linux, as well as HP-UX and Mac OS X. Bastille ships on recent HP-UX O/S's, is available from both Debian and SuSE as a vendor-supplied package.
Technically it's more PAT (port address translation) rather than NAT (network address translation).
On cisco it's also the "nat overload".
NAT leave you somewhat vulnerable it's a mapping address for address (many to many). Don't feel secure with NAT without firewalling.
PAT is much more closed (many to one).
It's also true that everyone say NAT when they do PAT.
Two issues with your solaris admin experience:
1) Even way back in solaris 2.5 (and probably before that, but that is when I started), you could just download the latest patch cluster, run 'install_cluster', and then reboot when you were done (if required... see below). That was it. No muss, no fuss... A new cluster was generated every 2 weeks for the lazy admin who wanted to stay up to date with patches yet not actually read the patch notes
2) Nowadays, its even easier... All you have to do is install the latest patchpro. Then you can do several things. For the brave/stupid, you can run smpatch (the main patchpro command) out of cron and have it automatically fetch and install the latest `non reboot` pathes and install them. For those of us who have to run under a change control system that requires notifying others of changes, there is `smpatch analyze`, `smpatch download` and `smpatch add`.
You can use the analyze command to generate a list of patches in order of dependencies and then feed that list into your change control system for tracking what you applied. The use the 'download' and 'add' commands then take that list and download them to the system and then add them to the system. (the 'add' command will also perform the download if you dont want to stage them ahead of time.)
If you made any 'major changes' like an updated kernel, you'll want to reboot. If you didnt apply any patches that require a reboot, then no problem, dont reboot. Some patches may say that they require a reboot, but a savvy admin (or a daring one ) can get around those 'recommendations' reloading the impacted kernel modules (sun even has a way to hot patch the kernel for those customers that absolutely can not bring the system down anytime soon)
Even 'apt-get update' needs a reboot when you change big things like kernels or major libraries (or at least restarting all apps/services/whatever that use those libraries, at which point you may as well just suck it up and reboot since the service is going down. You didnt think that those running apps would get all of those libc.so updates without restarting did ya?)
And as an extra added bonus, smpatch only downloads signed patches and verifies the signature before installing.