|
Home > Archive > Linux Debian support > January 2005 > Need security related suggestions on running a server
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Need security related suggestions on running a server
|
|
| Madhusudan Singh 2005-01-26, 5:49 pm |
| Hi
For the first time in my experience, I have been asked to deploy and
maintain a Linux server for the following purposes :
1. Maintain our group's webpage using plone (a very complicated and capable
piece of software I am beginning to get my arms around).
2. Act as a Samba fileserver.
3. Act as an NFS fileserver.
4. Act as a caching IMAP server that downloads email from another server
with limited space and makes it available for use to a restricted set of
people.
I have installed Debian Sarge on the beast (a Dell Poweredge 800 system
with RAID 5), but have a few questions before I dive into it.
1. Port 80 is known as a favorite target of worms / malicious hackers and
other undesirables. If I run a webserver, I would have to open it and have
apache listening to it. On all my personal machines, port 80 is closed. How
does one maintain the security of a webserver against DoS and other
attacks ?
2. How do I keep track of network intrusions ?
3. How do I set up the IMAP server described above ?
I might have a lot more questions later as I read up more, but these are
the questions for now.
Thanks.
| |
|
| On Wed, 26 Jan 2005 13:10:20 -0500, Madhusudan Singh
<spammers-go-here@spam.invalid> wrote:
> 1. Port 80 is known as a favorite target of worms / malicious hackers and
>other undesirables. If I run a webserver, I would have to open it and have
>apache listening to it. On all my personal machines, port 80 is closed. How
>does one maintain the security of a webserver against DoS and other
>attacks ?
Is this server open to the internet or just to your internal network?
If it's just internal, then your problem isn't as great as if it's
open to the internet.
Make sure that your server is firewalled.
Make sure that you have a stable, secure web server (Apache). Make
sure that you have all the security patches.
You can also partition you hard disk to isolate Apache. That way, if
it does get compromised, the damage will be limited to that partition.
> 2. How do I keep track of network intrusions ?
Look at your log files. Note that you will certainly see signs of
attack (if you're open to the internet). Things like long files being
sent to the web server in an attempt to create a buffer overflow.
With Apache, be glad that you have software that is capable of
handling that.
Have a look at snort.org. Snort looks at the log files for signs of
intrusion.
Dan
| |
| Madhusudan Singh 2005-01-28, 5:45 pm |
| Thanks for your response.
>
> Is this server open to the internet or just to your internal network?
When set up fully, the server will have to be open to the internet.
> If it's just internal, then your problem isn't as great as if it's
> open to the internet.
>
> Make sure that your server is firewalled.
Of course, but port 80 is usually closed on most machines. I cannot close it
on this machine as I need to run apache and have stuff available on the
net.
>
> Make sure that you have a stable, secure web server (Apache). Make
> sure that you have all the security patches.
Would the one in testing be considered stable enough ?
>
> You can also partition you hard disk to isolate Apache. That way, if
> it does get compromised, the damage will be limited to that partition.
You mean like having a separate /var/www partition ?
>
>
> Look at your log files. Note that you will certainly see signs of
> attack (if you're open to the internet). Things like long files being
> sent to the web server in an attempt to create a buffer overflow.
> With Apache, be glad that you have software that is capable of
> handling that.
Of course 
>
> Have a look at snort.org. Snort looks at the log files for signs of
> intrusion.
Thanks for the hint.
| |
| Jorey Bump 2005-01-29, 5:45 pm |
| Madhusudan Singh <spammers-go-here@spam.invalid> wrote in
news:35v9bqF4rlvm2U1@individual.net:
>
> When set up fully, the server will have to be open to the internet.
Consider running 2 servers, one for public use, one for private use.
>
> Of course, but port 80 is usually closed on most machines. I cannot
> close it on this machine as I need to run apache and have stuff
> available on the net.
You're right, you must open port 80 in order for your web site to be
accessible from anywhere on the Internet. In addition, you should turn
off any other services that you don't need. It's not unusual for a public
web server to run only http (port 80), https (port 443) and ssh (port
22). Even then, you will want to tighten up ssh access using builtin
controls (disable root logins, specify which users can ssh with
AllowUsers) and a firewall (limit access to known IP addresses, if
possible).
Of course, there's nothing to prevent you from running a lot of services
and using the many means available to you to control access.
>
> Would the one in testing be considered stable enough ?
In the scenario you describe, I would only consider Woody, until Sarge is
stable. This is because Woody is stable, security updates are released
quickly, and it's very easy to apply updates. Sarge is still a moving
target, Sid is a nightmare to maintain, and there's nothing worse than
upgrading a few hundred packages a week on a production machine.
The potential downside with Woody is that it's not cutting edge, and
while it's possible to add newer applications by compiling them yourself
or using backports, you start drifting away from the convenience and
security offered by the packaging system. I use Woody for the type of
scenario you describe, and it works fine. If I need to support custom
applications or continual modifications by other developers, I use
slackware, which provides a better development environment, in my
opinion. YMMV.
You also face the fact that Sarge will become stable, and you will need
to upgrade. Expect a lot of differences.
>
> You mean like having a separate /var/www partition ?
Just use two servers. Don't use a public server for a private intranet.
Sure, it's possible, but the public services will always be a vector for
compromise. It makes more sense not to store anything valuable on the
public server.
>
> Of course
It's also educational to run nmap or Nessus against your machines to see
what's exposed. Tail your logs to see what the result is. Try to break
into your own system, so you know what to look for in the logs. Choose
uncommon user names to make it easier to tell the difference between
automated brute force attacks and cases where someone actually knows
something about your organisation. There are a variety of file/log
monitors and rootkit detectors that can prove useful. It's also easy to
whip up your own bash scripts that search the logs for unusual activity.
Another key aspect to setting up a server is to only install applications
you will use. On Debian, it's really easy to start with a minimal install
and add only a few more apps. There is usually no need for X, and many
applications have been broken into parts, so you can install only the
command line tools (tethereal from ethereal, for example). This approach
reduces the number of exploitable applications or libraries on the
machine, which can foil an intruder even after a successful break-in.
Finally, since Woody is easily installed on an older machine, it's not a
bad idea to set up a test server to try out new configurations before you
apply them to your production server. I do this all the time, and find it
to be extremely helpful, especially when I'm troubleshooting an issue on
the production machine and don't want to risk any downtime.
| |
| Madhusudan Singh 2005-01-29, 5:45 pm |
| Thanks for such a detailed response !
>
> Consider running 2 servers, one for public use, one for private use.
Well, I do have two ethernet cards on the server (and possibility of getting
two different IP addresses). I do not think we can use another physical
machine though. Is that what you suggested ?
>
> You're right, you must open port 80 in order for your web site to be
> accessible from anywhere on the Internet. In addition, you should turn
> off any other services that you don't need. It's not unusual for a public
> web server to run only http (port 80), https (port 443) and ssh (port
> 22). Even then, you will want to tighten up ssh access using builtin
> controls (disable root logins, specify which users can ssh with
> AllowUsers) and a firewall (limit access to known IP addresses, if
> possible).
Good suggestions.
>
> Of course, there's nothing to prevent you from running a lot of services
> and using the many means available to you to control access.
I do need to run a few - NFS (should I consider coda ? - some of our
scientific instruments expect NFS), Samba and an IMAP server which would
accept email for some of the users (do not need an SMTP server - reduces
the headache).
> scenario you describe, and it works fine. If I need to support custom
> applications or continual modifications by other developers, I use
> slackware, which provides a better development environment, in my
> opinion. YMMV.
I was also thinking of Slackware. But then I could go the whole hog and get
FreeBSD. What is not certain is whether FreeBSD would support all the
hardware and also issues about my own familiarity with it.
>
> You also face the fact that Sarge will become stable, and you will need
> to upgrade. Expect a lot of differences.
I use Sarge on my laptop
>
>
> Just use two servers. Don't use a public server for a private intranet.
Do you mean two different physical machines ? That might not be an option
for us.
> Sure, it's possible, but the public services will always be a vector for
> compromise. It makes more sense not to store anything valuable on the
> public server.
It has nearly 400GB (after Raid 5). So, it is going to be used for storage.
> It's also educational to run nmap or Nessus against your machines to see
> what's exposed. Tail your logs to see what the result is. Try to break
> into your own system, so you know what to look for in the logs. Choose
> uncommon user names to make it easier to tell the difference between
> automated brute force attacks and cases where someone actually knows
> something about your organisation. There are a variety of file/log
> monitors and rootkit detectors that can prove useful. It's also easy to
> whip up your own bash scripts that search the logs for unusual activity.
Good suggestions again.
>
> Another key aspect to setting up a server is to only install applications
> you will use. On Debian, it's really easy to start with a minimal install
> and add only a few more apps. There is usually no need for X, and many
> applications have been broken into parts, so you can install only the
> command line tools (tethereal from ethereal, for example). This approach
> reduces the number of exploitable applications or libraries on the
> machine, which can foil an intruder even after a successful break-in.
Ok.
>
> Finally, since Woody is easily installed on an older machine, it's not a
> bad idea to set up a test server to try out new configurations before you
> apply them to your production server. I do this all the time, and find it
> to be extremely helpful, especially when I'm troubleshooting an issue on
> the production machine and don't want to risk any downtime.
Hmm. Let me see if I can find a small machine no one wants.
| |
| Jorey Bump 2005-01-30, 2:45 am |
| Madhusudan Singh <spammers-go-here@spam.invalid> wrote in
news:362fveF4p6j5aU1@individual.net:
>
> Well, I do have two ethernet cards on the server (and possibility of
> getting two different IP addresses). I do not think we can use another
> physical machine though. Is that what you suggested ?
I meant two machines, one for public use (web site) on your public IP,
one for private use (file server, intranet web site) on your LAN behind
your firewall. It's not really a good idea to keep private files on a
server exposed to the Internet.
>
> Do you mean two different physical machines ? That might not be an
> option for us.
While it is possible to set up a proper firewall to restrict access to
SMB/NFS, this isn't really the issue. The problem is that a publicly
facing machine is under continual attack. If an attack succeeds, the
intruder has instant access to all of your files. Putting the fileshare
in your private network behind a firewall reduces this threat
significantly.
>
> It has nearly 400GB (after Raid 5). So, it is going to be used for
> storage.
You'll need to do a risk assessment. I'm not saying that sensitive data
is never stored on public servers, but you'll want to avoid it whenever
possible.
|
|
|
|
|