Your message dated Tue, 29 Aug 2017 22:23:19 +0300
with message-id <20170829192319.cejs43vcgel7vswa@note>
and subject line Re: Bug#868778: monit: Invalid CSRF check when using monit web
page
has caused the Debian Bug report #868778,
regarding monit: Invalid CSRF check when using monit web page
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
868778: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868778
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: monit
Version: 1:5.20.0-6
Severity: normal
Dear Maintainer,
after a fresh install of monit on Debian Stretch, when trying to use the
functionality of enabling/disabling survey of processes like sshd, I get the
error "Invalid CSRF check" in the browser leading to fill the logs of monit
with:
[CEST Jul 18 10:03:37] info : 'scw-af2462' Monit 5.20.0 started
[CEST Jul 18 10:04:01] error : HttpRequest: access denied -- client
[127.0.0.1]: CSRF token mismatch
[CEST Jul 18 10:04:01] error : HttpRequest: error -- client [127.0.0.1]:
HTTP/1.0 403 Invalid CSRF Token
[CEST Jul 18 10:06:51] error : HttpRequest: access denied -- client
[127.0.0.1]: CSRF token mismatch
[CEST Jul 18 10:06:51] error : HttpRequest: error -- client [127.0.0.1]:
HTTP/1.0 403 Invalid CSRF Token
[CEST Jul 18 14:07:58] error : HttpRequest: access denied -- client
[127.0.0.1]: missing or invalid Authorization header
[CEST Jul 18 14:15:27] info : Monit daemon with pid [20998] stopped
and making web controls of monit being uneffective.
I suspect this error sharing the same origin as described in monit bug tracking:
https://bitbucket.org/tildeslash/monit/issues/495/invalid-csrf-check
where you will find the modification being added to the code of monit 5.21.
In my setup, I am using monit behind a reverse proxy managed by Apache 2.4.25.
I did not try direct access of monit (I am behind a proxy filtering ports).
As a quick and dirty workaround, I installed monit package from Sid, reverted
to the monit package from Stretch and then the problem was no more longer
present, web controls of monit were made useable again.
Here are the usual lines automatically added by reportbug.
-- Package-specific info:
Contents of /etc/monit/ directory:
/etc/monit:
total 36
drwxr-xr-x 2 root root 4096 Jul 18 14:21 conf-available
drwxr-xr-x 2 root root 4096 Jan 11 2017 conf-enabled
drwxr-xr-x 2 root root 4096 Jul 18 10:07 conf.d
-rw------- 1 root root 12384 Jan 11 2017 monitrc
drwxr-xr-x 2 root root 4096 Jul 16 12:25 monitrc.d
drwxr-xr-x 2 root root 4096 Jul 18 14:21 templates
/etc/monit/conf-available:
total 60
-rw-r--r-- 1 root root 481 Jan 11 2017 acpid
-rw-r--r-- 1 root root 640 Jan 11 2017 apache2
-rw-r--r-- 1 root root 455 Jan 11 2017 at
-rw-r--r-- 1 root root 691 Jan 11 2017 cron
-rw-r--r-- 1 root root 602 Jan 11 2017 mdadm
-rw-r--r-- 1 root root 669 Jan 11 2017 memcached
-rw-r--r-- 1 root root 703 Jan 11 2017 mysql
-rw-r--r-- 1 root root 521 Jan 11 2017 nginx
-rw-r--r-- 1 root root 471 Jan 11 2017 openntpd
-rw-r--r-- 1 root root 950 Jan 11 2017 openssh-server
-rw-r--r-- 1 root root 683 Jan 11 2017 pdns-recursor
-rw-r--r-- 1 root root 1421 Jan 11 2017 postfix
-rw-r--r-- 1 root root 869 Jan 11 2017 rsyslog
-rw-r--r-- 1 root root 501 Jan 11 2017 smartmontools
-rw-r--r-- 1 root root 306 Jan 11 2017 snmpd
/etc/monit/conf-enabled:
total 0
/etc/monit/conf.d:
total 36
-rw-r--r-- 1 root root 649 Jul 18 09:44 apache2
-rw-r--r-- 1 root root 680 Jul 18 09:44 exim4
-rw-r--r-- 1 root root 175 Jul 18 09:50 lufi
-rw-r--r-- 1 root root 205 Jul 18 09:44 munin-node
-rw-r--r-- 1 root root 280 Jul 18 09:44 nsd
-rw-r--r-- 1 root root 448 Jul 18 09:48 ntpd
-rw-r--r-- 1 root root 950 Jul 18 10:07 openssh-server
-rw-r--r-- 1 root root 235 Jul 18 09:44 perso
-rw-r--r-- 1 root root 341 Jul 18 09:47 pgsql
/etc/monit/monitrc.d:
total 4
-rw-r--r-- 1 root root 403 Apr 17 16:27 fail2ban
/etc/monit/templates:
total 12
-rw-r--r-- 1 root root 164 Jan 11 2017 rootbin
-rw-r--r-- 1 root root 160 Jan 11 2017 rootrc
-rw-r--r-- 1 root root 164 Jan 11 2017 rootstrict
-- System Information:
Debian Release: 9.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: arm64 (aarch64)
Kernel: Linux 4.9.23-std-1 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages monit depends on:
ii libc6 2.24-11+deb9u1
ii libpam0g 1.1.8-3.6
ii libssl1.1 1.1.0f-3
ii lsb-base 9.20161125
ii zlib1g 1:1.2.8.dfsg-5
monit recommends no packages.
Versions of packages monit suggests:
ii exim4 4.89-2+deb9u1
ii exim4-daemon-light [mail-transport-agent] 4.89-2+deb9u1
pn sysvinit-core <none>
-- no debconf information
Cheers,
Cyril
--- End Message ---
--- Begin Message ---
On Tue, Aug 29, 2017 at 09:17:40PM +0200, [email protected] wrote:
> Yes, dedicated FQDN for monit that will filtering out other cookies might
> solve the problem (provided no other cookie will be injected, for example by
> proxy).
Ok. Then I close this issue. Problem apparently is not severe enough
to make backport to the Debian stable and there is a known workaround.
And it's fixed in sid/testing.
--- End Message ---
