The document provides practical tips for securing web servers. It recommends removing unnecessary services to reduce vulnerabilities, using SSH or VPN for remote access rather than logging in from untrusted computers like Windows, having offline and offsite backups, separating development, static files, and CMS servers, regularly testing and applying critical security updates, monitoring logs daily, limiting user permissions, disabling unused server modules, subscribing to security alerts, and using automated scanners while following other guidelines to minimize vulnerabilities. The document aims to share tried and tested security practices that may not be commonly discussed.

1. Practical Web Server Security
By : Khawar Nehal
http://atrc.net.pk
5 August 2019
Muftasoft (TM)

2. Reason
There are many documents and articles on web
server security.
But I noticed I could share some ideas which are
old tried and tested for us but new for others
because we do not see them mentioned around
commonly.

3. The common ones floating around
I shall start by repeating those which are common
and maybe modify them a little.

4. Remove unnecessary services.
The number one reason for this provided by the
security people is that if the service is on then it
can be exploited.
This is true. However if it is not on, then it cannot
be exploited.
From my experience you need to be experienced
enough to make sure a service is off and stays off.

5. Remove unnecessary services.
The number two reason for this provided by the
security people (cracking side) is that if the
service is or software is installed, it can be used
by an attacker.

6. Remove unnecessary services.
This always seemed like a useless idea to me
because if I was a serious cracker, then I would
have all my software in one “bag” or file and
always available on the Internet ready for
download anywhere.
If I had root access, then I could download my
better and more capable software to do what I
wanted. So this does not really count.

7. Remove unnecessary services.
If you can demonstrate something better, then I
shall update this idea. Otherwise the experience
rules over the common suggestions provided.
Also there are reasons to have software around.
An example is ping. If you need to remove this
service, then you need to explain why you are too
lazy to fix the service software itself.

8. Remote access
Do not ever login from someone else’s computer
into the servers.
Hey business manager, if the admin does so, fire
them immediately. They are not security
conscious enough to work in the 20th
and 21st
century.

9. Remote access
If the admin is too lazy to have their own
computer to acces, they are not even professional
enough or qualified for the job.
Use ssh or some VPN based login.

10. Remote access
If the admin uses any insecure OS like Windows
to login, then they need to be fired.
I believe that this one change shall avoid more
than 50% of attacks.

11. Remote access
To confirm see how many attackers get access
via gaining passwords of admins from insecure
software based computers like windows before
they attack any system.

12. Remote access
https://www.securityweek.com/compromised-creden
tials-primary-point-attack-data-breaches
The next two slides are an excerpt from the above
article.

13. Remote access
The easiest way for a cyber-attacker to gain
access to sensitive data is by compromising an
end user’s identity and credentials. Things get
even worse if a stolen identity belongs to a
privileged user, who has even broader access,
and therefore provides the intruder with “the keys
to the kingdom”.

14. Remote access
By leveraging a “trusted” identity a hacker can
operate undetected and exfiltrate sensitive data
sets without raising any red flags. As a result, it’s
not surprising that most of today’s cyber-attacks
are front-ended by credential harvesting
campaigns. Common methods for harvesting
credentials include the use of password sniffers,
phishing campaigns, or malware attacks.

15. Remote access
Common methods for harvesting credentials
include the use of password sniffers, phishing
campaigns, or malware attacks.
These do not work on secure computers which
the admins could use. Examples include well
configured and updated opensource bugfree and
TRANSPARENT softwares like BSD and Linux.

16. Remote access
For very secure computers, have the server send
an SMS to verify the admin IP to allow the login
when the admin is roaming.

17. Remote access
Public wireless networks are the same as the rest
of the Internet. Who thinks that ssh or VPN based
connections would behave differently when going
through a public wireless network ?

18. Backup
Have offline and off site backups of all servers
data. Online backups are optional but not
sufficient.
Have backups of important desktops and laptops
and mobiles on backup servers.

19. Separate computers
Have separate computers for the development
and production environments.
This shall add another layer of checking to make
sure the production is hardened more than a
development machine.

20. Separate computers
Have separate computers for back end software
and static files.
Software like CMS should create static output.
Almost all software should create static output
and place it on the server generated output
server.

21. Separate computers
Have three web servers at least.
Server #1 for static file serving and modified via
technical users not common users directly.

22. Separate computers
Server #2 for running CMS editing softwares and
other backend web based software. Output is
static files to be automatically placed on server #3
Server #3 for storing and presenting files created
by server #2 as static files. No interaction
software active.

23. Separate computers
All software shall reside on server #2 and Servers
#1 and #3 shall only have static HTML and FTP
servers for serving files.

24. Separate computers
Server #1 shall host the static HTML main pages.
Chances of them being defaced with this method
are now near zero. A serious zero day is required
to do so.
Servers #1 and #3 do not have CGI or PHP type
stuff enabled.

25. Updates
Regular updates need to be done after regular
backups of the servers.
Some updates can destroy the system and make
it nonfunctional.

26. Updates
Test updates on development machines before
implementing on production machines.

27. Updates
For normal servers, updates every month. Admins
need to test only the critical security updates on
development machines and implement them on
the production servers. The other updates are not
required as long as the system is working.

28. Updates
Unnecessary updates can cause malfunctions
and are a waste of time.

29. Logs
Check the logs daily to make sure no one is trying
to get it.
Or at least did not get in. There can be many login
entries of tries.
Get a log analyzer to help if required.

30. Permissions
Check all permissions to make sure no user has
more than they need.

31. Apache modules
Eliminate or turn off all unused modules of the
webserver.

32. Updates
Subscribe to security alerts. In case a new
security flaw is found.
If a new flaw is found, then backup and update
the servers in a day on the development server to
test. Then update on the production after it works
on on the development server.

33. Automated scanners
Use automated scanners to check for
vulnerabilities.
If you have followed the steps mentioned so far,
you should get none found from all softwares and
systems available.

34. Automated scanners
If any are found, they shall be non critical and do
not allow user or root level access anywhere you
have not allowed specifically.

35. Thanks
Thanks for reading.
If you have suggestions for improvement, then
please email to khawar@atrc.net.pk

36. Thanks
Hopefully I can incorporate the ideas into the
updates of this one and into other future
presentations.

37. Practical Web Server Security
By : Khawar Nehal
http://atrc.net.pk
5 August 2019
Muftasoft (TM)