Score:0

How to secure my server with UFW (presumed under attack)

in flag

I am running Apache on Debian.

Below is a sample of entries in my apache error log. Question 1: Is the server under attack (I see about a 30-40 such entries every hour). I am presuming that these are attacks on or at least probes into my server.

[Sun Feb 13 16:37:54.013622 2022] [:error] [pid 16071] [client 106.193.114.87:19356] PHP Notice: Undefined variable: error_msg in /var/www/example.com/page-sidebar-both.php on line 57, referer: https://example.com/podbanks/abresult.php?ab=ab18&lg=English

[Sun Feb 13 16:38:01.289976 2022] [:error] [pid 16109] [client 106.193.114.87:19358] PHP Notice: Undefined variable: result_msg in /var/www/example.com/abc/defg.php on line 210, referer: https://example.com/result.php?ab=ab18&lg=English

[Sun Feb 13 16:38:01.290048 2022] [:error] [pid 16109] [client 103.77.154.37:1842] PHP Notice: Undefined variable: status in /var/www/example.com/pods/dashboard.php on line 210, referer: https://example.com/result.php?ab=AB18&lg=English

[Sun Feb 13 16:38:26.788827 2022] [:error] [pid 15961] [client 54.90.210.118:36104] PHP Notice: Undefined variable: BaseURL in /var/www/example.com/biz.php on line 63

(the pages and variables are valid, but the port numbers are strange).

Question 2: If these are attacks, can I stop them with UFW? I currently have:

To                         Action      From
--                         ------      ----
WWW Full                   ALLOW       Anywhere
3306                       ALLOW       Anywhere
22                         ALLOW       Anywhere
8081                       ALLOW       Anywhere
1185                       ALLOW       Anywhere
WWW Full (v6)              ALLOW       Anywhere (v6)
3306 (v6)                  ALLOW       Anywhere (v6)
22 (v6)                    ALLOW       Anywhere (v6)
8081 (v6)                  ALLOW       Anywhere (v6)
1185 (v6)                  ALLOW       Anywhere (v6)

8081                       ALLOW OUT   Anywhere
8081 (v6)                  ALLOW OUT   Anywhere (v6)

Are these following steps valid and complete considering the above?

ufw disable
ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow WWW Full
ufw allow 1185
ufw allow 3306
ufw enable

(line 1 is to make sure I don't get locked out - I am using PuTTY)

Question 3: Do I really need to open 3306 if MySQL is only used locally? I only give access to the database through php queries which are password and session protected.

Question 4: Do I need port 8081 at all? Is it automatically added by "WWW Full"?

Score:3
in flag

I don't see any indication of an attack, just poorly written PHP. You can filter the notices from the logs by changing the error reporting configuration of PHP. There is also nothing unusual about the ports, client ports in that range are normal.

Score:3
ar flag

(the pages and variables are valid, but the port numbers are strange).

The port numbers are normal. It's the clients ephemeral ports.

Question 2: If these are attacks, can I stop them with UFW? I currently have:

Generally no. You need to filter at the applicable level, and you want traffic to reach Apache - so you can't filter at L3.

Do I really need to open 3306 if MySQL is only used locally? I only give access to the database through php queries which are password and session protected.

No. You don't. Local mySQL goes over a socket, not TCP/IP. And even if not, you'd want to only allow it on the loopback interface (127.0.0.1).

Question 4: Do I need port 8081 at all? Is it automatically added by "WWW Full"?

Probably not. But you need to know how your application works.

us flag
Check `/etc/ufw/applications.d/apache2-utils.ufw.profile`. It contains all definitions. `Apache` = only port 80/tcp, `Apache Secure` = only port 443/tcp and `Apache Full` is the same as enabling `Apache` and `Apache Secure`.
Score:1
bd flag

Ad question 1: The log messages you quoted do not show any indication of an attack. Rather, they indicate errors in the PHP code of your webserver. The messages also contain the exact location (file name and line number) where the errors occurred. You may want to have a look there.

The port numbers in the messages are not strange at all but absolutely normal.

Ad question 2: Given there is no attack, the question does not apply.

Ad question 3: You do not need to, and shouldn't, expose the MySQL port 3306 to the network if it is only used locally by the webserver. That is, MySQL server should be configured to only listen on the address 127.0.0.1 (localhost) and port 3306 should not be allowed in ufw.

Ad question 4: Whether you need port 8081 allowed or not depends on whether there is any service running on that port which you want to be reachable via the network. If there is nothing listening on port 8081, or if whatever is listening there should not be reachable via the network, then you should not allow it in ufw.

Score:1
br flag

Anything you expose on the Internet will get probed for weaknesses.

The basis for good passive security is to understand what network flows are necessary for your service to function, and only allow that specific traffic. For anything nonstandard you don't get this understanding by asking strangers on Serverfault for advice.

If you are only presenting a web service to the Internet, it's likely the only traffic you need to allow from clients ("Any") is HTTP and HTTPS.

You will also need to present a management interface - either regular ssh, or a management VPN of some kind. It's important that whatever you choose here is hardened enough to withstand the inevitable brute force attacks. It's good practice to use key or certificate based authentication for these channels.

In general terms you never want to expose a database server directly to the Internet.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.