In this lesson we'll discuss a few simple configuration tweaks to further secure your in jinich server
and with the focus of this course being on web specific servers will also cover some common configuration
parameters to further secure your site.
Before we begin I'll remove a few lines from the previous lessons.
This limits zone and a bit further down the basic auth implementation.
Save this and over to the command line reload the configuration and with that done.
Let's start adding those final few configurations to harden our engineer server.
An obvious but often overlooked or neglected action is that of keeping all engine exer supporting software
up to date bondra abilities are discovered every day and with engine exis use of many third party libraries
such as openness s l or even the g d image library.
It's essential to keep these packages up to date.
So with that said we can run apt get update to first update all of a petey's repos and saucers.
Then with those all fetched upgrade all existing packages with app to get upgrade.
For which you might get a few of these prompts.
I'll just keep locally modified versions.
And done an easy task.
Then also when working with a custom build of engine x.
Another worthwhile step here would be checking your version of engine X and seen from that engine start
all changelog.
If there's any critical update worth recompiling engine X for which we've covered a few times throughout
the course.
Now when the engine exchange log reflects an important security fix or something of that nature.
This will of course only affect prior versions meaning that malicious users could target your server
based on its version number to get engine X as version number remotely then is as simple as doing a
cold request for the headers like so enter and there we have it burgeon one point thirteen point ten
as per this version on the command line.
So hiding this is definitely good as it certainly doesn't benefit us having the version in the response
headers over to the configuration and right at the top here in the HTP context set server underscore
tokens off easier that save and reload.
Form the same SQL request again.
And now we only get in Genex without that version.
The next edition is one of the less engineered specific configurations but nonetheless important for
web content X frame options.
In short this will prevent malicious users embedding your site into their own.
But what is typically known as click jacking.
To demonstrate I'll create a new file on my computer.
So not on the server.
I'll sit this to be recognized as h.t. amelle in my editor and add a basic etched here muhl structure.
Call this page origin test with this hvm old page now acting as the malicious site.
Trying to click Jack my server then in the body add an eye frame linking to my service IP so their demo
site.
Give this some dimensions.
Save.
And I'll open this file in my browser.
There but I framed loads indexed on HD email from my server without any issue.
Now whilst you might very well want third party websites to be able to embed your content via an eye
frame it's certainly never a good idea when your site contains any user specific pages such as logged
in pages profiles etc..
So do tell the browser to not allow this then we can add a simple header to our server responses in
the server context.
So going to all requests add underscore header x brain options same origin meaning only if the domain
embedding the contain matches that of the content itself.
Allow this safe.
Reload engine x.
And now when I reload this page.
Nothing.
We get this blank I frame open the developer tools console reload again and there we have it an error
load denied.
Our server does not permit cross origin framing or embedding.
Along with that header we can also add x x s s protection or cross-site scripting protection sitting
to one which is on and the mode to block delling the browser that if it detects crosseyed scripting
this Able loading the page.
So just a couple of additions to help secure your content once it's left the server.
The next and final improvement is removing unused or dangerous.
Engine X modules by default engine X gets compiled with a few built in modules of which some we might
never use and others even posing potential security risks.
So as with adding modules to a bold we can also remove default modules with the added benefit of reducing
the installation size and requiring engine X to load less code in my home directory here.
I still have the original source code so change into that running as before.
In the current directory configure with the help flag to see a list of configuration parameters and
modules that's available to compile.
But notice that some of these flag state with out rather then worth as we've seen when adding modules
these all being modules that will be added by default and to not have them pulled into in generics.
We can use these flags.
I'll filter to only those same configure command again using grep to only see with out there quite a
few.
You definitely want to be careful here not to remove and modules but for example a prime candidate for
removal would be this HTP auto index module.
This allowing engine X to respond to a directory request with the contents of that directory not something
we ever want for a public facing website.
So to rebuild engine X without this module then copy that flag.
Get the current configuration with engine X capital V flag.
Run configure in the source directory again paste the with out auto index module flag we copied and
add the existing configuration to that like so there's now allowing us to reconfigure our source code
to exclude the auto index module and follow the usual make and make install steps.