I januar 2026 lastet 29 personer ned en Chrome-utvidelse som lovet å automatisere handel på kryptobørsen MEXC. Utvidelsen gjorde noe helt annet: den opprettet nye API-nøkler i bakgrunnen, skrudde på uttaksrettigheter, skjulte endringen fra brukergrensesnittet og sendte nøkkelen rett til en Telegram-bot kontrollert av angriperen. Ingen av ofrene fikk et varsel før det var for sent. Det er nøyaktig dette scenariet denne guiden lærer deg å forhindre: å bygge et eget overvåkingssystem som oppdager mistenkelig API-aktivitet på kryptobørs-kontoen din før pengene forsvinner, ikke etterpå.
Du trenger ikke stole blindt på børsens egne varsler. I løpet av 12 steg bygger du et Python-basert system som leser kontostatus via API, sammenligner mot forrige tilstand, og sender deg et Telegram-varsel innen sekunder hvis noe endrer seg, ny IP-adresse, aktiverte uttaksrettigheter eller et brått fall i saldo. Systemet kjører på egen maskin eller en billig server, krever ingen betalt tjeneste, og gir deg samme type kontroll som børsenes interne sikkerhetsteam bruker.
Denne guiden er skrevet for norske og nordiske brukere som handler på internasjonale børser som Binance, Kraken eller Coinbase, eller som kobler egne handelsboter mot disse plattformene via API. Du trenger ikke være proffutvikler for å følge stegene, men du bør være komfortabel med å redigere tekstfiler og kjøre enkle kommandoer i et terminalvindu. Alt kildekode-eksempelet er skrevet på norsk der det er mulig, slik at det er lettere å forstå hva hver funksjon faktisk gjør uten å måtte oversette variabelnavn mentalt mens du leser.
Hvorfor API-nøkler til kryptobørs er blitt et yndet angrepsmål
Mellom januar 2025 og juli 2026 tapte kryptoplattformer til sammen 3,63 milliarder dollar fordelt på 245 dokumenterte hendelser, ifølge CoinGeckos State of Crypto Security Report 2026. Første halvår 2026 alene talte 212 utnyttelser, en rekordhøy periode for bransjen. Det store flertallet av disse sakene handler ikke om avanserte protokollangrep, men om noe langt enklere: en lekket eller stjålet API-nøkkel med for vide rettigheter.
Mønsteret er konsistent nok til å kalles en trend snarere enn enkelttilfeller. Angriperne trenger sjelden å knekke selve krypteringen bak en børs eller en blokkjede. Det er langt enklere å målrette seg mot mennesket som eier nøkkelen, gjennom en falsk nettleserutvidelse, et phishing-forsøk eller en lekket kodebase, og deretter utnytte at ingen oppdager endringen før midlene allerede er borte. Det er nettopp derfor kontinuerlig overvåking av nøkkelrettigheter er blitt like viktig som selve oppsettet av nøkkelen.
Den enkeltstørste hendelsen i perioden var Bybit-tyveriet 21. februar 2025, hvor angripere drenerte rundt 401 000 ETH, den gang verdt cirka 1,4 milliarder dollar. FBI knyttet angrepet til nordkoreanske aktører under paraplyen TraderTraitor. Et annet eksempel med tydeligere relevans for vanlige brukere er Coinbase-saken fra 2025, hvor en ansatt lekket API-nøkler og kundeinformasjon mot bestikkelser, noe som førte til at angripere fikk tilgang til varme lommebøker og et tap på rundt 200 millioner dollar.
I mai 2026 avdekket GitHub uautorisert tilgang til interne kodelagre. Selskapet fant ingen bevis for at kundedata var berørt, men hendelsen var alvorlig nok til at Binance-grunnlegger Changpeng Zhao offentlig ba utviklere om å rotere alle API-nøkler som kunne ligge lagret i kildekode, ifølge Cryptorank. Samme mønster gikk igjen i den ondsinnede MEXC-utvidelsen fra januar 2026, dokumentert av The Hacker News, hvor angriperen bygde inn funksjonalitet for å skjule aktiverte uttaksrettigheter fra brukeren, se den fulle analysen her.
Tabellen under oppsummerer de mest relevante hendelsene fra 2025 og 2026 der API-nøkler, hot wallets eller kontotilgang var inngangsporten.
| Hendelse | Dato | Anslått tap | Årsak |
|---|---|---|---|
| Bybit | 21. feb. 2025 | ca. 1,4 mrd. USD | Kompromittert kaldlager-oppsett, tilskrevet nordkoreanske aktører |
| Coinbase (innsiderhendelse) | 2025 | ca. 200 mill. USD | Ansatt lekket API-nøkler og kundedata mot bestikkelse |
| MEXC (Chrome-utvidelse) | jan. 2026 | Ikke oppgitt av kilden | Skadelig utvidelse stjal API-nøkler og skjulte aktiverte uttak |
| GitHub-bruddet | mai 2026 | Ikke oppgitt av kilden | Uautorisert tilgang til interne repoer, utløste global nøkkelrotasjon |
| Coinsbuy | 9. aug. 2026 | ca. 8,07 mill. USD | Kompromittert hot wallet-nøkkel, koordinert kryssekjede-uttak |
| Moonwell | 27. aug. 2026 | ca. 8,7 mill. USD | Orakelmanipulasjon av illikvid sikkerhet |
Det fellestrekket som går igjen i nesten alle sakene er tidsforsinkelsen mellom kompromittering og oppdagelse. Ingen av ofrene fikk et automatisk varsel da nøkkelrettighetene ble endret. Det er akkurat det gapet dette prosjektet lukker. Hvis du allerede har lest vår guide om å sikre selve kryptobørs-kontoen din i 13 steg, er dette det naturlige neste laget: kontinuerlig overvåking av det som skjer etter at kontoen er sikret.
Regulatoriske krav i Norden: hva MiCA betyr for deg som bruker
EUs forordning om kryptoaktivmarkeder, kjent som MiCA, er nå gjeldende regelverk for kryptobørser som opererer i EU og EØS, inkludert Norge. Regelverket pålegger børser strengere krav til drift, kapitalbuffere og hendelseshåndtering enn tidligere, men det fritar ikke deg som sluttbruker fra ansvaret for å sikre egen kontotilgang. MiCA regulerer hvordan børsen skal håndtere kundemidler og rapportere hendelser, ikke hvordan du beskytter dine egne API-nøkler eller enheter.
For norske brukere betyr dette i praksis at du bør sjekke om børsen din er registrert eller godkjent av Finanstilsynet, og at du fortsatt selv må sette opp granulære API-tillatelser, IP-hviteliste og et overvåkingslag som dette prosjektet. Flere nordiske aktører, deriblant norske Firi, opererer under nasjonalt tilsyn i tillegg til MiCA, men de fleste API-drevne handelsbotene og verktøyene nordmenn bruker kobler seg mot internasjonale børser som Binance eller Kraken, hvor ansvaret for nøkkelsikkerhet ligger helt og holdent hos deg som bruker. Verifiser alltid gjeldende vilkår og sikkerhetsfunksjoner direkte hos din børs, siden tilbudet varierer mellom plattformer og oppdateres jevnlig.
Et annet moment som er verdt å nevne for nordiske lesere, er skatteplikten. Norske skattemyndigheter krever at du dokumenterer kryptotransaksjoner uavhengig av hvordan de oppstod, også hvis de skyldes et hack. Et overvåkingssystem som logger saldoendringer over tid, slik du bygger i denne guiden, gir deg samtidig et nyttig tidsstemplet spor du kan bruke som dokumentasjon dersom du noen gang må rapportere et tap eller forklare en uventet kontobevegelse overfor Skatteetaten.
Forutsetninger: dette trenger du før du starter
Prosjektet er bygget for å kjøre på en vanlig bærbar PC, en Raspberry Pi eller en liten skyserver. Du trenger ikke betale for noen tredjepartstjeneste. Sett av rundt 40 minutter til første oppsett, litt mer hvis dette er første gang du jobber med Python-miljøer eller Telegram-boter.
Vi bruker Binance som gjennomgående eksempel fordi det er en av de mest brukte børsene blant norske kryptobrukere og fordi ccxt-biblioteket gir god dekning av API-et. Prinsippene, kodestrukturen og risikoreglene er de samme uansett hvilken børs du velger, du bytter i praksis kun ut noen få linjer som er spesifikke for børsens eget API-format.
- Python 3.10 eller nyere installert (test med
python3 --version) - ccxt, biblioteket for børs-API-er, nyeste versjon (4.5.77 per september 2026 ifølge prosjektets GitHub-repo)
- python-dotenv for å lese miljøvariabler fra en .env-fil
- requests for å sende varsler til Telegram sitt Bot API
- En konto hos en børs som støtter API-nøkler med granulære tillatelser (Binance, Kraken, Coinbase og de fleste store børser støtter dette)
- En Telegram-konto og en bot opprettet via BotFather og Telegram Bot API
- Grunnleggende kjennskap til terminalen og til å redigere tekstfiler
- Valgfritt: en liten VPS eller Raspberry Pi hvis du vil kjøre systemet 24/7 uten at PC-en må stå på
Merk at du aldri trenger å gi systemet en API-nøkkel med uttaksrettigheter. Hele poenget er at overvåkingen skal kunne kjøre trygt selv om maskinen den står på blir kompromittert. Det er også derfor dette prosjektet er et selvstendig komplement til, ikke en erstatning for, tiltak som sikker oppsett av en hardware-lommebok for langsiktig oppbevaring.
Steg 1: Kartlegg hvilke API-tillatelser børsen tilbyr
Før du oppretter noen nøkkel, bør du forstå hva slags tillatelser børsen faktisk gir deg mulighet til å skille mellom. De fleste store børser deler API-tilgang i tre eller flere kategorier: lesetilgang, handel og uttak. Noen legger til egne kategorier for futures, margin og interne overføringer mellom under-kontoer.
| Tillatelse | Hva den gir tilgang til | Risikonivå | Anbefaling |
|---|---|---|---|
| Les kontoinfo | Saldo, ordrehistorikk, API-status | Lav | Alltid aktivert, dette er alt overvåkingssystemet trenger |
| Spot- og marginhandel | Legge inn og kansellere ordre | Middels | Kun på egne nøkler for handelsboter med begrenset saldo |
| Uttak | Flytte midler ut av børsen til lommebok | Kritisk | Deaktivert som standard, aktiver kun manuelt ved behov |
| Futures og derivater | Åpne og lukke posisjoner med giring | Høy | Egen nøkkel, aldri delt med overvåkingsnøkkelen |
| Intern overføring | Flytte midler mellom under-kontoer | Middels til høy | Overvåk med egen varselregel, se steg 8 |
Logg deg inn på API-administrasjonssiden hos børsen din og noter ned nøyaktig hvilke avkrysningsbokser som finnes. Denne kartleggingen tar fem minutter, men den avgjør hvor presist systemet ditt kan oppdage avvik senere i guiden.
Legg også merke til hvordan børsen selv logger endringer i API-innstillinger. Mange plattformer sender en e-post automatisk når en ny tillatelse aktiveres på en eksisterende nøkkel. Det varselet er nyttig, men det er ikke tilstrekkelig alene, siden e-post ofte leses timer eller dager senere. Systemet du bygger i denne guiden fungerer som et raskere og mer pålitelig andre lag på toppen av børsens egne varsler, ikke som en erstatning for dem.
Steg 2: Opprett en skrivebeskyttet API-nøkkel til overvåking
Opprett en helt ny API-nøkkel utelukkende for overvåkingssystemet. Ikke gjenbruk en nøkkel du allerede bruker til handel eller boter. Gi den kun lesetillatelse. La uttak, handel og futures stå avslått. Gi nøkkelen et beskrivende navn som overvaking-varsel slik at du kjenner den igjen senere i loggen hos børsen.
De fleste børser krever 2FA-bekreftelse for å opprette en ny nøkkel, og noen låser nye nøkler i 24 til 48 timer før de aktiveres. Planlegg for det, spesielt hvis du følger denne guiden rett før en reise eller ferie hvor du vil ha overvåkingen aktiv.
Skriv ned nøkkelens opprettelsesdato et sted utenfor selve systemet, for eksempel i en passordbehandler. Det gjør det enkelt å svare på et enkelt spørsmål senere: “hvor lenge har denne nøkkelen vært aktiv?” Det spørsmålet blir viktig når du kommer til rutinen for nøkkelrotasjon i steg 12, og det er langt raskere å slå opp en dato enn å lete gjennom børsens transaksjonshistorikk for å finne ut av det i etterkant.
Steg 3: Aktiver IP-hviteliste på nøkkelen
IP-hviteliste er den enkeltviktigste innstillingen for å hindre at en lekket nøkkel kan misbrukes fra en annen maskin enn din egen. Finn den offentlige IP-adressen til maskinen eller serveren som skal kjøre systemet, og legg den inn i børsens hviteliste-felt for denne spesifikke nøkkelen.
Hvis du kjører systemet hjemmefra med en dynamisk IP-adresse fra internettleverandøren, bør du enten sette opp en statisk IP mot ekstra kostnad, bruke en liten VPS med fast IP, eller sørge for at IP-endringer trigger en egen varsling i steget om risikoregler lenger ned. Å hoppe over dette steget er den vanligste årsaken til at API-nøkler misbrukes etter et lekkasje-scenario, fordi en nøkkel uten IP-begrensning fungerer for angriperen uansett hvor de befinner seg.
Sjekk din offentlige IP raskt med en kommando som curl ifconfig.me fra samme maskin som skal kjøre overvåkingsscriptet. Skriv adressen inn nøyaktig slik den vises, siden mange børser krever hele IPv4-adressen uten mellomrom eller ekstra tegn. Noen børser lar deg legge inn flere IP-er, noe som er nyttig hvis du planlegger å kjøre systemet fra både en hjemmemaskin og en sky-instans som backup.
Steg 4: Sett opp Python-miljøet
Opprett en egen mappe for prosjektet og et isolert virtuelt miljø. Dette holder avhengighetene atskilt fra resten av systemet og gjør det enkelt å flytte prosjektet til en server senere.
mkdir kryptovarsling && cd kryptovarsling
python3 -m venv venv
source venv/bin/activate
pip install ccxt==4.5.77 python-dotenv requests
pip freeze > requirements.txt
På Windows aktiverer du miljøet med venv\Scripts\activate i stedet for source-kommandoen. Bekreft at installasjonen fungerte ved å kjøre python3 -c “import ccxt; print(ccxt.__version__)”, som bør skrive ut versjonsnummeret uten feilmeldinger.
Steg 5: Lagre hemmeligheter i en .env-fil
Skriv aldri API-nøkler direkte i Python-filene dine. Opprett i stedet en .env-fil i prosjektmappen, og legg den til i .gitignore med det samme hvis du bruker versjonskontroll. Dette er nøyaktig den typen feil som utløste nøkkelrotasjonsvarselet etter GitHub-bruddet i mai 2026, hvor lekkede nøkler i kildekode ble et reelt angrepsspor.
BINANCE_API_KEY=din_lesekun_api_nokkel
BINANCE_API_SECRET=din_api_hemmelighet
TELEGRAM_BOT_TOKEN=123456789:AAExempelTokenHerIkkeEkte
TELEGRAM_CHAT_ID=987654321
POLL_INTERVAL_SEKUNDER=30
Chat-ID-en finner du enklest ved å sende en melding til boten din og deretter åpne api.telegram.org/bot<TOKEN>/getUpdates i nettleseren, hvor feltet chat.id vises i JSON-svaret.
Steg 6: Bygg klienten som henter kontosnapshot
Denne modulen er selve broen mot børsen. Den bruker ccxt til å hente saldo og API-status i ett samlet objekt, kalt et snapshot, som resten av systemet kan sammenligne over tid.
import os
import ccxt
from dotenv import load_dotenv
load_dotenv()
exchange = ccxt.binance({
"apiKey": os.environ["BINANCE_API_KEY"],
"secret": os.environ["BINANCE_API_SECRET"],
"enableRateLimit": True,
})
def hent_kontosnapshot():
balance = exchange.fetch_balance()
status = exchange.sapi_get_account_apirestrictions()
return {
"saldo": {m: v for m, v in balance["total"].items() if v},
"kan_handle": status.get("enableSpotAndMarginTrading"),
"kan_ta_ut": status.get("enableWithdrawals"),
"ip_begrenset": status.get("ipRestrict"),
}
Metodenavnet sapi_get_account_apirestrictions er spesifikt for Binance sitt API, dokumentert i Binance sin offisielle API-dokumentasjon. Bruker du en annen børs, sjekker du tilsvarende endepunkt i ccxt-dokumentasjonen, siden feltnavnene varierer noe mellom børser selv om ccxt gir et felles grensesnitt for selve tilkoblingen.
Legg merke til at funksjonen filtrerer bort valutaer med null saldo før den returnerer snapshotet. Dette holder datastrukturen liten og gjør sammenligningslogikken i neste steg enklere, siden du slipper å håndtere hundrevis av tomme handelspar som børsen teoretisk støtter men du aldri har eid. Ønsker du å overvåke spesifikke myntbeholdninger uansett saldo, for eksempel for å oppdage om en null-saldo plutselig får innskudd fra en ukjent kilde, kan du fjerne dette filteret og heller håndtere støyen i risikomotoren.
Steg 7: Definer risikoregler for varsling
Kjernen i systemet er logikken som sammenligner nåværende tilstand mot forrige sjekk og avgjør om noe krever et varsel. Bygg dette som en egen modul slik at du enkelt kan legge til flere regler senere.
import json
from pathlib import Path
TILSTAND_FIL = Path("siste_tilstand.json")
def last_forrige_tilstand():
if TILSTAND_FIL.exists():
return json.loads(TILSTAND_FIL.read_text())
return {}
def lagre_tilstand(tilstand):
TILSTAND_FIL.write_text(json.dumps(tilstand))
def finn_avvik(forrige, naa):
avvik = []
if forrige.get("kan_ta_ut") is False and naa.get("kan_ta_ut") is True:
avvik.append(("KRITISK", "Uttak er aktivert pa API-nokkelen"))
if forrige.get("ip_begrenset") is True and naa.get("ip_begrenset") is False:
avvik.append(("KRITISK", "IP-hviteliste er fjernet fra nokkelen"))
for mynt, belop in forrige.get("saldo", {}).items():
nytt = naa.get("saldo", {}).get(mynt, 0)
if belop and nytt < belop * 0.9:
prosent = round((1 - nytt / belop) * 100, 1)
avvik.append(("HOY", f"{mynt}-saldo falt {prosent} % siden forrige sjekk"))
return avvik
Tabellen under viser terskelverdiene denne guiden bruker som utgangspunkt. Juster prosentgrensen for saldofall etter hvor aktivt du selv handler, en aggressiv daytrader trenger en høyere terskel enn noen som kun holder langsiktig.
| Hendelsestype | Utløser | Alvorlighetsgrad | Anbefalt handling |
|---|---|---|---|
| Uttaksrettighet aktivert | Feltet for uttak endres fra av til på | Kritisk | Umiddelbar varsling, vurder å slette nøkkelen |
| IP-hviteliste fjernet | Restriksjon endres fra aktiv til inaktiv | Kritisk | Umiddelbar varsling og manuell verifisering |
| Saldo faller mer enn 10 % | Sammenligning mot forrige sjekk | Høy | Varsel, logg inn og verifiser transaksjoner |
| Ukjent handelspar i bruk | Bot handler utenfor forhåndsdefinert liste | Middels | Varsel, gjennomgå ved neste anledning |
| Gjentatte API-feil | Mer enn fem feilede kall på rad | Middels | Varsel, sjekk om nøkkelen er lekket eller utløpt |
Reglene over er et startpunkt, ikke en fasit. Handler du sjelden, kan du senke terskelen for saldofall til 5 prosent for å fange opp mindre uttak raskere. Kjører du derimot flere handelsboter parallelt med hyppige rebalanseringer, bør du heve terskelen og heller legge til en regel som sammenligner mot et glidende gjennomsnitt over de siste timene i stedet for kun forrige måling, slik at du unngår en strøm av unødvendige varsler som til slutt gjør at du slutter å lese dem.
Steg 8: Bygg Telegram-varsling
Telegram er praktisk fordi varsler kommer rett til telefonen din uten at du trenger å holde en app åpen. Biblioteket requests er alt du trenger, siden Telegram sitt Bot API er en vanlig REST-tjeneste beskrevet i den offisielle dokumentasjonen. Ønsker du mer avanserte funksjoner som knapper for å bekrefte handlinger direkte fra varselet, kan du senere bytte til python-telegram-bot-rammeverket.
import os
import requests
def send_varsel(melding, alvorlighet="INFO"):
token = os.environ["TELEGRAM_BOT_TOKEN"]
chat_id = os.environ["TELEGRAM_CHAT_ID"]
url = f"https://api.telegram.org/bot{token}/sendMessage"
tekst = f"[{alvorlighet}] {melding}"
svar = requests.post(url, json={"chat_id": chat_id, "text": tekst}, timeout=10)
svar.raise_for_status()
Test funksjonen isolert før du kobler den til resten av systemet. Kjør python3 -c "from telegram_alert import send_varsel; send_varsel('Testmelding', 'INFO')" og bekreft at meldingen dukker opp i Telegram-chatten din i løpet av et par sekunder.
Vurder også å begrense hvor mange varsler som kan sendes innenfor et kort tidsrom. Telegram har egne rate-limits per bot, og et feilkonfigurert system som havner i en løkke og sender hundrevis av meldinger på sekunder kan bli midlertidig blokkert av Telegram selv. En enkel løsning er å legge til en kort pause, eller å samle flere avvik i én melding i stedet for å sende én melding per funn hvis mange avvik oppdages samtidig.
Steg 9: Koble alt sammen i en overvåkingsløkke
Nå setter du sammen klienten, risikomotoren og varslingen i en løkke som kjører kontinuerlig. Løkken henter et snapshot, sammenligner mot forrige, sender varsler for eventuelle avvik, og lagrer den nye tilstanden før den venter til neste runde.
import time
from exchange_client import hent_kontosnapshot
from risk_engine import last_forrige_tilstand, lagre_tilstand, finn_avvik
from telegram_alert import send_varsel
POLL_SEKUNDER = 30
def kjor():
forrige = last_forrige_tilstand()
send_varsel("Overvakingssystem startet", "INFO")
while True:
try:
naa = hent_kontosnapshot()
for alvorlighet, melding in finn_avvik(forrige, naa):
send_varsel(melding, alvorlighet)
lagre_tilstand(naa)
forrige = naa
except Exception as feil:
send_varsel(f"Overvakingsfeil: {feil}", "MIDDELS")
time.sleep(POLL_SEKUNDER)
if __name__ == "__main__":
kjor()
Legg merke til try/except-blokken. Uten den vil systemet stoppe helt stille hvis børsens API er nede eller returnerer en uventet feil, og da mister du nettopp den overvåkingen du bygde systemet for å ha.
Det er også lurt å skrive alle hendelser til en enkel loggfil parallelt med Telegram-varslene, ved å legge til Pythons innebygde logging-modul øverst i filen. En loggfil gir deg et fullstendig, søkbart spor av hva systemet har observert, noe som er verdifullt både hvis du trenger å dokumentere en hendelse overfor børsens support, og hvis du senere vil analysere mønstre i egen handelsaktivitet over flere måneder.
Steg 10: Test systemet med simulerte hendelser
Før du stoler på systemet i praksis, må du bevisst trigge hver varselregel. Den enkleste måten er å redigere siste_tilstand.json manuelt mellom to kjøringer, for eksempel ved å sette kan_ta_ut til false og deretter kjøre systemet på nytt slik at neste ekte snapshot vises som en endring til true hvis nøkkelen faktisk har uttak aktivert.
Test også hva som skjer hvis internettforbindelsen brytes midt i et kall, og hva som skjer hvis du oppgir feil API-nøkkel med vilje. Systemet bør sende et varsel om feilen i stedet for å krasje stille. Kjør denne testrunden minst to ganger med noen timers mellomrom for å bekrefte at løkken faktisk kjører stabilt over tid og ikke bare i det første minuttet.
Før en egen sjekkliste for testrunden og kryss av hvert punkt etter hvert: uttak aktivert gir kritisk varsel, IP-hviteliste fjernet gir kritisk varsel, saldofall over terskel gir høyt varsel, nettverksfeil gir eget feilvarsel, og en vellykket oppstart gir infomeldingen i Telegram. Har du krysset av alle fem, er systemet klart for produksjon. Mangler ett eller flere, gå tilbake til risikomotoren i steg 7 og feilsøk logikken der før du går videre.
Steg 11: Legg til en nødstopp-funksjon
Et rent varslingssystem forteller deg at noe er galt, men du vil ofte også kunne reagere umiddelbart. De fleste børser tilbyr et eget API-endepunkt eller et administrasjonspanel for å slette en API-nøkkel direkte. Legg inn en kommando i Telegram-boten din som lar deg trigge denne handlingen manuelt fra telefonen, uten å måtte logge inn på børsen fra en mulig kompromittert enhet.
Vær bevisst på at en fullautomatisk nødstopp som selv sletter nøkkelen ved første avvik kan skape falske positiver som låser deg selv ute midt i en legitim handel. En tryggere tilnærming er en to-trinns bekreftelse: systemet sender varselet umiddelbart, men den faktiske slettingen krever at du trykker en bekreftelsesknapp i Telegram-chatten innen et par minutter.
Et enkelt grep er å lage en egen liten kommandolinje-funksjon som kaller børsens endepunkt for å slette eller deaktivere en spesifikk API-nøkkel basert på nøkkel-ID-en. Test denne funksjonen på en nøkkel du uansett planla å slette, slik at du vet nøyaktig hvordan den oppfører seg før du er avhengig av den i en reell krisesituasjon klokken tre om natten.
Steg 12: Kjør systemet i produksjon med systemd
Skal systemet være til nytte, må det kjøre kontinuerlig, også etter en omstart av serveren. På Linux er systemd den enkleste måten å oppnå dette på uten ekstra avhengigheter.
[Unit]
Description=Kryptoborsvarsling
After=network.target
[Service]
WorkingDirectory=/opt/kryptovarsling
ExecStart=/opt/kryptovarsling/venv/bin/python overvaking.py
Restart=always
RestartSec=10
EnvironmentFile=/opt/kryptovarsling/.env
[Install]
WantedBy=multi-user.target
Lagre filen som /etc/systemd/system/kryptovarsling.service, kjør sudo systemctl daemon-reload og deretter sudo systemctl enable --now kryptovarsling. Sjekk status med systemctl status kryptovarsling, som bør vise active (running) og loggutskrifter fra Python-programmet.
5 vanlige fallgruver du må unngå
De fleste feilene som svekker et overvåkingssystem som dette, dukker ikke opp under selve oppsettet. De sniker seg inn over tid, etter hvert som du gjør små snarveier for å spare tid eller irritasjon. Her er de fem feilene vi ser oftest hos brukere som bygger tilsvarende system, og hvorfor hver av dem kan koste deg dyrt.
- Gjenbruk av handelsnøkkel til overvåking. Hvis overvåkingsnøkkelen også kan handle eller ta ut midler, mister du hele poenget med å isolere risiko. En kompromittert overvåkingsmaskin blir da like farlig som en kompromittert handelsbot.
- Hemmeligheter lagret i klartekst i kildekoden. Selv et privat GitHub-repo kan lekke, slik GitHub-bruddet i mai 2026 illustrerte. Bruk alltid .env-filer utenfor versjonskontroll.
- For lav pollingfrekvens. Sjekker du kontoen hvert 30. minutt i stedet for hvert 30. sekund, kan et angrep rekke å fullføres lenge før varselet når deg. Balanser frekvensen mot børsens rate-limits.
- Ingen feilhåndtering rundt nettverksfeil. Et program som krasjer stille ved første tidsavbrudd gir deg falsk trygghet, siden du tror overvåkingen kjører når den i realiteten har stoppet timevis tidligere.
- Å stole på varsling alene uten IP-hviteliste og lesebegrensning. Overvåking oppdager problemer raskt, men den forhindrer dem ikke. De grunnleggende tiltakene fra steg 2 og 3 er fortsatt førstelinjeforsvaret.
Feilsøking: 8 vanlige problemer og løsninger
Selv med koden fra denne guiden kopiert nøyaktig, vil du sannsynligvis støte på minst ett av problemene under før systemet kjører feilfritt. Det er normalt, og de fleste løsningene tar under fem minutter når du vet hva du leter etter.
- Problem: ccxt kaster en autentiseringsfeil ved oppstart. Løsning: Sjekk at API-nøkkel og hemmelighet er kopiert uten mellomrom, og at nøkkelen faktisk er aktivert hos børsen, ikke bare opprettet.
- Problem: sapi_get_account_apirestrictions gir 403-feil. Løsning: Dette endepunktet krever noen ganger at nøkkelen har "Enable Reading"-tillatelsen eksplisitt aktivert, ikke bare generell lesetilgang. Sjekk innstillingene på nytt.
- Problem: Telegram-varsler kommer aldri frem. Løsning: Bekreft at du har sendt minst én melding til boten manuelt først, ellers har ikke chat-ID-en blitt generert ennå på Telegrams side.
- Problem: Systemet rapporterer falske saldo-avvik hver gang du selv handler. Løsning: Dette er forventet oppførsel for aktive tradere. Hev terskelverdien i risikoregelen, eller legg til et unntak for kjente handelstider.
- Problem: systemd-tjenesten stopper rett etter oppstart. Løsning: Kjør journalctl -u kryptovarsling -n 50 for å se feilmeldingen, som oftest skyldes feil filsti i ExecStart eller manglende rettigheter på .env-filen.
- Problem: Rate limit-feil fra børsen. Løsning: Øk POLL_SEKUNDER til minst 20 til 30 sekunder, og bekreft at enableRateLimit er satt til True i ccxt-konfigurasjonen.
- Problem: IP-adressen endrer seg og nøkkelen slutter å virke. Løsning: Vurder en statisk IP fra internettleverandøren, en liten VPS med fast adresse, eller sett opp et eget varsel som overvåker din egen offentlige IP mot en tjeneste som viser gjeldende adresse.
- Problem: JSON-filen med tilstand blir korrupt etter en brå omstart. Løsning: Skriv til en midlertidig fil og bytt navn atomisk i stedet for å skrive direkte til siste_tilstand.json, slik at en avbrutt skriveoperasjon ikke etterlater en ugyldig fil.
Avanserte tips for et mer robust system
Når grunnsystemet fungerer stabilt, kan du bygge videre på flere fronter. Legg til støtte for flere børser samtidig ved å instansiere flere ccxt-klienter i en liste og kjøre samme sjekk-løkke for hver av dem, slik at ett program dekker både Binance, Kraken og andre plattformer du bruker.
Vurder å logge alle snapshots til en enkel SQLite-database i stedet for kun én JSON-fil. Det gir deg historikk du kan analysere i etterkant, og gjør det mulig å oppdage gradvise mønstre, som en saldo som sniker seg nedover litt om gangen, i stedet for kun brå endringer. Du kan også koble systemet til verktøyene fra vår guide om MEV-beskyttelse hvis du også handler direkte på kjeden og ikke bare på en sentralisert børs.
Et annet steg opp er å kryptere selve .env-filen i hvile med et verktøy som age eller gpg, og kun dekryptere den midlertidig når tjenesten starter. Dette beskytter mot scenarioet hvor noen får lesetilgang til disken uten å kunne kjøre koden direkte, for eksempel gjennom en feilkonfigurert backup som havner et sted den ikke skulle. Kombinert med IP-hviteliste og lesebegrensning fra tidligere steg bygger du dermed flere uavhengige forsvarslinjer i stedet for å stole på én enkelt kontroll.
For enda raskere reaksjonstid kan du bytte fra periodisk polling til en kombinasjon av polling og børsens WebSocket-strømmer der det er tilgjengelig, siden en WebSocket-tilkobling kan varsle deg om enkelte hendelser i sanntid i stedet for å vente på neste rundes sjekk. Til slutt bør du sette opp en enkel "heartbeat"-melding, for eksempel en daglig statusmelding klokken ni om morgenen, slik at du raskt merker det hvis selve overvåkingssystemet har sluttet å kjøre, ikke bare hvis kontoen din blir angrepet.
Hvis du deler kontoer med familie eller driver et lite team, kan du utvide Telegram-varslingen til en gruppechat i stedet for en privat chat, slik at flere personer ser samme varsel samtidig. Dette reduserer risikoen for at et kritisk varsel blir liggende ulest fordi én person var utilgjengelig, og det gir en naturlig logg over hvem som reagerte på hva og når, noe som er nyttig hvis dere senere trenger å rekonstruere hendelsesforløpet etter en reell sikkerhetshendelse.
Komplett fungerende prosjekt: alle filene samlet
Med alle stegene fullført skal prosjektmappen din se slik ut, klar til å kopieres til en server eller pakkes for backup.
kryptovarsling/
├── .env (hemmeligheter, aldri i versjonskontroll)
├── .gitignore (inneholder .env og siste_tilstand.json)
├── exchange_client.py (steg 6, henter kontosnapshot via ccxt)
├── risk_engine.py (steg 7, sammenligner tilstand og finner avvik)
├── telegram_alert.py (steg 8, sender varsler via Telegram Bot API)
├── overvaking.py (steg 9, hovedløkken som binder alt sammen)
├── requirements.txt (ccxt, python-dotenv, requests)
├── siste_tilstand.json (genereres automatisk ved første kjøring)
└── kryptovarsling.service (steg 12, systemd-tjenestefil)
Kjør hele systemet manuelt en siste gang med python3 overvaking.py før du overlater det til systemd, og bekreft at du mottar oppstartsmeldingen "Overvakingssystem startet" i Telegram-chatten. Fra dette punktet har du et selvstendig sikkerhetslag som fungerer uavhengig av hva børsen selv velger å varsle deg om, og som kan tilpasses etter hvert som du legger til flere børser eller nye risikoregler.
Den reelle kostnaden ved å drifte dette videre er lav. Kjører du på maskinvare du uansett eier, er den løpende kostnaden i praksis null utover strømforbruket til en Raspberry Pi, som typisk ligger på noen få kroner i måneden. Velger du i stedet en liten skyserver med fast IP-adresse for å slippe unna dynamisk IP hjemmefra, ligger prisen normalt på et lavt engangsbeløp per måned hos de fleste leverandører, en beskjeden pris sammenlignet med de flersifrede millionbeløpene enkelthendelser har kostet ofre i 2025 og 2026.
Husk at dette systemet er ett lag i en større sikkerhetsstrategi. Kombiner det gjerne med tiltak mot wallet-drainere hvis du også bruker en selvforvaltet lommebok, og med jevnlig verifisering hvis noe av kapitalen din ligger i stablecoins, som beskrevet i vår gjennomgang av hvordan du verifiserer stablecoin-reserver.
Ofte stilte spørsmål
Her samler vi de spørsmålene som dukker oftest opp fra lesere som har satt opp et lignende overvåkingssystem for egen kryptobørs-konto.
Er en skrivebeskyttet API-nøkkel helt trygg å bruke?
Ingen nøkkel er hundre prosent risikofri, men en nøkkel uten handels- og uttaksrettigheter reduserer skadepotensialet kraftig. En angriper som får tak i en ren lesenøkkel kan se saldoen din, ordrehistorikk og kontoinnstillinger, men kan ikke flytte midlene dine ut av kontoen eller legge inn ordre. Kombinert med IP-hviteliste blir en lekket lesenøkkel i praksis ubrukelig for noen andre enn deg selv.
Hvor ofte bør jeg rotere API-nøkler?
En vanlig tommelfingerregel er hver 60 til 90 dager for aktivt brukte nøkler, samt umiddelbart etter enhver hendelse hvor kildekode, en tredjeparts-tjeneste eller en maskin med tilgang til nøkkelen kan ha vært eksponert. Datoen du noterte i steg 2 gjør denne rutinen enkel å følge, siden du slipper å lete gjennom børsens grensesnitt for å finne ut når en nøkkel egentlig ble opprettet.
Kan jeg bruke dette systemet med flere børser samtidig?
Ja. Fordi ccxt tilbyr et felles grensesnitt mot over hundre børser, kan du instansiere flere klienter, en per børs, og kjøre samme risikologikk for hver av dem i samme program. Husk at feltnavnene for API-restriksjoner varierer noe fra børs til børs, så du må tilpasse funksjonen i steg 6 for hver plattform du kobler til.
Koster det noe å kjøre systemet 24/7?
Selve koden er gratis. Kjører du det på en eksisterende PC eller Raspberry Pi koster det ingenting utover strøm. En liten skyserver med fast IP-adresse koster typisk noen få dollar i måneden.
Er IP-hviteliste nødvendig hvis jeg allerede har topartsverifisering?
Ja. Topartsverifisering beskytter innloggingen til selve nettsiden, men API-nøkler går utenom denne innloggingsflyten. En lekket API-nøkkel uten IP-begrensning kan brukes direkte fra hvilken som helst maskin i verden, uten at 2FA noen gang trigges, nettopp fordi API-kall autentiseres med nøkkelen og hemmeligheten alene.
Hva gjør jeg hvis jeg mister tilgang til Telegram-boten min?
Opprett en ny bot via BotFather, oppdater token og chat-ID i .env-filen, og start systemet på nytt. Vurder også en sekundær varslingskanal, som e-post via SMTP, som reserveløsning hvis Telegram er nede.
Bryter dette børsens brukervilkår?
Nei, å lese egen kontoinformasjon via en offisiell, dokumentert API er en støttet bruksmåte hos alle større børser. Sjekk likevel alltid gjeldende rate-limits og vilkår hos din spesifikke børs før du setter opp automatisert polling, siden noen plattformer krever at du registrerer applikasjonen din eller holder deg under et bestemt antall kall per minutt.
Hva om børsen selv har nedetid eller vedlikehold?
Systemet er bygget med feilhåndtering som fanger opp nettverks- og API-feil, sender et eget varsel om selve overvåkingsfeilen, og fortsetter løkken automatisk i stedet for å stoppe permanent. Du vil dermed få beskjed om at overvåkingen er midlertidig blind, i stedet for å anta feilaktig at alt er normalt bare fordi du ikke har mottatt noen kritiske varsler.




