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
resolve_hostname added db logging #2132
Conversation
Is it really a good idea to clutter the hosts list with resolved hostnames? |
I think the most typical use for the resolve_hostname module would be post exploit where you would want IPs resolved internal hostnames that you can't get from outside. To use this with resource scripts you need a way to get the info back (e.g. say you have an internal hostname that doesn't resolve from outside and you want to programatically pivot). To me it seems like hosts list made the most sense as a place to save. |
Yeah, @jvazquez-r7 and I discussed this a bit, and that's what we agreed on. Maybe make the logging optional? I dunno. There's also post/windows/recon/resolve_ip. |
resolve_ip could use some fixin', too. The option descriptions are totally wrong. |
Yeah, I like optional logging better. Like if you're using this to see if internal hosts resolve google.com you don't want google added to hosts. |
Yep! |
I don't think the default option should be true, but that's just my opinion. |
I like default true, but I don't really care if it's changed to false either :) |
Hey, most modules don't even ask. If you have a database, the least surprising thing would be to log it in a way that you can get at it from the |
Works for me, I can tell that fake local drivers/etc/hosts in fact resolve right.
|
Also tested combining |
Also incidentally updated the description.
Thanks, @todb-r7! |
Good place for a contributor-to-be to get their chops started. On Jul 22, 2013, at 12:51 PM, wvu-r7 notifications@github.com wrote:
|
Simple change to resolve_hostname post module, just logging to db.