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

Prevent security scanner from killing wrapper with ECONNRESET #277

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

ChrisMiami
Copy link

@ChrisMiami ChrisMiami commented Dec 18, 2020

wrapper.js is continually killed by a security penetration test that causes ECONNRESET errors on the socket. Handling the socket error prevents a server error which forestalls cycling the app. Since we don't care about the connections anyway, I log the error but ignore it.

In server.on('error'), I added a server.close() because server errors do not automatically close the server, so it was probably leaking servers.

@coreybutler
Copy link
Owner

@ChrisMiami - I don't personally come across this scenario, but the fix seems fine/logical. My one concern is cluttering the logs with ignored log messages. In particular, if someone is retroactively scanning logs, will they be scanning through alot of noise? If it's more of a signal of a resolvable problem in the underlying app, then I'm fine with it as-is. If not, it seems prudent to have a configuration flag to toggle the messaging.

@ChrisMiami
Copy link
Author

@coreybutler - this makes eminent sense, but although the event has been trapped to make it a non-issue, I'd guess it's something that more people would want to see than not. In my case it was a proactive internal security scanner, but in other cases it could signal a breach or DoS attack because what else would be connecting to that socket?

Still, I'll add a separate log-level filter option (different PR?) to only log events at or above the listed level, with doc update. Is that a good solution?

@coreybutler
Copy link
Owner

@ChrisMiami I'm not sure if this is still something you're interested in, given the age. I've been going through old PR's in a number of projects and came across this. I'd still be open to merging this one, and yes, having a separate log-level filter option would be a good solution.

@lsh246
Copy link

lsh246 commented Jan 26, 2022

@coreybutler We're running into this issue as well and would love to have this PR merged. Could we create the logging level feature as a separate issue?

@edumansky
Copy link

@coreybutler We're also hitting this same issue in production FYI

@lsh246
Copy link

lsh246 commented Nov 8, 2022

@coreybutler still interested in this, FWIW.


server.on('error', function (err) {
launch('warn', err.message);
server = net.createServer().listen();
server.close(); // don't leak a trail of unclosed servers

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @ChrisMiami,
I have a question. Does the subsequent servers also close?

The first server will close the socket because we are listening the event, but after the first error, we are not listening the error events for the new created servers.

Thank you very much for your contribution

@jkomoda
Copy link
Contributor

jkomoda commented May 1, 2024

@ChrisMiami may you please allow me to push changes to your branch? I've made the logging change and we want to merge this ASAP. Otherwise, I'll create another PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants