Giter VIP home page Giter VIP logo

lzr's Introduction

LZR

LZR quickly detects and fingerprints unexpected services running on unexpected ports by working with ZMap. LZR can detect up to 18 unique protocols simultaneously with just two extra packets and can fingerprint over 35 different protocols.

To learn more about LZR's system and performance, check out the original paper appearing at USENIX Security '21. To use LZR to fingerprint services across all 65K ports, check out GPS.

Building

Install and set up ZMap. If also performing full L7 handshakes, set up ZGrab.

Set up $GOPATH (see https://golang.org/doc/code.html).

$ go get github.com/stanford-esrg/lzr
$ cd $GOPATH/src/github.com/stanford-esrg/lzr

LZR intercepts connections which ZMap opens; in order to ensure that the kernel does not interfere with LZR, LZR requires a source-ip to be specified for which the kernel drops all RSTs for traffic targeted to the source-ip. The chosen source-ip—which both ZMap and LZR will use—should be passed in as a parameter to make, so the appropriate iptables rule can be set.

$ make all source-ip=256.256.256.256/32

Usage

To fingerprint unexpected services on an random port (9002):

sudo zmap --target-port=9002 --output-filter="success = 1 && repeat = 0" \
-f "saddr,daddr,sport,dport,seqnum,acknum,window" -O json --source-ip=$source-ip | \
sudo ./lzr --handshakes http,tls

To complete full L7 handshakes of unexpected services on an random port (9002), substitute port=x in etc/all.ini with port=9002 and run the following command:

sudo zmap --target-port=9002 --output-filter="success = 1 && repeat = 0" \
-f "saddr,daddr,sport,dport,seqnum,acknum,window" -O json --source-ip=$source-ip | \
sudo ./lzr --handshakes wait,http,tls -feedZGrab | \
zgrab multiple -c etc/all.ini 

To scan a custom list of IP:Port (i.e., using LZR rather than ZMap to open connections):

<services_list pv -L$PACKETS_PER_SECOND -l --quiet | sudo ./lzr --handshakes http -sendSYNs -sourceIP $source-ip -gatewayMac $gateway

Note that we use pv to control the sending rate (i.e., the number of services fed to lzr per second).
The expected input format of an example services list is:

1.1.1.1:1234
2.2.2.2:80

Flags

$ ./lzr --help

Usage of ./lzr:
  -cpuprofile string
    	write cpu profile to file
  -d	debug printing on
  -f string
    	json results output file name (default "default_20210227212802.json")
  -feedZGrab
    	send to zgrab ip and fingerprint
  -forceAllHandshakes
    	Complete all handshakes even if data is returned early on. This also turns off HyperACKtive filtering.
  -gatewayMac string
    	gateway Mac Address in format xx:xx:xx:xx:xx:xx
  -haf int
    	number of random ephemeral probes to send to filter ACKing firewalls
  -handshakes string
    	handshakes to scan with (default "http")
  -memprofile string
    	write memory profile to this file
  -priorityFingerprint string
    	fingerprint to prioritize when multiple match
  -pushDataOnly
    	Don't attach data to ack but rather to push only
  -rn int
    	number of data packets to re-transmit (default 1)
  -rt int
    	number of seconds until re-transmitting packet (default 1)
  -sendInterface string
    	network interface to send packets on (default "ens8")
  -sendSYNs
    	will read input from stdin containing a newline-delimited list of ip:port
  -sourceIP string
    	source IP to send syn packets with (if using sendSYNs flag)
  -t int
    	number of seconds to wait in timeout queue for last retransmission (default 5)
  -w int
    	number of worker threads for each channel (default 1)

Caveats for specific features

Acking Firewall Filtering (-haf): If a host responds both on the expected port and on the random ephemeral port, whichever response comes first will dictate whether the host is marked as having an ACKing firewall.

LZR's Algorithm

License and Copyright

Copyright 2020 The Board of Trustees of The Leland Stanford Junior University

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

lzr's People

Contributors

lgrangeia avatar lizizhikevich avatar paralax avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

lzr's Issues

Unable to build from source (iptables issue)

As of go1.17 the go get command mentioned doesn't work and has been deprecated, instead go suggests to use go install, which fails.
When I'm trying to build from source I encounter this issue:

$ make all source-ip=256.256.256.256/32
sudo iptables -A OUTPUT -p tcp --tcp-flags RST RST -s 256.256.256.256/32 -j DROP
iptables v1.8.7 (legacy): host/network `256.256.256.256' not found
Try `iptables -h' or 'iptables --help' for more information.
make: *** [Makefile:10: all] Error 2

OS: fedora 36

lzr runtime fatal error

I'm running lzr following instructions in README.md, when I ran

 sudo zmap --target-port=9002 --output-filter="success = 1 && repeat = 0" \
-f "saddr,daddr,sport,dport,seqnum,acknum,window" -O json --source-ip=172.26.48.1 -n 20 | \
sudo ./lzr --handshakes http,tls

I encountered the followed error

++Writing results to file: default_20220827165939.json
++Handshakes: http,tls
++Worker threads: 1
++Timeout Interval (s): 5
++Retransmit Interval (s): 1
++Number of Retransmitions: 1
fatal error: runtime: out of memory

runtime stack:
runtime.throw(0x8297b5, 0x16)
        /usr/lib/go-1.13/src/runtime/panic.go:774 +0x72
runtime.sysMap(0xc004000000, 0x538000000, 0x10a1638)
        /usr/lib/go-1.13/src/runtime/mem_linux.go:169 +0xc5
runtime.(*mheap).sysAlloc(0xb59f20, 0x53724e000, 0x459140, 0x7ff928219008)
        /usr/lib/go-1.13/src/runtime/malloc.go:701 +0x1cd
runtime.(*mheap).grow(0xb59f20, 0x29b927, 0xffffffff)
        /usr/lib/go-1.13/src/runtime/mheap.go:1255 +0xa3
runtime.(*mheap).allocSpanLocked(0xb59f20, 0x29b927, 0x10a1648, 0x421035)
        /usr/lib/go-1.13/src/runtime/mheap.go:1170 +0x266
runtime.(*mheap).alloc_m(0xb59f20, 0x29b927, 0x7ff924790100, 0x7ff92479a9f0)
        /usr/lib/go-1.13/src/runtime/mheap.go:1022 +0xc2
runtime.(*mheap).alloc.func1()
        /usr/lib/go-1.13/src/runtime/mheap.go:1093 +0x4c
runtime.(*mheap).alloc(0xb59f20, 0x29b927, 0x7ff924010100, 0x1)
        /usr/lib/go-1.13/src/runtime/mheap.go:1092 +0x8a
runtime.largeAlloc(0x53724e000, 0x1, 0xc00015bb18)
        /usr/lib/go-1.13/src/runtime/malloc.go:1138 +0x97
runtime.mallocgc.func1()
        /usr/lib/go-1.13/src/runtime/malloc.go:1033 +0x46
runtime.systemstack(0x45c6e4)
        /usr/lib/go-1.13/src/runtime/asm_amd64.s:370 +0x66
runtime.mstart()
        /usr/lib/go-1.13/src/runtime/proc.go:1146

goroutine 1 [running]:
runtime.systemstack_switch()
        /usr/lib/go-1.13/src/runtime/asm_amd64.s:330 fp=0xc00015bd20 sp=0xc00015bd18 pc=0x45c7e0
runtime.mallocgc(0x53724e000, 0x80c660, 0x1, 0xc0001e76c4)
        /usr/lib/go-1.13/src/runtime/malloc.go:1032 +0x895 fp=0xc00015bdc0 sp=0xc00015bd20 pc=0x40fb75
runtime.makechan(0x7753a0, 0x5f5e100, 0xc0000b8060)
        /usr/lib/go-1.13/src/runtime/chan.go:106 +0x153 fp=0xc00015be08 sp=0xc00015bdc0 pc=0x4083b3
github.com/stanford-esrg/lzr.ConstructWritingQueue(...)
        /home/wangtz/lzr/construct_main_routines.go:49
github.com/stanford-esrg/lzr/bin.LZRMain()
        /home/wangtz/lzr/bin/bin.go:43 +0x174 fp=0xc00015bf50 sp=0xc00015be08 pc=0x5d5aa4
main.main()
        /home/wangtz/lzr/cmd/lzr/main.go:11 +0x20 fp=0xc00015bf60 sp=0xc00015bf50 pc=0x738450
runtime.main()
        /usr/lib/go-1.13/src/runtime/proc.go:203 +0x21e fp=0xc00015bfe0 sp=0xc00015bf60 pc=0x4332ae
runtime.goexit()
        /usr/lib/go-1.13/src/runtime/asm_amd64.s:1357 +0x1 fp=0xc00015bfe8 sp=0xc00015bfe0 pc=0x45e8b1

it seems that my machine's memory has run out, how should deal with this problem?

Read From ZMap --dryRun

add functionality such that lzr can read from zmap --dryRun (and not assume that whenever lzr is in charge of starting a connection (e.g., sendSYNs), that the input is coming in as a list). Will require to chance the lzr.readZMap() logic in bin/bin.go

Failing to get any scan results

I'm trying to get lzr to fingerprint anything, and I'm failing. I'm running the following command, using the latest release of lzr, from a debian 12 host:

$ echo "192.168.1.1:22" | sudo ./lzr \
   --handshakes ssh \
   -sendSYNs \
   -sourceIP      192.168.1.71 \
   -sendInterface wlp0s20f3 \
   -gatewayMac    30:89:4a:11:71:eb \
   -f -

The json it outputs, contains "fingerprint: unknown":

{
  "saddr": "192.168.1.1",
  "daddr": "192.168.1.71",
  "sport": 22,
  "dport": 42472,
  "seqnum": 2052859966,
  "acknum": 0,
  "window": 65535,
  "ttl": 0,
  "Counter": 1,
  "ACK": false,
  "ACKed": false,
  "SYN": true,
  "RST": false,
  "FIN": false,
  "PUSH": false,
  "HandshakeNum": 0,
  "fingerprint": "unknown",
  "Timestamp": "2024-04-11T15:25:37.616496178+01:00",
  "expectedRToLZR": "sa"
}

The host I am scanning from has this network interface

wlp0s20f3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.71  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::3289:4aff:fe11:71eb  prefixlen 64  scopeid 0x20<link>
        ether 30:89:4a:11:71:eb  txqueuelen 1000  (Ethernet)
        RX packets 147663603  bytes 169865914024 (158.1 GiB)
        RX errors 0  dropped 73712  overruns 0  frame 0
        TX packets 44722281  bytes 59451909408 (55.3 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The IP and port I am trying to scan is open (below run from the scanning host):

$ telnet 192.168.1.1 22
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u4

Can you suggest what I am doing wrong?

`Received Response Length` Always Zero

I've been attempting to get LZR to play nicely with ZMap and I'm finding I keep running into an issue where I apparently am getting no data response from anything I'm attempting to scan.

I've tried both in an externally-facing environment and on my internal network as well, but no matter what I do I can't seem to get a received response length above 0.

I've tested on both the latest version of Ubuntu 23 as well as Ubuntu 22 LTS and I'm getting the same results.

Example chain of commands:

LOCAL_SRC_IP=192.168.1.100 # (eth0 ipv4 address - LZR compiled with this same value for internal scans. Separately, I compiled LZR with my external/ISP-provided IP for external scans when running from a VPS.)

GATEWAY=<my eth0 gateway mac>

sudo zmap 192.168.1.0/24 --target-port=80 -O json -f "saddr,daddr,sport,dport,seqnum,acknum,window,ttl" \
--source-ip=$LOCAL_SRC_IP --output-filter="success=1 && repeat=0" | \
sudo ~/lzr/lzr -d --handshakes "http,tls" -sendInterface eth0 -gatewayMac $GATEWAY -feedZGrab

ZMap appears to successfully identify all the hosts that are running HTTP services on :80 in the above example, but LZR consistently returns TotalResponses: 0.

Example output:

Oct 19 XX [INFO] dedup: Response deduplication method is window with size 1000000
++Writing results to file: default_20231019XX.json
++Handshakes: http,tls
++Using Sending Interface: eth0
++Using Gateway Mac: redacted
++Feeding ZGrab with fingerprints
++Worker threads: 1
++Timeout Interval (s): 5
++Retransmit Interval (s): 1
++Number of Retransmitions: 1
Oct 19 XX [INFO] recv: duplicate responses will be passed to the output module
Oct 19 XX [INFO] recv: unsuccessful responses will be passed to the output module
 0:00 1%; send: 134 1 p/s (2.04 Kp/s avg); recv: 0 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 0.00%

<...snip...>

192.168.1.222 ====
recv seq num: 2905414489
stored seqnum:  2905414489
recv ack num: 1494555975
stored acknum:  1494555975
received response length:  0
stored response length:  111
192.168.1.222 ====
 0:08 100% (1s left); send: 256 done (6.83 Kp/s avg); recv: 145 0 p/s (18 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 56.64%
Oct 19 XX [INFO] zmap: completed
Finished Reading Input
Runtime: 9.047087634s
{"TotalResponses":0,"ZeroWindow":0,"ACKed":0,"Data":0,"No_SYNACK":0,"Rst":0,"Fin":0,"Resp_ack":0,"HyperACKtive":0}

Any ideas on how to get LZR properly reading the scan data and identifying the proper protocols would be greatly appreciated - thanks in advance!

LZR Continously Crashing

The following command: zmap 0.0.0.0/0 -p 80,443 --shards=32 --shard=3 --seed=123 -B 10m --probe-ttl=510 -O json -f saddr,daddr,sport,dport,seqnum,acknum,window,ttl --sender-threads=16 --source-ip=xxx --output-filter "success=1 && repeat=0" | ztee -u zmap_status.txt -l zmap_errors.txt --raw ztee.output | lzr --handshakes http,tls -t 5 -w 3 -sendInterface eth0 -gatewayMac xxx -f -

Results in the following crash after a few minutes. This is an issue that has occurred on numerous servers. Could this be patched to handle this issue gracefully, or are there any workarounds I could use to make this tool usable?

panic: send: No buffer space available

goroutine 58 [running]:
github.com/stanford-esrg/lzr.SendSyn(0xc29dd87c00, 0xc00011c1e0, 0xc000063ea8?)
        /tmp/lzr/handle_syn.go:31 +0x156
github.com/stanford-esrg/lzr.handleExpired(0xc00015e0e0, 0xc29dd87c00, 0xc00011c1e0, 0xc000128358?, 0xf?)
        /tmp/lzr/handle_expired.go:77 +0x19e
github.com/stanford-esrg/lzr.HandleTimeout(0xc00015e0e0, 0xc29dd87c00, 0x0?, 0xc29dd87c00?, 0x0?, 0x0?)
        /tmp/lzr/handle_timeout.go:52 +0x185
github.com/stanford-esrg/lzr/bin.LZRMain.func4(0x0?)
        /tmp/lzr/bin/bin.go:162 +0xc7
created by github.com/stanford-esrg/lzr/bin.LZRMain in goroutine 1
        /tmp/lzr/bin/bin.go:149 +0x734

I've also tried increasing the tcp_mem, wmem max, and xfrm4_gc_thresh:

echo "$(($RAM * 1024 * 1024 / 4096)) $(($RAM * 1024 * 1024 * 2 / 4096)) $(($RAM * 1024 * 1024 * 3 / 4096))" > /proc/sys/net/ipv4/tcp_mem
sysctl net.ipv4.xfrm4_gc_thresh=65536
echo 83886080 > /proc/sys/net/core/wmem_max
echo 83886080 > /proc/sys/net/core/wmem_default
echo 83886080 > /proc/sys/net/core/rmem_max
echo 83886080 > /proc/sys/net/core/rmem_default

However, this doesn't work. I've only had this issue with this tool. Other ones like Zmap, zrgab2, and masscan never crash and throw this error.

destination mac address hardcoded in source code for outbound packets

It seems like there is a mac address hardcoded in construct_responses.go :

func getHostMacAddr() (addr net.HardwareAddr) {
	return net.HardwareAddr{0xa8, 0x1e, 0x84, 0xce, 0x64, 0x5f}
}

This makes it difficult for the packets to actually arrive to their destination unless the scanning machine's gateway's mac address matches this address.

it's acting weird!

Hello there, I'm running lzr with zmap, it gives me correct output for one time and then it returns 0 results for all other scans!

note: my main interface is ens160, there is only one IP address on this interface, I've used this to make the lzr
make all source-ip=x.x.x.x/32

my target network has at least 21 results on port 80, zmap can verify that but I don't know what happens that it's giving me this results !

one time that it gave me results ( just 5 item, it should give me about 21 items ) !

{"saddr":"x.x.x.13","daddr":"185.x.x.x","sport":80,"dport":56425,"seqnum":3014031342,"acknum":110,"window":29200,"ttl":60,"Counter":0,"ACK":true,"ACKed":true,"SYN":false,"RST":false,"FIN":false,"PUSH":true,"HandshakeNum":1,"fingerprint":"http","Timestamp":"2023-11-13T12:37:18.393362549+03:30","expectedRToLZR":"data","data":"HTTP/1.1 301 Moved Permanently\r\nServer: openresty\r\nDate: Mon, 13 Nov 2023 09:07:18 GMT\r\nContent-Type: text/html\r\nContent-Length: 166\r\nConnection: keep-alive\r\nLocation: https://x.x.x.13/\r\n\r\n\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e301 Moved Permanently\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody\u003e\r\n\u003ccenter\u003e\u003ch1\u003e301 Moved Permanently\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003eopenresty\u003c/center\u003e\r\n\u003c/body\u003e\r\n\u003c/html\u003e\r\n"}
{"saddr":"x.x.x.12","daddr":"185.x.x.x","sport":80,"dport":46649,"seqnum":1393460254,"acknum":110,"window":29200,"ttl":60,"Counter":0,"ACK":true,"ACKed":true,"SYN":false,"RST":false,"FIN":false,"PUSH":true,"HandshakeNum":1,"fingerprint":"http","Timestamp":"2023-11-13T12:37:18.393380333+03:30","expectedRToLZR":"data","data":"HTTP/1.1 301 Moved Permanently\r\nServer: openresty\r\nDate: Mon, 13 Nov 2023 09:07:18 GMT\r\nContent-Type: text/html\r\nContent-Length: 166\r\nConnection: keep-alive\r\nLocation: https://x.x.x.12/\r\n\r\n\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e301 Moved Permanently\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody\u003e\r\n\u003ccenter\u003e\u003ch1\u003e301 Moved Permanently\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003eopenresty\u003c/center\u003e\r\n\u003c/body\u003e\r\n\u003c/html\u003e\r\n"}
{"saddr":"x.x.x.11","daddr":"185.x.x.x","sport":80,"dport":47539,"seqnum":2199870258,"acknum":110,"window":29200,"ttl":60,"Counter":0,"ACK":true,"ACKed":true,"SYN":false,"RST":false,"FIN":false,"PUSH":true,"HandshakeNum":1,"fingerprint":"http","Timestamp":"2023-11-13T12:37:18.393385312+03:30","expectedRToLZR":"data","data":"HTTP/1.1 301 Moved Permanently\r\nServer: openresty\r\nDate: Mon, 13 Nov 2023 09:07:18 GMT\r\nContent-Type: text/html\r\nContent-Length: 166\r\nConnection: keep-alive\r\nLocation: https://x.x.x.11/\r\n\r\n\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e301 Moved Permanently\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody\u003e\r\n\u003ccenter\u003e\u003ch1\u003e301 Moved Permanently\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003eopenresty\u003c/center\u003e\r\n\u003c/body\u003e\r\n\u003c/html\u003e\r\n"}
{"saddr":"x.x.x.10","daddr":"185.x.x.x","sport":80,"dport":51667,"seqnum":2846776825,"acknum":110,"window":29200,"ttl":60,"Counter":0,"ACK":true,"ACKed":true,"SYN":false,"RST":false,"FIN":false,"PUSH":true,"HandshakeNum":1,"fingerprint":"http","Timestamp":"2023-11-13T12:37:18.393396227+03:30","expectedRToLZR":"data","data":"HTTP/1.1 301 Moved Permanently\r\nServer: openresty\r\nDate: Mon, 13 Nov 2023 09:07:18 GMT\r\nContent-Type: text/html\r\nContent-Length: 166\r\nConnection: keep-alive\r\nLocation: https://x.x.x.10/\r\n\r\n\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e301 Moved Permanently\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody\u003e\r\n\u003ccenter\u003e\u003ch1\u003e301 Moved Permanently\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003eopenresty\u003c/center\u003e\r\n\u003c/body\u003e\r\n\u003c/html\u003e\r\n"}
{"saddr":"x.x.x.14","daddr":"185.x.x.x","sport":80,"dport":57849,"seqnum":1098684816,"acknum":110,"window":29200,"ttl":60,"Counter":0,"ACK":true,"ACKed":true,"SYN":false,"RST":false,"FIN":false,"PUSH":true,"HandshakeNum":1,"fingerprint":"http","Timestamp":"2023-11-13T12:37:18.39340616+03:30","expectedRToLZR":"data","data":"HTTP/1.1 301 Moved Permanently\r\nServer: openresty\r\nDate: Mon, 13 Nov 2023 09:07:18 GMT\r\nContent-Type: text/html\r\nContent-Length: 166\r\nConnection: keep-alive\r\nLocation: https://x.x.x.14/\r\n\r\n\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e301 Moved Permanently\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody\u003e\r\n\u003ccenter\u003e\u003ch1\u003e301 Moved Permanently\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003eopenresty\u003c/center\u003e\r\n\u003c/body\u003e\r\n\u003c/html\u003e\r\n"}

output for wrong results:
root@ubuntu20:/tmp/lzr# port=80 ; target=86.x.x.x/24 ; zmap -c 5 --retries=3 $target -i ens160 --target-port=$port --output-filter="success = 1 && repeat = 0" -f "saddr,daddr,sport,dport,seqnum,acknum,window" -O json | lzr --handshakes wait,http,tls -sendSYNs -sendInterface ens160
Nov 13 13:05:50.540 [WARN] blocklist: ZMap is currently using the default blocklist located at /etc/zmap/blocklist.conf. By default, this blocklist excludes locally scoped networks (e.g. 10.0.0.0/8, 127.0.0.1/8, and 192.168.0.0/16). If you are trying to scan local networks, you can change the default blocklist by editing the default ZMap configuration at /etc/zmap/blocklist.conf. If you have modified the default blocklist, you can ignore this message.
Nov 13 13:05:50.542 [INFO] dedup: Response deduplication method is full
++Writing results to file: default_20231113130550.json
++Handshakes: wait,http,tls
++Sending SYNs
++Using Sending Interface: ens160
++Worker threads: 1
++Timeout Interval (s): 5
++Retransmit Interval (s): 1
++Number of Retransmitions: 1
Nov 13 13:05:50.617 [INFO] recv: duplicate responses will be passed to the output module
Nov 13 13:05:50.620 [INFO] recv: unsuccessful responses will be passed to the output module
0:00 0%; send: 0 0 p/s (0 p/s avg); recv: 0 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 0.00%
0:00 0%; send: 0 0 p/s (0 p/s avg); recv: 0 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 0.00%
0:01 21%; send: 256 done (2.49 Kp/s avg); recv: 21 21 p/s (19 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 8.20%
0:02 40%; send: 256 done (2.49 Kp/s avg); recv: 21 0 p/s (10 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 8.20%
0:03 60%; send: 256 done (2.49 Kp/s avg); recv: 21 0 p/s (6 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 8.20%
0:04 80%; send: 256 done (2.49 Kp/s avg); recv: 21 0 p/s (5 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 8.20%
0:05 99% (1s left); send: 256 done (2.49 Kp/s avg); recv: 21 0 p/s (4 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 8.20%
Nov 13 13:05:56.633 [INFO] zmap: completed
Killed

Guidance request

Hello,

Just for clarification; I just want to know if I have to choose one random IP address for the $source-ip variable when executing the make command.

Also, I am having the below problem when doing the scan. What could it be?

panic: ens8: No such device exists (SIOCGIFHWADDR: No such device)

Can you please offer some guidance on the above concerns?
Thank you in advance.

Issues with ZMap+LZR

Hello,

I've run into the following issues when using LZR with ZMap.

  • When reading SYN-ACKs from ZMap, the SYN and ACK flags are not explicitly set. This causes LZR to respond to SYN-ACKs with a zero window size (which shouldn't happen according to the algorithm diagram), since the windowZero function checks for those flags.
  • ZMap outputs SeqNum and AckNum as signed 32-bit integers, but LZR uses 64-bit integers on a 64-bit machine (int is architecture-dependent in Go). This causes verification to fail for the first handshake whenever the MSB in SeqNum or AckNum is one.

Here is a possible fix, though the fix for the latter is a bit hacky!

--- a/packet.go
+++ b/packet.go
@@ -132,7 +132,17 @@ func convertFromZMapToPacket( input string ) *packet_metadata      {
        synack := &packet_metadata{}
        //expecting ip,sequence number, acknumber,windowsize, sport, dport
        err := json.Unmarshal( []byte(input),synack )
+       synack.SYN = true
+       synack.ACK = true
        synack.Processing = true
+       if strconv.IntSize == 64 {
+               if synack.Seqnum < 0 {
+                       synack.Seqnum = 4294967296 + synack.Seqnum
+               }
+               if synack.Acknum < 0 {
+                       synack.Acknum = 4294967296 + synack.Acknum
+               }
+       }
        if err != nil {
                log.Fatal(err)
                return nil

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.