I am trying to get TCP. From TCP RFC 793 server and client select a random sequence numbers and after they increase it each time when it receives a new byte (it is wrong but just for example). To dump TCP packages I used tcpdump -n -i eth0 tcp:
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
04:32:20.732914 IP 10.10.0.2.43168 > 10.50.0.2.9: S 372254521:372254521(0)
win 5840 <mss 1460,sackOK,timestamp 3644068 0,nop,wscale 1>
04:32:20.766194 IP 10.50.0.2.9 > 10.10.0.2.43168: S 363863555:363863555(0)
ack 372254522 win 5792 <mss 536,sackOK,timestamp 3644074 3644068,nop,wscale 1>
04:32:20.766416 IP 10.10.0.2.43168 > 10.50.0.2.9: .
ack 1 win 2920 <nop,nop,timestamp 3644073 3644074>
04:32:25.502532 IP 10.10.0.2.43168 > 10.50.0.2.9: P 1:7(6)
ack 1 win 2920 <nop,nop,timestamp 3644548 3644074>
04:32:25.503272 IP 10.50.0.2.9 > 10.10.0.2.43168: .
ack 7 win 2896 <nop,nop,timestamp 3644548 3644548>
04:32:29.510131 IP 10.10.0.2.43168 > 10.50.0.2.9: F 7:7(0)
ack 1 win 2920 <nop,nop,timestamp 3644949 3644548>
04:32:29.513123 IP 10.50.0.2.9 > 10.10.0.2.43168: F 1:1(0)
ack 8 win 2896 <nop,nop,timestamp 3644949 3644949>
04:32:29.513356 IP 10.10.0.2.43168 > 10.50.0.2.9: .
ack 2 win 2920 <nop,nop,timestamp 3644949 3644949>
The first two packages look normally but from the third and so on it uses ack 1 instead of 363863556 and I can't get why?
It hasn't. You are running tcpdump without telling it that you want to see absolute sequence numbers (-S).
The default behavior for tcpdump is to translate sequence numbers to relative sequence numbers, which allow you to see how many bytes of data have transferred in either direction. In this specific case, you are seeing it go to 1 because, according to RFC-793, the SYN consumes one byte in the stream, so the proper response is SEQ+1. You will see the same thing happen going the other direction. (You will also find that the FIN consumes one byte). Following this, the ACK will increase by the number of bytes sent.
If you want to see the absolute sequence numbers, try again running tcpdump -n -i eth0 -S tcp
Related
I am analyzing some events against dns servers running unbound. In the course of this investigation I am running into traffic involving queries to the dns servers that are reported as having in some cases a source port between 1 and 1024. As far as my knowledge goes these are reserved for services so there should never be traffic originating / initiated from those to a server.
Since I also know this is a practice, not a law, that evolved over time, I know there is no technical limitation to put any number in the source port field of a packet. So my conclusion would be that these queries were generated by some tool in which the source port is filled with a random value (the frequency is about evenly divided over 0-65535, except for a peak around 32768) and that this is a deliberate attack.
Can someone confirm/deny the source port theory and vindicate my conclusion or declare me a total idiot and explain why?
Thanks in advance.
Edit 1: adding more precise info to settle some disputes below that arose due to my incomplete reporting.
It's definitely not a port scan. It was traffic arriving on port 53 UDP and unbound accepted it apparently as an (almost) valid dns query, while generating the following error messages for each packet:
notice: remote address is <ipaddress> port <sourceport>
notice: sendmsg failed: Invalid argument
$ cat raw_daemonlog.txt | egrep -c 'notice: remote address is'
256497
$ cat raw_daemonlog.txt | egrep 'notice: remote address is' | awk '{printf("%s\n",$NF)}' | sort -n | uniq -c > sourceportswithfrequency.txt
$ cat sourceportswithfrequency.txt | wc -l
56438
So 256497 messages, 56438 unique source ports used
$ cat sourceportswithfrequency.txt | head
5 4
3 5
5 6
So the lowest source port seen was 4 which was used 5 times
$ cat sourceportswithfrequency.txt | tail
8 65524
2 65525
14 65526
1 65527
2 65528
4 65529
3 65530
3 65531
3 65532
4 65534
So the highest source port seen was 65534 and it was used 4 times.
$ cat sourceportswithfrequency.txt | sort -n | tail -n 25
55 32786
58 35850
60 32781
61 32785
66 32788
68 32793
71 32784
73 32783
88 32780
90 32791
91 32778
116 2050
123 32779
125 37637
129 7077
138 32774
160 32777
160 57349
162 32776
169 32775
349 32772
361 32773
465 32769
798 32771
1833 32768
So the peak around 32768 is real.
My original question still stands: does this traffic pattern suggest an attack or is there an logical explanation for, for instance, the traffic with source ports < 1024?
As far as my knowledge goes these are reserved for services so there should never be traffic originating / initiated from those to a server.
It doesn't matter what the source port number is, as long as it's between 1 and 65,535. It's not like a source port of 53 means that there is a DNS server listening on the source machine.
The source port is just there to allow multiple connections / in-flight datagrams from one machine to another machine on the same destination port.
See also Wiki: Ephemeral port:
The Internet Assigned Numbers Authority (IANA) suggests the range 49152 to 65535 [...] for dynamic or private ports.[1]
That sounds like a port scan.
There are 65536 distinct and usable port numbers. (ibid.)
FYI: The TCP and UDP port 32768 is registered and used by IBM FileNet TMS.
I have encountered some trouble when testing different MTU settings on 2 nodes.
node1:192.168.160.2:MTU:1000
node2:192.168.160.3:MTU:9000
There is unmanaged switch between them.
Path MTU Discovery is turned OFF
When testing traffic from node2 to node1, MTU below 1500 doesn't seem to be fragmented even though every packet above MTU 1000 should be dropped.
On node2:
root#192.168.160.3:~$ ping -Mdo -s 1472 node1
PING node1.lan (192.168.160.2) 1472(1500) bytes of data.
1480 bytes from node1.lan (192.168.160.2): icmp_seq=1 ttl=64 time=0.227 ms
1480 bytes from node1.lan (192.168.160.2): icmp_seq=2 ttl=64 time=0.274 ms
1480 bytes from node1.lan (192.168.160.2): icmp_seq=3 ttl=64 time=0.265 ms
^C
--- node1.lan ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2061ms
root#192.168.160.3:~$ tracepath -l1504 node1
1: node1.lan 0.227ms reached
Resume: pmtu 1504 hops 1 back 1
On node1:
root#192.168.160.2:~$ ping -Mdo -s 1000 node2
PING node2.lan (192.168.160.3) 1000(1028) bytes of data.
ping: local error: Message too long, mtu=1000
^C
--- node2.lan ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
root#192.168.160.2:~$ tracepath -l1500 node2
1?: [LOCALHOST] pmtu 1000
1: node2.lan 0.294ms reached
1: node2.lan 0.180ms reached
Resume: pmtu 1000 hops 1 back 1
Why packets aren't dropped on receiving end even though I'm not allowed to send them above set limit (1000)? Is there any additional mechanism that allows all packets below MTU value of 1500 be received that I'm unaware of? I wanted to create mechanism that would allow me to check MTU values on remote clients.
I have an HTTP server and a client (I use curl for testing). The problem I have is that even the simplest, "ping" request takes 3-5 seconds to accomplish. I have run tcpdump on the server and it seems that after establishing TCP connection, the client (curl) waits 3-4 seconds for sending the HTTP request:
09:06:55.079376 IP client > server: Flags [S], seq 1639466412, win 64240, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0
09:06:55.079457 IP server > client: Flags [S.], seq 2519785093, ack 1639466413, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
09:06:55.087145 IP client > server: Flags [.], ack 1, win 1029, length 0
09:06:59.722060 IP client > server: Flags [P.], seq 1:83, ack 1, win 1029, length 82: HTTP: GET /ping HTTP/1.1
You can see the problem between 3 and 4 line of the tcpdump output.
Do you know what can cause this issue? Is this really on the client side or I should check also on the server side?
UPDATE
If I use telnet to connect to the server's port and send GET, the server replies immediately.
Flags [S] Syn
Flags [S.] - Syn Ack
Flags [.] - Placeholder, usually used for ACK.
Flags [P.] - Push Ack
Can you prepend time to your curl command? as shown below.
These hosts, is there latency between the two?
As a test on the same host (terminal):
terminal a $ python -m SimpleHTTPServer 8989
terminal b $ time curl -vvv localhost:8989
results look something like:
real 0m0.018s
user 0m0.006s
sys 0m0.005s
At this point its hard to say if this is client or server side, this depends on the data you are attempting to query. Can you share that query/curl command?
I am writing a pinging utility to check the connectivity. We have an IP range from X.X.X.0 - X.X.X.24
Ping X.X.X.08 - gives unknown host
Ping X.X.X.008- gives unknown host
Ping X.X.X.8 - gets successful response
How many digits should be there in the last octet?
But when I ping X.X.X.007 or X.X.X.07 or X.X.X.7 works, i get successful response.
Could some shade some light what i am missing?
This depends almost entirely on the implementation of your ping but the most likely cause is that the 08 is being treated as an octal number because it begins with 0.
And, since the valid octal digits are limited to 0..7, it assumes it's not a numeric IP address but instead a name to be looked up (in DNS, for example).
This octal behavior can be confirmed (under Windows) with the following transcript:
C:\Users\Pax> ping 192.168.1.061
Pinging 192.168.1.49 with 32 bytes of data:
Reply from 192.168.1.61: Destination host unreachable.
:
The 061 appears to have been treated as octal from the first line of the output, since 618 (6x8+1) = 4910. The subsequent lines, though they claim to be pinging the .61 address, are lying. That's because that's my actual machine and, if I do it without the leading zero, it works fine:
C:\Users\Pax>ping 192.168.1.61
Pinging 192.168.1.61 with 32 bytes of data:
Reply from 192.168.1.61: bytes=32 time<1ms TTL=128
:
If the octal bit contains a non-octal digit, that's when it starts complaining about the host itself rather than it just not being reachable (or, worse, pinging the wrong machine):
C:\Users\Pax>ping 192.168.1.61
Pinging 192.168.1.61 with 32 bytes of data:
Reply from 192.168.1.61: bytes=32 time<1ms TTL=128
:
C:\Users\Pax>ping 192.0168.1.61
Ping request could not find host 192.0168.1.61.
Please check the name and try again.
Normally, it doesn't matter if you have X.X.X.001 or .01 or .1 for the last octet.
See my ping results on 192.168.0.1 and .01 and .001 => they all result to .1
When I type www.google.com at my browser address bar, what exactly happens technically and how entire stuff is loaded. Considering the same HTTP page is being loaded...
what is role of DNS server, IP address, MAC address, subnet mask, proxy setting, default gateway in this case.
Does it make any different if I am in different class of network?
You are asking about all things at once, it's a big concept.
Still in short.
When you type www.google.com (or any other site name) then the request goes to the DNS server which translates the URL into an IP address.
Read here more: http://en.wikipedia.org/wiki/Domain_Name_System
Then the request goes to server where the website is being hosted, the server which is providing hosting service for the website contains the website-stuff that has to be shown to the world.
Read about apache server: http://en.wikipedia.org/wiki/Apache_HTTP_Server
Subnet: http://en.wikipedia.org/wiki/Subnetwork
does it make any different if i am in different class of network?
No, it doesn't make any difference if you are in different class of network.
(Study about routers: http://en.wikipedia.org/wiki/Routers)
Points to help you out:
Every computer that belongs to a network -including yours has an ip address.
Every network has hosts under it. The network may be divided into subnets
The ip addressing is hierarchial.This helps in routing
IP addresses may be assigned manually or by the DHCP server
Manual-IP configuration
DHCP-Dynamic Host Configuration Protocol
All packets that are sent to your ip address come through your isp network - this includes switches and routers
Packets from other networks are forwarded by this ip address. Once they reach the nearest switch. Switches use your MAC address to send packets to your computer. The MAC address is obtained by ARP
The gateway address is the path through which packets are sent out of your network or your ISP's
Proxy servers are servers that allow connections through them
To understand more about how this works, download Wireshark:
Start the sniffer and then load google.com in your browser.
You will notice the following
The browser first sends a DNS request with the hostname to the DNS server of your ISP (or your network if any)- DNS finds out the ip address from the hostname.
The DNS server replies with the IP address of the server
The browser then sends the HTTP request
This is in the form e.g
GET /index.html HTTP/1.1
The server responds with the format
The data is sent to the user
Usually if a webpage is requested, it is in HTML format(with javascript,css,etc). This is then parsed and processed by the browser to get the webpage we see.
To test this :
ON LINUX,
type
telnet stackoverflow.com 80
in the terminal.
As soon as it gets connected,type the following (quickly before it gets disconnected):
GET /index.html HTTP/1.1 (enter)
Host: stackoverflow.com (enter)(enter)
to see the response
ON WINDOWS
Download the putty client and fill the host as stackoverflow.com, port as 80, and choose Connection type as Telnet.
As soon as it gets connected, repeat same steps as above to see the response.
The examples shown above illustrate how things work from Layer 7, but not Layer 3+ from your device's perspective. I would look at using tcpdump/wireshark to try and dump all of the network packets if you're interested in getting those kinds of low-level details. An example's provided below (run on FreeBSD).
Notes:
- Be sure to start wireshark/tcpdump before your web browser/client first so the packets get captured.
- Specify the right port when starting wireshark/tcpdump; filtering the connection via a DNS address might not work in all cases if the remote webserver has load balancing/failover setup.
Window with tcpdump:
# tcpdump -A tcp port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes
capability mode sandbox enabled
01:48:17.917640 IP 10.0.2.15.50636 > nuq05s01-in-f20.1e100.net.http: Flags [P.], seq 1631738201:1631738227, ack 30720002, win 65535, length 26
E..BP.#.#...
...J}.t...PaBYY....P...F5..GET /index.html HTTP/1.1
01:48:17.918119 IP nuq05s01-in-f20.1e100.net.http > 10.0.2.15.50636: Flags [.], ack 26, win 65535, length 0
E..(.U..#..{J}.t
....P......aBYsP...'+........
01:48:18.072501 IP 10.0.2.15.50636 > nuq05s01-in-f20.1e100.net.http: Flags [P.], seq 26:28, ack 1, win 65535, length 2
E..*P.#.#...
...J}.t...PaBYs....P...F...
01:48:18.072662 IP nuq05s01-in-f20.1e100.net.http > 10.0.2.15.50636: Flags [.], ack 28, win 65535, length 0
E..(.X..#..xJ}.t
....P......aBYuP...')........
01:48:18.074353 IP nuq05s01-in-f20.1e100.net.http > 10.0.2.15.50636: Flags [P.], seq 1:687, ack 28, win 65535, length 686
E....Y..#...J}.t
....P......aBYuP...Z...HTTP/1.0 400 Bad request: request header 'Host' missing
Content-type: text/html; charset="iso-8859-1"
<html>
<body>
<h3> Request denied by WatchGuard HTTP proxy. </h3>
<b> Reason: </b> request header 'Host' missing <br>
<hr size="1" noshade>
<b> Method: </b> GET <br>
<b> Host: </b> 74.125.239.116 <br>
<b> Path: </b> /index.html <br>
<hr size="1" noshade>
</body>
<!-- PAD --></html>
01:48:18.074512 IP nuq05s01-in-f20.1e100.net.http > 10.0.2.15.50636: Flags [F.], seq 687, ack 28, win 65535, length 0
E..(.Z..#..vJ}.t
....P......aBYuP...$z........
01:48:18.074683 IP 10.0.2.15.50636 > nuq05s01-in-f20.1e100.net.http: Flags [.], ack 688, win 65014, length 0
E..(P.#.#...
...J}.t...PaBYu....P...F...
01:48:18.077023 IP 10.0.2.15.50636 > nuq05s01-in-f20.1e100.net.http: Flags [F.], seq 28, ack 688, win 65535, length 0
E..(P.#.#...
...J}.t...PaBYu....P...F...
01:48:18.077070 IP nuq05s01-in-f20.1e100.net.http > 10.0.2.15.50636: Flags [.], ack 29, win 65535, length 0
E..(.[..#..uJ}.t
....P......aBYvP...$y........
Window with telnet:
# telnet www.google.com 80
Trying 74.125.239.116...
Connected to www.google.com.
Escape character is '^]'.
GET /index.html HTTP/1.1
HTTP/1.0 400 Bad request: request header 'Host' missing
Content-type: text/html; charset="iso-8859-1"
<html>
<body>
<h3> Request denied by WatchGuard HTTP proxy. </h3>
<b> Reason: </b> request header 'Host' missing <br>
<hr size="1" noshade>
<b> Method: </b> GET <br>
<b> Host: </b> 74.125.239.116 <br>
<b> Path: </b> /index.html <br>
<hr size="1" noshade>
</body>
<!-- PAD --></html>
Connection closed by foreign host.