Shulou(Shulou.com)06/01 Report--

Ding Ding ~ ~ the phone rang and saw that the old man called directly to answer, "Brother, my website can't be opened! is the server down? can you take a look at it for me? thank you!" My answer is, of course, no problem, so I want to IP and login information.

Lao tie's website is a personal website, mostly some picture goods display and so on. After my recommendation on a domestic VPS provider above, from the outside to find someone to configure the server and website pages, I help to do the record real-name authentication and so on.

All right, here we go.

Browser input URL can not be opened, firebug check server did not return

Telnet xxx.me port 80 is not accessible to dig xxx.me parsing normal ping xxx.me normal ssh can log in to ps to check the existence of web process lsof-iping xxx.me 80 port normal telnet private network ip port 80 normal iptables check found that there are no regular restrictions on telnet public network port 80 can not access the restart web service, repeat the above check effect is the same

After the above inspection, it is found that the problem lies in the public network IP, but the ping public network address is normal and the ssh login indicates that the IP itself is fine, then there is only port 80 left, but the private network address 80 is fine, that is to say, the problem lies in the public network IP port 80.

After testing port 80 of the public network several times, I found that it was still impassable and seemed to be blocked by the firewall. So he picked up the phone and dialed the XX VPS customer service sister. It didn't take long to get through: "Hello, I am a user of my xxx account. Could you check for me if port 80 of my public network ip address xxx.xxx.xxx.xxx is blocked?"

The customer service sister simply said, "OK, just a moment." After the music, "Hello, your IP address xxx provides a normal website service for domain names that have not been filed, and its port 80 is blocked in accordance with the X requirements of XXX."

What?! Did not put on record, wrong ah, his domain name or I helped to get on record! Then I told the things that had been put on record and told the customer service girl the domain name. The reply I got was: "Hello, this is not the domain name that caused the IP port to be blocked. The domain name involved is xxx.com. Please put this domain name on record as soon as possible."

Speaking of which, I understand that it should be maliciously parsed. But why do you have to warn me before you seal the port?

When I opened the configuration file, I found that there was no domain name mentioned by the customer service, and of course there was no restriction on malicious resolution. The phone confirmed with the old man that this was really not his domain name, and asked him what unusual things had happened to him recently. he said that an introduction had been posted on a new product launch website recently. All right, it's clear at this point.

This is easy. Change it. Add a configuration before all vhost in the web server configuration file. If there is no matching domain name by default, it will go to this vhost. Restart the web service to make sure that the web page cannot be opened directly with ip. After scanning the security loophole with a tool, I spoke to the customer service girl and sent an email, and the website resumed a few hours later.

After June 1, 2017, major IDC and providers attach great importance to filing, real-name system and loopholes, blocking your IP if there is a disagreement, or even killing you without even telling you.

This seems to give some people with impure purposes an opportunity to use this rule to kill your site with the help of XX institutions and IDC. Managers seem to think it is more effective to target victims directly than to find saboteurs-_-| |. Website operators who are often caught off guard.

It is suggested that website operators should pay more attention to some security details when building their stations, and hope that our network operators can give us some reminders and repair time when they find problems and before dealing with them. after all, we are consumers and your customers, and you are businessmen, service providers, not "co-managers".

The configuration of apache and nginx to prevent malicious parsing is posted below

Apache DocumentRoot / data/vhost/error/ ServerName 127.0.0.1 Options None AllowOverride None Order deny,allow Deny from all CustomLog / data/logs/null.log combinedNginxserver {listen 80 default; return 405;}

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.