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

Use existing TCP opts in p0f_impersonate #1023

Merged
merged 2 commits into from
Jan 19, 2018
Merged

Conversation

saturn597
Copy link
Contributor

Trying to address "Check options in p0f.py" from #399 (the contributions roadmap). Making it so p0f_impersonate uses TCP options from the original packet where possible.

If this commit is on the right track, I can make changes/add tests as needed. Thanks!

@codecov-io
Copy link

codecov-io commented Jan 7, 2018

Codecov Report

Merging #1023 into master will increase coverage by 1.22%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #1023      +/-   ##
=========================================
+ Coverage   82.67%   83.9%   +1.22%     
=========================================
  Files         148     144       -4     
  Lines       37768   36805     -963     
=========================================
- Hits        31226   30882     -344     
+ Misses       6542    5923     -619
Impacted Files Coverage Δ
scapy/layers/tls/__init__.py 50% <0%> (-50%) ⬇️
scapy/error.py 82.35% <0%> (-7.85%) ⬇️
scapy/consts.py 77.19% <0%> (-4.63%) ⬇️
scapy/arch/windows/__init__.py 75.44% <0%> (-2.44%) ⬇️
scapy/autorun.py 81.57% <0%> (-1.76%) ⬇️
scapy/sendrecv.py 74.8% <0%> (-1.68%) ⬇️
scapy/config.py 83.6% <0%> (-1.64%) ⬇️
scapy/dadict.py 97.43% <0%> (-1.29%) ⬇️
scapy/supersocket.py 78.26% <0%> (-0.96%) ⬇️
scapy/layers/ipsec.py 89.58% <0%> (-0.93%) ⬇️
... and 42 more

Copy link
Member

@p-l- p-l- left a comment

Choose a reason for hiding this comment

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

Hi,

Thanks for this PR! Could you have a look at my remarks?

It would be great to add some unit tests for your changes. If you feel like it, you can create a tiny p0f.uts in test, based on other files you'll find in that repository.

Also, could you rebase your work against current master so that your changes get tested under Python 3?

@@ -14,6 +14,7 @@
import os
import socket
import random
import scapy.modules.six as six
Copy link
Member

Choose a reason for hiding this comment

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

You can write from scapy.modules import six. Also, since that's a Scapy import, please move it with the other Scapy imports.

else:
options.append(('WScale', int(opt[1:])))
elif opt == 'T0':
options.append(('Timestamp', (0, 0)))
elif opt == 'T':
if 'T' in pers[5]:
# Determine first timestamp.
if uptime is not None:
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure, but shouldn't we always set ts_a = ts_hint[0] when ts_hint[0] and 0 < ts_hint[0] < 2**32?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you mean instead of setting ts_a to uptime when uptime is set?

To me it seems more intuitive to use the value explicitly passed as an argument (uptime), rather than overriding it with the original packet's timestamp. If the caller wanted to use the value in the original packet, I wouldn't expect them to call the function with uptime=x.

Also this way the behavior is more consistent with the way it was before these changes. The first timestamp will be equal to uptime if uptime was passed, as before. An alternative if we aren't worried about consistency might be remove the uptime argument, since people can just set the timestamp in the original packet.

But for now I've kept it the way I had it. I could definitely be wrong, though, so please let me know if you do prefer it the other way.

@saturn597
Copy link
Contributor Author

Happy to help! Thank you for your review.

I've updated based on your comments, added some tests, and rebased against current master. I also replied back to your comment about setting timestamps. A few things weren't initially working in Python 3. So I fixed the issues I found and added a couple more tests in a second commit (can squash if preferred).

@p-l- p-l- merged commit 9d20c92 into secdev:master Jan 19, 2018
@p-l-
Copy link
Member

p-l- commented Jan 19, 2018

Thanks!

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.

3 participants