xnih / satori Goto Github PK

Warning on startup when doing a live capture:
satori.py:254: DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats
(header, buf) = preader.next()

There are many TCP signatures which have the 'T' oddity, for example in the signature below:

By looking at the code that generates these oddities, I noticed that the 'T' oddity is added in one of two cases:

1. The TCP packet is a syn/ack packet and the 'T' option was identified in the TCP options
2. The TCP packet is a syn packet and the tcpTimeStampEchoReply != 0

The potential issue is in the second case:

The tcpTimeStampEchoReply value is defined to be '' (an empty string) and is only populated if the TCP timestamps option is found within the parsed TCP options. However, the check for syn packets checks whenever this value is != 0 as seen above. So this check will evaluate to true for all syn packets that do not have the TCP timestamps option, because in those cases tcpTimeStampEchoReply == '' != 0.

I wanted to ask and verify whether or not this is the expected and intended behavior, as it affects which packets are parsed to signatures that have the 'T' oddity.

Thanks!

Example (modified for example purposes):
Big-IP F5 Load Balancer Unknown Version:5|Linux 3.10.x:5|Redhat 7.5:5|Ubuntu 18.x:5|Windows 10 - 1607:10|Windows 10 - 1703:5|Windows 10 - 1709:5|Windows 10 - 1803:7

Should be:
Windows 10 - 1607:10|Windows 10 - 1803:7|Big-IP F5 Load Balancer Unknown Version:5|Linux 3.10.x:5|Redhat 7.5:5|Ubuntu 18.x:5|Windows 10 - 1703:5|Windows 10 - 1709:5

At a minimum it should be highest score first.

Hello, I am testing latest satori with -m tcp module on pcap file bigFlows.pcap from https://tcpreplay.appneta.com/wiki/captures.html. I get no (empty) result from satori. I tested other pcap files too, but same behaviour. DHCP module is working, but TCP not.
Cmd:
python3 satori.py -r bigFlows.pcap -m tcp
Any ideas what can I recheck?
Thanks

Thanks!

Hey is this module supposed to spoof the original device's os fingerprint?

Hi,
Can we somehow process pcapng file directly with satori without converting it into pcap first?

Reported by 3rd party via email.

"I've run into some problems when I tried to use Satori on my data. It doesn't output anything. I'm guessing it might be due to the link layer used in my captures is "linux cooked", in which there is no Ethernet layer. Is there any way to get Satori to read it anyway?"

can you give me the paper of thie project,i can not download it。
thanks!
[email protected],this is my email

Caused by: org.graylog2.contentpacks.exceptions.DivergingEntityConfigurationException: Different pipeline rule sources for pipeline rule with name "convert_timestamp_from_log"
        at org.graylog2.contentpacks.facades.PipelineRuleFacade.compareRuleSources(PipelineRuleFacade.java:151) ~[graylog.jar:?]
        at org.graylog2.contentpacks.facades.PipelineRuleFacade.findExisting(PipelineRuleFacade.java:140) ~[graylog.jar:?]
        at org.graylog2.contentpacks.facades.PipelineRuleFacade.findExisting(PipelineRuleFacade.java:126) ~[graylog.jar:?]
        at org.graylog2.contentpacks.ContentPackService.installContentPack(ContentPackService.java:131) ~[graylog.jar:?]

As soon as I remove this section, it will install with no issues.

Hi, how accurate is tcp signatures from tcp.xml? If we take that example from previous -m tcp issue thread, your output shows:

root@ubuntu:/home/xnih/satori# python3 ./satori.py -m tcp -r /home/xnih/Downloads/bigFlows.pcap | more
2013-02-26T22:02:35.959911;172.16.133.103;00:21:70:67:6A:E7;TCP;S;8192:128:1:52:M1460,N,W8,N,N,S:T;Windows 10 - 1607:5|Windows 10 - 1803:5|Windows 7:5|Windows 7 SP1:5|Windows 8.1:5|Windows Server 2008 R2:5

Meaning, Windows 10 - 1607:5|Windows 10 - 1803:5|Windows 7:5|Windows 7 SP1:5|Windows 8.1:5|Windows Server 2008 R2:5 all have the signature 8192:128:1:52:M1460,N,W8,N,N,S:T.

Questions: 1) how reliable are the signatures in tcp.xml 2) can we say even more precisely which exactly OS?
Thank you

The DHCP fingerprint is too long, I don't know if it is legal? And how can I verify the fingerprint of the device

if we take a look at first condition in detectOddities,

All signatures ending with option E are supposed to contain 'P', yet there are 0 signatures containing this oddity.
is this a code update issue?

"Android 4.1.x" in tcp.xml has TTL of 60 - is this something that is implemented OS wise?
this issue creates a problem when computing near TTL, as sometimes a packet can be 5+ hops away from the recording device.
how do you treat that possibility?

Example:
Fingerprint: 8192:128:1:48:M1460,N,N,S:T
Guess: Windows 10 - 1607:5|Windows 7 SP1:5|Windows 7 SP1:5|Windows Server 2016:5

Found a number of places, need to write something to parse the xml looking for dupes across the existing OS.

Short term fix, cleaning up by hand when noticed.

So unlike windows satori version, where it would just update the timestamp, the python version spits out every instance and kills the log servers. Graylog with nxlog is only "smart" enough to dedupe them if they are within one second.

Example:
2020-05-10T07:00:01;10.101.142.210;00:C1:64:xx:xx:xx;TCP;S;64240:64:1:52:M1460,N,W8,N,N,S:T;Windows 10 - 1803:52020-05-10T07:00:03;10.178.160.24;00:C1:64:xx:xx:xx;TCP;S;8192:128:1:52:M1460,N,W8,N,N,S:T;Windows 10 - 1607:5|Windows 7:5|Windows 7 SP1:5|Windows 8.1:5|Windows Server 2008 R2:5

This is seen across fingerprint methods, IE across different modules.