Win2008 Server Security Check Steps Guide (Daily Maintenance Instructions)

The document has been written for a while, but I have not dared to upload it. The more I know about server security, the more superficial I feel that I am. I haven't even got started with many things. If I post it and try to show off my skills in front of so many great people, I might get chopped to pieces if I am not careful.

During the writing process, there are many places where I understand what is going on and how to analyze and deal with them, but I just don’t know how to express them in words (it’s true that knowledge is rarely used when it is needed), so please forgive me for my limited writing skills.

There are some places where I would like to talk more deeply and explain the reasons behind them, but my personal ability is limited and I can only know the basics. Now I can only shamelessly talk about some of my methods for daily server management, and the analysis and handling methods of some problems encountered recently. As for other attack methods, I can only deal with them according to the actual situation after encountering them. Now I don’t know how to talk about those analysis and handling methods since I haven’t encountered them. Some of the contents proposed in the article are for reference only, and you can use them as a way of operation.

In the previous article "Server Security Deployment Document", it only wrote about how to deploy the server more securely, but there was no detailed description of why to set it up like this and why to use McAfee firewall, etc. But think about it, if it really goes into more detail, the length of the document may be more than half, and everyone will really be dizzy reading it, haha... However, this article will re-explain and supplement a small part of the content.

Okay, I won’t waste any more time, let’s get to the point.

Table of contents
1. Introduction 3
2. Deployment environment 3
2.1 Server environment information 3
3. Safety Check 4
3.1. Check the VirusScan console 4
3.2. Check McAfee HIP Firewall 6
3.3. Check Windows Firewall 9
3.4. Check IIS related settings and website directory access permissions 10
3.5. Checking the Administrator Account14
3.6. Check Windows log 15
3.7. Check IIS website access log 16
3.8. Check FTP log 17
3.9. Check website related logs 17
3.10. Check the server running process 19
4. Back up data21
5. Related Notes 21

1. Introduction

After the server has been securely deployed, if daily maintenance is not done, it is like leaving a flock of sheep surrounded by a fence on an open grassland without paying attention to it. One day, a wolf discovers a problem with the fence, tears open the fence, breaks into the flock and enjoys himself, while the owner is far away and unaware. If daily maintenance is done well, problems can be discovered and loopholes can be repaired in a timely manner, reducing losses.

2. Deployment Environment

Omitted (Please refer to the server deployment document)

3. Security Check

3.1. Check the McAfee VirusScan console

Some friends may ask, why use McAfee instead of other tools? This is because McAfee has an access protection function. As long as the corresponding security policy is enabled, all software that is not authorized (the excluded processes set in access protection) will not be able to perform corresponding operations. For example, if you enable "Prohibit creation of new executable files in Windows folders" or customize a policy to prohibit creation of dll and exe files in all directories on the server, then when someone hacks the server, some methods may not be executed. In case they use some of our open services to upload Trojans or invade, this security strategy will also cause great difficulties for them when performing privilege escalation operations.

After enabling these policies, when we add excluded processes, we must exclude all processes that we do not understand or are not familiar with. Some processes are not necessary to use and must be deleted after being temporarily opened to make the server more secure. Of course, I am not afraid of god-like enemies, but I am afraid of pig-like teammates. If the server management is messy and you just add exclusion processes when you see blocking items in the log, then I have nothing to say.

Open the VirusScan console

Check whether the relevant items are enabled normally

Check the Access Protection log

Check whether there are any new disabled or blocked records, check which account operated the record, whether it affects the operation of the website, and then consider whether to add it to the rule list. Generally speaking, if the blocking items do not affect the operation of the website or service, ignore them.

From the log, you can see which user is operating, which program is running, and what operation was blocked. Generally speaking, our servers are used for websites. If the SYSTEM or IIS related accounts are disabled here, then carefully check whether these programs are necessary for the operation of the website. If so, allow them, otherwise ignore them. As for the operations of the administrator account, if they are generated by one's own operations, just temporarily allow them. If not, check whether it is possible that it has been invaded.

If you need to add it, add it to the exclusion process rules of access protection

After adding, test it again to see if it is normal. If it still doesn’t work, open the log again and add the processes prohibited by the new log record to the corresponding policy.

3.2. Check McAfee HIP Firewall

McAfee HIP Firewall can directly monitor all internal and external access to all ports of the server, can directly disable the use of a certain port by designated software, and can instantly defend and block known, zero-day, denial of service (DoS), distributed denial of service (DDoS), SYN Flood and encrypted attacks.

If application policies are enabled, you can also directly control the use and operation of all server software.

Double-click the firewall icon to open the firewall software

Check whether the IPS policy anti-intrusion firewall is enabled

Check whether the firewall is enabled and check whether there are any newly added items in the rules that have been set up to determine whether these items are set up normally.

Check the activity log, open the record of all allowed items, see if there are any new ports with access links, and determine whether to allow them. If not, manually add them in the firewall rules.

Manually add blocking rules

Check the activity record again, the access to this product has been blocked

If you want the server to be more secure, you can also enable the application policy function. In this way, any software running on the server will need to be authorized. Although it will be more troublesome, the system will be more secure and reliable. You can find out how to set it up by testing it on a virtual machine.

3.3. Check Windows Firewall

Open Windows Firewall and check whether it is turned on (although McAfee Firewall is already there, the system's own firewall needs to be turned on to prevent one firewall from being turned off accidentally while the other is still turned on)

Check the firewall port opening status to see if they are those you set yourself and whether there are any new ports opened. If so, make corresponding judgments and consult other administrators of the server.

3.4. Check IIS related settings and website directory access permissions

Mainly check the directory settings of several websites to see whether the directory write permission is enabled, and then check whether all folders with write permission have executable permissions. At the same time, check whether there are any new directories on the website (some directories may be added arbitrarily by developers without the server administrator's knowledge, and some may be added by hackers), how these directory permissions are set, etc.

In addition to checking write permissions, also check whether new accounts have been added. If the root directory has write permissions, be careful. In addition, if there are new accounts, also pay attention to whether they were added by other administrators.

Check if the writable directory has executable permissions

Check the relevant folders of the website according to the above method. In addition, for the directories that do not need to be executed, such as JS, CSS, Images, configuration, logs, HTML, etc., although they are not set with write permissions, it is best to set them to have no script execution restrictions

3.5. Check the administrator account

Open the server manager and check whether the accounts are the default ones and whether there are any new accounts (generally, after the server is invaded, some new accounts will be created or some accounts originally belonging to the Guest group will be upgraded to administrator or User group permissions)

Since this document is being tested and written on a new virtual machine, the IIS access account uses the application pool account, so there are not as many accounts as in the previous article.

Check whether the group to which the Administrator account belongs is empty.

Check whether the DisableGuest account belongs to Guests and whether the account is disabled

If there are other accounts, also do the above check

3.6. Check Windows logs

Log files are very important to us. We can use them to view the operation traces of various accounts, so it is best to modify the log storage path. In addition, the SYSTEM account permissions of the log directory should be set to read-only and add-only, but not modify-only. In this way, if the system is invaded, the log files cannot be deleted or modified. (There are many articles on the Internet about log path modification, so I will not describe them in detail here)

We check the logs, mainly looking at the warnings and error messages in the logs, and analyze which exceptions are caused by code problems (send these exceptions to relevant colleagues for repair), which are system errors (determine whether they are caused by firewall rules or service or program errors, and determine whether corresponding processing is required), and which are hackers conducting intrusion attacks (after analyzing the attack method, you can re-check and process the relevant code pages to avoid vulnerabilities in individual pages that lead to successful intrusion)... For the exceptions shown in the logs, there are actually many records that are not caused by the code itself. The more common ones are exceptions caused by someone using XSS to attack submission. You don’t need to pay attention to these exceptions. As long as the SQL injection and XSS attack filtering operations at the page submission entrance are done well, there will be no problem.
In addition, if you have time, you should also take the time to look at the normal information . You can analyze many operations that have passed the firewall rules to see if any intrusion has been successful (for example, check whether some IP addresses that normally access the background are from other regions, and then check the relevant background logs to see which colleague operated it, etc.).

For the security event log, check the records of successful and failed audits carefully, and pay attention to the following: normal or failed login and logout time, check whether the server administrator logged in himself, and check whether there are accounts not created by himself; pay attention to whether there are batch login events (and possible successful intrusion); various account management events and security group management events (after a successful intrusion, you may create accounts, change passwords or delete accounts, etc., which will be recorded); audit policy change events (whether the administrator changed it himself, and if it is not his own but another administrator, check what was changed). For details, you can search "Auditing WINDOWS Security Log" on Baidu and carefully study the descriptions of various audit events.

3.7. Check IIS website access log

There are many introductions on the Internet about the inspection and analysis of website access logs. I will not repeat them here. I will mainly talk about my own views.

IIS logs will faithfully record all links that users visit to the website. If your site uses the GET method to submit parameters, you can easily see various SQL injection and XSS attack methods from the logs. If you submit using POST, you won't be able to see these contents. We check the logs mainly to find various abnormal access methods.

For example: look for some special characters commonly used in attacks from the log, such as ',1=1,1>0,update,insert,<,>,#,$,{,sp_,xp_,exe,dll, etc. Check whether there are parameters in the record of the image extension (check whether there is an upload vulnerability). Of course, you can also download an analysis tool or write one yourself.

Access logs are usually not isolated and need to be analyzed in conjunction with other related logs.

Here is an example to illustrate:

On February 10, I checked the company's backend operation log and found several access records from Shanghai IPs (Note: the backend of the company's website is an independent domain name, which is unknown to others, and the company has no other staff in Shanghai. In addition, each page of the backend management system I developed is encrypted. If you click on the URL generated by the page without logging in normally, you will have no access rights. The framework will carefully record all operations of each administrator in the background (including page browsing records))

Backstage administrator operation and access log information:

I was very surprised when I found it, and immediately checked the corresponding login log and IIS log

No login log records found

There are many corresponding records in the IIS log, such as the one corresponding to the user operation log record above (Note: the time zone of the IIS log record is not the East 8 zone where China is located, so add 8 when checking the time)

Since the encrypted code of KeyEncrypt is the same, a corresponding company IP access record was found immediately.

Then follow the clues and check the user operation log to find out who was operating at this time.

Then I went straight to that colleague to see if his computer was infected or if someone hijacked his browser.

Everyone thought that the matter had come to an end, and my colleague was also reinstalling the system~~~

When I checked again using the above method, I found that many colleagues had such records. The visiting IP addresses were all from several IP segments of Shanghai Telecom, Shenzhen Telecom and China Unicom, and the same IP was also found on the front-end page. The corresponding IP addresses of the access links belonged to customers from all over the country. It was impossible that everyone was infected. Moreover, all the characteristics of these visits were that after everyone visited the designated page, after a few minutes or half an hour, there would be one or more access records of the same path... Suddenly I had a creepy feeling. What privacy do we have when we surf the Internet? Every page we visit is monitored by someone who also takes a look to see where we go. I don’t know what to say at this point (you can try to check your server logs to see if the following IP addresses are there). Is it the browser we are using that is exposing our access or is it the firewall? Or other software? This requires further research to find out.

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

Although the background address was exposed this time, they were not allowed to successfully access the system. However, for the sake of safety, the background login immediately added the IP authorization method (need to obtain the SMS verification code, and obtain the current user's IP authorization method after submission - the mobile phone that can receive SMS is the employee's mobile phone number entered into the background system)

Log analysis cannot be directly applied because everyone's system is different, so there is no fixed pattern. It needs to be operated according to the specific situation. What we need to learn is a way of thinking about log analysis so that we can better apply it to our own work.

You should search more on Baidu to see how other friends analyze logs, so that you can improve yourself better.

Other log analysis examples: https://www.jb51.net/hack/648537.html

3.8. Check FTP logs

The FTP log mainly checks whether someone is trying to intrude, what account is used to try, whether the login is successful, what operations have been performed, etc.

3.9. Check website related logs

If your website's front-end and back-end operations, payments, and related business interfaces have log records, you should also check them carefully.

First check whether there are any abnormal records. If so, send them to relevant personnel for repair.

The backend of the website mainly checks whether the IP address accessed by the logged-in administrator is the company's location, whether there are any foreign IP addresses, and if so, whether it is a company employee, etc.; whether there is any illegal login, which pages have been visited, and what operations have been performed.

The logs related to the website front-end and business interface mainly check the business logic, recharge and other related information, which depends on the specific business.

3.10. Check the server running process

After the server is installed, it is best to immediately take a screenshot of the processes running on the server and save it. When maintaining the server on a regular basis, you can compare it with the currently running processes to see if there are any additional unfamiliar processes. If so, search on Baidu to see what software it is, what its function is, whether it is a dangerous backdoor program, etc.

4. Back up your data

Do a good job of automatic database backup, and frequently check whether the backup of the day is successful (sometimes the backup may not be successful due to data full or other abnormalities). In case the backup fails and the database has problems, hehe~~~you can predict what will happen. If the space is large and the data is very important, it would be safer to do more backups or data synchronization operations every day. If most of your friends only have one or several independent servers, then in addition to automatic backup, it is still necessary to compress the database and download it to the local backup every day.

Back up your website and related images regularly.

Regularly back up the various logs mentioned above (sometimes you need to use them when you need to view and analyze some information, such as when an intrusion is discovered after a period of time. At this time, you need to slowly look through the historical logs to see where the vulnerability is caused so that you can repair it), and clean up the backed up log files (some friends often do not clean up the logs, and sometimes errors occur because the log storage space is full)

5. Related Notes

1. The work of anti-hacking is a long and arduous task. In addition to making good security settings, you must also do detailed inspection and maintenance work related to the server on a regular basis.
2. You can regularly use various hacking tools to try to attack your own server to see if there are any vulnerabilities. Seriously go to major forums and websites to learn various attack techniques. Only by understanding the opponent's attack methods can you do a good job of protection.
3. During the inspection process, if you find that unfamiliar settings have been changed, you need to contact relevant colleagues immediately for consultation to ensure the security of the server.
4. Regarding server settings, disable all operations prompted by the firewall first, and then enable them when you find that a certain service or something cannot run, so as to avoid opening up some unnecessary ports of the server.

5. When a problem is found, it is necessary to analyze all new and old logs in detail to check how the attacker entered and what operations were performed, so as to formulate corresponding strategies to prevent the next intrusion.
6. The analysis of server logs is flexible and varied. Different problems require different analysis methods, and different logs need to be combined for comprehensive analysis. This requires continuous learning and accumulation of experience.

7. Of course, if you can understand the website's program architecture, it will be more helpful to the security of the website.

Due to my limited writing skills, there are definitely many omissions in this article. I would like to ask you to point them out. Finally, I hope this article can be helpful to you.

If you feel this article is helpful to you, please recommend it.

Copyright Notice:

This article was published by AllEmpty on Blog Garden. The copyright of this article is shared by the author and Blog Garden. Reprinting is welcome, but this statement must be retained without the author's consent, and the original link must be given in a prominent position on the article page. If you have any questions, you can contact me at 1654937#qq.com . Thank you very much.

The purpose of publishing this content is to learn and make progress together with everyone. Friends who are interested can join the QQ group: 327360708 or email me (1654937#qq.com) for discussion. Due to my busy work, if you have any questions, please leave a message first. Please forgive me for the late reply.