- Products
- Learn
- Local User Groups
- Partners
-
More
Celebrate the New Year
With CheckMates!
Value of Security
Vendor Self-Awareness
Join Us for CPX 360
23-24 February 2021
Important certificate update to CloudGuard Controller, CME,
and Azure HA Security Gateways
How to Remediate Endpoint & VPN
Issues (in versions E81.10 or earlier)
Mobile Security
Buyer's Guide Out Now
Important! R80 and R80.10
End Of Support around the corner (May 2021)
700/1400 were quite nice and powerful boxes. Were, because after a tremendous development effort, the new 1500 series were intorduced in 2019, leveraging a more powerful hardware architecture and, more important, bringing the SMB line to R80 world and unifying the management options - thus, the 700/1400 series will reach end of sale in May 2020 and, aligned with Support Life Cycle Policy, maintenance releases and/or bug fixes will be supplied until October 2022. That means a full 5 1/2 years lifecycle of the 700/1400 line, far beyond the common hardware obsolescence.
So, maintenance releases and/or bug fixes, no new software development. What if I need a tool (executable, user-space) which was not included in the software package (R77.20.87 JHF Build 990173004 General Availability release is the latest at the time of writing) and is not mandatory for the proper functioning of the platform, to be included in maintenance releases ? Remember - using even the executables supplied with the software package in expert mode is not supported, meaning that TAC will not assist you in troubleshooting the proper or improper usage of them.
Well, I could help myself and compile the tool for the platform. Disclaimer: the activities described in this post are neither endorsed, approved nor supported by the organization - they are the result of individual explorations and described only for educational purposes; the results were not assessed by the rigorous QA routines applied to GA releases. Please read carefully the EULA regarding implications before any attempt to reproduce the procedures described in this post.
That being said, I would like to have the powerful OS tool, strace
, running on my 730. Warning: tracing a process can heavily affect performance up to two orders of magnitude slow-down in syscalls, please think twice before using in a production environment.
A decent development environment is required. Mine is an oldish i5 gen3 / 8 GB DRAM running Ubuntu 16.04 x86_64 LTS. If running a newer version, the operations described might need to be adjusted to the environment.
A cross compiling set of tools is also required (you are not logged in as root, are you?):
sudo apt-get install -y wget curl git python \ gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf binutils-arm-linux-gnueabihf \ make gcc binutils patch build-essential bc\ flex bison gawk libncurses5-dev gettext autoconf automake autotools-dev xz-utils
run dpkg -L
on gcc-arm-linux-gnueabihf, g++-arm-linux-gnueabihf
and binutils-arm-linux-gnueabihf
and record the install location, you might need it later.
Note: the GNU toolchain is not the original one used to compile the software release, you can run strings
on binaries on the box to find out the original one, which is still freely available).
The source - I used strace-4.14
and not the latest version available on https://github.com/strace/strace because starting with version 4.15 strace is able to modify return/error code of the syscalls, and to inject signals upon their execution. Pretty dangerous!
Get the source, extract it and step in the source folder (adjust to your own $PWD
wget https://sourceforge.net/projects/strace/files/strace/4.14/strace-4.14.tar.xz tar -xvf strace-4.14.tar.xz cd strace-4.14
To keep it simple, configure the build for a statically linked executable on the target ARM architecture:
env \
CC=arm-linux-gnueabihf-gcc \ LDFLAGS="-static" \ AR=/usr/bin/arm-linux-gnueabihf-ar \ ./configure --build x86_64-pc-linux-gnu --host arm-linux-gnueabihf
Review the Makefile
and run
make
Note that statically linked binaries require at runtime the shared libraries from the glibc
version used for linking.
Let's inspect it the output:
ps-101-ro@PS-101-RO:~/strace-4.14$ ll strace -rwxr-xr-x 1 ps-101-ro root 1808548 mar 28 15:37 strace* ps-101-ro@PS-101-RO:~/strace-4.14$ file strace strace: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=6ea347bca3a91079c96b72fbfd59de6ffff70cb4, not stripped
Shrink the binary:
ps-101-ro@PS-101-RO:~/strace-4.14$ /usr/bin/arm-linux-gnueabihf-strip strace ps-101-ro@PS-101-RO:~/strace-4.14$ ll strace -rwxr-xr-x 1 ps-101-ro root 750976 mar 28 15:44 strace*
Use your favourite method (scp or sneakernet on FAT32 formatted USB) to load the executable in /storage
folder on the 730. Mine runs:
[Expert@730]# uname -a
Linux 730 3.10.20-al-5.0-pr2 #1 SMP Wed Jun 19 10:20:09 IDT 2019 armv7l arm GNU/Linux [Expert@730]# clish -c "show diag" | head -11 Current system info ----------------------------------- Current image name: R77_990173004_20_87 Current image version: 004 Previous image name: R77_990172929_20_87 Previous image version: 929 Default image name: R77_990170952_20_31 Default image version: 952 Bootloader version: 68
Switch to /storage
and give strace
a try:
[Expert@730]# ./strace -V strace -- version 4.14
Let's attach strace
to a running process, say arping
(if you're wondering what arping might do, think of gateway monitoring):
[Expert@730]# PIDOFARP=`ps -ef | grep -v grep | grep arping | OFS=" \t" awk '{print $2}'` [Expert@730]# strace -v -e trace=sendto -o /storage/strace.out -p $PIDOFARP -f strace: Process 4451 attached ^Cstrace: Process 4451 detached
and check the output:
[Expert@730]# tail /storage/strace.out 4451 --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- 4451 sendto(22,"\0\1\10\0\6\4\0\1\0\34\177s\rw\254\21k\32\270\312:\312\204\277\254\21k\274", 28, 0, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ARP), sll_ifindex=if_nametoindex("WAN"), sll_hatype=ARPHRD_ETHER, sll_pkttype=PACKET_HOST, sll_halen=6, sll_addr=[0xb8, 0xca, 0x3a, 0xca, 0x84, 0xbf]}, 20) = 28
QED
If your're interested, I posted the exercise of having hping3
running on 730 (why would someone want to run hping
from the firewall and not through the firewall?).
Stay healthy, stay secured!
tcptraceroute
, which hardly could be described as maintained, depends on libnet
(more recently on libnet1
) and libpcap
. Only libpcap-1.9
was smoothly compiled from the currently maintained github repository (git clone, git checkout origin/libpcap-1.9.1, configure with build and host and make install), libnet.so
& tcptraceroute
were compiled using more obscure & tedious manual procedures.Extract the attach archive in /storage
. Tested with the following flags:
[Expert@730]# ./tcptraceroute -d -n -i WAN -m 20 -w 10 -t 8 203.0.xxx.yyy 80 debug: tcptraceroute 1.5beta7 debug: Compiled with libpcap version 1.9.1 (with TPACKET_V3); libnet 1.3-dev (API 110) debug: o_numeric set to 1 debug: device set to WAN debug: o_maxttl set to 20 debug: o_timeout set to 10 debug: o_tos set to 8 debug: entering getinterfaces() debug: ifreq buffer set to 32 debug: Successfully retrieved interface list debug: Discovered interface lo with address 127.0.0.1 debug: Discovered interface WAN with address 172.xxx.yyy.24 debug: Discovered interface LAN1 with address 192.xxx.yyy.1 debug: Discovered interface br0 with address 10.154.xxx.yyy debug: Discovered interface br1 with address 10.34.xxx.yyy debug: Discovered interface br2 with address 10.14.xxx.yyy debug: Discovered interface LAN3.830 with address 192.xxx.yyy.1 debug: Discovered interface LAN2.830 with address 192.xxx.yyy.1 debug: leaving getinterfaces() debug: Determined source address of 172.xxx.yyy.24 to reach 203.0.xxx.yyy debug: Setting o_syn, in absence of either o_syn or o_ack debug: debugoptions(): debug: TEXTSIZE: 1024 SNAPLEN: 92 IPTOSBUFFERS: 12 debug: ALLOCATEID_CACHE: 512 datalink: 1 datalinkoffset: 14 debug: o_minttl: 1 o_maxttl: 20 o_timeout: 10 debug: o_debug: 1 o_numeric: 1 o_pktlen: 0 debug: o_nqueries: 3 o_dontfrag: 0 o_tos: 8 debug: o_forceport: 0 o_syn: 1 o_ack: 0 debug: o_ecn: 0 o_nofilter: 0 o_nogetinterfaces: 0 debug: o_trackport: 0 datalinkname: ETHERNET device: WAN debug: o_noselect: 0 o_dnat: 0 isn: 1789831824 Selected device WAN, address 172.xxx.yyy.24, port 39969 for outgoing packets debug: pcap filter is: (tcp and src host 203.0.xxx.yyy and src port 80 and dst host 172.xxx.yyy.24) or ((icmp[0] == 11 or icmp[0] == 3) and dst host 172.xxx.yyy.24) Tracing the path to 203.0.xxx.yyy on TCP port 80 (www), 20 hops max debug: Generating a new batch of 512 IP ID's debug: Sent probe 1 of 3 for hop 1, IP ID 28506, source port 39969, SYN debug: null pointer from pcap_next() debug: received 68 byte IP packet from pcap_next() debug: Received ICMP packet debug: displayed hop 1 debug: Not attempting to resolve RFC1918 address 172.17.xxx.yyy 172.17.xxx.yyydebug: Not attempting to resolve RFC1918 address 172.17.xxx.yyy 0.217 ms
Hope this helps,
andreip
About CheckMates
Learn Check Point
Advanced Learning
WELCOME TO THE FUTURE OF CYBER SECURITY