Is this an attack to be worried about?

[Mike McLoughlin]

A Chinese site repeatedly "attacks" one of my customers on a multi-site host.

On the screenshot you can see that using a different IP it makes GETs of folders like /scripts and /images several times a second.

a few questions:

1) how does it know exactly which files to take - such as all.js and other files?
2) should an outsider be able to access folders "under" the /web folder?

Anyone else seen this sort of targeted attempt?

Mike

[osquiabro]

Do you have a safe harbor? if true, close it, when you open port 80, many sniffers enter through that port

[Mike McLoughlin]

thanks for your suggestion but unfortunately I need port 80 to get Let's Encrypt certs.

[bshields]

Hi Mike,

It looks like they are requesting resources from a public page (could be just your login page). I expect its just a web crawler. Check the UserAgent and you might find its just some dodgy web crawler.

They aren't going to cause any issue downloading your public site resources (other than waste your server CPU).

Regards
Bill

[osquiabro]

Mike, you only need port 80 for create a certificate after this not, i have a site only port 443 open

https://fecipur.org

[frankacosta]

Hi osquiabro,
clicked on your site, loved the way your browse had highlighted record 'shadowed', how did you do that?
thanks
frank

[osquiabro]

hi, frank is simple, in my own css:

.nt-browse-selected{
   background-color: #CCCCCC;
   /*box-shadow: 10px 10px 5px #888;*/
   box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2), 0 6px 20px 0 rgba(0, 0, 0, 0.19);
}

[Bruce]

Mike, you only need port 80 for create a certificate after this not, i have a site only port 443 open

This is not (completely) true. Yes you only need the port 80 to verify that you control the domain - so once you have the certificate you can close it - but the certificate is only good for 90 days, so you will need to open it again in order to get the new certificate after 60 days.

Since all traffic on port 80 is just redirected to port 443, it's not a security issue to have this port open.

>> many sniffers enter through that port

if you have port 80 open then a port scan will reveal that port is open. But you can't "enter through a port" - that's not how ports work. All you can do is talk to the server listening on that port, and the NetTalk server just redirects you to try again on port 443. (aka a permanent redirect.)

Cheers
Bruce

[Bruce]

>> A Chinese site repeatedly "attacks" one of my customers on a multi-site host.

more accurately they are just "browsing your site".

>> On the screenshot you can see that using a different IP it makes GETs of folders like /scripts and /images several times a second.

it's pretty normal web-crawler behavior.
And it's not accurate to call this an "attack" since they are just requesting resources that you "advertise" as being available.

>> 1) how does it know exactly which files to take - such as all.js and other files?

go to any page on your site. Right-click, Page source. You'll see the source code for the HTML of your page. This includes all the resources that the page needs - JavaScript, CSS and so on. Your browser will parse these from the page as it loads, and fetch thouse resources. In other words, this thing you are seeing in the log is completely normal traffic for any browser.

>> 2) should an outsider be able to access folders "under" the /web folder?

Firstly - there's no such thing as an "insider" or an "outsider". This is a site on the web. As such it is accessible to all clients on the web. Secondly, yes, all users (aka every client in the world) should be able to access any static file you have under your web folder. [1]

Incidentally this is not an "attack" or a "targeted attempt". It is a very generic scan of your site. You'll see it happen every day from any number of search engines.

[1] There is a \web\LoggedIn folder - static files in here can only be accessed if the user is logged in.

Cheers
Bruce

[osquiabro]

if you have port 80 open then a port scan will reveal that port is open. But you can't "enter through a port"

wrong look the image, that server only had 3 open ports, 443, 80 and remote desktop.

Just for curious, is possible that letsencrypt renew automatically? because with a port 80 open and a program running as service the certificate expiry after 90 days,and i have to enter with a version that does not run as a service for it to be renewed and always have to delete the directory where the certificate

Mike, you only need port 80 for create a certificate after this not, i have a site only port 443 open

This is not (completely) true. Yes you only need the port 80 to verify that you control the domain - so once you have the certificate you can close it - but the certificate is only good for 90 days, so you will need to open it again in order to get the new certificate after 60 days.

Since all traffic on port 80 is just redirected to port 443, it's not a security issue to have this port open.

>> many sniffers enter through that port

if you have port 80 open then a port scan will reveal that port is open. But you can't "enter through a port" - that's not how ports work. All you can do is talk to the server listening on that port, and the NetTalk server just redirects you to try again on port 443. (aka a permanent redirect.)

Cheers
Bruce

[Mike McLoughlin]

Thanks for the clarification Bruce - I'm relaxing now

[Bruce]

Hi Osa,

>> wrong look the image, that server only had 3 open ports, 443, 80 and remote desktop.

So it's important to understand what an "open port" means. It means a program is listening on the port. In itself a port being open or not is not the important thing - and the port number is irrelevant - what is important is the program listening on the port.

Of the 3 ports you listed, by _far_ the most vulnerable is the Remote Desktop port. This is because the program listening on that port gives the user complete access to the computer. Also, because it is so powerful it is subject not only to back-door attacks, but also brute-force attacks. Since the login to RDP is "visible to all [1]" it's easy to simply try common login names (Administrator) with lots and lots of password attempts. Most people unfortunately have weak passwords.

[1] The best thing you can do for RDP is limit the IP addresses that can access the machine. In other words, on the server side, limit incoming RDP connections not just to a user/password but also to a specific IP address. Then you greatly reduce the risk of an attack.

[2] Of course machines can be compromised by vectors other than just direct entry. Receiving email on the machine is always a possibility. Ransomeware can also spread through a LAN if the server is on a LAN.

By comparison, having a web server listen on a port is much safer because web servers are designed to limit machine access. A web server user for example cannot read, or write, to the bulk of the server's hard drive. and by design the functions it can do are limited (even for logged in users.)

Also, once you have opened one port for the web server to listen on (443) it doesn't make any difference if it's also listening on other ports (like port 80) because it's the same program listening on both. If there is a flaw, it's not limited to any one specific port.

>> Just for curious, is possible that letsencrypt renew automatically? because with a port 80 open and a program running as service the certificate expiry after 90 days,and i have to enter with a version that does not run as a service for it to be renewed and always have to delete the directory where the certificate

I think what you are saying is that the certificate will renew if running as an exe, but not if running as a service?
that's likely to be caused by the account you are running the service in - whether that account lets you spawn the openssl.exe program or not. I recommend changing the service account settings to match your user account.

cheers
Bruce

[osquiabro]

My account assigned to the service is the same as logging into the machine and has administrator privileges.

[osquiabro]

"Of the 3 ports you listed, by _far_ the most vulnerable is the Remote Desktop port."

and NT through upload is vulnerable, look at this picture, this file with admin privileges cannot be deleted, I am consulting with security experts to try to remove it, be careful with uploads, after finding this strange file, this server it has strange calls to the database, example I found in my message log that I am trying to update a table, this table is a view in the database and the only purpose is for a report.

Be careful, the hackers are on fire...

[Bruce]

>> and NT through upload is vulnerable,

yes, if you allow uploads through your server, then files can get uploaded.
But a file being _uploaded_ means very little - it's not like we run the file when it arrives.

The biggest issue with uploading files is that they can be downloaded (although files downloaded from the uploads folder are treated differently.) So you don't want your server to become a generic "file storage" place. For this reason many developers set their uploads folder to be _outside_ the web folder, into say a special temp folder. Then the sys-admin can move files from here when they are deemed to be ok.  Obviously this approach depends a lot on the site, and what you are doing with your uploads.

The other interesting item from the pic is that the file has 0 length.

>> after finding this strange file, this server it has strange calls to the database,

again, the server can only do what it is programmed to do. And "running" external code is not (presumably) what you have programmed it to do.

>> example I found in my message log

message log? you mean Windows log? WebServer log? SQL log? I'm not sure which log you are referring to here.

>> that I am trying to update a table, this table is a view in the database and the only purpose is for a report.

There are several possible reasons for a program updating a table you think of as "read only" - but of course without more information on the write it's impossible to suggest what might be the cause.

Of course if you use the prop:sql statement, then you need to be sanitizing that statement. SQL Injection is a thing and if you use prop:sql then that becomes your responsibility. If you use the file-driver functions (as all the NetTalk code does) then you are safe from SQL injection (*)

(*) Safe in the sense that I've never been able to construct a Driver statement that creates a SQL Injection hazard. So it might be possible, but I don't know how...

cheers
Bruce