Not clear how to build a Jail with ezjail

[barti]

Hi

I use this links:
http://forums.freebsd.org/showthread.php?t=16860
http://scratching.psybermonkey.net/2...gure-jail.html



------------
Step 2.
Next we'll create the jail for our webserver.

ezjail-admin create WEBSERVER 10.1.1.1
------------
What is 10.1.1.1 address?




-----------------------
Step 3.
Add the following to your hosts rc.conf (or manually via ifconfig)
ee /etc/rc.conf

cloned_interfaces="lo1"
ifconfig_lo1="inet 10.1.1.1 netmask 255.255.255.0"

----------------------


What is this?
cloned_interfaces="lo1"


Is there a simple manual for using ezjail?


Thanks.

I have a dedicated server with an ip address and that's it.

[barti]

http://www.packtpub.com/article/secu...-freebsd-jails


Good Book : Network Administration with FreeBSD 7







I'm searching for hours for good info.

---------------------------
To create persistent network aliases (aliases that will persist across reboots) you would add the following to your /etc/rc.conf file (replacing your IP as needed):

ifconfig_hme0_alias0="inet 192.168.0.100/32"
ifconfig_hme0_alias1="inet 192.168.0.101/32"
ifconfig_hme0_alias2="inet 192.168.0.102/32"
---------------------------

What is the network alias?
Do I have to create it on a stand alone dedicated server?



Thanks.

[jggimi]

I can't answer any questions about FBSD Jails.

What is the network alias?

A NIC may respond to multiple IP addresses. There is a primary IP address, and optionally any number of secondary addresses that it will respond to. These are "alias addresses."

A single service may "listen" and respond to packets destined for multiple IP addresses. Or, multiple services may "listen" for packets using the same protocol/port but different IP addresses.

[barti]

Is it a good idea to use jail or not?

To protect Nginx inside Freebsd?


I'm getting a headache.

[jggimi]

Originally Posted by barti

Is it a good idea to use jail or not?

To protect Nginx inside Freebsd?


I'm getting a headache.

The purpose of isolating network services is to (possibly) limit the damage of an attack upon them.

Web servers that run "server side" programs, such as CGI or PHP, may have errors in those programs which allow an attacker to submit and execute their own code -- an injection. That injected code can do anything the web server could do.

This is a reason one might choose a "jail" -- a successful attacker would be limited to accessing only those files and services available to the jail. However, this is not necessarily good enough.

For example, the web server may be permitted to contact a database server and issue any SQL operation. A successful attacker, even in a "jail" could still reach out and read or modify the databases available to it.

I can't answer jail or FreeBSD questions. But now you know why a jail may be recommended for nginx in FreeBSD. I hope your headache subsides.

----

As you came from OpenBSD, I will tell you how this is done there:

• Services that require superuser capability (such as network servers that listen at low numbered ports) use privilege separation.
• Services that have programmatic interfaces for "server side" programs use chroot(8) to isolate filesystems.

Both the built-in httpd(8) and nginx(8) web servers use privilege separation and are chrooted by default.

[barti]

http://blogs.coventrytelegraph.net/p...ust%202012.jpg

[ocicat]

Originally Posted by barti

http://blogs.coventrytelegraph.net/p...ust%202012.jpg

Please stop posting links without providing any information about their content.

[jggimi]

Here's a an explanation of privilege separation from a 2004 presentation. This links to slide #28 and the technology is discussed through slide #31.

http://www.openbsd.org/papers/auug04/mgp00028.html

[barti]

Because if attacker can still easily go to the database then everything is doomed.


Jail can protect only the main server but the web service is in deep problems.
Attacker can replace the files in /var/www/html and then what?



--------------------
The protection is only between the main server and the web application, not between the
attacker and the web application, therefore the web application is not protected.
--------------------


What do you think, my conclusion is true?



Other means like DMZ maybe.




Thanks.


-

[jggimi]

Originally Posted by barti

Because if attacker can still easily go to the database then everything is doomed.

With this architecture...

[web server] - [database]

a jail, a chroot, a DMZ, or some other separation technology may limit data access, data change, or data loss. "Doom" will depend on the nature and extent of the attack.

With this architecture...

[web server] - [application server] - [database]

the web server is used for presentation, and database access is controlled by the business rules of the application server. An attacker that compromises a web server would not have free reign to attack the database server without first compromising the application server.

Jail can protect only the main server but the web service is in deep problems.

Attacker can replace the files in /var/www/html and then what?

Perhaps I wasn't clear. A compromised platform is one that under partial or complete control of the attacker. ALL of these various technologies merely limit the extent of possible control. In the case of a web server, it is not only the files accessible to the web server, but its abilities to be used as an attack vector towards other systems -- I used a back end database server as a common example.

What do you think, my conclusion is true?

Yes. But for clarity, ANY network facing application is at risk from attack. And that includes... not just Internet facing, but private networks as well. A compromised platform on a private network could be a vector of attack.

Other means like DMZ maybe.

No; perhaps you misunderstand what these are. They limit broad access but by design they permit certain types of access. For example, a DMZ that permits a web server to only access a database server will not prevent an attack on that database server if the web server is compromised.

Security cannot be installed.

Security is not software, nor is it hardware. Security is a process. And that is because you cannot eliminate risk. But by understanding risks, you can seek to mitigate them. In this case, risk mitigations do come from infrastructure design, and there are also mitigations from software implementation and softare tools, and also from operational best practices.

[barti]

For a web hosting company it is good idea to use jails.


But for a dedicated server with apache/nginx even inside a jail it is not so big deal.



----
So, a firewall and jail does not really protecting you from the internet jungle.
----

You only feel protected.

[jggimi]

Originally Posted by barti

But for a dedicated server with apache/nginx even inside a jail it is not so big deal.

If by this you mean that you will not bother to limit what an attacker can do in the event your server is compromised, then you have misunderstood me.

So, a firewall and jail does not really protecting you from the internet jungle... You only feel protected.

No; you may get some protection. Limited protection. But not invulnerability.

1. With server side applications you cannot eliminate all risk of compromise.
2. The various isolation technologies we've discussed so far in this thread may be able to limit what an attacker can access or can do in the event of a compromise.
3. Some of these isolation technologies might make it more difficult for an attacker to use the compromise as a vector to other services or other systems.

Along with a carefully constructed architecture and infrastructure, there are many best practices which can be deployed to further mitigate risk.

Software tools, such as:

• Network monitors and intrusion detection systems
• Application analysis and testing tools

Operational governance, such as:

• Backups at frequent cadence to removable media enforcing an "air gap" from network attached systems.
• A tested and functional disaster recovery plan.

[jggimi]

If you elect to install such a packet inspecting firewall, you should consider it only one tool of many to help you manage risk.

Your quote states that, even though the tool requires customization and maintenance, and that requires considerable effort -- it does not address all possible attacks. It cannot eliminate risk.