Een audit uitvoeren

Deze pagina geeft een eerste overzicht van de noodzakelijke stappen voor het uitvoeren van een audit van een pakket.

De eerste stap is het kiezen van een pakket om te onderzoeken, bij voorkeur één dat kritisch is voor de beveiliging.

Zie de lijst van pakketten die wij het meest belangrijkst vinden voor een audit voor suggesties.

Eén ding dat duidelijk moet zijn is dat we niet proberen te verzekeren dat een pakket slechts één keer wordt geaudit. Als veel mensen kiezen om hetzelfde pakket te onderzoeken is dit goed, want het toont aan dat veel mensen denken dat het pakket beveiligingsgevoelig is.

Door in essentie een willekeurige selectie van pakketten toe te laten, vergemakkelijken we de coördinatie en we elimineren het probleem van hoe kan ik er op vertrouwen dat persoon X zijn werk goed doet? (Dit is niet nodig omdat wordt verondersteld dat vroeg of laat iemand anders ervoor zal kiezen hetzelfde pakket te onderzoeken).

De audit starten

Na uw pakketselectie te hebben gemaakt, moet u echt starten met de audit.

Als u niet zeker bent van het soort problemen waarnaar u zoekt, start dan met het lezen van een boek over hoe veilige software te ontwikkelen.

De Secure Programming for Linux and Unix HOWTO heeft een heleboel goede informatie die u kan helpen. Secure Coding: Principles & Practices door Mark G. Graff en Kenneth R. van Wyk is ook een uitstekend boek.

Hoewel programma's niet perfect zijn, kunnen ze ontzettend veel helpen bij het vinden van mogelijke zwaktes, zie de audithulpmiddelenpagina voor meer informatie over enkele beschikbare audithulpmiddelen en hoe ze worden gebruikt.

Naast het kijken naar de code zelf is het een goed idee om de documentatie van het pakket te lezen en het pakket te proberen installeren en gebruiken.

Dit laat u misschien toe om manieren te bedenken om het programma te misbruiken in haar typische operatie.

Problemen rapporteren

Als u een probleem ontdekt in het pakket dat u aan het onderzoeken bent, dan kan u dit best rapporteren. Wanneer u een beveiligingsprobleem rapporteert, probeer er dan ook een patch aan te bieden zodat de ontwikkelaars het op tijd kunnen verhelpen. Het is niet nodig van een aanvalsvoorbeeld (veelal exploit of proof of concept genoemd) aan te bieden omdat de patch voor zichzelf zou moeten spreken. Het is meestal beter om tijd te investeren in het aanbieden van een geschikte patch, dan om een succesvolle aanval op de bug aan te bieden.

Hier is een lijst van te ondernemen stappen nadat u een beveiligingssprobleem heeft gevonden in Debian:

  1. Probeer een patch aan te maken voor de bug of verkrijg voldoende informatie zodat anderen het bestaan van het probleem kunnen nagaan. Idealiter zou elk rapport een oplossing moeten bieden ,voor het probleem dat u hebt ontdekt, die is getest en waarvoor is geverifieerd dat ze het probleem werkelijk oplost.

    Hoe gedetailleerder u bent over de omvang van het probleem, het relatieve belang van het probleem en mogelijke pistes om het probleem te omzeilen, hoe beter, als u geen oplossing hebt.

  2. Kijk eerst na of het beveiligingsprobleem aanwezig is in de stable Debian release en of het aanwezig is in andere distributies of in de versie aangeboden door de upstream beheerders.
  3. Gebaseerd op bovenstaand nazicht, rapporteert u het probleem:
    • naar de upstream beheerders via hun beveiligingscontact, geef de analyse en de patch.
    • naar het Debian Security Team als de fout aanwezig is is een gereleasde Debian-versie. Het Debian Security Team zal typisch een CVE-naam toewijzen aan het beveiligingsprobleem. Het beveiligingsteam zal met andere Linux-distributies coördineren indien nodig en zal contact opnemen met de pakketbeheerder in uw naam. U kunt echter ook een kopie van de e-mail versturen naar de pakketbeheerder. Doe dit echter enkel voor beveiligingsproblemen met een laag risico (zie verder).
    • Als het probleem zich niet voordoet in een gereleasde Debian-versie en de applicatie is misschien opgenomen in andere distributies of besturingssystemen, stuur dan een e-mail naar vendor-sec (een private mailinglijst die door de meeste vrije software-distributies wordt gebruikt om over beveiligingsproblemen te discussiëren). U hoeft dit niet te doen wanneer u het probleem al hebt doorgestuurd naar de Debian Security Team want zij zullen het ook naar deze lijst doorsturen.
    • Als het probleem zich niet voordoet in een gereleasde Debian-versie en u bent er absoluut zeker van dat de applicatie niet is opgenomen in een andere distributie of besturingssysteem, rapporteer het dan met het Bug Tracking Systeem.
  4. Eens het probleem publiek is (wanneer het Debian Security Team of een andere distributie een beveiligingsbericht heeft uitgebracht), dient er een bug met alle relevante informatie worden geöpend in het Debian Bug Tracking Systeem om het beveiligingsprobleem te kunnen traceren in niet-gereleasde Debian-versies (sid en testing). Dit wordt gewoonlijk door het Security Team zelf gedaan. Als u denkt dat ze er één vergaten of u bent niet aan het Security Team aan het rapporteren, dan kunt u het zelf rapporteren. Zorg ervoor dat de bug de gepaste tags heeft (gebruik de security-tag) en geef ze de gepaste prioriteit (gewoonlijk grave of hoger). Zorg er ook voor dat de bugtitel de gepaste CVE name bevat, als er één is toegewezen. Dit zorgt ervoor dat beveiligingsproblemen niet vergeten worden en dat ze opgelost worden in de gereleasde en niet-gereleasde Debian-versies.
  5. Als u dat wenst, dan kunt u deze informatie, eens ze publiek is, doorsturen naar publieke full disclosure mailinglijsten zoals full-disclosure of Bugtraq.

Merk op dat deze stappen kunnen afhangen van het risico dat geassocieerd is met het gevonden beveiligingsprobleem. U moet het risico bepalen via:

Er moeten verschillende stappen worden gezet om bijvoorbeeld een lokale symbolische koppelingsaanval te rapporteren die enkel kan gebruikt worden door geauthenticeerde gebruikers en die enkel het systeem kan beschadigen, dan om een bufferoverloop op het netwerk die beheersprivileges verschaft en aanwezig is in veelgebruikte software te rapporteren.

In de meeste gevallen, omdat beveiligingsproblemen niet mogen vrijgegeven worden vooraleer ze zijn opgelost, rapporteert u ze niet via het standaard Debian Bug Tracking Systeem, maar rapporteert u het probleem rechtstreeks naar het the Security Team die de release van een bijgewerkt pakket zal verzorgen en het zal rapporteren in de BTS eens het is opgelost.