Today, on my 28th birthday, I'm finally delivering on a promise to my readers which I made about two months ago. I've on how to host a web application redundantly in a cloud environment. While it's still a bit of a rough draft, it should be a good starting point for those who haven't worked in virtualized environments before. Also, it may show some of the more experienced systems administrators a new way to do things.
The guide:
As always, if you find anything in the guide that needs improvement, I'm all ears.
Regardless of the type of hosting you're using — dedicated or cloud — it's important to take network interface security seriously. Most often, threats from the internet are the only ones mentioned. However, if you share a private network with other customers, you have just as much risk on that interface.
Many cloud providers allow you access to a private network environment where you can exchange data with other instances or other services offered by the provider. The convenience of this access comes with a price: other instances can access your instance on the private network just as easily as they could on the public interface.
Here are some security tips for your private interfaces:
Disable the private interface This one is pretty simple. If you have only one instance or server, and you don't need to communicate privately with any other instances, just disable the interface. Remember to configure your networking scripts to leave the interface disabled after reboots.
Use packet filtering The actual mechanism will vary based on your operating system, but filtering packets is the one of the simplest ways to secure your private interface. You can take some different approaches with them, but I find the easiest method is to allow access from your other instances and reject all other traffic.
For additional security, you can limit access based on ports as well as source IP addresses. This could prevent an attacker from having easy access to your other instances if they're able to break into one of them.
Configure your daemons to listen on the appropriate interfaces If there are services that don't need to be listening on the private network, don't allow them to listen on your private interface. For example, MySQL might need to listen on the private interface so the web server can talk to it, but apache won't need to listen on the private interface. This reduces the profile of your instance on the private network and makes it a less likely target for attack.
Use hosts.allow and hosts.deny Many new systems administrators forget about how handy tcpwrappers can be for limiting access. If your firewall is down in error, host.allow and hosts.deny could be an extra layer of protection. It's important to ensure that the daemons you are attempting to control are build with tcpwrappers support. Daemons like sshd support it, but apache and MySQL do not.
Encrypt all traffic on the private network Just because it's called a «private» network doesn't mean that your traffic can traverse the network privately. You should always err on the side of caution and encrypt all traffic traversing the private network. You can use ssh tunnels, stunnel, or the built-in SSL features found in most daemons.
This also brings up an important point: you should know how your provider's private network works. Are there safeguards to prevent sniffing? Could someone else possibly ARP spoof your instance's private IP addresses? Is your private network's subnet shared among many customers?
With all of that said, it's also very important to have proper change control policies so that administrators working after you are fully aware of the security measures in place and why they are important. This will ensure that all of the administrators on your instances will understand the security of the system and they should be able to make sensible adjustments later for future functionality.
You need to disable SSL ver 2 and enable SSL ver 3 in apache for PCI compliance. Its very easy to do. Following settings will set SSL ver 3 and also disable older/unsecure cipher suite in Redhat/centos/fedora Linux server:
1. Open /etc/httpd/conf.d/ssl.conf and add or if these lines already there, edit them as per follows:
Happy New Year! I certainly hope it's a great one for you, your family, and your business. As the new year begins, I figured it would be a good time to sit down and answer a question that I hear very often:
How do I become a better systems administrator?
The best way to become a better systems administrator is to fully understand the theory of what's happening in your server's environment.
What do I mean by that? Learn why things aren't happening as you expected and think about all of the factors that could possibly be involved. Instead of thinking purely about cause and effect, you'll find it much easier and rewarding to consider everything inside and outside your environment before you make any changes.
This still may be a little difficult to fully understand, so he's an example. Let's say you're handling an issue where a customer can't reach a website hosted on their server. When you ask them for more details, they might give you the dreaded reply: «It's not coming up.» Start by making a mental list of the problems that are easiest to check:
Is the web server daemon running?
If a database server is being used, is it running and accessible?
Is there a software/hardware firewall blocking port 80?
Is a script stuck on the server tying up resources?
Could there be a DNS resolution problem?
Is the server up?
Did a switch fail?
Is the server's hard disk out of space?
Can the customer reach other websites like Google or Yahoo?
If SELinux is involved, have the appropriate contexts been set?
Could the site be a target of a denial of service attack?
Has the server reached its connection tracking limit?
Of course, this is a relatively short list, but these are all easy to check. If you're thinking about cause and effect, you might only consider the web server daemon and some basic network issues. By considering all of the other factors that may be related, you've ensured that all of the basics are covered before you consider more complex problems.
Most systems administrators have taken an error message and tossed it in en masse into Google before. Occasionally, no results will appear for the search. If you find yourself in this situation, try to understand the individual parts of the error message. Work outward from what you know already. You should know which daemon said it, and you may have an idea of what the application was doing when the error occurred. Take time to consider what the daemon is trying to tell you within the context of what it was doing at the time.
One of the easiest ways to force yourself to be immersed into this way of thinking is to host applications for non-technical people. You'll find that many customers want things done differently, and they're all at different levels of technical aptitude. Some may find it a frustrating experience at first, but you'll think yourself later. It will force you to consider all aspects of how a server operates since you might not always know what's happening within a customer's application.
As always, if you find yourself stumbling, remember to ask your peers and colleagues. Even if they haven't seen the particular issue, they will probably be able to guide you closer to the solution you seek.
При сборке apache 1.3.41 под debian 5.0 lenny возникает ошибка: отсутствует ndbm.h:
$ ./configure \
--prefix=/usr/local/apache \
--enable-module=most \
--enable-shared=max \
$ make
...
mod_auth_dbm.c:42:18: error: ndbm.h: No such file or directory
mod_auth_dbm.c: In function ‘get_dbm_pw’:
mod_auth_dbm.c:110: error: ‘DBM’ undeclared (first use in this function)
mod_auth_dbm.c:110: error: (Each undeclared identifier is reported only once
mod_auth_dbm.c:110: error: for each function it appears in.)
mod_auth_dbm.c:110: error: ‘f’ undeclared (first use in this function)
mod_auth_dbm.c:111: error: ‘datum’ undeclared (first use in this function)
mod_auth_dbm.c:111: error: expected ‘;’ before ‘d’
mod_auth_dbm.c:114: error: ‘q’ undeclared (first use in this function)
mod_auth_dbm.c:128: error: ‘d’ undeclared (first use in this function)make[4]: *** [mod_auth_dbm.so] Error 1make[3]: *** [all] Error 1make[2]: *** [subdirs] Error 1make[2]: Leaving directory `/usr/src/apache_1.3.41/src'
make[1]: *** [build-std] Error 2
make[1]: Leaving directory `/usr/src/apache_1.3.41'make: *** [build] Error 2
Поиск по содержимому пакетов показывает, что такого файла в пакетах debian нет. Пишут, что раньше он входил в состав libc6. В одном из листов рассылки было найдено такое решение:
К сожалению, в базовых репозиториях CentOS apache-модуля mod_rpaf нет. Для его установки можно пойти двумя путями: найти готовый пакет или собрать его из SRPM самостоятельно. В этой заметке описано, как собрать пакет из SRPM.
Для установки понадобятся пакеты gcc, rpm-build и httpd-devel
В случае, если rebuild ругается, что не хватает какой-то devel-библиотеки, ее можно без труда установить используя «yum install» (так же может не хватать which, gcc, make и т.п.).
Готовый rpm-пакет можно найти в папке /usr/src/redhat/RPMS/, откуда можно его установить командой
