Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provide an option for one-line-logs in a file #178

Closed
doctore74 opened this issue Dec 20, 2021 · 14 comments
Closed

provide an option for one-line-logs in a file #178

doctore74 opened this issue Dec 20, 2021 · 14 comments
Assignees
Labels
enhancement New feature or request patch released

Comments

@doctore74
Copy link

doctore74 commented Dec 20, 2021

It would be good to have an option to log into a logfile in i.e. syslog style.

Because...
Here's something else I've been thinking about.
If a host was potentially attackable, it would be useful to know later which one it was. If an attacker was fast and infected the host, maybe he could place a trojan or something to activate it later.

A single line logfile is easy to parse and/or logrotated or shipped to checkmk logwatch or Elastic Stack (with or without machine learning), Graylog, ...

Hey... and DO NOT USE LOG4J :-D

@xeraph xeraph self-assigned this Dec 21, 2021
@xeraph xeraph added the enhancement New feature or request label Dec 21, 2021
@xeraph
Copy link
Contributor

xeraph commented Dec 21, 2021

Great idea. Merged into #183. :D

@xeraph
Copy link
Contributor

xeraph commented Dec 21, 2021

@doctore74 Would you test v2.5.0?

@doctore74
Copy link
Author

doctore74 commented Dec 21, 2021

@xeraph

syslog via udp is working -> that's great

Would it also be possible to add a flag to write this log to a local file?
I.e. Elastic can use its beat-agents. These are able to buffer the data. UDP just drops the data if it cannot be sent.

@xeraph
Copy link
Contributor

xeraph commented Dec 23, 2021

@doctore74 I'm considering syslog over tcp or HTTPS post logging. I will inform you if this feature is released.

@doctore74
Copy link
Author

@xeraph
I think a locally stored log file is really necessary to find out what the scan is doing and where it gets stuck when run unattended (e.g. monitoring tool).

btw. Keep going! Awsome work!

@thl-cmk
Copy link

thl-cmk commented Jan 2, 2022

@xeraph

Added --log-path option for appendable json logging, See #178

Will this also work with CSV format?

THX

xeraph added a commit that referenced this issue Jan 2, 2022
@xeraph
Copy link
Contributor

xeraph commented Jan 2, 2022

@thl-cmk @doctore74 Would you test v2.7.0 release? You can use --csv-log-path or --json-log-path option for file logging.

@thl-cmk
Copy link

thl-cmk commented Jan 2, 2022

@xeraph
Added --csv-log-path option

looks good /json also ok), except for the missing the headline in the csv file, should be put there on creation of the file.

@doctore74
Copy link
Author

@xeraph

Looks good so far.

"unifi","/usr/lib/unifi/lib/log4j-core-2.13.3.jar","","Log4j 2","2.13.3","CVE-2021-44228","VULNERABLE","","2022-01-02 14:02:34" "unifi","/usr/lib/unifi/lib/log4j-core-2.13.3.jar","","Log4j 2","2.13.3","CVE-2021-44228","VULNERABLE","","2022-01-02 15:04:05" "unifi","/usr/lib/unifi/lib/log4j-core-2.13.3.jar","","Log4j 2","2.13.3","CVE-2021-44228","VULNERABLE","","2022-01-02 15:04:09" "unifi","/usr/lib/unifi/lib/log4j-core-2.13.3.jar","","Log4j 2","2.13.3","CVE-2021-44228","VULNERABLE","","2022-01-02 15:04:26" "unifi","/usr/lib/unifi/lib/log4j-core-2.13.3.jar","","Log4j 2","2.13.3","CVE-2021-44228","VULNERABLE","","2022-01-02 15:04:30"

Would it be possible to add an additional format like this?

2019-12-25T19:48:12.669+0000 I CONTROL [signalProcessingThread] got signal 15 (Terminated), will terminate after current cmd ends 2019-12-25T19:48:12.669+0000 I NETWORK [signalProcessingThread] shutdown: going to close listening sockets... 2019-12-25T19:48:12.669+0000 I NETWORK [signalProcessingThread] removing socket file: /run/mongodb/mongodb-27017.sock 2019-12-25T19:48:12.669+0000 I FTDC [signalProcessingThread] Shutting down full-time diagnostic data capture 2019-12-25T19:48:12.672+0000 I STORAGE [signalProcessingThread] WiredTigerKVEngine shutting down 2019-12-25T19:48:12.763+0000 I STORAGE [signalProcessingThread] shutdown: removing fs lock... 2019-12-25T19:48:12.763+0000 I CONTROL [signalProcessingThread] now exiting 2019-12-25T19:48:12.763+0000 I CONTROL [signalProcessingThread] shutting down with code:0

xeraph added a commit that referenced this issue Jan 2, 2022
@xeraph
Copy link
Contributor

xeraph commented Jan 2, 2022

@thl-cmk Added csv file header in v2.7.1.
@doctore74 I can't get the point of your suggestion.

@thl-cmk
Copy link

thl-cmk commented Jan 2, 2022

@xeraph

Added csv file header in v2.7.1.

will check ;-), done. Looks good to me. THX

@thl-cmk
Copy link

thl-cmk commented Jan 2, 2022

can't get the point of your suggestion.

I guess what @doctore74 means is to have the format of the log file more like a "standard" linux logfile. So first he wants to remove the " except the are neccesary, and a different order of the fields. So more like this i guess:

Detected_at,Hostname,Product,Version,CVE,Status,Fixed,Path,Entry
2019-12-25T19:48:12.669+0000,unifi,Log4j_2,2.13.3,CVE-2021-44228,VULNERABLE,,/usr/lib/unifi/lib/log4j-core-2.13.3.jar,,

@xeraph xeraph closed this as completed Jan 7, 2022
@doctore74
Copy link
Author

@xeraph Have you seen @thl-cmk explanation?

@xeraph
Copy link
Contributor

xeraph commented Jan 11, 2022

@doctore74 Yes. I don't considering change of format for now..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request patch released
Projects
None yet
Development

No branches or pull requests

3 participants