Vad är LLMjacking? Den snabba tillväxten av stora språkmodeller har gett hackare ett nytt och lönsamt sätt att attackera. LLMjacking, som är den olagliga kapningen av självhostade LLM-infrastruktur för dåliga ändamål, är ett omedelbart hot. ," en komplicerad plan som söker på internet för exponerade LLM och Model Context Protocol-ändpunkter, tar kontroll över dem och säljer de stulna resurserna på mörka webbmarknader.Det har varit mer än 35 000 attack sessioner, med i genomsnitt 972 attacker per dag. Operation Bizarre Bazaar Denna artikel går in i stor detalj om hur LLMjacking fungerar, vilka svagheter den utnyttjar, och viktigast av allt, de kodnivålösningar du kan använda just nu för att skydda dina självhostade LLMs från detta växande hot. Anatomi av en LLMjacking Attack LLMjacking är inte bara en enstaka exploit, utan snarare en komplex, flerstegsoperation som kännetecknas av ett systematiskt tillvägagångssätt. Steg 1: Skanna Bots som fungerar automatiskt letar alltid efter öppna portar och tjänster som är kopplade till populära självhostade LLM-ramverk på internet. 
 
 
 
 Standardporten för Ollama instanser är 11434.Det finns inga säkerhetsåtgärder på plats. Du kan komma åt OpenAI-kompatibla APIs via webben.Dessa inkluderar de som är gjorda med LiteLLM eller FastChat, som fungerar på standardutvecklingsportar som 8000. Oautentiserade modellkontextprotokollservrar gör det lättare för AI-agenter att arbeta med olika verktyg och datakällor genom att ge dem ett standard sätt att göra det. Steg 2: Validering När ett potentiellt mål har identifierats, utvärderar enhetens infrastruktur, till exempel "silver.inc", slutpunkten inom 8 timmar eller mindre. 
 
 
 
 
 Bygg en omfattande inventering av de befintliga modellerna tillsammans med deras respektive funktionaliteter. Utvärdera användbarheten och snabbheten i svaren. Kontrollera om slutpunkten implementerar räntebegränsning eller har ytterligare säkerhetsåtgärder. Utforska potentiella vägar för lateral navigering inom interna system. Steg 3: Monetarisering Validerade slutpunkter läggs till i "The Unified LLM API Gateway", en marknadsplats som erbjuder tillgång till över 30 olika LLM-program – alla körs på kapad infrastruktur. Denna plattform är värd på bulletproof-infrastruktur i Nederländerna och marknadsförs via Discord och Telegram-kanaler. De ekonomiska och säkerhetsmässiga konsekvenserna av en LLMjacking-attack är allvarliga. Att köra slutsatser på stora modeller kan snabbt lägga till stora molnfakturor på grund av de höga kostnaderna för databehandling. Dessutom, om den kapade LLM kan komma till känsliga interna data genom hämtningsförstärkt generering eller funktionssamtal, är chansen att data blir stulen mycket hög. Problemets källa: Utplaceringar som är osäkra som standard Den främsta anledningen till att LLMjacking fungerar så bra är att många självhostade LLM-ramverk är gjorda för lokal, enanvändarutveckling och inte är säkra som standard för produktions- eller web-exponerade miljöer. Ta en titt på Ollama, som är ett av de bästa verktygen för att köra LLM på din egen dator. Ollama är inställt så att du inte behöver logga in när du går till http://localhost:11434. Detta är vettigt för lokal utveckling, men så snart den porten är öppen för internet, antingen avsiktligt eller av misstag, blir det ett stort säkerhetshål. Den goda nyheten är att dessa problem kan åtgärdas om du gör saker på rätt sätt.I nästa del kommer vi att prata om de specifika saker du kan göra för att skydda din självhostade LLM infrastruktur. En användbar guide för att göra din självhostade LLM säkrare Du behöver använda ett försvar-i-djupet tillvägagångssätt för att skydda din självhostade LLM-infrastruktur. Du kan inte bara sätta en brandvägg framför din server; du måste lägga till säkerhetskontroller till varje lager av stacken. Visa aldrig råa slutpunkter: kraften i omvänd proxy Det viktigaste du kan göra för att hålla din självhostade LLM säker är att aldrig låta den råa, oautentiserade slutpunkten ses av internet. Du bör alltid sätta en omvänd proxy, som Nginx eller Caddy, framför din LLM-tjänst istället. Detta lägger till ett viktigt lager av säkerhet, såsom autentisering, TLS-kryptering och räntebegränsning. Hur man skyddar Ollama med Nginx och API-nyckelautentisering Ollama är ett bra sätt att köra LLM på din egen dator, men du bör inte lägga det på webben.Detta är hur du använder Nginx för att lägga till ett lager av API-nyckelautentisering till din Ollama-instans. Till att börja med måste du skapa en fil för att hålla dina giltiga API-nycklar i. I det här fallet kommer vi att kalla den apikeys.txt: # apikeys.txt
my-secret-api-key-1
another-valid-key
 Därefter måste du konfigurera Nginx för att fungera som en omvänd proxy och kontrollera för en giltig API-nyckel i behörighetsrubriken för inkommande förfrågningar. 
# /etc/nginx/sites-available/ollama.conf A map to see if the API key you gave is valid.

    default 0; "Bearer my-secret-api-key-1" 1; "Bearer another-valid-key" 1;

server { listen 80; server_name your-llm-domain.com; 

    location / {
        # If the API key is not valid, return 401 'Unauthorized' and reject requests.

        # Proxy requests to the Ollama backend proxy_pass http://localhost:11434; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme;
        
        # Raise the timeout for inference requests that take a long time to process. proxy_read_timeout 300s; proxy_connect_timeout 75s; 
    }
}
 Detta gör två viktiga saker: 
 
 
 Den konstruerar en variabel som kallas $api_key_valid med kartdirektivet. Denna variabel ställs in på 1 baserat på auktoriseringsrubriken som har en giltig nyckel; annars ställs den in på 0. Den tittar på värdet $api_key_valid i platsblocket. Om begäran är 0, betyder ett 401 Obehörigt fel att det inte är tillåtet. Den här inställningen innebär att varje begäran till din Ollama-instans måste innehålla en giltig API-nyckel i auktoriseringsrubriken: curl http://your-llm-domain.com/api/generate \-H "Authorization: Bearer my-secret-api-key-1" \
-d '{ "model": "llama2", "prompt": "Why is the sky blue?" }'
 Se till att MCP är säker Modellkontextprotokollet är ett bra sätt att göra AI-agenter, men det gör dem också mindre säkra. Angripare kan komma in i dina LLMs och alla verktyg eller API som MCP-servern är inställd på att använda om den inte är skyddad. Isolering på nätverksnivå Din MCP-server bör inte vara direkt ansluten till det offentliga internet när det är möjligt.Om endast ett litet antal klienter behöver kunna komma åt den, använd en VPN eller andra nätverkskontroller för att begränsa åtkomsten. Använd säkerhetsgrupper eller nätverkspolicyer för att se till att endast godkända tjänster kan prata med din MCP-server när du distribuerar den i molnet. Autentisering och auktorisering MCP säger inte vilken autentiseringsmetod du ska använda, så du måste välja en själv. Du bör åtminstone kräva en unik API-nyckel som inte kan gissa för varje begäran. Om du behöver hålla saker mer privata, tänk på att använda en starkare autentiseringsmetod som OAuth 2.0 eller ömsesidig TLS. Du bör också använda en fingrå tillståndsmodell för att styra vilka klienter som kan använda vilka verktyg. Till exempel kan du ha en "läsbar" klient som bara kan använda verktyg som ger dig information och en "läs-skriv" klient som kan använda verktyg som ändrar data. Rengöring av ingång och utgång Du bör aldrig lita på input från klienten, precis som du inte bör lita på input från någon annan webbapp. För att stoppa injektionsattacker, bör du noggrant rengöra och kontrollera alla input till din MCP-server. Att göra räntan begränsa arbetet bra Att begränsa antalet förfrågningar som en klient kan göra inom en angiven tidsram är ett bra sätt att skydda mot attacker med avslag på service och missbruk av resurser som inträffade i Operation Bizarre Bazaar. Det finns olika strategier för att genomföra räntebegränsning: 
 
 
 
 Per-IP Rate Limiting: Reglera volymen av förfrågningar som härrör från en enskild IP-adress.Även om det är enkelt att implementera, kan det visa sig ineffektivt mot distribuerade attacker och kan orättvist straffa användare som arbetar bakom en NAT. Genomförandet av räntebegränsning baserat på API-nyckeln visar sig vara en mer effektiv strategi, vilket garanterar en rättvis fördelning av resurser mellan användare och underlättar identifieringen och blockeringen av missbrukande individer. Tokenbaserad räntebegränsning: I samband med LLMs är det generellt mer logiskt att genomföra räntebegränsning baserat på mängden tokens som produceras, i motsats till frekvensen av förfrågningar. I ett produktionssystem skulle du vilja använda en mer robust och skalbar lösning, till exempel Redis med glidande fönsterräknare, eller ett dedikerat prisbegränsande bibliotek som flask-limiter. Ytterligare bästa praxis för säkerhet Förutom de primära försvar som beskrivits tidigare, överväga att genomföra följande säkerhetsåtgärder: Övervaka och dokumentera alla åtkomstaktiviteter. Håll omfattande register över alla API-förfrågningar, dokumentera den API-nyckel som används, den ursprungliga IP-adressen, den begärda modellen och det totala antalet genererade tokens.Detta kommer att hjälpa till att identifiera ovanligt beteende och undersöka potentiella säkerhetsproblem. Rutinmässiga säkerhetsbedömningar Använd verktyg som nmap eller molnbaserade säkerhetsskannrar för att identifiera felkonfigurerade slutpunkter innan potentiellt utnyttjande av angripare. Fastställa användningsbegränsningar Förutom att implementera räntebegränsning är det lämpligt att fastställa strikta användningsgränser för varje API-nyckel. Till exempel är det möjligt att tilldela en gräns på 1 miljon tokens per nyckel på månadsbasis. Håll din programvara uppdaterad Se till att hålla dina LLM-ramverk, omvänd proxy och operativsystem uppdaterade hela tiden för att korrigera kända sårbarheter. Slutsats: Det är dags att sätta säkerheten först. Ökningen av LLMjacking bör väcka AI-gemenskapen.Vi kan inte längre ha råd att ignorera säkerhet.Vi behöver fortsätta att driva gränserna för vad AI kan göra, men vi behöver också sätta säkerhet först och göra system som kan motstå attacker. Operation Bizarre Bazaar-kampanjen visar att angripare aktivt letar efter och använder svag LLM-infrastruktur i stor skala.Den goda nyheten är att försvaret i den här artikeln - att sätta din LLM bakom en omvänd proxy, använda stark autentisering och auktorisering och genomdriva strikt räntebegränsning - är alla välkända säkerhetsåtgärder som inte tar mycket arbete att sätta in. Vi, de ingenjörer och utvecklare som arbetar på frontlinjen, är de som behöver använda dem. Du kan hålla din AI-infrastruktur säker och säker genom att ta dessa steg idag. De kommer också att skydda ditt företag från det växande hotet av LLMjacking.

This story contains new, firsthand information uncovered by the writer.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Read My Stories

Det här ljudet är producerat på berättelsens originalspråk!

LLMjacking uppstår som ett kostsamt nytt hot mot självhostad AI-infrastruktur

About Author

KOMMENTARER

HÄNG TAGGAR

DENNA ARTIKEL PRESENTERAS I

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps