This was made for a class in Network Security and Management. The idea was to configure a small business network according to a set of requirements. These requirements are in docs/Projecto_Final.pdf (in portuguese). Our solution is represented in the following diagram.
To simulate this network and be able to test the configurations as best we could, we used Vagrant and Chef. In VirtualBox, we can simulate the same network using the following setup.
You need to have Vagrant and VirtualBox installed first.
After that, through the command line, cd into the project's folder, and run:
$ vagrant upThis will start to download the base box from the web, start 7 virtual machines, and apply configurations (provision), which includes downloading all necessary packages (e.g. named, http).
You can also up only one machine:
$ vagrant up dmzOr all client machines using a regular expression:
$ vagrant up /client*/Note: The names of these machines are represented in the above diagram.
After doing up for the first time, you can skip provisioning to save time:
$ vagrant up server --no-provisionIt only makes sense to run up when the machine is down. To reboot, use reload, or halt to shutdown. There's also suspend and resume. Run vagrant -h for available options.
When you're done, you can destroy it all with:
$ vagrant destroy -f
$ vagrant box remove centos virtualboxThe first command removes all virtual machines from disk. The second, removes the base image where the VMs are based off of.
During provisioning, the DNS server is automatically updated with the public/external IP attributed to the dmz, so that it's possible to access from outside.
There's a script that checks and updates the IP address in the DNS server, in case it has changed. In any case, the current IP address is printed on screen so you can use it to update the list of nameservers in your host machine or any other computer in your LAN that are trying to access the dmz.
To find your dmz IP:
$ ./dns.sh
Already up to date for IP 192.168.1.131!If your VM has already been started and that IP changed for some reason (e.g. roaming to another network), you can also restart the interface so that the new IP is updated:
$ ./dns.sh -r
Determining IP information for eth2... done.
Recovering from backup... done.
Updating files... done.
Stopping named: .[ OK ]
Starting named: [ OK ]
Your nameserver is at 192.168.0.105All the VMs can be accessed through the command vagrant ssh [vm]. That access is created automatically by Vagrant through the eth0 interface, with NAT. This access makes it easier o manage each individual VM, but, to simulate what would happen in production, we should access the DMZ and through it, the rest of the network. Since Vagrant also creates the user vagrant with administration privileges, all the VMs make use of this by being the only user that is allowed to ssh to.
To gain root access to the internal server:
$ ssh [email protected]
[email protected]’s password:
[vagrant@dmz ~]$ ssh vagrant@server
vagrant@server’s password:
[vagrant@server ~]# su -
Password:
[root@server ~]#The password for the users vagrant and root is vagrant.
Vagrant sets up automatically a shared folder at /vagrant which points to the current folder in the host machine, where Vagrantfile is located. This can be useful to transfer files from the VM to the host machine and vice versa.
The order in which the VMs are booted up matters, since there's dependencies between them. The VM dmz has it's own connection to the Internet e so it can be used independently, except for ownCloud which needs LDAP from server.
All other VMs need the router to be able to access the Internet and the dmz for the DNS, including router itself.
This only matters if using vagrant up [vm] though. vagrant up by itself will boot all VMs in the right order.
If a VM doesn't respond when it's being shutdown or booted up, the following error may appear:
stderr: VBoxManage: error: The object is not ready
If that happens, just keep insisting.
For errors during the provision phase, just keep repeating the provisioning as many times as you want:
$ vagrant provision serverIt's built in a way that it tries to make sure the VM is in the intended state.
If a VM can't connect to the Internet it will fail during the provision phase. If the VM has already gone through a completely successful vagrant up, then you can skip this phase with the option --no-provision as seen at the beginning of this guide.
- Make a secure connection with TLS between ownCloud and the LDAP server;
- Use LDAP with FTPS to authenticate:
- the real estate group (imobiliária) into their userdirs;
- the web designers to the
/var/wwwdir.
O enunciado e relatório está em docs.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent