bbs ist ein Router für SOCKS- und HTTP-Proxys. Es stellt einen SOCKS5-Dienst (oder HTTP CONNECT) bereit und leitet eingehende Anfragen basierend auf dem Ziel der Anfrage an Proxys oder Proxy-Ketten weiter. Das Routing kann über ein PAC-Skript (sofern mit PAC-Unterstützung erstellt) oder über eine JSON-Datei konfiguriert werden.
Das alte bbs finden Sie hier.
bbs ist ein Router für SOCKS- und HTTP-Proxys. Es stellt SOCKS5-, HTTP-
CONNECT- oder Portweiterleitungsdienste bereit und leitet eingehende Anfragen an Proxys oder Proxy-Ketten
basierend auf dem Ziel der Anfrage weiter. Das Routing kann über ein PAC-Skript (falls
mit PAC-Unterstützung gebaut) oder über eine JSON-Datei konfiguriert werden.
go install github.com/synacktiv/bbs@master
Um bbs mit PAC-Skript-Unterstützung zu installieren:
go install -tags pac github.com/synacktiv/bbs@master
Hinweis: PAC basiert auf nicht geprüften Drittanbieter-Bibliotheken.
Die Python-CLI bbscli.py wird bereitgestellt, um die Konfiguration von bbs zu erleichtern und das manuelle Schreiben von JSON-Dateien zu vermeiden.
Sie benötigt die Bibliothek pyparsing, die von Debian paketiert wird:
apt install python3-pyparsing
Falls die Bibliothek von Ihrer Distribution nicht paketiert ist, kann sie mit pip installiert werden:
pip install pyparsing
Die Konfiguration erfolgt in einer JSON-Datei, die aus mehreren Abschnitten besteht:
Der Pfad zur Konfigurationsdatei wird über das Argument -c <path> angegeben (Standard: ./bbs.json).
bbs lädt Konfigurationsdateien bei SIGHUP neu; verwenden Sie kill -HUP <pid>, um neu zu laden.
Hier ist ein Beispiel für eine solche Konfiguration:
{
"proxies": {
"proxy1": {
"connstring": "socks5://127.0.0.1:1337",
"user": "user",
"pass": "s3cr3t"
},
"proxy2": {
"connstring": "http://127.0.0.1:1338"
}
},
"chains": {
"chain1": {
"proxyDns": true,
"tcpConnectTimeout": 1000,
"tcpReadTimeout": 2000,
"proxies": [
"proxy1",
"proxy2"
]
},
"direct": {
"proxies": []
}
},
"routes": {
"table1": {
"default": "direct",
"blocks": [
{
"comment": "Block1 comment",
"rules": {
"rule": "regexp",
"variable": "host",
"content": "me\\.gandi\\.net"
},
"route": "chain1"
},
{
"comment": "Route non web traffic towards 10.35.0.0/16 through proxy2",
"rules": {
"rule1": {
"rule": "subnet",
"content": "10.35.0.0/16"
},
"op": "AND",
"rule2": {
"rule": "regexp",
"variable": "port",
"content": "^(80|443)$",
"negate": true
}
},
"route": "proxy2"
},
{
"comment": "Drop traffic to 445",
"rules": {
"rule": "regexp",
"variable": "port",
"content": "^445$"
},
"route": "drop"
},
{
"comment": "Route *.corp.local through chain1",
"rules": {
"rule": "regexp",
"variable": "host",
"content": "(?i)^(.*\\.)?corp\\.local$"
},
"route": "chain1",
"disable": true
}
]
},
"table2": {
"default": "drop",
"blocks": [
{
"comment": "Route *.corp.local through chain2",
"rules": {
"rule": "regexp",
"variable": "host",
"content": "(?i)^(.*\\.)?corp\\.local$"
},
"route": "chain2"
}
]
}
},
"servers": [
"socks5://127.0.0.1:1081:table1",
"http://127.0.0.1:1080:table2",
"fwd://127.0.0.1:4445:chain1:10.0.0.1:445"
],
"hosts": {
"host1": "1.1.1.1",
"host2": "10.0.0.1",
"host3": "modified.host3",
"10.1.1.4": "10.1.1.5"
}
}
Upstream-Proxys müssen im Abschnitt proxies als Map von Proxy-Strukturen deklariert werden.
Die Map-Schlüssel sind frei wählbar, müssen aber mit denen in der Ketten-Definition übereinstimmen.
Proxy-Strukturen sehen wie folgt aus:
connstring ist erforderlich und hat das Format protocol://host:port (protocol kann socks5 oder httpconnect/http sein)user und pass sind optionalFür jeden deklarierten Proxy wird eine implizite Kette (siehe nächster Absatz) mit demselben Namen erstellt. Sie hat Standardparameter und besteht aus dem einzelnen zugehörigen Proxy. Wenn Sie nicht standardmäßige Parameter verwenden möchten, müssen Sie explizit eine Kette erstellen.
Ketten müssen im Abschnitt chains als Map von Kettenstrukturen deklariert werden.
Die Map-Schlüssel sind frei wählbar, müssen aber mit denen in der Routen-Definition übereinstimmen und
dürfen nicht mit den Map-Schlüsseln des Abschnitts proxies identisch sein.
Kettenstrukturen haben proxychains-ähnliche Parameter (vgl. https://github.com/rofl0r/proxychains-ng):
proxyDns: boolesch, optional, Standardwert truetcpConnectTimeout: integer, optional, Standardwert 1000 (wird beim Verbinden von Sockets verwendet, entweder zum ersten Proxy
der Kette oder direkt zum Ziel)tcpReadTimeout: integer, optional, Standardwert 2000 (wird beim Lesen von Proxy-Handshake-Antworten auf verbundenen Sockets verwendet)proxies: Liste von Zeichenketten, optional, Standardwert leere ListeDer Schlüssel proxies einer chain muss ein Array von Proxy-Namen enthalten, die als Schlüssel im Abschnitt proxies deklariert sind.
Wie im vorherigen Absatz erwähnt, wird für jeden im Abschnitt proxies deklarierten Proxy eine implizite
Kette (siehe nächster Absatz) mit demselben Namen erstellt. Sie hat Standardparameter und ist
aus dem einzelnen zugehörigen Proxy zusammengesetzt.
Der eingebaute Konfigurationsmodus für das Routing erfolgt über die Konfigurationsdatei. Er ordnet
Adressen Kettennamen zu. Die Datei muss eine Map von Routing-Tabellen enthalten. Die Map-Schlüssel
sind frei wählbar, müssen aber mit denen im Abschnitt servers übereinstimmen.
Jede Routing-Tabelle enthält einen Schlüssel default, der die Standardroute darstellt, und einen Schlüssel blocks,
der ein Array von Regelblöcken ist. Jeder
Regelblock enthält einen comment, eine Reihe von rules und einen zugehörigen
Kettennamen. Regeln werden ausgewertet: Für eine Adresse im Format host:port können sie
true oder false sein. Für eine bestimmte Adresse werden die Blöcke in ihrer
Deklarationsreihenfolge ausgewertet. Blöcke können durch Setzen des Felds disable auf true deaktiviert werden.
Dies ermöglicht eine Art „Auskommentieren", was in JSON nicht möglich ist.
Die Auswertung stoppt beim ersten Block, der true ergibt, und
der zugehörige Kettenname wird zurückgegeben. Jeder geöffnete Server (aus dem Abschnitt servers)
ist einer Routing-Tabelle aus der Konfiguration zugeordnet. Anfragen, die auf
jedem Server eingehen, werden gemäß der passenden Routing-Tabelle weitergeleitet. Wenn alle Blöcke auf
ausgewertet werden, wird die Standardroute verwendet. Wenn nicht definiert ist, werden Verbindungen standardmäßig verworfen.
Block-Felder:
comment (Zeichenkette)rules (Rule oder RuleCombo)route (Zeichenkette)disable (bool)Rule-Felder:
rule (Zeichenkette): Regeltyp, regexp, subnet.variable (Zeichenkette): Variable für die Regexp-Auswertung, host, port oder addr (host:port).content (Zeichenkette): Inhalt der Regel, abhängig vom Regeltyp (siehe unten).negate (bool) [optional]: ob die Regel negiert werden soll.RuleCombo-Felder:
rule1 (Rule oder RuleCombo): linker Operand.op (Zeichenkette): Operator, AND, And, and, &, &&, OR, Or, or, |, ||.rule2 (Rule oder RuleCombo): rechter Operand.Regeltypen:
regexp: gleicht die in variable definierte Variable (host, port oder addr=host:port) mit dem Regexp in content ab.subnet: prüft, ob sich der Host im in content definierten Subnetz befindet. Wenn der Host ein Domänenname und keine Subnetz-Adresse ist, gibt die Regel false zurück.Die Regelblöcke aus dem Abschnitt routes oder die PAC-Funktion müssen deklarierte
Kettennamen zurückgeben, keine Proxy-Namen. Wenn Sie einen einzelnen Proxy verwenden möchten, müssen Sie ihn
in eine Kette einbinden. Der Name drop ist speziell und muss in dieser Konfiguration nicht deklariert werden.
Wenn die PAC-Funktion oder ein Routing-Block drop als
Kettennamen zurückgibt, wird die Verbindung verworfen.
Wenn bbs mit PAC-Unterstützung gebaut wurde und das Argument -pac auf eine PAC-Datei zeigt, werden die Routen
in der Konfigurationsdatei nicht verwendet. Das PAC-Datei-Routing unterstützt keine
mehrfachen Routing-Tabellen. Dieselbe PAC-Datei wird für jeden geöffneten Server verwendet.
Die von bbs geöffneten Listener müssen im Abschnitt servers als Liste von
Verbindungszeichenfolgen im Format protocol://bind_addr:bind_port:routing_table oder
protocol://bind_addr:bind_port:chain:dest_addr:dest_port deklariert werden.
protocol kann http oder socks5 sein, wenn die routing_table angegeben istprotocol kann fwd sein, wenn chain, dest_addr und dest_port angegeben sindrouting_table muss einer der im Abschnitt routes definierten Tabellen entsprechenchain muss einer der im Abschnitt chains definierten Ketten entsprechenEine benutzerdefinierte Host-Auflösung (ähnlich wie /etc/hosts) kann im
Abschnitt hosts als Map von Zeichenketten konfiguriert werden. Die Map-Schlüssel entsprechen dem Hostnamen
und die Werte der IP-Adresse, zu der der Host aufgelöst werden soll.
Es ist zu beachten, dass Map-Schlüssel auch IP-Adressen sein können. In diesem Fall wird die Schlüssel-IP-Adresse durch die Wert-IP-Adresse ersetzt. Ebenso können Map-Werte Hostnamen sein und ersetzen dann den entsprechenden Map-Schlüssel.
Falls definiert, erfolgen benutzerdefinierte Host-Auflösungen zu Beginn der Verbindungsphase,
nachdem die Routing-Entscheidung getroffen wurde und vor jeder lokalen DNS-Auflösung (falls die Kette
mit proxyDns=false konfiguriert ist) sowie vor dem Senden der Zieladresse an die
verschiedenen Proxys der Kette.
Wenn bbs mit PAC-Unterstützung gebaut wurde, kann das Routing mit einem PAC-Skript
anstelle einer JSON-Konfigurationsdatei konfiguriert werden. Dies erfordert jedoch die Verwendung einer nicht vertrauenswürdigen
Go-Bibliothek. Der Pfad zur PAC-Datei muss mit -pac angegeben werden.
Das PAC-Skript muss die Funktion FindProxyForURL(url, host) definieren. Die
von dieser Funktion zurückgegebenen Werte müssen den Namen der Ketten (nicht der
Proxys) entsprechen, die in der JSON-Konfiguration deklariert sind.
falsedefault