Support socklog log entries
Issue #10
resolved
It doesn't continue parsing after it hits other information for me. I assume this is a bug, as it would be really confusing behaviour if not.
This is on Void Linux, gcc 4.9.2. I've tried both 1.5 and 1.6, the behaviour is about the same.
An example run is included below. Quoted lines are my input.
># sshguard -v sshguard 1.6.0 ># SSHGUARD_DEBUG=1 sshguard whitelist: add '127.0.0.1' as plain IPv4. whitelist: add plain IPv4 127.0.0.1. Set environment: SSHG_ACTION=init;SSHG_PID=31782 Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED sshguard all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain sshguard (1 references) target prot opt source destination Run command "iptables -w -L -n": exited 0. Started with danger threshold=40 ; minimum block=420 seconds >2015-05-27T04:31:27.46667 auth.info: May 27 04:31:27 sshd[30993]: Invalid user roedh from 10.0.0.2 Starting parse Entering state 0 Reading a token: --accepting rule at line 211 ("2015-05-27T04") Next token is token WORD () Cleanup: discarding lookahead token WORD () Stack now 0 >May 27 04:31:27 sshd[30993]: Invalid user roedh from 10.0.0.2 Starting parse Entering state 0 Reading a token: --accepting rule at line 201 ("May 27 04:31:27") Next token is token TIMESTAMP_SYSLOG () Cleanup: discarding lookahead token TIMESTAMP_SYSLOG () Stack now 0 >sshd[30993]: Invalid user roedh from 10.0.0.2 Starting parse Entering state 0 Reading a token: --accepting rule at line 211 ("sshd") Next token is token WORD () Cleanup: discarding lookahead token WORD () Stack now 0 >Invalid user roedh from 10.0.0.2 Starting parse Entering state 0 Reading a token: --accepting rule at line 110 ("Invalid user roedh from ") Next token is token SSH_INVALUSERPREF () Shifting token SSH_INVALUSERPREF () Entering state 6 Reading a token: --accepting rule at line 189 ("10.0.0.2") Next token is token IPv4 () Shifting token IPv4 () Entering state 53 Reducing stack by rule 24 (line 193): $1 = token IPv4 () -> $$ = nterm addr () Stack now 0 6 Entering state 56 Reducing stack by rule 32 (line 262): $1 = token SSH_INVALUSERPREF () $2 = nterm addr () -> $$ = nterm ssh_illegaluser () Stack now 0 Entering state 33 Reducing stack by rule 27 (line 252): $1 = nterm ssh_illegaluser () -> $$ = nterm sshmsg () Stack now 0 Entering state 32 Reducing stack by rule 11 (line 158): $1 = nterm sshmsg () -> $$ = nterm msg_single () Stack now 0 Entering state 30 Reducing stack by rule 9 (line 152): $1 = nterm msg_single () -> $$ = nterm logmsg () Stack now 0 Entering state 29 Reducing stack by rule 4 (line 121): $1 = nterm logmsg () -> $$ = nterm text () Stack now 0 Entering state 25 Reading a token: --(end of buffer or a NUL) --accepting rule at line 212 (" ") --(end of buffer or a NUL) --EOF (start condition 0) Now at end of input. Shifting token $end () Entering state 75 Stack now 0 25 75 Cleanup: popping token $end () Cleanup: popping nterm text () Matched address 10.0.0.2:4 attacking service 100, dangerousness 10. Purging stale attackers. >^D Got exit signal, flushing blocked addresses and exiting... Set environment: SSHG_ACTION=flush;SSHG_PID=31782 ip6tables: No chain/target/match by that name. Run command "/sbin/iptables -w -F sshguard ; /sbin/ip6tables -w -F sshguard": exited 1. Set environment: SSHG_ACTION=fin;SSHG_PID=31782
Comments (4)
-
-
Ah, I see. Then this is a feature request, not a bug report. I was under the impression that with “2015-05-27T04:31:27.46667 auth.info: ” removed the log format was pretty standard, but I see now that hostname is missing.
The syslogd in use is socklog.
-
- changed title to Support socklog log entries
-
assigned issue to
- marked as enhancement
- marked as minor
-
- changed status to resolved
Fix committed in d5e0a2b, submitted by pull request #5. Thanks!
- Log in to comment
SSHGuard is not recognizing the timestamp. What logging daemon are you using?