I set up tightvnc tunneling through SSH and it's pretty nice. I wouldn't mind accessing my LAN from work if I could do it without compromising my setup.
Clarify "compromising your setup"?
I'm not sure if I'm ready to take the big step of letting this go to the outside world.
Then I suggest the following approach: read, think, read, post, plan.
I guess my questions may be a bit vague so I hope some of the Slackers who are pro sysadmins or who run services open to the net will share their experiences on the topic.
Sorry to say but nothing you've said sofar comes close to anything Slack-specific. This should be in Linux - Security.
Feel free to give any advice not necessarily just on my questions.
Check out the
LQ FAQ: Security references. Minimally read up on hardening, auditing and post #6 on web app security.
Are the exploits based on bad php or other scripting code running or are they inside Apache itself
From what I see ninetynine percent of the time it's a combination of these six:
- bad planning (server in user LAN and not DMZ),
- bad setup practices (no virtualisation, GRsecurity, SELinux, or chrooting),
- bad restrictions (no/loosely configured firewall (*in AND outbound!!!), tcp_wrappers, apache.conf, mod_security),
- insufficient or no auditing and no "early warning" caps (IDS), let alone auditing regularly,
- bad maintenance practices (not updating when updates are released),
- and running "bad" PHP configuration and PHP-based apps (like those authors who tell you their stuff won't run with safe mode on but at the same time won't apologise for what is essentially softening up the webserver, or running "experimental" apps).
The chance you'll get caught by something within Apache is not non-existant but way, way smaller. Most of the time you'll see those exploiting flaws in PHP-based apps are "just" spammers or bot herders. Search the Linux - Security forum for some real cases. The first category doesn't want *nor need* root account privileges to do their thing. The second category, once in, just has the time to throw all kinds of exploits at the box to get root since the admin won't notice anyway. The chance you will encounter crackers of the third MO kind is small. Way, way small.
Does setting up a userid and password to get into the web site help (don't know how to do that either) or is that not a significant barrier to hacking?
No barrier. Depends on what you got running and how it's shielded, not one single restriction.
Which ftp server does everbody like. I see Pat has both vsftpd and profptd in the distro. I'm leaning towards vsftpd because I see some BSD distro sites using it. I really have no idea if one is better than the other or what you have to do to avoid problems with them also.
It's not about "liking" something. If I'd go with that criterium I'd end up buying an O2 since I still like the design.
This is an easy one though: do minimal research. Visit CVE, SecurityFocus, Secunia and make a tally for the top-four FTP daemons. See how much vulns there where the past three years. List by severity, remote risk (and if available: time to fix data). *Then* choose. Now you're choosing based on cold, hard facts.