FreeBSD Pf and Tftp-proxy

Several IP-enabled devices in the lab use TFTP to retrieve configuration files from various locations on the Internet. This pains me. You can probably imagine what these devices are. Unfortunately I don't control how these devices work.

I run Sguil at my lab gateway to the Internet. I watch traffic right before the gateway, before it is NAT'd. I really don't care what's on the other side. I mostly care what is leaving the network, so I concentrate my NSM activities there.

I noticed one of these TFTP-enabled devices trying to retrieve a file repeatedly. I looked closer at the traffic (thanks to Sguil I keep a record of traffic leaving for the Internet) and noticed I never saw any replies. Simultaneously I received an email from tech support for this device. They told me to unplug all Internet devices from my cable modem and plug the troublesome device into the cable modem overnight (!) My answer to that: "heck no."

I decided to run an experiment with a TFTP client inside the lab and a TFTP server on the Internet. By watching traffic on the internal and external sides of the gateway, I could see TFTP requests making it to the TFTP server on the Internet, and TFTP replies coming from the server back to the gateway. However, the TFTP replies never appeared on the internal side of the gateway.

I did some research and determined that FreeBSD's Pf firewall can't handle TFTP traffic by default. Here is why:

18:13:31.205435 IP my.public.ip.addr.64212 > tftp.server.public.ip.69:  17 RRQ "test.txt" octet
18:13:31.282363 IP tftp.server.public.ip.51186 > my.public.ip.addr.64212: UDP, length 29
18:13:31.284161 IP my.public.ip.addr.57880 > tftp.server.public.ip.51186: UDP, length 4

You see the TFTP request to port 69 UDP. The reply, however, comes from port 51186 UDP to port 64212 UDP. Pf doesn't automatically know that packet 2 is associated with the TFTP request in packet 1.

Fortunately, FreeBSD and other operating systems ship with tftp-proxy(8). I tried following the example in the man page, but I ended up adding the following to the configuration file /etc/pf.conf. $local192 is the LAN from which I expect to see TFTP requests.

no nat on $ext_if to port tftp

rdr-anchor "tftp-proxy/*"

rdr on $int_if proto udp from $local192 to port tftp -> \
    $int_if port 6969

anchor "tftp-proxy/*"

I added the following to /etc/inetd.conf.

acmsoda dgram udp wait root /usr/libexec/tftp-proxy tftp-proxy -v

acmsoda is the name in /etc/services for port 6969.

I had to enable /etc/inetd in /etc/rc.conf.

inetd_enable="YES"
inetd_flags="-wW -C 60 -a 172.16.2.1"

Without the -a flag, tftp-proxy would be listening on all interfaces, and I don't want that.

Now I was ready to reload Pf and restart /etc/inetd.conf.

r200a:/root# pfctl -Fa -f /etc/pf.conf

r200a:/root# /etc/rc.d/inetd restart

I checked to ensure port 6969 UDP was listening.

r200a:/root# sockstat -4 | grep 6969
root     inetd      161   5  udp4   172.16.2.1:6969       *:*

Now I was able to retrieve my test file via TFTP.

tftp> get test.txt
getting from tftp.server.public.ip:test.txt to test.txt [octet]
sent RRQ 
received DATA 
Received 25 bytes in 0.1 seconds [2000 bits/sec]

I wanted to note that the man page recommended this addition to inetd.conf:

inetd(8) must be configured to spawn the proxy on the port that packets
are being forwarded to by pf(4).  An example inetd.conf(5) entry follows:

  127.0.0.1:6969  dgram   udp     wait    root \
     /usr/libexec/tftp-proxy tftp-proxy

That didn't work for me; I saw this error in /var/log/messages.

Jul 13 17:11:56 r200a inetd[99738]: 127.0.0.1:6969/udp: unknown service

By specifying the port only and using -a to bind inetd where I needed it, I avoided this error. There's probably another way around this though.

The final step will be seeing this TFTP-enabled device updating itself during the next 24 hours.

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Late Las Vegas registration ends 22 July.

Comments

Anonymous said…
This comment has been removed by a blog administrator.
9:03 AM
Anonymous said…
This comment has been removed by a blog administrator.
10:25 AM
Post a Comment

Popular posts from this blog

Zeek in Action Videos

Image
This is a quick note to point blog readers to my Zeek in Action YouTube video series for the Zeek network security monitoring project .  Each video addresses a topic that I think might be of interest to people trying to understand their network using Zeek and adjacent tools and approaches, like Suricata, Wireshark, and so on.  I am especially pleased with Video 6 on monitoring wireless networks . It took me several weeks to research material for this video. I had to buy new hardware and experiment with a Linux distro that I had not used before -- Parrot .  Please like and subscribe, and let me know if there is a topic you think might make a good video.
Read more

MITRE ATT&CK Tactics Are Not Tactics

Image
Just what are "tactics"? Introduction MITRE ATT&CK  is a great resource, but something about it has bothered me since I first heard about it several years ago. It's a minor point, but I wanted to document it in case it confuses anyone else. The MITRE ATT&CK Design and Philosophy document from March 2020 says the following: At a high-level, ATT&CK is a behavioral model that consists of the following core components: • Tactics, denoting short-term, tactical adversary goals during an attack; • Techniques, describing the means by which adversaries achieve tactical goals; • Sub-techniques, describing more specific means by which adversaries achieve tactical goals at a lower level than techniques; and • Documented adversary usage of techniques, their procedures, and other metadata. My concern is with MITRE's definition of "tactics" as "short-term, tactical adversary goals during an attack," which is oddly recursive. The key word in the tacti...
Read more

New Book! The Best of TaoSecurity Blog, Volume 4

Image
  I've completed the TaoSecurity Blog book series . The new book is  The Best of TaoSecurity Blog, Volume 4: Beyond the Blog with Articles, Testimony, and Scholarship .  It's available now for Kindle , and I'm working on the print edition.  I'm running a 50% off promo on Volumes 1-3 on Kindle through midnight 20 April. Take advantage before the prices go back up. I described the new title thus: Go beyond TaoSecurity Blog with this new volume from author Richard Bejtlich. In the first three volumes of the series, Mr. Bejtlich selected and republished the very best entries from 18 years of writing and over 18 million blog views, along with commentaries and additional material.  In this title, Mr. Bejtlich collects material that has not been published elsewhere, including articles that are no longer available or are stored in assorted digital or physical archives. Volume 4 offers early white papers that Mr. Bejtlich wrote as a network defender, either for technica...
Read more