>>> packet = IP(dst="ntpid")/UDP(dport=123,sport=50000)/("\x1b\x00\x00\x00"+"\x00"*11*4)
>>> packet.show()
###[ IP ]###
version = 4
ihl = None
tos = 0x0
len = None
id = 1
flags =
frag = 0
ttl = 64
proto = udp
chksum = None
src = xxx.xxx.xxx.xxx
dst = xxx.xxx.xxx.xxx
\options \
###[ UDP ]###
sport = 50000
dport = ntp
len = None
chksum = None
###[ Raw ]###
load = '\x1b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
>>> rep,non_rep = sr(packet)
Begin emission:
Finished sending 1 packets.
..........................^C
Received 26 packets, got 0 answers, remaining 1 packets
I would like to get the ntp_monlist response of my NTP server.
Actually the packet is sent but I didn't receive anything.
Can someone tell me the reason?
I try for it like this？ But the received ntp is question mark。
>>> packet = IP(dst=ntpserver)/UDP(dport=123,sport=50000)/ NTP(version=4)
>>>rep,non_rep = sr(packet)
>>> rep.show()
0000 IP / UDP / NTP v??, ?? ==> IP / UDP / NTP v??, ??
I was able to get this to work with the following command:
data = "\x17\x00\x03\x2a" + "\x00" * 4
send(IP(src=src_ip, dst=dst_ip)/UDP(sport=RandShort(),dport=123)/Raw(load=data),count=packets_chunk)
Source: https://vulners.com/packetstorm/PACKETSTORM:127492
Related
For a UDP socket, sendto() will attempt to bind an ephemeral port. For a Unix domain socket of datagram type, since there is no port concept, only a path address, does sendto() try to come up with a random path(which needs to be backed by a real file in the fs), or a random abstract path(such as '#blah'), and then binds to it?
I am asking because on my machine I see these datagram Unix socket pairs in 'ESTAB' state, and I wonder how are these endpoints identified if the address here is '*', which I guess is a NULL string?
# ss -xp | grep dev-log
u_dgr ESTAB 0 0 /run/systemd/journal/dev-log 15236 * 0 users:(("systemd-journal",pid=254,fd=3),("systemd",pid=1,fd=36))
# ss -xp | grep 15236
u_dgr ESTAB 0 0 /run/systemd/journal/dev-log 15236 * 0 users:(("systemd-journal",pid=254,fd=3),("systemd",pid=1,fd=36))
u_dgr ESTAB 0 0 * 19250 * 15236 users:(("dbus-daemon",pid=369,fd=14))
u_dgr ESTAB 0 0 * 21686 * 15236 users:(("dbus-daemon",pid=701,fd=10))
A related question is, what are those numbers in place of port numbers mean, in unix domain socket world?
I was under the impression that under Linux you could bind to a non-local address as long as you set the IP_FREEBIND socket option, but that's not the behavior I'm seeing:
$ sudo strace -e 'trace=%network' ...
...
socket(AF_INET, SOCK_RAW, IPPROTO_UDP) = 5
setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(5, SOL_SOCKET, SO_NO_CHECK, [1], 4) = 0
setsockopt(5, SOL_IP, IP_HDRINCL, [1], 4) = 0
setsockopt(5, SOL_IP, IP_FREEBIND, [1], 4) = 0
bind(5, {sa_family=AF_INET, sin_port=htons(abcd), sin_addr=inet_addr("w.x.y.z")}, 16) = -1 EADDRNOTAVAIL (Cannot assign requested address)
...
I also set the ip_nonlocal_bind setting, just to be certain, and I get the same results.
$ sysctl net.ipv4.ip_nonlocal_bind
net.ipv4.ip_nonlocal_bind = 1
Unfortunately, it seems that it is not possible to bind a raw IP socket to a non-local, non-broadcast and non-multicast address, regardless of IP_FREEBIND. Since I see inet_addr("w.x.y.z") in your strace output, I assume that this is exactly what you're trying to do and w.x.y.z is a non-local unicast address, thus your bind syscall fails.
This seems in accordance with man 7 raw:
A raw socket can be bound to a specific local address using the
bind(2) call. If it isn't bound, all packets with the specified
IP protocol are received. In addition, a raw socket can be bound
to a specific network device using SO_BINDTODEVICE; see socket(7).
Indeed, looking at the kernel source code, in raw_bind() we can see the following check:
ret = -EADDRNOTAVAIL;
if (addr->sin_addr.s_addr && chk_addr_ret != RTN_LOCAL &&
chk_addr_ret != RTN_MULTICAST && chk_addr_ret != RTN_BROADCAST)
goto out;
Also, note that .sin_port must be 0. The .sin_port field for raw sockets is used to select a sending/receiving IP protocol (not a port, since we are at level 3 and ports do not exist). As the manual states, from Linux 2.2 onwards you cannot select a sending protocol through .sin_port anymore, the sending protocol is the one set when creating the socket.
i'm learning the tun/tap device of linux, there is a little problem i cannot figure out
here is what i've done:
1: create a tap device, name is "tap1", get the file descriptor: tapfd
2: prepare an array huge enough, like: buf[2048]
3: write a ethernet frame into buf, inside it is an ip(udp) packet, 74bytes total. done it in a clumsy way, like:
// mac dst
buf[0] = 0xbb;
buf[1] = 0xaa;
buf[2] = 0xbb;
...
// mac src
buf[6] = 0xaa;
buf[7] = 0xbb;
...
// eth type
...
// ip ver & ip hdr_len
...
...
...
// data offset=42 length=32
buf[42] = 0x61;
...
buf[73] = 0x61
4: call write(), send the [74bytes] mentioned above into [tapfd]
write(fd, buf, 74);
5: use "tcpdump -i tap1 -vv" to check, but the result is as below:
18:06:40.466971 aa:bb:08:00:45:00 (oui Unknown) Unknown SSAP 0x18 > bb:aa:aa:bb:aa:bb (oui Unknown) Unknown DSAP 0x78 Information, send seq 0, rcv seq 0, Flags [Response], length 56
0x0000: 7919 0000 4011 ed95 0a00 0001 0a00 0001 y...#...........
0x0010: 5b25 5f7c 0028 1ae4 6161 6161 6161 6161 [%_|.(..aaaaaaaa
0x0020: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa
0x0030: 6161 6161 6161 6161 aaaaaaaa
total = 56bytes + 12bytes mac src&dst + 2bytes eth type = 70 bytes, so, where is the leading 4bytes?
first, i thought the leading 4bytes should be "preamble & Start of frame delimiter", but as the wiki says, preamble was 7 octets and Start of frame delimiter was 1 octet.
6: then i insert 4 bytes into my [buf], now the buf is like:
buf[0] = 0xab;
buf[1] = 0xab;
buf[2] = 0xab;
buf[3] = 0xcc;
buf = buf + 4;
{ buf[0] ~ buf[73] just as before }
then retry to send 78 bytes to fd
write(fd, buf, 78)
then check again, this time, tcp dump told me that is a legal ethernet frame!
18:13:57.676562 IP (tos 0x0, ttl 64, id 31001, offset 0, flags [none], proto UDP (17), length 60, bad cksum ed95 (->ed96)!)
localhost.23333 > localhost.24444: [bad udp cksum 0x1ae4 -> 0x1ae5!] UDP, length 32
it works! but why? why the leading 4bytes was missing?(please ignore the bad udp checksum)
This looks like a misconfiguration of the flags when opening your tap device.
The documentation for the Linux tun/tap kernel driver describes the following frame format.
3.2 Frame format:
If flag IFF_NO_PI is not set each frame format is:
Flags [2 bytes]
Proto [2 bytes]
Raw protocol(IP, IPv6, etc) frame.
You can find more information here: /usr/src/linux/Documentation/networking/tuntap.rst
Just add IFF_NO_PI to your interface flags and the device driver will not strip away the leading 4 bytes.
I am using Scapy to monitor towards man in the middle I would like to know in Scapy what does mean the following terms???
%IP.src%
%TCP.sport%
%IP.dst%
%TCP.dport%
%TCP.flags%
%TCP.payload%
I'm not Scapy user but seems pretty straight forward:
Source IP Address
TCP Source Port
Destination IP Address
TCP Destination Port
TCP Flags
TCP Payload (message body)
These are the useable TCP-Flags.
# TCP-Flags
FIN = 0x01
SYN = 0x02
RST = 0x04
PSH = 0x08
ACK = 0x10
URG = 0x20
ECE = 0x40
CWR = 0x80
You coul'd test for a flag with the & operator
e.g.:
if paket[TCP].flags & SYN:
do_anything()
Please help me to resolve the issue I am facing in my Linux Server.
I have a Linux System having 16GB RAM.
My java server is running on this machine it accepts only tcp connections from its clients.
But there are alsways 8 -10 clients stay in TCP DISCONNECTION state.
When I have checked my linux system by running
netstat -an | grep -c SYN
it gives always a value between 4 to 10 or sometimes more than 10.
CAN any one help to get rid of it.
how can I have 0 SYN_RECV sockets.
Thank you in advance.
sysct.conf is as follows:-
net.ipv4.ip_forward = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.wmem_max = 16777216
net.core.rmem_max = 16777216
net.core.netdev_max_backlog = 30000
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_congestion_control = htcp
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_mtu_probing = 0
fs.file-max = 4573502
net.ipv4.tcp_max_tw_buckets = 1000000