IB Gateway und TWS absichern: Ports, Trusted IPs, Benutzer.

Wer IB Gateway oder TWS absichern will, muss vor allem den API-Port schützen: Er ist eine unverschlüsselte TCP-Verbindung ohne Passwort, und wer ihn erreicht und zugelassen wird, arbeitet mit den Rechten des angemeldeten Benutzers. Für den Zugriff von anderen Rechnern ist es deshalb meist am saubersten, „Allow connection from localhost only“ eingeschaltet zu lassen und den Bot entweder auf demselben Rechner zu betreiben oder über einen SSH-Tunnel beziehungsweise ein privates Netz anzubinden. Trusted IPs akzeptieren laut Interactive Brokers (IBKR) nur einzelne Adressen, keine Subnetze. Dieser Leitfaden zeigt, Stand Oktober 2026, welche Ports gelten, wie Sie Trusted IPs, Docker-Port-Mapping, Read-Only API und Client-IDs einsetzen und warum ein eigener Benutzername für den Bot Sitzungskonflikte und unnötige Rechte vermeidet. Er richtet sich an private Trader, Selbstentwickler und Teams mit Bots auf VPS, in Docker oder im Heimnetz.

Wie verbindet sich ein Bot mit TWS oder IB Gateway?

Die TWS API ist keine Web-Schnittstelle im Internet, sondern ein lokaler Dienst: TWS oder IB Gateway öffnen einen TCP-Port und arbeiten als Server, Ihr Programm verbindet sich als Client. Für die Verbindung braucht der Client drei Angaben: die IP-Adresse des Rechners, auf dem TWS oder Gateway laufen, den Socket-Port und eine Client-ID. TWS oder Gateway reichen die Anfragen an IBKR weiter, wo Sie bereits mit Passwort und Zwei-Faktor-Bestätigung angemeldet sind.

Genau daraus ergibt sich das Sicherheitsmodell. Die Anmeldung schützt den Weg zu IBKR, nicht den lokalen API-Port. Wer den Port erreicht und eine Verbindung aufbauen darf, kann Konto- und Positionsdaten abfragen und, sofern die API Orders zulässt, Orders senden. Ein Passwort oder API-Schlüssel gibt es an dieser Stelle nicht; die Zugangskontrolle besteht nur aus Einstellungen in TWS oder Gateway und aus dem Netz drumherum.

Die Standard-Ports laut IBKR-Dokumentation:

Die Ports sind änderbar, und auf einem Rechner können mehrere Instanzen parallel laufen, wenn jede einen eigenen Port nutzt. Jede Sitzung nimmt bis zu 32 Client-Anwendungen gleichzeitig an, unterschieden über die Client-ID. Scheitert schon der Verbindungsaufbau, meldet die API den Fehler 502. Er kommt laut IBKR vom Betriebssystem und taucht deshalb nicht in den TWS-Logs auf. Typische Ursachen: deaktivierte API, falscher Port, Firewall oder fehlende Trusted IP.

IB Gateway remote verbinden: localhost und Trusted IPs setzen.

Alle relevanten Schalter liegen in TWS unter Global Configuration → API → Settings, im IB Gateway unter Configure → Settings → API → Settings. Damit überhaupt Verbindungen angenommen werden, muss „Enable ActiveX and Socket Clients“ aktiv sein, und der „Socket Port“ muss zu dem Port passen, den Ihr Programm verwendet. Die Option „Allow connection from localhost only“ entscheidet, ob Verbindungen von anderen Rechnern ankommen dürfen. Ist sie aktiv, kommen nur Verbindungen vom eigenen Rechner an; Einträge unter Trusted IPs ignoriert TWS dann laut IBKR.

Für eine Verbindung von einem anderen Rechner beschreibt IBKR diesen Weg: „Allow connection from localhost only“ abwählen, unter „Trusted IPs“ auf „Create“ klicken und die Adresse eintragen, die TWS im Dialog „Accept incoming connection attempt from …“ anzeigt. Zwei Details sind wichtig. Erstens akzeptiert die Liste nur einzelne IP-Adressen, keine Subnetze wie /27 oder /28. Wechselnde Cluster-Knoten müssen einzeln eingetragen werden. Zweitens sieht TWS die Adresse, die nach einer Adressumsetzung (NAT) ankommt. IBKR nennt als Ursache für Fehler 502 ausdrücklich eine fehlende Router-IP in den Trusted IPs. Über das Internet ist das die öffentliche Adresse des Anschlusses, bei Docker oft eine Adresse des Container-Netzes.

Standardmäßig nimmt TWS API-Verbindungen nicht automatisch an. IBKR beschreibt dafür einen Dialog, in dem jemand die Verbindung bestätigen muss, und zugleich, dass nicht vertrauenswürdige IPs ohne Rückfrage abgewiesen werden. Automatisch angenommen werden nur der lokale Rechner und eingetragene Trusted IPs, wenn das so konfiguriert ist. Ein unbeaufsichtigter Bot muss also über localhost oder eine Trusted IP kommen. Einen Dialog für eine unbekannte Adresse lehnen Sie ab.

Den Port zu ändern, etwa von 4001 auf eine fünfstellige Zahl, hält automatisierte Scans kurz auf, ersetzt aber keine Zugangskontrolle. Wichtiger ist, Live- und Paper-Port im Bot fest an die Umgebung zu binden, damit ein Testlauf nicht versehentlich am Live-Port landet.

Warum der API-Socket nicht ins Internet gehört: Tunnel und privates Netz.

Trusted IPs sind ein Adressfilter, keine Anmeldung. Die Betreiber des verbreiteten Projekts gnzsnz/ib-gateway-docker beschreiben das Protokoll als unverschlüsselten, nicht authentifizierten TCP-Socket: Ist der Port im Netz offen, kann jedes Gerät in diesem Netz über das Gateway auf das Konto zugreifen. Alles, was über die Leitung geht, also Orders, Positionen und Kontostände, ist im Klartext lesbar und auf dem Weg veränderbar. Dazu kommt: Private Anschlüsse bekommen oft wechselnde Adressen, manche Provider teilen eine öffentliche Adresse zwischen vielen Kunden. Eine eingetragene IP kann so später zu einem fremden Anschluss gehören.

Daraus folgen drei Bauformen, geordnet nach Aufwand:

• Bot und Gateway auf demselben Rechner: Der Bot verbindet sich mit 127.0.0.1, „Allow connection from localhost only“ bleibt an, der Port ist von außen nicht erreichbar. Für die meisten privaten Setups die einfachste Lösung.
• SSH-Tunnel: Gateway und Bot laufen auf verschiedenen Rechnern, die Verbindung läuft aber verschlüsselt durch SSH (Secure Shell). Auf dem Gateway-Server bleibt localhost-only aktiv, denn aus Sicht des Gateways kommt die Verbindung vom lokalen Rechner. Nach außen ist nur der SSH-Port offen, idealerweise nur mit Schlüssel-Anmeldung.
• Privates Netz oder VPN: Beide Rechner hängen in einem verschlüsselten privaten Netz, etwa über WireGuard. Dann tragen Sie die VPN-Adresse des Bot-Rechners als Trusted IP ein und lassen den API-Port in der Firewall nur auf der VPN-Schnittstelle zu.

Ein Tunnel zum Paper-Port eines entfernten Gateways sieht etwa so aus; der Bot verbindet sich danach lokal mit 127.0.0.1 und Port 4002:

ssh -N -o ServerAliveInterval=20 -L 4002:127.0.0.1:4002 trader@gateway-server

Ein weiterer Grund, den Kreis der Clients klein zu halten: Seit TWS API 10.44 kann ein Client über die API auch Einstellungen von TWS ändern, und zwar zu Orders, Precautions und API-Einstellungen. Voraussetzung ist laut IBKR, dass „Read-Only API“ vorher manuell in der Oberfläche abgeschaltet wurde. Die zugehörige Datenstruktur enthält auch die Felder für localhost-only und Trusted IPs. Ein Client mit Schreibzugriff ist damit eher Administrator als Datenabnehmer.

Docker und VPS: Port-Mapping und Images prüfen.

In Docker steckt die häufigste Falle im Port-Mapping. Laut Docker-Dokumentation ist das Veröffentlichen von Container-Ports standardmäßig unsicher: Ohne Adressangabe veröffentlicht Docker einen Port auf allen Adressen des Hosts, für IPv4 und IPv6. Unter Linux kommt hinzu, dass Docker veröffentlichte Ports an der Firewall ufw vorbeileitet, weil die Pakete umgeleitet werden, bevor ufw-Regeln greifen. Wer den API-Port in ufw sperrt und im Compose-File nur „4001:4003“ schreibt, hat ihn trotzdem offen.

Die Gegenmaßnahme ist eine Bindung an die Loopback-Adresse des Hosts, wie sie das Beispiel von gnzsnz/ib-gateway-docker standardmäßig verwendet:

ports:
  - "127.0.0.1:4001:4003"
  - "127.0.0.1:4002:4004"
  - "127.0.0.1:5900:5900"

Noch enger ist ein internes Docker-Netz ohne veröffentlichte Ports: Der Bot-Container erreicht das Gateway dann über den Dienstnamen, von außen gibt es keinen Weg hinein. Docker weist außerdem darauf hin, dass in Versionen vor 28.0.0 Rechner im selben Netzsegment auch auf localhost veröffentlichte Ports erreichen konnten. Ein aktueller Docker-Stand gehört deshalb zur Absicherung dazu.

Beim Image selbst lohnt ein zweiter Blick. gnzsnz/ib-gateway-docker nimmt API-Verbindungen im Container mit dem Werkzeug socat entgegen und reicht sie von localhost an das Gateway weiter. Aus Sicht des Gateways kommen damit alle Verbindungen vom lokalen Rechner; die Trusted-IP-Liste schützt in diesem Aufbau praktisch nicht mehr, entscheidend ist allein, wer den veröffentlichten Port erreicht. Für die Oberfläche startet das Image optional einen VNC-Server auf Port 5900. Wer darauf zugreift, bedient das Gateway wie am Bildschirm; auch dieser Port gehört nur auf localhost. Stand 22.10.2026 bündelt das Image Gateway 10.51.1d (latest) beziehungsweise 10.50.1f (stable) mit IBC 3.24.2, obwohl das Original-Repository von IBC inzwischen archiviert ist. Feste Versions-Tags zeigen, welche Komponenten laufen. Das Passwort lässt sich als Datei übergeben (TWS_PASSWORD_FILE), was zu Docker-Secrets passt. Was das Ende von IBC für Neustarts und Anmeldungen bedeutet, beschreibt der Beitrag IB Gateway im Dauerbetrieb; Grundlagen zu Container-Setups stehen in Docker für Trading-Bots.

Auf dem VPS gelten die üblichen Regeln: SSH nur mit Schlüssel, Root-Login aus, die Firewall des Anbieters als zweite Ebene.

Read-Only API und Client-IDs als Schutzschicht.

„Read-Only API“ ist die zweite wichtige Einstellung im API-Menü. Ist sie aktiv, lässt TWS über die API keine Änderungen zu, also auch keine Orders. Für Bots, die handeln sollen, verlangt IBKR deshalb, sie abzuschalten. Für rein lesende Prozesse ist sie dagegen eine wirksame Schutzschicht: Ein Dashboard oder Monitoring-Skript kann dann auch bei einem Programmfehler keine Orders auslösen.

Die Einstellung steht in der globalen Konfiguration und gilt damit für die ganze TWS- oder Gateway-Sitzung, nicht für einzelne Clients. Wer einen handelnden Bot und einen rein lesenden Prozess strikt trennen will, braucht zwei Sitzungen: eine mit Schreibrechten für den Bot und eine mit Read-Only API für die Auswertung. Weil jeder Benutzername nur eine Handelssitzung zur Zeit haben kann, setzt das einen zweiten Benutzer voraus.

Client-IDs sind kein Zugangsschutz, denn jeder Client wählt seine ID beim Verbinden selbst. Sie helfen aber, Ordnung zu halten. Eine ID darf nur einmal gleichzeitig verbunden sein, sonst lehnt TWS die zweite Verbindung ab (Fehler 326). Ohne besondere Einstellung sieht ein Client über openOrder und execDetails nur Orders und Ausführungen seiner eigenen Client-ID. Die in der Konfiguration festgelegte Master Client ID sieht auch Orders anderer API-Verbindungen; die Client-ID 0 erhält zusätzlich Orders aus TWS und FIX. Setzt man die Master Client ID auf 0, erhält diese Verbindung laut IBKR die Orders aus TWS, FIX-Sitzungen und allen API-Verbindungen des Kontos.

Praktisch heißt das: feste IDs je Prozess vergeben und dokumentieren, etwa eine für den Handels-Bot, eine für den Datenabruf und die Master-ID nur für die Überwachung, die den Gesamtblick braucht.

Eigener Benutzer für den Bot: Sitzungen, Rechte, Kosten.

Ein IBKR-Konto kann mehrere Benutzernamen haben, und für den Bot-Betrieb ist das mehr als Komfort. Laut IBKR kann man sich mit demselben Benutzernamen nicht gleichzeitig in mehreren Handelsanwendungen anmelden. Meldet sich jemand während einer laufenden TWS- oder Gateway-Sitzung mit demselben Benutzer im Client Portal an, kann sich TWS oder Gateway nach der nächsten Trennung, etwa dem Server-Reset, nicht mehr automatisch neu verbinden. Eine Paper-Sitzung, die Marktdaten eines Live-Benutzers mitnutzt, bekommt keine Daten mehr, sobald dieser Live-Benutzer im Client Portal angemeldet ist. Auch die Web API erlaubt nur eine aktive Brokerage-Sitzung je Benutzername. Als Lösung nennt IBKR für diese Fälle zusätzliche Benutzernamen.

Der zweite Grund sind Rechte. IBKR beschreibt Benutzer mit eingeschränkten Rechten, etwa für Entwickler, die mit dem Live-Konto arbeiten, aber weder Auszahlungen veranlassen noch direkt handeln dürfen. Solche Benutzer richtet das Account-Configuration-Team von IBKR ein. Für einen Bot-Benutzer ist der Grundgedanke derselbe: Er braucht Handels- und Datenrechte für die Instrumente des Systems, aber keine Auszahlungen und keine Kontoverwaltung. Welche Kombination für Ihr Konto möglich ist, klären Sie direkt mit IBKR.

Der Haken sind die Kosten. Marktdaten werden laut IBKR je Benutzer bereitgestellt: Ein Abo des einen Benutzers gilt nicht für einen zweiten Benutzer desselben Kontos. Brauchen Bot und Mensch dieselben Echtzeitdaten, braucht jeder ein eigenes Abo, und die Gebühren fallen zweimal an. Das gehört vorab in die Kostenrechnung.

Grenzen und Risiken.

Eine abgeschottete Verbindung ist Grundlage, aber kein vollständiges Schutzkonzept. Offen bleiben:

• Geschützter Port heißt nicht fehlerfreier Bot. Netzwerkschutz verhindert fremden Zugriff, aber keine falschen Orders aus der eigenen Logik. Dafür braucht es Positions- und Verlustlimits, einen Abgleich mit dem Broker und einen Notschalter.
• Der Server ist das Konto. Wer Administratorrechte auf dem Gateway-Rechner hat, kann sich mit der laufenden Sitzung verbinden und Einstellungen ändern. Automatische Logins legen das Passwort auf dem Server ab.
• Kein offizieller Headless-Betrieb. Eine Sitzung ohne grafische Oberfläche unterstützt IBKR aus Sicherheitsgründen nicht. Docker-Images behelfen sich mit virtuellem Bildschirm und VNC, also mit zusätzlicher Software und Angriffsfläche.
• Archivierte Komponenten. IBC erhält über das archivierte Original-Repository keine Updates mehr. Neue Gateway-Versionen können Dialoge oder Abläufe ändern, auf die es reagiert.
• Abgeschaltete Warnungen. Order-Precautions lassen sich für API-Orders umgehen. Das entfernt eine Kontrollstufe; welche Warnungen wegfallen dürfen, ist eine bewusste Entscheidung je System.
• Marktrisiko bleibt. Automatisierter Handel kann zu hohen Verlusten bis zum Totalverlust führen, mit Hebel oder bei Futures auch über den Einsatz hinaus. Jede Änderung an Netz und Konfiguration gehört zuerst ins Paper-Konto.

IB Gateway und TWS absichern: was Sie jetzt tun können.

Diese Checkliste passt für ein bestehendes Setup ebenso wie vor dem ersten Live-Start:

1. Ports inventarisieren: Welche Instanz läuft auf welchem Port, live oder Paper, und ist der Bot fest auf den richtigen Port konfiguriert?
2. localhost-only aktiv lassen, wenn der Bot auf demselben Rechner oder über einen SSH-Tunnel verbindet.
3. Trusted IPs ausdünnen: nur einzelne, feste Adressen, keine wechselnden öffentlichen IPs, alte Einträge entfernen.
4. Von außen prüfen: Mit einem Portscanner von einem fremden Rechner testen, ob API- und VNC-Port erreichbar sind. Erwartet wird: geschlossen.
5. Docker kontrollieren: Port-Mappings mit 127.0.0.1 oder internes Netz, Docker ab Version 28.0.0, Image-Version fest gesetzt, Passwort als Secret statt im Compose-File.
6. Read-Only API in jeder Sitzung aktivieren, die nicht handeln muss.
7. Client-IDs festlegen und dokumentieren, die Master Client ID bewusst vergeben.
8. Bot-Benutzer anlegen, Rechte mit IBKR abstimmen und die zusätzlichen Marktdatenkosten einplanen.
9. API-Protokoll einschalten („Create API Message Log File“): Die Logs sind nach Client-ID benannt.

Wer das nicht selbst aufsetzen möchte: Marcel Gautsche entwickelt Python-Systeme für Interactive Brokers nach Ihren Vorgaben, testet sie im Paper-Konto und betreibt sie auf Wunsch auf einem VPS mit Monitoring. Die Live-Aktivierung bleibt beim Kontoinhaber. Details stehen auf der Seite Trading-Automatisierung.

Häufige Fragen.

Welche Ports nutzen TWS und IB Gateway für die API?

Standardmäßig lauscht TWS auf Port 7496 für das Live-Konto und 7497 für das Paper-Konto, IB Gateway auf 4001 für live und 4002 für Paper. Die Ports lassen sich in den API-Einstellungen ändern. Wichtig ist, dass der Bot genau den Port verwendet, der dort als Socket Port eingetragen ist, und dass Live- und Paper-Port im Code klar getrennt sind.

Wie lässt sich IB Gateway von einem anderen Rechner aus verbinden?

Technisch muss „Allow connection from localhost only“ abgewählt und die Adresse des Clients unter Trusted IPs eingetragen werden. Weil die Verbindung unverschlüsselt und ohne Passwort läuft, ist ein SSH-Tunnel oder ein VPN meist die bessere Wahl. Beim Tunnel bleibt localhost-only aktiv, und nach außen ist nur der SSH-Port offen.

Kann man bei Trusted IPs ein ganzes Subnetz freigeben?

Nein. Laut IBKR akzeptiert die Liste der Trusted IPs nur einzelne IP-Adressen, keine Subnetze wie /27. Wer aus einem Cluster mit wechselnden Knoten verbindet, muss jede Adresse einzeln eintragen. Zu beachten ist außerdem, dass TWS die Adresse nach einer Adressumsetzung sieht, also etwa die IP des Routers oder des Docker-Netzes.

Braucht ein Trading-Bot einen eigenen IBKR-Benutzer?

In den meisten Bot-Setups ja. Mit einem Benutzernamen ist nur eine Handelssitzung zur Zeit möglich, und eine Anmeldung im Client Portal mit demselben Benutzer kann den automatischen Reconnect von TWS oder Gateway verhindern. Ein eigener Bot-Benutzer lässt sich mit eingeschränkten Rechten anlegen. Marktdatenabos gelten aber je Benutzer und müssen für ihn separat abgeschlossen werden.

Was bewirkt die Einstellung Read-Only API?

Mit aktivierter Read-Only API lässt TWS oder IB Gateway über die API keine Änderungen zu, also auch keine Orders und keine Änderungen an Einstellungen. Für handelnde Bots muss sie deshalb aus sein. Für reine Daten-, Dashboard- oder Monitoring-Sitzungen ist sie eine sinnvolle Schutzschicht. Sie gilt für die gesamte Sitzung, nicht für einzelne Clients.

Quellen und Stand.

• Excel RTD: Connection Parameters (Standard-Ports, 32 Clients) — Interactive Brokers
• TWS API: Remote TWS API Connections with Trader Workstation — Interactive Brokers
• TWS API: Setting Management — Interactive Brokers
• TWS API: Logging into multiple applications — Interactive Brokers
• Market Data Users: Multiple Users — Interactive Brokers
• ib-gateway-docker: README und Security Considerations — gnzsnz (GitHub)
• Port publishing and mapping — Docker
• Packet filtering and firewalls (Docker und ufw) — Docker

Stand: 22. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.

Sie wollen Ihren IBKR-Bot sauber abgeschottet auf einem Server betreiben? Unverbindlich anfragen — wir klären Architektur, Zugriffswege, Benutzer und Monitoring, bevor Ihr System live geht. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.