* pr/1232/head:
removed system.log
Removed old svn revision comment
removed false matches
Removed includes comment for screensharing jail
Now using a literal logpath for screensharing jail
Fixed blatant typo in regex
clarified comments on sample log format
Fixed name (again?)
Made screensharing jail off by default
Changed regex prequel
added entry for new screensharingd filter
name change & new sample data
Added json metadata
Sample log for test case
Replaced .* with literal
Update jail.conf
Added new path variable for system.log
Added in settings for screensharingd filter
Created file
Conflicts:
ChangeLog - moved to New Features
config/jail.conf - kept at the end
However, still failing test, even though ```PYTHONPATH=. fail2ban-regex -v fail2ban/tests/files/logs/screensharingd /etc/fail2ban/filter.d/screensharingd.conf``` gives desired result
Previously, an attacker could fake a domain like
crawl-1-1-1-1.googlebot.com.fake.net and get resolved. This change
avoids to resolve fake Google domains.
The regex for matching against "Auth fail" disconnect log message does
not match against current versions of ssh. OpenSSH 5.9 introduced
privilege separation of the pre-auth process, which included
[logging through monitor.c](http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/monitor.c.diff?r1=1.113&r2=1.114)
which adds " [preauth]" to the end of each message and causes the log
level to be prepended to each message.
It also fails to match against clients which send a disconnect message
with a description that is either empty or includes a space, since this
is the content in the log message after the disconnect code, per
[packet.c:1785](http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/packet.c?annotate=1.215),
which was matched by \S+. Although I have not observed this yet, I
couldn't find anything which would preclude it in [RFC
4253](https://tools.ietf.org/html/rfc4253#section-11.1) and since the
message is attacker-controlled it provides a way to avoid getting
banned.
This commit fixes both issues.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
Event containing Challenge may come without ReceivedChallenge, but with
Response and ExpectedResponse.
Also Challenge now accepts '/' character, since it is used at least by PJSIP.
Unlike chan_sip and manager, PJSIP populates SessionID using
Call-Id header of a related SIP message.
As Call-Id of a SIP message can contain almost anything,
the regular expression for SessionID has been loosened.
Johannes Weberhofer