[LEDE-DEV] [OpenWrt-Devel] Test results of OpenWrt 15.05.1 according to BSI test concept for home routers

[Nemesis]

On 04/26/2017 10:23 PM, Eric Schultz wrote:
> On 04/08/2017 11:38 AM, Hauke Mehrtens wrote:
> 
>> The German Bundesamt für Sicherheit in der Informationstechnik (short:
>> BSI, English: Federal Office for Information Security) published a
>> "Testkonzept für Breitband-Router (DSL-, Kabel-, SOHO-, CE-, CPE-Router,
>> IADs)" (English: Test concept for broadband routers). This test concept
>> is only available in German and most chapters are published in the
>> public by the BSI, chapter 4 and 5 are only available after signing a
>> NDA (Traffic Light Protocol) with the BSI:
>> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/Themen/Testkonzept-Breitbandrouter.pdf?__blob=publicationFile&v=5
>>
>> Some unnamed organization tested OpenWrt 15.05.1 on a TP-Link  TL-WR841N
>> V10.0 according to this test concept. Because I commented on the first
>> public draft of the test concept and said that I am active in the
>> OpenWrt project, the organization contacted me to check if their test
>> results are correct and provided me with the full test report under NDA.
>>
>>
>> OpenWrt 15.05.1 failed this test and LEDE will probably also fail this
>> test, because we failed on section 4.5.1 "Firewall-Bypass", which is a
>> criterion for exclusion (Ausschlusskriterium), see details below.
>>
>> The test concept focus on "normal" routers and only tests the web GUI
>> and also looks mostly on features normal home routers have. We are
>> missing some functionality like individual default password, for the web
>> GUI and the Wifi, the logging is not very good and so on. The tests
>> regarding DNS are interesting and more advanced, if someone wants to
>> look into that it would be very nice.
>>
>> The main problem is in section 4.5.1 "Firewall-Bypass".
>> OpenWrt and LEDE implement RFC4890 section 4.3.1:
>> -------------------------------------------------------------------
>> 4.3.1.  Traffic That Must Not Be Dropped
>>
>>    Error messages that are essential to the establishment and
>>    maintenance of communications:
>>
>>    o  Destination Unreachable (Type 1) - All codes
>>    o  Packet Too Big (Type 2)
>>    o  Time Exceeded (Type 3) - Code 0 only
>>    o  Parameter Problem (Type 4) - Codes 1 and 2 only
>>
>>    Appendix A.4 suggests some more specific checks that could be
>>    performed on Parameter Problem messages if a firewall has the
>>    necessary packet inspection capabilities.
>>
>>    Connectivity checking messages:
>>
>>    o  Echo Request (Type 128)
>>    o  Echo Response (Type 129)
>> -------------------------------------------------------------------
>>
>> The BSI used RFC6092 (Recommended Simple Security Capabilities in
>> Customer Premises Equipment (CPE) for Providing Residential IPv6
>> Internet Service) with this section as the base for the test:
>> -------------------------------------------------------------------
>> 3.2.1.  Internet Control and Management
>>
>>    Recommendations for filtering ICMPv6 messages in firewall devices are
>>    described separately in [RFC4890] and apply to residential gateways,
>>    with the additional recommendation that incoming "Destination
>>    Unreachable" and "Packet Too Big" error messages that don't match any
>>    filtering state should be dropped.
>>
>>    REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination
>>    Unreachable" and "Packet Too Big" messages containing IP headers that
>>    do not match generic upper-layer transport state records.
>> -------------------------------------------------------------------
>>
>>
>> Attached are the results of this test of OpenWrt 15.05.1. The
>> information on how the tests from chapter 4 and 5 are done is redacted
>> from the document, if you want to work on these problems and would like
>> to get more details about the problems from chapter 4 and 5, please
>> contact me. I can also help you with translating the problem from German
>> to English. ;-)
>>
>> The "sensitive" informations are under the Traffic Light Protocol
>> classification "TLP AMBER", see these German information about the NDA:
>> https://mip.bsi.bund.de/Anlage_1_TLP-Merkblatt.pdf
>>
>>
>> I commented on the tests itself, because they are missing many important
>> stuff to test, most of the security problem of IoT devices and home
>> routers one hears about in the media are not covered here at all.
>>
>>
>> History:
>> 20.10.2015: I read this article https://heise.de/-2851354 and wrote some
>> comments to the BSI based on the first public draft. In this mail I
>> mentioned that I am activate in the OpenWrt project.
>> 23.10.2015: The BSI answered me and offered me the full draft when I
>> would sign an NDA, I did so and got the full document, but did not
>> comment on it again.
>> 23.2.2016: I got the full final draft from the BSI
>> 22.11.2016: I was told by the unnamed organization that they tested a
>> TP-Link device running OpenWrt 15.05.1 and if I could comment on their
>> results. I got the results under the NDA and commented in them.
>> 31.3.2017: I asked if I can publish at lest some parts of the results
>> again and got the OK that I am allowed to publish the redacted results.
>>
>>
>> Hauke
>>
> 
> All,
> 
> A few members of prpl have expressed interest in organizing a public
> group to evaluate the results of this document and see what can be
> learned from it for OpenWrt/LEDE, with a particular focus on security.
> I'm sure there are others here who are interested in the same topic.
> 
> Is there a specific group already dedicated to addressing this? If so,
> please let me know and I'll let the prpl members know.
> 
> If not, I'd like to organize or work with others to organize such a
> group.If you have particular interest in this topic, please let me know
> if you'd like to participate in or help organize this group.
> 
> Thanks all,
> 
> Eric


Great job Hauke,

a possible first step could be to translate the German text to english.

Federico