
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I was playing some time ago with a little server, running Apache, in a dynamic home address. And using a very high port, to avoid scans. I forgot about it. Then the other day, I wanted to share a file using my server, and noticed that Apache was being hit, with "stupid" requests. Well, not stupid, they are probably probing vulnerabilities. What it surprises me is that they hit such a high port, they have to be probing every port. (The router is set to redirect incoming tcp on that high port to the inside server at the same high port) My IP address changed on the 7 and 8 of February, the hits increase on the 10th. It is possible that the previous user of that IP had a known domain. Should I worry? Should I try to implement something in the firewall that blocks IPs that attempt on vulnerabilities, somehow? If there is such a tool. Can I know if they are attempting to access the URL by domain name or by IP address? Ie, what do they write exactly on the "browser". Or script. Excerpt from /var/log/apache2/access_log: 167.248.133.54 - - [15/Feb/2021:17:20:14 +0100] "GET / HTTP/1.1" 403 972 "-" "Mozilla/5.0 (compatible; CensysInspect/1.1; +https://about.censys.io/)" 193.27.228.23 - - [15/Feb/2021:21:13:58 +0100] "\x03" 400 911 "-" "-" 185.202.2.149 - - [15/Feb/2021:21:43:39 +0100] "\x03" 400 911 "-" "-" 185.156.72.7 - - [15/Feb/2021:21:59:50 +0100] "\x03" 400 911 "-" "-" 185.202.2.149 - - [15/Feb/2021:23:00:41 +0100] "\x03" 400 911 "-" "-" 185.202.2.149 - - [16/Feb/2021:01:49:38 +0100] "\x03" 400 911 "-" "-" 185.176.220.106 - - [16/Feb/2021:05:00:32 +0100] "\x03" 400 911 "-" "-" 194.61.55.248 - - [16/Feb/2021:05:10:43 +0100] "\x03" 400 911 "-" "-" 94.102.49.193 - - [16/Feb/2021:09:28:17 +0100] "GET / HTTP/1.1" 403 972 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36" 94.102.49.193 - - [16/Feb/2021:09:28:17 +0100] "GET /favicon.ico HTTP/1.1" 403 958 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Firefox/80.0" 72.251.228.107 - - [16/Feb/2021:11:39:07 +0100] "GET //admin/config.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:07 +0100] "GET //ippbx/admin/config.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:08 +0100] "GET //apps/ippbx/admin/config.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:08 +0100] "GET //admin/images/ HTTP/1.1" 403 972 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:09 +0100] "GET //freepbx/admin/images/ HTTP/1.1" 403 972 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:09 +0100] "GET //html/admin/config.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:10 +0100] "GET //fpbx/admin/images/ HTTP/1.1" 403 972 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:10 +0100] "GET //www/admin/images/ HTTP/1.1" 403 972 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:10 +0100] "GET //asterisk/admin/images/ HTTP/1.1" 403 972 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:11 +0100] "GET //myasterisk/admin/images/ HTTP/1.1" 403 972 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:11 +0100] "GET //pbx/admin/images/ HTTP/1.1" 403 972 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:12 +0100] "GET //html/admin/config.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:12 +0100] "GET //fpbx/admin/config.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:12 +0100] "GET //www/admin/config.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:13 +0100] "GET //asterisk/admin/config.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:13 +0100] "GET //myasterisk/admin/config.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:13 +0100] "GET //pbx/admin/config.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:14 +0100] "GET //recordings/index.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:14 +0100] "GET //freepbx/recordings/index.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:15 +0100] "GET //html/recordings/index.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:15 +0100] "GET //fpbx/recordings/index.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:15 +0100] "GET //www/recordings/index.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:16 +0100] "GET //asterisk/recordings/index.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:16 +0100] "GET //myasterisk/recordings/index.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:17 +0100] "GET //pbx/recordings/index.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:17 +0100] "GET //admin/modules/ HTTP/1.1" 403 972 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:18 +0100] "GET //freepbx/admin/modules/ HTTP/1.1" 403 972 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:18 +0100] "GET //html/admin/modules/ HTTP/1.1" 403 972 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:19 +0100] "GET //fpbx/admin/modules/ HTTP/1.1" 403 972 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:19 +0100] "GET //www/admin/modules/ HTTP/1.1" 403 972 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:20 +0100] "GET //asterisk/admin/modules/ HTTP/1.1" 403 972 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:20 +0100] "GET //myasterisk/admin/modules/ HTTP/1.1" 403 972 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:21 +0100] "GET //pbx/admin/modules/ HTTP/1.1" 403 972 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:21 +0100] "GET //user/admin/images/ HTTP/1.1" 403 972 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:21 +0100] "GET //user/admin/config.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:22 +0100] "GET //user/recordings/index.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 72.251.228.107 - - [16/Feb/2021:11:39:22 +0100] "GET //user/recordings.php HTTP/1.1" 403 958 "-" "python-requests/2.25.1" 122.228.19.79 - - [16/Feb/2021:12:17:06 +0100] "-" 408 - "-" "-" 122.228.19.79 - - [16/Feb/2021:12:17:52 +0100] "GET / HTTP/1.1" 403 972 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0" 122.228.19.79 - - [16/Feb/2021:12:18:58 +0100] "GET / HTTP/1.1" 403 972 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 QIHU 360SE" 122.228.19.79 - - [16/Feb/2021:12:18:58 +0100] "GET /favicon.ico HTTP/1.1" 403 958 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 QIHU 360SE" 194.61.55.248 - - [16/Feb/2021:14:45:02 +0100] "\x03" 400 911 "-" "-" 117.157.71.16 - - [16/Feb/2021:16:11:56 +0100] "-" 408 - "-" "-" 72.251.228.107 - - [16/Feb/2021:19:23:13 +0100] "\x16\x03\x01" 400 911 "-" "-" 78.128.112.14 - - [17/Feb/2021:10:20:15 +0100] "\x03" 400 911 "-" "-" 185.202.2.149 - - [17/Feb/2021:18:13:10 +0100] "\x03" 400 911 "-" "-" 185.202.2.149 - - [17/Feb/2021:22:20:23 +0100] "\x03" 400 911 "-" "-" 94.232.47.170 - - [17/Feb/2021:22:54:01 +0100] "\x03" 400 911 "-" "-" 185.202.2.149 - - [17/Feb/2021:23:36:37 +0100] "\x03" 400 911 "-" "-" 94.232.47.170 - - [18/Feb/2021:06:31:02 +0100] "\x03" 400 911 "-" "-" 167.99.129.160 - - [18/Feb/2021:09:38:58 +0100] "HEAD / HTTP/1.0\n" 400 911 "-" "-" 167.99.129.160 - - [18/Feb/2021:09:38:58 +0100] "GET /system_api.php HTTP/1.1" 403 958 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" 167.99.129.160 - - [18/Feb/2021:09:38:58 +0100] "GET /system_api.php HTTP/1.1" 403 958 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" 167.99.129.160 - - [18/Feb/2021:09:38:58 +0100] "GET /c/version.js HTTP/1.1" 403 958 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" 167.99.129.160 - - [18/Feb/2021:09:38:58 +0100] "GET /streaming/clients_live.php HTTP/1.1" 403 958 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" 167.99.129.160 - - [18/Feb/2021:09:38:58 +0100] "GET /stalker_portal/c/version.js HTTP/1.1" 403 958 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" 167.99.129.160 - - [18/Feb/2021:09:38:58 +0100] "GET /client_area/ HTTP/1.1" 403 972 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" 167.99.129.160 - - [18/Feb/2021:09:38:58 +0100] "GET /stalker_portal/c/ HTTP/1.1" 403 972 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" 167.99.129.160 - - [18/Feb/2021:09:38:58 +0100] "GET /stream/rtmp.php HTTP/1.1" 403 958 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" 167.248.133.37 - - [18/Feb/2021:19:44:05 +0100] "GET / HTTP/1.1" 403 972 "-" "Mozilla/5.0 (compatible; CensysInspect/1.1; +https://about.censys.io/)" 185.202.2.149 - - [18/Feb/2021:23:26:24 +0100] "\x03" 400 911 "-" "-" 185.176.220.106 - - [19/Feb/2021:07:51:23 +0100] "\x03" 400 911 "-" "-" - -- Cheers Carlos E. R. (from 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYDFkexwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV3YIAn3Pm3hBMPaVD91DnnVAG lldoQ6rzAJ9VaZstpPUvRkD9Vr5fUZHjy1IOJA== =VXHj -----END PGP SIGNATURE-----

Carlos E. R. wrote:
Then the other day, I wanted to share a file using my server, and noticed that Apache was being hit, with "stupid" requests. Well, not stupid, they are probably probing vulnerabilities.
Yup, thousands and thousands every day and hour.
Should I worry?
Nope.
Should I try to implement something in the firewall that blocks IPs that attempt on vulnerabilities, somehow? If there is such a tool.
Much depends on what you are running on your Apache server. There are many vulnerable apps out there. Maybe study your logs and pick the most frequent patterns, then configure apache to refuse them.
Excerpt from /var/log/apache2/access_log:
167.248.133.54 - - [15/Feb/2021:17:20:14 +0100] "GET / HTTP/1.1" 403 972 "-" "Mozilla/5.0 (compatible; CensysInspect/1.1; +https://about.censys.io/)"
Just a probe of SSL support. Harmless. -- Per Jessen, Zürich (6.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland.

On 20/02/2021 21.04, Per Jessen wrote:
Carlos E. R. wrote:
Then the other day, I wanted to share a file using my server, and noticed that Apache was being hit, with "stupid" requests. Well, not stupid, they are probably probing vulnerabilities.
Yup, thousands and thousands every day and hour.
Quite, but on a very high port? This is new.
Should I worry?
Nope.
Should I try to implement something in the firewall that blocks IPs that attempt on vulnerabilities, somehow? If there is such a tool.
Much depends on what you are running on your Apache server. There are many vulnerable apps out there. Maybe study your logs and pick the most frequent patterns, then configure apache to refuse them.
No apps. There is a /srv/cgi-bin that came with the installation or the example, but the "external" vhost doesn't have it. Just a static index.html file with a "hello you". Isengard:~ # rpm -qa | grep -i apache apache2-mod_security2-2.9.2-lp152.3.7.x86_64 apache2-2.4.43-lp152.2.12.1.x86_64 apache2-doc-2.4.43-lp152.2.12.1.noarch apache2-utils-2.4.43-lp152.2.12.1.x86_64 apache-commons-logging-1.2-lp152.5.1.noarch apache2-prefork-2.4.43-lp152.2.12.1.x86_64 Isengard:~ # -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

Carlos E.R. wrote:
Should I try to implement something in the firewall that blocks IPs that attempt on vulnerabilities, somehow? If there is such a tool.
Much depends on what you are running on your Apache server. There are many vulnerable apps out there. Maybe study your logs and pick the most frequent patterns, then configure apache to refuse them.
No apps.
There is a /srv/cgi-bin that came with the installation or the example, but the "external" vhost doesn't have it. Just a static index.html file with a "hello you".
Then you have nothing to worry about, Apache by itself is very safe. Typically the risks increase as you put php apps on it. wordpress, moodle, roundcube etc etc. Mind you, if you want to be absolutely safe, just stop apache :-) -- Per Jessen, Zürich (8.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland.

On 21/02/2021 10.46, Per Jessen wrote:
Carlos E.R. wrote:
Should I try to implement something in the firewall that blocks IPs that attempt on vulnerabilities, somehow? If there is such a tool.
Much depends on what you are running on your Apache server. There are many vulnerable apps out there. Maybe study your logs and pick the most frequent patterns, then configure apache to refuse them.
No apps.
There is a /srv/cgi-bin that came with the installation or the example, but the "external" vhost doesn't have it. Just a static index.html file with a "hello you".
Then you have nothing to worry about, Apache by itself is very safe. Typically the risks increase as you put php apps on it. wordpress, moodle, roundcube etc etc.
Mind you, if you want to be absolutely safe, just stop apache :-)
:-D But then I don't have fun ;-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

Carlos E. R. wrote:
On 21/02/2021 10.46, Per Jessen wrote:
Carlos E.R. wrote:
Mind you, if you want to be absolutely safe, just stop apache :-)
:-D
But then I don't have fun ;-)
Absolutely, playing it safe, where is the fun in that ... -- Per Jessen, Zürich (10.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland.

On 21/02/2021 12.36, Per Jessen wrote:
Carlos E. R. wrote:
On 21/02/2021 10.46, Per Jessen wrote:
Carlos E.R. wrote:
Mind you, if you want to be absolutely safe, just stop apache :-)
:-D
But then I don't have fun ;-)
Absolutely, playing it safe, where is the fun in that ...
Nono, I want to play safe and have fun :-P (no hits yet since I randomized the port) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On Sat, 20 Feb 2021 20:35:23 +0100 (CET) "Carlos E. R." <robin.listas@telefonica.net> wrote:
I was playing some time ago with a little server, running Apache, in a dynamic home address.
And using a very high port, to avoid scans.
I forgot about it.
Then the other day, I wanted to share a file using my server, and noticed that Apache was being hit, with "stupid" requests. Well, not stupid, they are probably probing vulnerabilities.
What it surprises me is that they hit such a high port, they have to be probing every port.
(The router is set to redirect incoming tcp on that high port to the inside server at the same high port)
My IP address changed on the 7 and 8 of February, the hits increase on the 10th. It is possible that the previous user of that IP had a known domain.
Unlikely, unless you chose a well-known high number. Switch to a random one.
Should I worry?
Depends what you've got being served by Apache and how well exploit-proofed it is.
Should I try to implement something in the firewall that blocks IPs that attempt on vulnerabilities, somehow? If there is such a tool.
Why not just tell Apache to refuse all requests except those from your own IP addresses? Or just close the port in the router if you're not using it.
Can I know if they are attempting to access the URL by domain name or by IP address? Ie, what do they write exactly on the "browser". Or script.
No, requests are by IP. Their browser or whatever does the lookup. You can have Apache do a reverse lookup to see their domain if you wish.
Excerpt from /var/log/apache2/access_log:
[snip]
- -- Cheers
Carlos E. R. (from 15.2 x86_64 at Telcontar)

On 20/02/2021 21.14, Dave Howorth wrote:
On Sat, 20 Feb 2021 20:35:23 +0100 (CET) "Carlos E. R." <> wrote:
I was playing some time ago with a little server, running Apache, in a dynamic home address.
And using a very high port, to avoid scans.
I forgot about it.
Then the other day, I wanted to share a file using my server, and noticed that Apache was being hit, with "stupid" requests. Well, not stupid, they are probably probing vulnerabilities.
What it surprises me is that they hit such a high port, they have to be probing every port.
(The router is set to redirect incoming tcp on that high port to the inside server at the same high port)
My IP address changed on the 7 and 8 of February, the hits increase on the 10th. It is possible that the previous user of that IP had a known domain.
Unlikely, unless you chose a well-known high number. Switch to a random one.
Good idea, I will do that.
Should I worry?
Depends what you've got being served by Apache and how well exploit-proofed it is.
I serve nothing, it is just a static index.html with a "hello you" line.
Should I try to implement something in the firewall that blocks IPs that attempt on vulnerabilities, somehow? If there is such a tool.
Why not just tell Apache to refuse all requests except those from your own IP addresses?
I don't have "my own IP address" :-)
Or just close the port in the router if you're not using it.
Possible, certainly. I was simply not expecting anyone to find it.
Can I know if they are attempting to access the URL by domain name or by IP address? Ie, what do they write exactly on the "browser". Or script.
No, requests are by IP. Their browser or whatever does the lookup. You can have Apache do a reverse lookup to see their domain if you wish.
Ah. No, not really interested in finding their domain. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On 20/02/2021 21.36, Carlos E.R. wrote:
On 20/02/2021 21.14, Dave Howorth wrote:
On Sat, 20 Feb 2021 20:35:23 +0100 (CET) "Carlos E. R." <> wrote:
What it surprises me is that they hit such a high port, they have to be probing every port.
(The router is set to redirect incoming tcp on that high port to the inside server at the same high port)
My IP address changed on the 7 and 8 of February, the hits increase on the 10th. It is possible that the previous user of that IP had a known domain.
Unlikely, unless you chose a well-known high number. Switch to a random one.
Good idea, I will do that.
Well, I did that and now it doesn't work. I get timeouts on both Chrome and Firefox trying from the phone. I only changed the port number in router /etc/apache2/listen.conf /etc/apache2/vhosts.d/vhost.conf Ah! I forgot the firewall. :-D Nothing like writing an email to see the problem. Now it works. :-D Trying to write the URL in FF for Android when it fails is horribly difficult. When it fails, it tries google, and you no longer can edit it. Stupid. I had to go again to Chrome, share the (non working) URL to WhatsApp, then in Whatsapp tap on the URL and say open with FF. Interestingly, when I use Chrome in my phone to access the page, the access_log does include the full URL I typed: 176.*.*.200 - - [20/Feb/2021:22:51:56 +0100] "GET /favicon.ico HTTP/1.1" 404 1235 "http://host.domain:port/" "Mozilla/5.0 (Linux; Android 9; moto g(6) plus) AppleWeb Kit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.181 Mobile Safari/537.36" -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

Carlos E. R. wrote:
Nothing like writing an email to see the problem. Now it works. :-D
+1 <anecdote> Years ago a trainer told me - when it is 5-6 in the morning, and you have no more hair left and the cleaning woman walks into the room, you drag her over to the blackboard and you explain the problem to her. Always works. </anecdot>
Interestingly, when I use Chrome in my phone to access the page, the access_log does include the full URL I typed:
176.*.*.200 - - [20/Feb/2021:22:51:56 +0100] "GET /favicon.ico HTTP/1.1" 404 1235 "http://host.domain:port/" "Mozilla/5.0 (Linux;
I presume "http://host.domain:port/" is the full URL ? that is the referer. -- Per Jessen, Zürich (8.9°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland.

On 21/02/2021 10.58, Per Jessen wrote:
Carlos E. R. wrote:
Nothing like writing an email to see the problem. Now it works. :-D
+1
<anecdote> Years ago a trainer told me - when it is 5-6 in the morning, and you have no more hair left and the cleaning woman walks into the room, you drag her over to the blackboard and you explain the problem to her. Always works. </anecdot>
LOL :-D I have a thought. If I write it in a paper which is destined to the paper basket, the voodoo doesn't work. It has to be an email ;-p -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On Sun, 21 Feb 2021 10:58:11 +0100 Per Jessen <per@computer.org> wrote:
Carlos E. R. wrote:
Nothing like writing an email to see the problem. Now it works. :-D
+1
<anecdote> Years ago a trainer told me - when it is 5-6 in the morning, and you have no more hair left and the cleaning woman walks into the room, you drag her over to the blackboard and you explain the problem to her. Always works. </anecdot>
We used to have a teddy bear at work who was skilled in debugging. When you had a problem in your code that you couldn't solve, you got the teddy and sat it where it could see your screen. Then you explained how your code worked to the teddy, and he always pointed out where the problem was. We only had the one teddy though, so sometimes you had to wait :)
Interestingly, when I use Chrome in my phone to access the page, the access_log does include the full URL I typed:
176.*.*.200 - - [20/Feb/2021:22:51:56 +0100] "GET /favicon.ico HTTP/1.1" 404 1235 "http://host.domain:port/" "Mozilla/5.0 (Linux;
I presume "http://host.domain:port/" is the full URL ? that is the referer.

Hi, all -- ...and then Dave Howorth said... % % On Sun, 21 Feb 2021 10:58:11 +0100 % Per Jessen <per@computer.org> wrote: % % > Carlos E. R. wrote: % > % > > Nothing like writing an email to see the problem. Now it % > > works. :-D ... % > drag her over to the blackboard and you explain the problem to her. % > Always works. % > </anecdot> % ... % how your code worked to the teddy, and he always pointed out where the % problem was. [snip] I was the cleaning woman or teddy bear to a classmate back in college. We tended to work in the computer lab at the same time, and he would suddenly walk up to me with his long fan-fold printout and start walking me through his code before suddenly exclaiming "wait, it shouldn't do THAT" or similar and walking away. It took me a few weeks to realize that I didn't actually have to pay him any attention :-) On the other hand, Laura and I could never debug each other's code because we always came at a problem from opposite directions. Two different designs, both eventually valid products, but reading hers always tied me up in "but it should be THIS WAY" knots. I guess that's why we've made such a good team for nearly 30 years now :-) Fun memories ... HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt

On 2021-02-21 07:54:37 David T-G wrote:
|Hi, all -- | |...and then Dave Howorth said... |% |% On Sun, 21 Feb 2021 10:58:11 +0100 |% Per Jessen <per@computer.org> wrote: |% |% > Carlos E. R. wrote: |% > |% > > Nothing like writing an email to see the problem. Now it |% > > works. :-D |... |% > drag her over to the blackboard and you explain the problem to her. |% > Always works. |% > </anecdot> |% |... |% how your code worked to the teddy, and he always pointed out where the |% problem was. |[snip] | |I was the cleaning woman or teddy bear to a classmate back in college. |We tended to work in the computer lab at the same time, and he would |suddenly walk up to me with his long fan-fold printout and start walking |me through his code before suddenly exclaiming "wait, it shouldn't do |THAT" or similar and walking away. It took me a few weeks to realize |that I didn't actually have to pay him any attention :-) | |On the other hand, Laura and I could never debug each other's code |because we always came at a problem from opposite directions. Two |different designs, both eventually valid products, but reading hers |always tied me up in "but it should be THIS WAY" knots. I guess that's |why we've made such a good team for nearly 30 years now :-)
Debugging one another's code (I look at your listing, you look at mine) never works, because you're not explaining your own code to another. When you explain your own code you have to elucidate the tacit assumptions you have made about what it does, and when you do that you show /yourself/ where the problem is. That's why you don't have to listen much to your colleague's explanation. Leslie
| |Fun memories ... | | |HAND | |:-D -- openSUSE Leap 15.2 x86_64

On Sun, 21 Feb 2021 18:45:50 -0600 J Leslie Turriff wrote: [...]
Debugging one another's code (I look at your listing, you look at mine) never works, because you're not explaining your own code to another. When you explain your own code you have to elucidate the tacit assumptions you have made about what it does, and when you do that you show /yourself/ where the problem is. That's why you don't have to listen much to your colleague's explanation.
Leslie
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian Kernighan -- Bob Williams System: Linux 5.3.18-lp152.50-default Desktop: KDE Frameworks: 5.71.0, Qt: 5.12.7 and Plasma: 5.18.5 https://useplaintext.email/

On 2/21/21 6:17 AM, Dave Howorth wrote:
We used to have a teddy bear at work who was skilled in debugging.
When you had a problem in your code that you couldn't solve, you got the teddy and sat it where it could see your screen. Then you explained how your code worked to the teddy, and he always pointed out where the problem was.
We only had the one teddy though, so sometimes you had to wait :)
I know that one as having a chat with the duck! See Debugging Small Programs https://ericlippert.com/2014/03/05/how-to-debug-small-programs/ -- David C. Rankin, J.D.,P.E.

On 2021-02-20 21:36, Carlos E.R. wrote:
I was simply not expecting anyone to find it.
I can assure you. It doesn't take more than a couple of hours to find it for the abusers out there. OT: If you really want to see how scans are done you should setup an argus server and dive into the logs. I did setup my first argus server 16-17 years ago at a university. It's not under my supervision anymore but it's still used and gives a lot of valuable research data, and for feeding a filtering system for abusive connections and IP's. I do have one at home and turn it on from time to time if needed or just to watch live internet-abuse-TV. -- /bengan

On 20/02/2021 23.53, Bengt Gördén wrote:
On 2021-02-20 21:36, Carlos E.R. wrote:
I was simply not expecting anyone to find it.
I can assure you. It doesn't take more than a couple of hours to find it for the abusers out there.
I understand they are fast if you put services in the normal ports, but not that easy if you use a high port. My error was that "50000" is apparently a commonly used port. Now I use a random number. Scanning for it takes 60000 times more - I know because I tried with nmap and it takes minutes. So far, no hits! We will see in a few days. I use the same strategy for ssh since some years, and I saw nothing in the logs.
OT: If you really want to see how scans are done you should setup an argus server and dive into the logs. I did setup my first argus server 16-17 years ago at a university. It's not under my supervision anymore but it's still used and gives a lot of valuable research data, and for feeding a filtering system for abusive connections and IP's. I do have one at home and turn it on from time to time if needed or just to watch live internet-abuse-TV.
Interesting. But no, the powers of my internet facing router are limited, so no, I don't think I can try, and anyway I'm not that interested to invest time in it :-D -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On Sat, 20 Feb 2021 23:53:39 +0100 Bengt Gördén <bengan@bag.org> wrote:
On 2021-02-20 21:36, Carlos E.R. wrote:
I was simply not expecting anyone to find it.
I can assure you. It doesn't take more than a couple of hours to find it for the abusers out there.
OT: If you really want to see how scans are done you should setup an argus server and dive into the logs. I did setup my first argus server 16-17 years ago at a university. It's not under my supervision anymore but it's still used and gives a lot of valuable research data, and for feeding a filtering system for abusive connections and IP's. I do have one at home and turn it on from time to time if needed or just to watch live internet-abuse-TV.
I was interested by this comment. If I go to https://software.opensuse.org/package/argus it says that the version available for openSUSE is 3.0.8.2 If I go to http://argus.tcp4me.com/history.html it says the current version is 3.7 from 2013, that version 3.1 was produced in 2002 and that the version prior to that is Version 3.0.1. So what is 3.0.8.2 and why is openSUSE providing something that even if it exists appears to be from 2001-2002?

Dave Howorth wrote:
Can I know if they are attempting to access the URL by domain name or by IP address? Ie, what do they write exactly on the "browser". Or script.
No, requests are by IP. Their browser or whatever does the lookup. You can have Apache do a reverse lookup to see their domain if you wish.
Maybe for completeness - the servername is indicated in the request, otherwise Apache will not know which virtual host to serve (if it is serving more than one). -- Per Jessen, Zürich (8.9°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland.

On 21/02/2021 10.48, Per Jessen wrote:
Dave Howorth wrote:
Can I know if they are attempting to access the URL by domain name or by IP address? Ie, what do they write exactly on the "browser". Or script.
No, requests are by IP. Their browser or whatever does the lookup. You can have Apache do a reverse lookup to see their domain if you wish.
Maybe for completeness - the servername is indicated in the request, otherwise Apache will not know which virtual host to serve (if it is serving more than one).
It is the case, I have two virtual hosts, one for the LAN and another for internet. I differentiate them by the port. <VirtualHost *:port> vs <VirtualHost *:80> -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
participants (9)
-
Bengt Gördén
-
Bob Williams
-
Carlos E. R.
-
Carlos E.R.
-
Dave Howorth
-
David C. Rankin
-
David T-G
-
J Leslie Turriff
-
Per Jessen