Secure Apache Web Server – Practical Guide
1 Introduction
The Web Server is a crucial part of web-based applications. Apache Web Server is often placed at the edge of the network hence it becomes one of the most vulnerable services to attack. Having default configuration supply many sensitive information which may help hacker to prepare for an attack the web server.
The majority of web application attacks are through XSS, Info Leakage, Session Management and PHP Injection attacks which is due to weak programming code and failure to sanitize web application infrastructure. According to the security vendor Cenzic, 96% of tested applications have vulnerabilities. Below chart from Cenzic shows the vulnerability trend report of 2013.
This practical guide provides you the necessary skill set to secure Apache Web Server. In this course, we will talk about how to Harden & Secure Apache Web Server on Unix platform. Following are tested on Apache 2.4.x and I don’t see any reason it won’t work with Apache 2.2.x.
- This assumes you have installed Apache on UNIX platform. If not, you can go through Installation guide. You can also refer very free video about how to Install Apache, MySQL & PHP.
- We will call Apache installation directory /opt/apache as $Web_Server throughout this course.
- You are advised to take a backup of existing configuration file before any modification.
1.1 Audience
This is designed for Middleware Administrator, Application Support, System Analyst, or anyone working or eager to learn Hardening & Security guidelines. Fair knowledge of Apache Web Server & UNIX command is mandatory. This is seven page guide, click on Next to proceed. You may navigate through table of contents at right hand side.
Lire la suite…
Using VMWare ESXi and PFsense as a network firewall/router
In most networks, you will have dedicated hardware to function as your “edge” (firewall/router). This is typically for the best, but there are always cases where you can’t put out that dedicated hardware. Sometimes it’s for cost reasons and sometimes it’s for complexity. In my particular case, I was installing an ESXi server in a datacenter and only had 2 amps of power to work with, of which my server took up ~1.8amps at peak load. So cost came into play and we simply couldn’t afford to put in dedicated hardware that could push enough bits. In such cases, it is possible the setup ESXi on the network edge, in a reasonably secure fashion, with PFSense acting as a firewall.
The most important requirement to this project is that your VMWare ESXi server has at least two network ports on it. One will be the WAN port, one will be the LAN port. Also throughout this tutorial I will use PFSense as my firewall/router OS of choice, however it is just an example that can be easily swapped out with any other virtualized firewall product. Some options include Palo Alto Networks, Fortinet, and even generic *NIX operating systems with the right forwarding/firewall setup.
Section 1 – VMWare Setup
Section 2 – Virtual Machine Setup
| Step 1 – New VM |
 |
| Step 2 – Typical Setup |
 |
| Step 3 – Name your VM |
 |
| Step 4 – Select Datastore |
 |
Step 5 – OS Type
If you’re using PFSense, select “Other” and “FreeBSD 64bit” |
 |
Step 6 – Two NICs
Unlike most VMs with 1 NIC, add 2 NICs to this VM.
Make sure one adapter is on “WAN” network and one adapter is on “LAN” network. |
 |
Step 7 – Allocated HD
PFSense doesn’t need much space, but it should be allocated a 2:1 for swap (e.g. 4096 MB swap file for 2048 MB of RAM), plus some extra space for packages and logs may be useful. |
 |
| Step 8 – Edit before completion |
 |
Step 9 – Final settings
As this is my firewall, I want to make sure it is plenty fast. So I opted for 4 cores and 2 GB RAM. Also attach the CD drive to PFSense installer (be it datastore ISO or real USB/Optical drive). |
 |
Step 8 – Verify Network
Hop back to Configuration > Networking and you should see something like this. Note: various VMs are all attached to the LAN vSwitch, however only PFsense VM is attached to both WAN & LAN (just like a real firewall). |
 |
Step 9 – VM Startup
Go to Configuration > VM Startup/Shutdown
Click Properties |
 |
Step 10 – Set PFSense to first boot order
You may have other VMs that you want to auto-start, but as this is your firewall, it should be the first to start. |
 |
Section 3 – PFSense
Step 1 – Install PFSense
Once you’ve installed PFSense, it will automatically configure its local interface to 192.168.1.1 |
 |
Step 2 (Optional) – Change local network
You can reconfigure the local network either via web interface (at the aforementioned IP: http://192.168.1.1) or command line |
 |
Step 3 – Configure WAN
Again, this can be configured either via the web, or command line. |
 |
| Step 4 – Plug in WAN cable |
 |
Step 5 – Test
If you’ve got the ports configured properly (i.e. WAN hardware is WAN in VMWare and WAN in PFSense), you should be able to connect to the internet. |
 |
There are two big questions after building a setup like this, the first is security. Since PFSense is the host to provide an interface on the WAN, it should be the only method of ingress into your network. With no VMware management interface on the WAN, there should be no way for an outside party to access ESXi directly. I’ve used this setup successfully (and safely) before, as have others. However, you always need to balance your particular security concerns with the cost of dedicated devices.
The second question is remote management/maintenance/failure. Managing ESXi remotely is easy, if you setup a VPN on your PFSense VM. Without that (or similar) you will not be able to remotely manage the box (by design). But what happens if there is a failure either in the VMWare hardware or the PFSense virtual machine? That’s the big failing point of this setup – you’re down. If, for whatever reason, PFsense dies – your network is offline and you cannot remotely manage it. If this hardware is installed in a dateacenter, you’d need to either get in there yourself or remote hands reboot. Something to keep in mind when balancing the cost issue. OF course, if it’s local (say you use this at home), then it’s not such a big deal.
I will note that this is the setup I use in my home network, which doubles as my homelab. Having a VM for a firewall gives me a lot of flexibility, like adding an entirely separate vSwitched network for experimental VMs. I can also swap out the firewall VM for another one with next to no downtime. It also allows me to skip one more piece of hardware at home which would add to my otherwise hefty powerbill.
Source: obviate.io
From Wikipedia, the free encyclopedia
A
residual-current device (
RCD), or
residual-current circuit breaker (
RCCB), is a device that instantly breaks an electric circuit to prevent serious harm from an ongoing electric shock. Injury may still occur in some cases, for example if a human falls after receiving a shock. In the
United States and
Canada, the device is more commonly known as a
ground fault circuit interrupter (
GFCI),
ground fault interrupter (
GFI) or an
appliance leakage current interrupter (
ALCI). In the
United Kingdom, these are better known by their initials
RCD, and a combined RCD+MCB (
miniature circuit breaker) is known as a
RCBO (
residual-current circuit breaker with overcurrent protection). In
Australia, they are sometimes known as
safety switches or an
RCD. An
earth leakage circuit breaker (ELCB) may be a residual-current device, although an older type of voltage-operated earth leakage circuit breaker also exists. In German-speaking countries the device is sometimes known as
FI where the
F stands for fault (Fehler) and
I for the symbol that represents
electric current.
These
electrical wiring devices are designed to quickly and automatically disconnect a circuit when it detects that the
electric current is not balanced between the energized (line) conductor(s) and the return (
neutral) conductor. Under normal circumstances, these two wires are expected to carry matching currents, and any difference can indicate a
short circuit or other electrical anomaly is present, such as leakage. Leakage can indicate a shock hazard (or shock in progress) which is a potential danger to a person. Current leakage can result in harm or death due to electric shock, especially if the leaking electric current passes through the torso of a human. A current of around 30
mA (0.030 amperes) is potentially sufficient to cause
cardiac arrest or serious harm if it persists for more than a small fraction of a second. RCDs are designed to disconnect the conducting wires quickly enough to prevent serious injury from such shocks, commonly described as the RCD being « tripped ».
An RCD does not provide protection against unexpected or dangerously high current (called spikes or surges) when current is flowing in the usual wires in the circuit, therefore it cannot replace a fuse or protect against overheating or fire risk due to overcurrent (overload) or short circuits if the fault does not lead to current leakage. Therefore, RCDs are often used or integrated as a single product along with some kind of circuit breaker, such as a fuse or miniature circuit breaker (MCB), which adds protection in the event of excessive current in the circuit (the resulting RCD with overcurrent protection called an RCBO). RCDs also cannot detect the situation where a human accidentally touches both conductors at the same time, since the flow of current through an expected device, an unexpected route, or a human, are indistinguishable if the current returns through the expected conductor.
RCDs are usually testable and resettable devices. Commonly they include a button that when pressed, safely creates a small leakage condition, and a switch that reconnects the conductors when a fault condition has been cleared. Depending upon their design, some RCDs disconnect both the energized and return conductors upon a fault, while others only disconnect the energized conductor and rely upon the return conductor being at ground (earth) potential. The former are commonly known as « double-pole » designs; the latter as « single-pole » designs. If the fault has left the return wire « floating » or not at its expected ground potential for any reason, then a single-pole RCD will leave this conductor still connected to the circuit when it detects the fault.
[one-third-first]
A two-pole, or double-pole, residual-current device. The test button and connect/disconnect switch are colored blue. A fault will trigger the switch to its down (off) position, which in this device would disconnect both conductors.[/one-third-first]
[one-third]
[/one-third]
[one-third]
1: Electromagnet with help electronics
2: Current transformer secondary winding
3: Transformer core
4: Test push-button
L: Line conductor
N: Neutral conductor
[/one-third]
Lire la suite…
Source: Changzhou Chen
The default firewall in the Control Panel is so poor because of the poor design of Synology’s firewall policy. You can not use the white list in the global environment if you have both IPv4 or IPv6 network environment. To decrease the risk of being hacked, I’ve decided to change the firewall manually. We should use iptables and ip6tables to change both IPv4 and IPv6 firewall. If you don’t have the need for IPv6 network environment, you can ignore the ip6tables part.
Warning: If you don’t have enough IT experience, you should run the following sections carefully. Maybe you will lose your connection to your Synology and find it hard to connect to it again.
I wrote some IPv4 rules, the following code section is part of the rule file, you can run the iptables-save to export the rule file:
DiskStation> iptables-save > ipv4
# For your simple reference, I delete the
# unuseful part of rule file which exported by iptables-save. The following
# part is completely different from the file exported by iptables-save.
DiskStation> cat ipv4
*filter
:INPUT DROP # Drops all inbound connections that doesn't use the following rules
:FORWARD ACCEPT # It may be default, you can ignore it
:OUTPUT ACCEPT # It may be default, you can ignore it
-A INPUT -i lo -j ACCEPT # Allows all loopback (lo0) traffic
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Accepts all established inbound connections
-A INPUT -s 192.168.1.1/255.255.255.0 -j ACCEPT # Allows your Intranet inbound connections
-A INPUT -s 1.2.3.4 -j ACCEPT # Allows the specified ip address inbound connections
COMMIT
After run the iptables-restore and iptables -L, you can see the following result:
DiskStation> iptables-restore < ipv4
DiskStation> iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
DEFAULT_INPUT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DEFAULT_INPUT (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- 192.168.1.0/24 anywhere
ACCEPT all -- 1.2.3.4 anywhere
Lire la suite…
What was used and how it’s connected up.
