So I have this pet tracker I got from China This model (not advertising at all). It includes an option to change the report server so I set it up to report to my server but now I'd like to ba able to "decode" TCP Frame.
Here are two examples of what's sent (it's not sent together). It's really not intuitive so I'm posting this here hoping some of you are better at reading between the lines.
Frame 1
4500 0040 affa 4000 7506 3884 4dcd 9901
25bb 10b0 f05a 1e4b 1123 3ec4 0000 0000
b002 4fb0 e868 0000 0204 0550 0103 0300
0101 0402 0101 080a 0003 8282 0000 0000
Frame 2
4500 0040 affb 4000 7506 3883 4dcd 9901
25bb 10b0 d67e 1e4b 126d 9432 0000 0000
b002 4fb0 67e5 0000 0204 0550 0103 0300
0101 0402 0101 080a 0003 c629 0000 0000
Here are the information about what might be sent :
Device IMEI : 013347005954573
Devide "ID" (used to login to gps18.com servers) : 4700595457
Tracker location : ~ N43.54XXXX,W1.46XXXX (censored I don't wish for my exact location to be unveiled here. This is the value sent when I request a Google Maps url via SMS)
I can also have this sent to your server if you wish to have some samples (give me IP + Port)
Thx
I did not understand fully the usage of the server change command.
I stumbled upon this https://decoded.avast.io/martinhron/the-secret-life-of-gps-trackers/
In fact, the sensor has to get some response from the server for it to work properly, which lead me to setup a MITM (with socat, simply) and tcpdump is now way more verbose, scanning nearby WiFi networks and stuff, thanks China !! All without encryption OFC
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 a Xen Server which got a new NIC recently. The Xen Server got deleted from the pool, the interfaces got new IDs as per documentation and the server was re-inserted.
Since then, I cannot connect to on some of the interfaces as I was used to. The interfaces in question were used to connect to our Storage Servers.
Even after searching the interwebs for quite some time, I am confused of the configuration, as there seems to be a vlan on the other side of the interfaces. But that vlan isn't configured on the Xen Server. Still, the same configuration is present on other servers, where it seems to work.
What confuses me the most are the following messages, captured on eth4, which is a bridge (xenbr4), with its own IP:
[root#xensrv01~]# tcpdump -vv -i eth4
tcpdump: WARNING: eth4: no IPv4 address assigned
tcpdump: listening on eth4, link-type EN10MB (Ethernet), capture size 65535 bytes
10:10:48.175669
10:10:49.359977 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 80c8.<bridge-id>.8009, length 43
message-age 2.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
root-id 80c8.<root-id>, root-pathcost 6, port-role Designated
10:10:49.581931 <mac-1> (oui Unknown) > <mac-2> (oui Unknown), ethertype Unknown (0x22f4), length 125:
0x0000: 831b 0106 0f01 0001 01cc 3e5f 1422 a001 ..........>_."..
0x0010: 2c00 6f40 cc3e 5f14 22a0 0401 0201 0081 ,.o#.>_.".......
0x0020: 01c0 8f3d 0000 0108 0004 e0ec c001 0001 ...=............
0x0030: 0203 0000 4002 0301 b880 0205 0708 dfff ....#...........
0x0040: d803 1ee0 ec00 0100 01e0 ec01 b801 b8e0 ................
0x0050: ec07 0807 09e0 ec07 0b07 19e0 ec07 1b07 ................
0x0060: 1c91 01c0 d309 0000 0000 0000 0000 00 ...............
10:10:50.392126 <mac-3> (oui Unknown) > Broadcast, ethertype Unknown (0x9001), length 64:
0x0000: 0201 000b 0001 0000 0002 0000 0000 0000 ................
0x0010: 0000 0000 0100 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 1600 0000 0000 ................
0x0030: 0840 .#
This is pretty much all you can see on the interface. It doesn't seem to appear on any other of the six servers we have.
What does this mean? Is my NIC broken (again)?
I would appreciate some insight into this, as I have no idea where to look anymore and have spent a considerable amount of time already. I can provide any additional necessary information.
In the end, it came down to two things:
Having the right cables connect the right ports with each other X)
Deleting and re-creating the network bridge
This made me have network connectivity again and the errors above stopped. I did this via the Xen Center though, which made all VMs running in the pool not have a connection for some time. Not recommended ;-)
I am still trying to find out how to re-create just the bridge on one xen host, not on all of them.
I want to capture the packet content description and the packet data to a file with tcpdump for later inspection.
Currently I am using the -w option to save packet data to a file:
tcpdump -c 100 -w /root/tcpdump.txt
This saves the packet data to the file but also includes several lines of binary before each packet. However, I would like to have the packet content description (what's normally shown on STDOUT when running tcpdump) shown before the packet data itself (in the same file) without the binary.
So the file should save the following for each packet:
Packet content description
Packet data
Example of what I want to save to the file:
17:17:42.847059 IP some.server.com.17845 > some.host.net.55618: Flags [P.], seq 137568:137888, ack 1185, win 167, length 320
<-- Followed by the raw packet data here -->
This information is to be used for later analysis of the file so we can review the full packets going to a specific host/address.
Can anyone suggest how to do this?
tcpdump -c 100 -w /root/tcpdump.txt
If you use -w with a name that ends with .txt, you're misunderstanding what -w does.
-w writes out a completely binary file, in pcap format, which is intended to be read by tcpdump or by other programs such as Wireshark, NOT to be directly read by humans!
IF the packets, at some layer, are carrying a text-based protocol, such as the FTP control protocol, SMTP, or HTTP requests/responses and their headers, then SOME of the data in the file will be text, but it will NOT all be text. Do NOT treat that as an indication that it is, or should be, a text file.
However, I would like to have the packet content description (what's normally shown on STDOUT when running tcpdump) shown before the packet data itself (in the same file) without the binary.
The packet data itself is binary!
If you mean you want a text hex dump of the packet data, in a form such as
0x0000: 0001 0800 0604 0001 0001 0000 0010 0a78
0x0010: 0452 0000 0000 0000 0a78 0452 0101 0600
after the packet description, so that what you see is like this:
17:49:38.007886 ARP, Request who-has 10.120.4.82 tell 10.120.4.82, length 32
0x0000: 0001 0800 0604 0001 0001 0000 0010 0a78
0x0010: 0452 0000 0000 0000 0a78 0452 0101 0600
then you should do
tcpdump -c 100 -x >/root/tcpdump.txt
so that the text output of tcpdump - the output you get when you don't use -w - is redirected to /root/tcpdump.txt rather than being printed on your terminal or terminal emulator, and so that a hex dump is written as well as a packet description (that's what -x tells tcpdump to do).
This will not write out the link-layer header for the packet in the hex dump; if you want the link-layer header for the packet, e.g.
17:49:38.007886 ARP, Request who-has 10.120.4.82 tell 10.120.4.82, length 32
0x0000: ffff ffff ffff 0001 0000 0010 0806 0001
0x0010: 0800 0604 0001 0001 0000 0010 0a78 0452
0x0020: 0000 0000 0000 0a78 0452 0101 0600
then use -xx rather than -x.
I am using Lua to create a custom authentication layer for my backend services. Nginx is compiled with Lua module and LuaJIT. It works fine. I would like to do some encryption of tokens that I am serving back in those lua files and want that no one read the plain text source files. Can these lua source files be compiled into a binary or obfuscated/encrypted in such a way that Nginx's access_by_lua_file directive is still able to load these compiled files? I know this is not a full proof method but better then plain text.
Lua strings are all present in the bytecode even in the absence of debugging info. Viewing a string stored in the code requires no motivation whatsoever.
$ luajit -be 'print("hello world")' hello.out
$ luajit hello.out
hello world
$ xxd hello.out
0000000: 1b4c 4a01 0229 0200 0200 0200 0434 0000 .LJ..).......4..
0000010: 0025 0101 003e 0002 0147 0001 0010 6865 .%...>...G....he
0000020: 6c6c 6f20 776f 726c 640a 7072 696e 7400 llo world.print.
$ luajit -bl hello.out
-- BYTECODE -- hello.out:0-0
0001 GGET 0 0 ; "print"
0002 KSTR 1 1 ; "hello world"
0003 CALL 0 1 2
0004 RET0 0 1
If your plan was to hide the encryption tokens within the bytecode, I would suggest first devising a reversible method to use an obfuscated version of them stored within the plain text of the source code (e.g. shuffle the characters, perform arithmetic on them, etc...)
I was able to use the web interface but I get this error when launching an instance. "Not enough resources (0 in cluster1 < 1): vm instances."
I installed Eucalyptus 4 manually on a single physical server running CentOS 6.5 (minimal)
Various articles I found, including this one URL below, mention that the Node Controller is not registered. Apparently evidence of this (shown below) is the "free/max" column is showing all zeros (0000)
http://opensource.sys-con.com/node/1349819
This command in the instructions seemed to register ok when I did it:
[root#server2 eucaconsole]# /usr/sbin/euca_conf --register-nodes "172.17.1.22"
INFO: We expect all nodes to have eucalyptus installed in $EUCALYPTUS for key synchronization.
root#172.17.1.22's password:
...done
The command given in the article has a parameter that's not supported (maybe deprecated)
[root#server2 eucaconsole]# euca_conf --no-rsync --discover-nodes
Usage: euca_conf [options]
euca_conf: error: no such option: --discover-nodes
Below is my output that shows all zeros in the "free" and "max" columns
[root#server2 eucaconsole]# euca-describe-availability-zones verbose
AVAILABILITYZONE cluster1 172.17.1.22 arn:euca:eucalyptus:cluster1:cluster:cc-22/
AVAILABILITYZONE |- vm types free / max cpu ram disk
AVAILABILITYZONE |- m1.small 0000 / 0000 1 256 5
AVAILABILITYZONE |- t1.micro 0000 / 0000 1 256 5
AVAILABILITYZONE |- m1.medium 0000 / 0000 1 512 10
AVAILABILITYZONE |- c1.medium 0000 / 0000 2 512 10
AVAILABILITYZONE |- m1.large 0000 / 0000 2 512 10
AVAILABILITYZONE |- m1.xlarge 0000 / 0000 2 1024 10
AVAILABILITYZONE |- c1.xlarge 0000 / 0000 2 2048 10
AVAILABILITYZONE |- m2.xlarge 0000 / 0000 2 2048 10
AVAILABILITYZONE |- m3.xlarge 0000 / 0000 4 2048 15
AVAILABILITYZONE |- m2.2xlarge 0000 / 0000 2 4096 30
AVAILABILITYZONE |- m3.2xlarge 0000 / 0000 4 4096 30
AVAILABILITYZONE |- cc1.4xlarge 0000 / 0000 8 3072 60
AVAILABILITYZONE |- m2.4xlarge 0000 / 0000 8 4096 60
AVAILABILITYZONE |- hi1.4xlarge 0000 / 0000 8 6144 120
AVAILABILITYZONE |- cc2.8xlarge 0000 / 0000 16 6144 120
AVAILABILITYZONE |- cg1.4xlarge 0000 / 0000 16 12288 200
AVAILABILITYZONE |- cr1.8xlarge 0000 / 0000 16 16384 240
AVAILABILITYZONE |- hs1.8xlarge 0000 / 0000 48 119808 24000
The most relevant article I could find on the community forum on StackOverflow only found this which didn't help me.
Not enough resources available eucalyptus describe availability zones
Thanks in advance if anyone help me fix this.
Try to use euca-describe-nodes
if you get output similar to the following -
NODE PARTI00 10.111.5.176 ENABLED
Then your node is properly registered. One common problem is the lack of diskspace. If you do the normal CentOS 6.5 minimal install, it will sometimes create a separate partition for /home and put the lion's share of space in that partition. Check your eucalyptus.conf for the INSTANCE_PATH variable and whatever directory that points to, make sure it is located on a partition with a lot of space.
Make changes in /etc/eucalyptus/eucalyptus.conf, search for Max_Cores, and change the number of instances you want to launch. this solved the issues