How can you specify a source address in a multicast join in Haskell? - haskell

In the network-multicast Haskell documentation, I see a function
setInterface :: Socket -> HostName -> IO ()
Set the outgoing interface address of the multicast.
How can I use this to specify a source-address in a multicast join? The following code, when ran, produces the given output.. (IP Addresses masked for privacy)
Code
import Network.BSD
import Network.Socket hiding (send, sendTo, recv, recvFrom)
import Network.Socket.ByteString
import Network.Multicast hiding (multicastReceiver)
import Text.Printf
import Data.ByteString as B hiding (putStrLn)
sourceIP = "192.168.MMM.NNN"
mcastIP = "224.0.XXX.YYY"
mcastPort = 32101
mcastLoop :: Socket -> IO ()
mcastLoop sock = do
(msg, addr) <- recvFrom sock 1024
printf "%s-> %s\n" (show addr) (show . B.unpack $ msg)
mcastLoop sock
multicastReceiver :: HostName -> PortNumber -> IO Socket
multicastReceiver host port = do
proto <- getProtocolNumber "udp"
sock <- socket AF_INET Datagram proto
setInterface sock sourceIP
{-# LINE 81 "src/Network/Multicast.hsc" #-}
setInterface sock sourceIP
bindSocket sock $ SockAddrInet port 0
setInterface sock sourceIP
{-# LINE 82 "src/Network/Multicast.hsc" #-}
setInterface sock sourceIP
addMembership sock host
return sock
main :: IO ()
main = withSocketsDo $ do
sock <- multicastReceiver mcastIP mcastPort
dropMembership sock mcastIP
setInterface sock sourceIP
addMembership sock mcastIP
mcastLoop sock
Output
~ - sudo tcpdump -n -nn -i any "host 224.0.XXX.YYY"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
08:00:44.463153 IP 10.52.ZZZ.WWW > 224.0.XXX.YYY: igmp v2 report 224.0.XXX.YYY
08:00:52.498722 IP 10.52.ZZZ.WWW > 224.0.XXX.YYY: igmp v2 report 224.0.XXX.YYY
08:00:58.301711 IP 10.52.ZZZ.WWW > 224.0.XXX.YYY: igmp v2 report 224.0.XXX.YYY
08:01:08.408710 IP 10.52.ZZZ.WWW > 224.0.XXX.YYY: igmp v2 report 224.0.XXX.YYY
08:02:04.104707 IP 10.52.ZZZ.WWW > 224.0.XXX.YYY: igmp v2 report 224.0.XXX.YYY
08:03:08.545718 IP 10.52.ZZZ.WWW > 224.0.XXX.YYY: igmp v2 report 224.0.XXX.YYY
08:04:02.634709 IP 10.52.ZZZ.WWW > 224.0.XXX.YYY: igmp v2 report 224.0.XXX.YYY
08:05:03.757718 IP 10.52.ZZZ.WWW > 224.0.XXX.YYY: igmp v2 report 224.0.XXX.YYY
08:06:10.600716 IP 10.52.ZZZ.WWW > 224.0.XXX.YYY: igmp v2 report 224.0.XXX.YYY
08:07:07.248707 IP 10.52.ZZZ.WWW > 224.0.XXX.YYY: igmp v2 report 224.0.XXX.YYY
08:08:10.202708 IP 10.52.ZZZ.WWW > 224.0.XXX.YYY: igmp v2 report 224.0.XXX.YYY
08:09:02.390708 IP 10.52.ZZZ.WWW > 224.0.XXX.YYY: igmp v2 report 224.0.XXX.YYY
This is the comparison of C++/Haskell applications running (as requested by EJP)
~/sandbox - sudo tcpdump -i any "host 192.168.MMM.NNN"
[sudo] password for gresko:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
# C++ application started
16:15:55.490156 IP 192.168.MMM.NNN > 224.0.62.108: igmp v2 report 224.0.62.108
# C++ application killed
16:16:04.689342 IP 192.168.MMM.NNN > all-routers.mcast.net: igmp leave 224.0.62.108
# Haskell application started
# Haskell application killed

The Haskell authors haven't allowed for this in their constructor. It shouldn't take a group parameter at all, as it doesn't allow you to set the multicast interface before joining the group. Or, the group should be optional.
Also I would say that they should provide an addMembership() override or alternative that takes an NIC address as well as a group address. The underlying Sockets system call supports it after all.
However, unless Haskell's setInterface() method doesn't work at all, in which case there isn't much you can do, the sequence of
dropMembership()
setInterface()
addMembership()
should work.
I would want to confirm that you genuinely don't see any IGMP messages going out that interface before I concluded that setInterface() doesn't work.
I suspect that what is really happening is that the sender isn't sending properly.

Related

Have unbound use only ipv6 transport

So I wanted to have Unbound use IPv6 transport only and not use IPv4 when doing lookups. (This is for fun. I want to see all the dns look ups done in IPv6 for educationsl purpose.)
My computer has IPv6 connectivity (can do curl -6) so I created an Unbound server.
Thought adding do-ip4: no was enough but I'm not getting anything from dig.
My prediction was that my computer is trying to use systemd-resolved instead of unbound but that has nothing to do with IPv6 so I guess not?
Here are my config files and tcpdump
With IPv4 enabled (working)
$ cat /etc/unbound/unbound.conf.d/myunbound.conf
server:
port: 53
verbosity: 0
num-threads: 2
outgoing-range: 512
num-queries-per-thread: 1024
msg-cache-size: 32m
interface: 0.0.0.0
interface: 2001:myipv6addr:20
rrset-cache-size: 64m
cache-max-ttl: 86400
infra-host-ttl: 60
infra-lame-ttl: 120
access-control: 127.0.0.0/8 allow
access-control: 0.0.0.0/0 allow
username: unbound
directory: "/etc/unbound"
use-syslog: no
hide-version: yes
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
# prefer-ip6: no
remote-control:
control-enable: yes
control-port: 953
control-interface: 0.0.0.0
tcpdump -n -vv port 53 -i any
for dig o.com
19:56:49.226291 IP6 (flowlabel 0xa269b, hlim 64, next-header UDP (17) payload length: 54) ::1.39522 > ::1.53: [bad udp cksum 0x0049 -> 0xa5ea!] 35213+ [1au] A? o.com. ar: . OPT UDPsize=4096 (46)
19:56:50.222460 IP (tos 0x0, ttl 64, id 49989, offset 0, flags [none], proto UDP (17), length 74)
127.0.0.1.52155 > 127.0.0.1.53: [bad udp cksum 0xfe49 -> 0x7690!] 35213+ [1au] A? o.com. ar: . OPT UDPsize=4096 (46)
19:56:50.222695 IP (tos 0x0, ttl 64, id 47599, offset 0, flags [none], proto UDP (17), length 62)
[myIPv4].41206 > 192.35.51.30.53: [bad udp cksum 0x4644 -> 0x5c52!] 46488% [1au] A? o.com. ar: . OPT UDPsize=4096 DO (34)
19:56:50.292985 IP (tos 0x0, ttl 54, id 26365, offset 0, flags [none], proto UDP (17), length 1153)
192.35.51.30.53 > [myIPv4].41206: [udp sum ok] 46488 NXDomain*- q: A? o.com. 0/8/1 ns: com. SOA a.gtld-servers.net. nstld.verisign-grs.com. 1653044192 1800 900 604800 86400, com. RRSIG, CK0POJMG874LJREF7EFN8430QVIT8BSM.com. Type50, CK0POJMG874LJREF7EFN8430QVIT8BSM.com. RRSIG, TE4S5DTC23DPH5M574GG84GG0Q86T3GM.com. Type50, TE4S5DTC23DPH5M574GG84GG0Q86T3GM.com. RRSIG, 3RL2Q58205687C8I9KC9MV46DGHCNS45.com. Type50, 3RL2Q58205687C8I9KC9MV46DGHCNS45.com. RRSIG ar: . OPT UDPsize=4096 DO (1125)
19:56:50.293239 IP (tos 0x0, ttl 64, id 49997, offset 0, flags [none], proto UDP (17), length 135)
127.0.0.1.53 > 127.0.0.1.52155: [bad udp cksum 0xfe86 -> 0xc2e6!] 35213 NXDomain q: A? o.com. 0/1/1 ns: com. SOA a.gtld-servers.net. nstld.verisign-grs.com. 1653044192 1800 900 604800 86400 ar: . OPT UDPsize=4096 (107)
With IPv4 disabled (not working)
$ cat /etc/unbound/unbound.conf.d/myunbound.conf
server:
port: 53
verbosity: 0
num-threads: 2
outgoing-range: 512
num-queries-per-thread: 1024
msg-cache-size: 32m
interface: 0.0.0.0
interface: 2001:myipv6addr:20
rrset-cache-size: 64m
cache-max-ttl: 86400
infra-host-ttl: 60
infra-lame-ttl: 120
access-control: 127.0.0.0/8 allow
access-control: 0.0.0.0/0 allow
username: unbound
directory: "/etc/unbound"
use-syslog: no
hide-version: yes
do-ip4: no
do-ip6: yes
do-udp: yes
do-tcp: yes
# prefer-ip6: no
remote-control:
control-enable: yes
control-port: 953
control-interface: 0.0.0.0
tcpdump
dig k.com
20:02:32.122198 IP6 (flowlabel 0x8897b, hlim 64, next-header UDP (17) payload length: 54) ::1.53805 > ::1.53: [bad udp cksum 0x0049 -> 0x676c!] 15532+ [1au] A? k.com. ar: . OPT UDPsize=4096 (46)
20:02:33.122126 IP (tos 0x0, ttl 64, id 59754, offset 0, flags [none], proto UDP (17), length 74)
127.0.0.1.35568 > 127.0.0.1.53: [bad udp cksum 0xfe49 -> 0xb0a8!] 15532+ [1au] A? k.com. ar: . OPT UDPsize=4096 (46)
20:02:38.126147 IP6 (flowlabel 0x8897b, hlim 64, next-header UDP (17) payload length: 54) ::1.53805 > ::1.53: [bad udp cksum 0x0049 -> 0x676c!] 15532+ [1au] A? k.com. ar: . OPT UDPsize=4096 (46)
20:02:39.122227 IP (tos 0x0, ttl 64, id 59906, offset 0, flags [none], proto UDP (17), length 74)
127.0.0.1.35568 > 127.0.0.1.53: [bad udp cksum 0xfe49 -> 0xb0a8!] 15532+ [1au] A? k.com. ar: . OPT UDPsize=4096 (46)
20:02:44.126099 IP6 (flowlabel 0x8897b, hlim 64, next-header UDP (17) payload length: 54) ::1.53805 > ::1.53: [bad udp cksum 0x0049 -> 0x676c!] 15532+ [1au] A? k.com. ar: . OPT UDPsize=4096 (46)
20:02:45.122363 IP (tos 0x0, ttl 64, id 60247, offset 0, flags [none], proto UDP (17), length 74)
127.0.0.1.35568 > 127.0.0.1.53: [bad udp cksum 0xfe49 -> 0xb0a8!] 15532+ [1au] A? k.com. ar: . OPT UDPsize=4096 (46)
Needed to add
interface: ::1
to the conf file

How to get process/PID responsible for creating outbound connection request (linux) (command line)

I've got an alert from my firewall that a Debian virtual machine I have tried to download a miner virus.
tcpdump shows every minute it reaching out to:
07:55:01.379558 IP 185.191.32.198.80 > 192.168.1.205.49126: tcp 7300
07:55:01.379566 IP 192.168.1.205.49126 > 185.191.32.198.80: tcp 0
07:55:01.379576 IP 185.191.32.198.80 > 192.168.1.205.49126: tcp 2920
07:55:01.379584 IP 192.168.1.205.49126 > 185.191.32.198.80: tcp 0
07:55:01.379593 IP 185.191.32.198.80 > 192.168.1.205.49126: tcp 5840
07:55:01.379601 IP 192.168.1.205.49126 > 185.191.32.198.80: tcp 0
07:55:01.379609 IP 185.191.32.198.80 > 192.168.1.205.49126: tcp 8760
07:55:01.379617 IP 192.168.1.205.49126 > 185.191.32.198.80: tcp 0
07:55:01.379657 IP 185.191.32.198.80 > 192.168.1.205.49126: tcp 7300
07:55:01.379669 IP 192.168.1.205.49126 > 185.191.32.198.80: tcp 0
07:55:01.379680 IP 185.191.32.198.80 > 192.168.1.205.49126: tcp 4380
07:55:01.380974 IP 192.168.1.205.49126 > 185.191.32.198.80: tcp 0
07:55:01.381264 IP 192.168.1.205.49126 > 185.191.32.198.80: tcp 0
07:56:01.900223 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 0
07:56:01.900517 IP 185.191.32.198.80 > 192.168.1.205.49128: tcp 0
07:56:01.900553 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 0
07:56:01.900826 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 146
07:56:01.900967 IP 185.191.32.198.80 > 192.168.1.205.49128: tcp 0
07:56:01.901642 IP 185.191.32.198.80 > 192.168.1.205.49128: tcp 2920
07:56:01.901667 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 0
07:56:01.901684 IP 185.191.32.198.80 > 192.168.1.205.49128: tcp 4380
07:56:01.901696 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 0
07:56:01.901705 IP 185.191.32.198.80 > 192.168.1.205.49128: tcp 4380
07:56:01.901714 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 0
07:56:01.901725 IP 185.191.32.198.80 > 192.168.1.205.49128: tcp 2920
07:56:01.901738 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 0
07:56:01.901814 IP 185.191.32.198.80 > 192.168.1.205.49128: tcp 5840
07:56:01.901835 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 0
07:56:01.901848 IP 185.191.32.198.80 > 192.168.1.205.49128: tcp 8760
07:56:01.901858 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 0
07:56:01.901868 IP 185.191.32.198.80 > 192.168.1.205.49128: tcp 2920
07:56:01.901880 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 0
07:56:01.901891 IP 185.191.32.198.80 > 192.168.1.205.49128: tcp 4380
07:56:01.901905 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 0
07:56:01.901915 IP 185.191.32.198.80 > 192.168.1.205.49128: tcp 2920
07:56:01.901922 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 0
07:56:01.901932 IP 185.191.32.198.80 > 192.168.1.205.49128: tcp 5840
07:56:01.901939 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 0
07:56:01.901949 IP 185.191.32.198.80 > 192.168.1.205.49128: tcp 2920
07:56:01.901955 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 0
07:56:01.902010 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 0
07:56:01.902039 IP 185.191.32.198.80 > 192.168.1.205.49128: tcp 4380
07:56:01.902065 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 0
07:56:01.902076 IP 185.191.32.198.80 > 192.168.1.205.49128: tcp 4380
07:56:01.902084 IP 192.168.1.205.49128 > 185.191.32.198.80: tcp 0
07:57:01.909829 IP 192.168.1.205.49130 > 185.191.32.198.80: tcp 0
07:57:01.910130 IP 185.191.32.198.80 > 192.168.1.205.49130: tcp 0
07:57:01.910157 IP 192.168.1.205.49130 > 185.191.32.198.80: tcp 0
07:57:01.910245 IP 192.168.1.205.49130 > 185.191.32.198.80: tcp 146
07:57:01.910375 IP 185.191.32.198.80 > 192.168.1.205.49130: tcp 0
07:57:01.911050 IP 185.191.32.198.80 > 192.168.1.205.49130: tcp 2920
07:57:01.911076 IP 192.168.1.205.49130 > 185.191.32.198.80: tcp 0
07:57:01.911096 IP 185.191.32.198.80 > 192.168.1.205.49130: tcp 4380
07:57:01.911108 IP 192.168.1.205.49130 > 185.191.32.198.80: tcp 0
07:57:01.911120 IP 185.191.32.198.80 > 192.168.1.205.49130: tcp 4380
07:57:01.911130 IP 192.168.1.205.49130 > 185.191.32.198.80: tcp 0
07:57:01.911141 IP 185.191.32.198.80 > 192.168.1.205.49130: tcp 2920
07:57:01.911414 IP 192.168.1.205.49130 > 185.191.32.198.80: tcp 0
07:57:01.911507 IP 192.168.1.205.49130 > 185.191.32.198.80: tcp 0
When I look at the firewall logs I can see it reaching out to: http://185.191.32.198/lr.sh
I can block it via the firewall, but what I'm interested in is understanding which PROCESS on my server is doing such queries, as these are outbound queries. So there is some kind of exploit or virus reaching out from the server to try and download this script.
I've tried various netstat and lsof commands I've found on here, but they don't catch the traffic when it's actually happening, they just dump out and so no active connections. Also, bear in mind, I have no local ports actively listening, these new outbound requests once a minute.
So how would one set something up to see which process / PID is making these outbound requests each minute?
netstat can be used in continuous mode with the "-p" option to log the process initiating the connections, as described here: https://unix.stackexchange.com/questions/56453/how-can-i-monitor-all-outgoing-requests-connections-from-my-machine
Use the following command to log the connection attempts and pinpoint the initiating process:
sudo netstat -nputwc | grep 185.191.32.198 | tee /tmp/nstat.txt
Interrupt with Ctrl-C when you think the connection was logged.
less /tmp/nstat.txt
Then you can analyze the <PID> (replace with the pid of the process), its environment and threads with ps:
sudo ps -ef | grep <PID>
sudo ps eww <PID>
sudo ps -T <PID>
Using mbax's & Dude Boy input you could do this:
#!/bin/bash
while true
do
PID=$(netstat -nputw | grep 185.191.32.198)
if [ $? -ne 0 ]; then
:
else
ps -ajxf
echo "PID: ${PID}"
exit
fi
done
As a oneliner:
while true; do PID=$(netstat -nputw | grep 185.191.32.198); if [ $? -ne 0 ]; then :; else ps -ajxf; echo "PID: ${PID}"; break; fi; done
Edit: The original while timer 0.1 did not detect every attempt I tested, 0.01 did.
Edit 2: Using true uses up to 2% CPU, worth it when hunting ;)
Suggesting to research your problem using nethogs traffic monitoring tool. https://www.geeksforgeeks.org/linux-monitoring-network-traffic-with-nethogs/
It might take a while to catch the offending process .
And even if you catch it, it is possible the offending process is a transient vanishing script/program that is recreated with random names.
If your system is infected, then probably you will identify the infection is applied on a legitimated process or service.
Suggesting to scan your system with anti-virus as well.

Linux OpenSuse42.3 - port status - filtered

I have a problem, which I hope somebody can point me to the right direction.
Problem >>>
A) Our external provider (connects via VPN) needs to access "OpenSuse42.3" to specific ports, which
"nmap" or "ncat" tools shows as "filtered" or "refused".
B) No services are listening on these ports.
C) No firewall is running on this server.
D) Security team opened these ports on firewall with evidence that connection get reset by server
"OpenSuse42.3".
Test runs from "10.10.10.2" to "10.10.10.1" (problem server) from provider VPN connection (from my computer)
Example 1 : from "10.10.10.2"
>>> nmap -sT -p1101,3050 10.10.10.1
>>>
PORT STATE SERVICE
1101/tcp filtered pt2-discover
3050/tcp filtered gds_db
Example 2 : from "10.10.10.2"
nc -z -v 10.10.10.1 1101
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connection refused.
nc -z -v 10.10.10.1 3050
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connection refused.
Example 3: on server "10.10.10.1"
tcpdump -n -i eth0 port 1101 or port 3050 -v
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:00:28.940582 IP (tos 0x0, ttl 64, id 32383, offset 0, flags [DF], proto TCP (6), length 60)
10.10.10.2.58000 > 10.10.10.1.1101: Flags [S], cksum 0xa3fc (correct), seq 3906215335, win 29200,
options [mss 1460,sackOK,TS val 1388733400 ecr 0,nop,wscale 7], length 0
13:00:28.940662 IP (tos 0x0, ttl 64, id 40440, offset 0, flags [DF], proto TCP (6), length 40)
10.10.10.1.1101 > 10.10.10.2.58000: Flags [R.], cksum 0x347b (correct), seq 0, ack 3906215336,
win 0, length 0
13:00:31.263502 IP (tos 0x0, ttl 64, id 60627, offset 0, flags [DF], proto TCP (6), length 60)
10.10.10.2.40830 > 10.10.10.1.3050: Flags [S], cksum 0x8bc2 (correct), seq 3504308280, win 29200,
options [mss 1460,sackOK,TS val 1388735723 ecr 0,nop,wscale 7], length 0
13:00:31.263569 IP (tos 0x0, ttl 64, id 40888, offset 0, flags [DF], proto TCP (6), length 40)
10.10.10.1.3050 > 10.10.10.2.40830: Flags [R.], cksum 0x2554 (correct), seq 0, ack 3504308281,
win 0, length 0
BUT
As soon as I put something on the server like - "nc -l 1101" or "nc -l 3050"
problem disappears, which probably makes sense. To my knowledge "nmap" tool usually shows port status as "closed" if port is not firewalled and service is not running and "open" if service is running on this port.
Question
Are ports opened or closed ??? What else do I check, because provider keep insisting that ports are closed on "10.10.10.1" and he cannot continue his work.
Please let me knoe if something is unclear in this situation and I will respond.
Appreciate it !!!!

Reading pcap files and fetch dport number with specific ip address

I'm new to Python. I'm reading pcap file using scapy, i want to fetch dport number by specifying particular ip addresses, I have something like below
from scapy.all import *
pkts = rdpcap('example.pcap')
for pkt in pkts:
if IP in pkt:
ip_src=pkt[IP].src
ip_dst=pkt[IP].dst
if TCP in pkt:
tcp_sport=pkt[TCP].sport
tcp_dport=pkt[TCP].dport
print " IP src " + str(ip_src) + " TCP sport " + str(tcp_sport)
print " IP dst " + str(ip_dst) + " TCP dport " + str(tcp_dport)
if ( ( pkt[IP].src == "10.116.206.114") or ( pkt[IP].dst == "10.236.138.184") ):
print("!")
pcap file
required output
here in the above code i'm getting both results as shown below
IP src 10.116.206.114 TCP dport 443
IP dst 10.236.138.184 TCP dport 443
----
IP src 10.236.138.184 TCP dport 12516
IP dst 10.116.206.114 TCP dport 12516
.
.
so on, but i want only with specific src and dst ip which i specify like below i dont want both dport numbers.
IP src 10.116.206.114 TCP dport 443
IP dst 10.236.138.184 TCP dport 443
----
IP src 10.116.206.114 TCP dport 22
IP dst 10.236.138.184 TCP dport 22
Please suggest a method and explain how to fetch dport number from specific ip address. Thank you!

how does the tcp packet “size” reported by tcpdump correlate to the actual IP packet sent?

When I run a tcpdump – what exactly does the number reported between the () after the lowest and highest sequence number mean?
If it correlates to the IP packet sent, how can it be larger than
the mtu of 1500?
On the receive side of this flow tcpdump always
sees packets of 1448 or smaller – where are these packets being
defragmented and reassembled? Can I see that with tcpdump?
Is there any relationship between this number and the size of the tcp socket
buffer?
I.e: Typical tcpdump on the sender:
11:47:18.278352 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 3263771:3272459(8688) ack 1 win 54
11:47:18.278371 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 3272459:3282595(10136) ack 1 win 54
11:47:18.278620 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 3282595:3298523(15928) ack 1 win 54
11:47:18.278727 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 3298523:3301419(2896) ack 1 win 54
11:47:18.278731 IP 1.1.1.36.41034 > 1.1.1.37.60960: P 3301419:3301719(300) ack 1 win 54
11:47:18.777160 IP 1.1.1.36.41034 > 1.1.1.37.60960: P 3301719:3301723(4) ack 1 win 54
11:47:18.777175 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 3301723:3303171(1448) ack 1 win 54
And the receiver:
11:47:18.277895 IP 1.1.1.36.41034 > 1.1.1.37.60960: P 990413:990417(4) ack 1 win 54
11:47:18.277948 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 990417:991865(1448) ack 1 win 54
11:47:18.277953 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 991865:993313(1448) ack 1 win 54
11:47:18.277958 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 993313:994761(1448) ack 1 win 54
11:47:18.278028 IP 1.1.1.36.41034 > 1.1.1.37.60960: . 994761:996209(1448) ack 1 win 54
That is the length of the data, as you can see if you substract the two sequence numbers (after accounting +1 for SYN and FIN flags, if they are present in the packet).
As to why it's greater than the MTU, either your netword card can send jumbo-frames (quite normal on 1Gbps cards), or your card can accept large segments and divide them on hardware (called LSO/GSO or some similar acronym I cannot seem to recall).
Edit: See Large Segment Offload on Wikipedia.

Resources