-
Notifications
You must be signed in to change notification settings - Fork 246
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
Add a statcounter that prints statistics about the connection #117
Conversation
…disconnection - Rename mitm.py to RDPMITM.py to follow convention - Add an info log statement for virtual channel name <---> channel ID association
I like the idea, but I don't think it gives any useful information for a user monitoring the connection. Since it can be really good for data collection, should this be "silently" logged at a DEBUG level? |
We've had this discussion before, but debug vs info should not be honeypot vs pentest. Right now we dont have a way to differenciate both afaik. Right now, only INFO logs are written to the json file to be injested by elasticsearch. |
My point was for both honeypot and pentest, but I didn't know that only INFO log were inside the JSON. I assumed that DEBUG were logged as well. |
The most relevant information it gives for someone monitoring the logs would be the connection time and the input / output ratio, which helps identify connections worth looking at imo |
And of course clipboard and/or rdpdr activity |
After a few tests, I got this error message. Maybe validate the
|
Right, didnt think about that but with a simple tcp scan that would trigger the error. Will update. |
…bject and not a string
The fix was simpler than I thought. Apparently something changed when @xshill refactored the logging classes and now we can put arbitrary key/values objects even if they don't appear in the "message" part of the log, which is nice. |
So, after testing, it "works" because the log goes in the
This is counter-intuitive for the user, we should either print the connection report to the user, or log it silently. This mixes both. |
Lol I overlooked that small detail, I'll take a look
…On Tue., Jun. 25, 2019, 08:51 Maxime Carbonneau, ***@***.***> wrote:
So, after testing, it "works" because the log goes in the mitm.json, but
here is what the console output looks like:
[2019-06-25 12:45:22,225] - INFO - Philip232610 - pyrdp.mitm.connections.tcp - Connection report
This is counter-intuitive for the user, we should either print the
connection report to the user, or log it silently. This mixes both.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#117?email_source=notifications&email_token=ADPMNL6CNDELTY65ZCOZ3YLP4IIE5A5CNFSM4HXE5FXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYQECDA#issuecomment-505430284>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADPMNL772MUOKWZV43L3ZRTP4IIE5ANCNFSM4HXE5FXA>
.
|
I tested and merged master into the branch since there was a lot of conflicts. |
Alright it should be good now @Pourliver |
Looks good to me! Merging. |
Logs various data about the connection when the client disconnects. Looks like this:
each field is separated so it can be used as filters and to build visualizations in ES/Kibana.
What I implemented for now: