I haven’t updated much on the satellite tracker but I figured I would make the repo public since it is just sitting there at the moment. 🙂
https://github.com/bostrt/sattrack
https://github.com/bostrt/libpredict-arduino-lib
I plan to work on this some more before upcoming DEF CON 26.
Things are progressing nicely on the satellite tracker. The following is functional:
Serial interface
All components
Polar chart that will display relative satellite position
Missing photo of the satellite position data due to being in middle of display code rewrite.
After some fighting with libpredict, I found that I am going to need a microcontroller with better floating-point support. The Atmega series of microcontrollers do not have an FPU which means any floating-point support is hard (either inaccurate, slow, or hacked).
I found that some of the ARM Cortex processors do indeed have an FPU and their also come in similar form as Arduinos or other development boards:
https://www.adafruit.com/product/2772
Or
https://www.adafruit.com/product/2756
Above is Adafruit’s Feather which I’m going to give a shot. It hosts a Cortex M0 which actually does not have an FPU but would handle floating point much better than Atmega due to 32-bit arch.
The Teensy 3.2 hosts a Cortex M4 which actually does have an FPU which might be the winner.
I’ll be experimenting with both to see which one better suits my needs.
A couple months ago, I worked on putting a satellite tracking application on a Raspberry Pi. This worked okay but I have to use a keyboard to select the satellite I want to track before going outside to find it. I also have to lug around an external battery outside which isn’t fun. I could really use something more compact.
Hard Requirements
Soft Requirements
I have one of these pockeTETRIS things and love the little OLED screen. I will probably end up using the same screen. I’d like to just re-purpose my already built pockeTETRIS, but, I still need the RTC and definitely a microcontroller with more program space for largest library I will need, libpredict, which comes out to around 40k when I drop features I don’t need. The ATtiny85 in pocketTETRIS only has 8K. Pretty sure I am going with ATmega1284 a whopping 128k; plenty of room for libpredict, RTC library, OLED library, and my own code.
I am using Adafruit’s 3.5” TFT display so I used their custom image with the drivers already configured. You can find that here: https://learn.adafruit.com/adafruit-pitft-3-dot-5-touch-screen-for-raspberry-pi/easy-install.
Once you have Raspbian setup, you will need to get the device networked and install some dependencies of flyby:
# apt-get install libncurses-dev cmake gcc make git
Check out the source code for both projects using git:
# git clone https://github.com/la1k/libpredict.git
# git clone https://github.com/la1k/flyby.git
At the time of writing this, I ran into a few issues with crashes while starting up flyby. A patch has been filed here: https://github.com/la1k/flyby/pull/74
If you run into problems when trying to do the initial QTH setup (that’s later on in this post), then my fix may not have been merged yet. You can checkout the patch using, rebuild, and re-try:
# cd flyby
# git fetch origin pull/74/head:qth-setup-segfault
# git checkout qth-setup-segfault
Update: patch above has been accepted.
After you have checked out the sources, run the build process for libpredict:
# cd ~/libpredict
# mkdir build; cd build
# cmake ..
# make
# sudo make install
# sudo ldconfig
Then, build flyby:
# cd ~/flyby
# mkdir build; cd build
# cmake ..
# make
# sudo make install
The default font in Raspbian is too big to render flyby properly. Change the terminal by doing this:
# sudo dpkg-reconfigure console-setup
Choose the following options in each prompt:
The screen may hang for a moment while the settings are applied. After it completes, you will be sent back to a shell with your new font visible.
Finally, start up flyby simply by executing:
# flyby
Your screen should look something like below. Fill in your details and you are good to go 🙂
Segmentation Fault, then follow the steps in the Patch section earlier in this post.Finally, proceed with the normal setup steps provided in flyby’s Wiki: https://github.com/la1k/flyby/blob/master/docs/usage_guide.md#obtaining-and-updating-tlesOne of the simplest questions that comes up over-and-over is regarding the Server header in Apache HTTPD responses; the thing with the arrows are pointing to below:
# curl -I http://localhost/
HTTP/1.1 200 OK
Date: Tue, 28 Feb 2017 20:56:24 EST
Server: Apache/2.4.25 (Fedora) OpenSSL/1.0.2k-fips ◀◀◀◀◀◀◀◀
Content-Type: text/html; charset=UTF-8
There are a couple ways to reduce what is disclosed in the Server header.
ServerTokens directive to be ProductOnly.SecServerSignature directive to overwrite the Server header with custom contents.Each of the options are backed by opposing opinions. The Apache HTTPD documentation claims there is no advantage to hiding/altering the contents of the Server header because a malicious user could just throw all their attacks at a webserver, no matter what the webserver product actual is.
Setting ServerTokens to less than minimal is not recommended because it makes it more difficult to debug interoperational problems. Also note that disabling the Server: header does nothing at all to make your server more secure. The idea of “security through obscurity” is a myth and leads to a false sense of safety. 1
And, as far as I know, the motivation behind ModSecurity’s SecServerSignaturedirective is the because of a not in the HTTP/1.1 RFC 2068:
Revealing the specific software version of the server may allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make the Server header field a configurable option. 2
I’m not going to take sides in the matter, becaues I think both points have merits. However, I think our battles must be chosen carefully. Should time be spent deciding whether or not to obfuscate your Server header or should time be spent on more significant security matters? Why not satisfy this simple concern to satisfy the request of security professionals or security auditors?
ModSecurity has solved this issue with the SecServerSignature directive. However, I’ve seen people use ModSecurity only for this header. I think the module is completely overkill to use just for this one directive. So, I worked up a simple module who’s only purpose is to overwrite the Server header: https://github.com/bostrt/mod_serverheader
There are just a few fundamental pieces to learn in order to get started with ModSecurity.
There are 5 phases of request processing in ModSecurity 1. You can hook into any one these phases using the phase keyword when writing ModSecurity Actions and Rules. The 5 phases occur in this order:
As you pass through the phases, you can still access the information from the previous phases. So, if you are not sure where to begin, start with Logging Phase 5.
ModSecurity configurations are built around Actions (SecAction) and Rules (SecRule). We’ll start with SecAction since it is the same as a SecRule, just without a conditional. In other words, SecAction will always execute a list of actions, while a SecRule will only execute a list of actions if a certain condition is met.
SecRuleEngine On
SecAction id:100,phase:1,deny
SecRuleEngine enables the ModSecurity engine. If you do not enable it, none of your actions/rules will apply.
The SecAction above is about as simple as it gets. It always denies a request, sending a 403 status to client.
The id:100,phase:1,deny is known as the action list. Let’s work through it now. Every action must include an id and it must be unique amongst all your SecAction and SecRule2. After the id is the phase:1 which means this rule will run in the Request Headers phase. Finally, the deny is the part that actually says this SecAction will send a 403 status.
If you want to send something besides the default deny status of 403, you can change it by using the status action like this:
SecAction id:100,phase:1,deny,status:451
The action above would deny the client access and send a “451 Unavailable For Legal Reasons” status.
The ordering of items in an action list is not always important. If you are using things like Transformation Functions 3 (e.g. base64Encode, hexEncode, trim, etc) you need to pay attention to order, especially when you use multiple Transformation Functions in a single action or rule. Transformation Functions will change the input for the following functions and actions.
The example from the previous section does not have any actions that are sensitive to ordering. For instance, the following would execute in exact same manner as in previous section:
SecAction status:451,deny,phase:1,id:100
In the previous sections we used an example that simply denies every request. This isn’t very useful so we will add a condition to the action, making it a SecRule. The condition will be this: if someone requests the page and is from the IP address 192.168.100.200, then we want to deny them with the 451 status:
SecRule REMOTE_ADDR "192\.168\.100\.200" id:100,phase:1,deny,status:451
The REMOTE_ADDR 4 is the value we are testing and the “192.168.100.200” is value that needs to match. If the test passes then the action list is executed.
Collections (a.k.a. Persistent Storage) are an important feature of ModSecurity because they give you the ability to store information over multiple requests. There are a few different types of collections5 but we will focus on GLOBAL and SESSION collections in this guide. A GLOBAL collection is not associated with any single request, session, or anything really; it is just a general collection that can be accessed from anywhere. A SESSION collection is different in that it is associated with a specific session and initialized differently than a GLOBAL collection.
Let’s take a look at some example configuration.
SecDataDir /var/cache/mod_security/
SecAction id:150,phase:1,initcol:reindeer=rudolph
SecAction id:152,phase:1,setvar:reindeer.antlers=+2
SecAction id:153,phase:1,setvar:reindeer.hoofs=+4
SecDataDir is the directory where the persistent database files will be kept. Make sure this is writable by your Apache HTTPD user.
The first SecAction initializes the collection (initcol stands for initialize collection). The last two SecActions are setting the variables inside of the collection. So, in the example above, the collection is called rudolph and and it has two attributes: antlers and hoofs. The antlers are incremented by 2 for each request and the hoofs are incremented by 4 for each request.
The collection has a structure like this:
File name: reindeer
rudolph => {
antlers: 2,
hoofs: 4
}
Something imporatnt to note is that you can only call initcol once in your configuration since it is a GLOBAL collection. However, you can use SecRule in combination with initcol in the event you need to conditionally initialize a GLOBAL collection to use throughout a request’s lifecycle. For example, you can do:
SecRule REQUEST_URI rudolph id:150,phase:1,initcol:reindeer=rudolph
SecRule REQUEST_URI dancer id:151,phase:1,initcol:reindeer=dancer
SecAction id:152,phase:1,setvar:reindeer.antlers=+2
Instead of tracking things globally, you may want to associate a counter or variable with a specific session or request cookie. Let’s track how many people send requests from a specific session ID.
SecAction id:154,phase:1,setsid:%{REQUEST_COOKIES.SESSIONID}
SecAction id:155,phase:1,setvar:SESSION.requests=+1
In the configuration above, a counter called requests will be incremented for each request from the user with a specific session ID.
The collection will have a structure like this:
File name: default_SESSION
e0d47ef20 => {
requests: 100
},
a303b3cc7 => {
requests: 93
},
146f5a98e => {
requests: 174
}
e0d47ef20, a303b3cc7, and 146f5a98e are just example session ID’s which are the “keys” for each collection.
After reading this article, you will be ready to get started with writing your own rules and actions for ModSecurity. Maybe even dive into the complex set of prebuilt rules in the OWASP ModSecurity Core Rule Set 6.
References:
bostrt's notes 