bbs è un router per proxy SOCKS e HTTP. Espone un servizio SOCKS5 (o HTTP CONNECT) e inoltra le richieste in arrivo a proxy o catene di proxy in base alla destinazione della richiesta. Il routing può essere configurato con uno script PAC (se compilato con supporto PAC) o tramite un file JSON.
Il vecchio bbs può essere trovato qui
bbs è un router per proxy SOCKS e HTTP. Espone servizi SOCKS5, HTTP CONNECT o port forwarding e inoltra le richieste in arrivo a proxy o catene di proxy in base alla destinazione della richiesta. Il routing può essere configurato con uno script PAC (se compilato con il supporto PAC) oppure tramite un file JSON.
go install github.com/synacktiv/bbs@master
Per installare bbs con il supporto degli script PAC:
go install -tags pac github.com/synacktiv/bbs@master
Nota: PAC si basa su librerie di terze parti non sottoposte a revisione.
La CLI Python bbscli.py è fornita per facilitare la configurazione di bbs ed evitare di scrivere manualmente i file JSON.
Richiede la libreria , inclusa nei pacchetti di Debian:
pyparsingapt install python3-pyparsing
Se la libreria non è inclusa nei pacchetti della tua distribuzione, può essere installata usando pip:
pip install pyparsing
La configurazione viene effettuata in un unico file JSON composto da più sezioni:
Il percorso del file di configurazione viene fornito tramite l'argomento -c <path> (predefinito: ./bbs.json).
bbs ricarica i file di configurazione al ricevimento di SIGHUP; usa kill -HUP <pid> per ricaricare.
Ecco un esempio di tale configurazione:
{
"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"
}
}
I proxy a monte devono essere dichiarati nella sezione proxies come una mappa di strutture proxy. Le chiavi della mappa sono scelte liberamente ma devono corrispondere a quelle usate nella definizione delle catene. Le strutture proxy sono così composte:
connstring è obbligatoria con formato protocol://host:port (protocol può essere socks5 o httpconnect/http)user e pass sono opzionaliPer ogni proxy dichiarato, viene creata una catena implicita (vedi paragrafo successivo) con lo stesso nome. Ha parametri predefiniti ed è composta dal singolo proxy associato. Se si desidera utilizzare parametri non predefiniti, è necessario creare esplicitamente una catena.
Le catene devono essere dichiarate nella sezione chains come una mappa di strutture di catena. Le chiavi della mappa sono scelte liberamente ma devono corrispondere a quelle usate nella definizione delle route e devono essere diverse dalle chiavi della mappa della sezione proxies. Le strutture di catena hanno parametri simili a quelli di proxychains (cfr. https://github.com/rofl0r/proxychains-ng):
proxyDns: booleano, opzionale, predefinito truetcpConnectTimeout: intero, opzionale, predefinito 1000 (usato durante la connessione dei socket, sia al primo proxy della catena che direttamente alla destinazione)tcpReadTimeout: intero, opzionale, predefinito 2000 (usato durante la lettura delle risposte di handshake dei proxy sui socket connessi)proxies: elenco di stringhe, opzionale, predefinito elenco vuotoLa chiave proxies di una chain deve contenere un array di nomi di proxy dichiarati come chiavi nella sezione proxies. Come accennato nel paragrafo precedente, per ogni proxy dichiarato nella sezione proxies viene creata una catena implicita (vedi paragrafo successivo) con lo stesso nome. Ha parametri predefiniti ed è composta dal singolo proxy associato.
La modalità di configurazione integrata per il routing avviene tramite il file di configurazione. Associa gli indirizzi ai nomi delle catene. Il file deve contenere una mappa di tabelle di routing. Le chiavi della mappa sono scelte liberamente ma devono corrispondere a quelle usate nella sezione servers. Ogni tabella di routing contiene una chiave default che rappresenta la route predefinita e una chiave blocks che è un array di blocchi di regole. Ogni blocco di regole contiene un comment, un insieme di rules e un nome di catena associato. Le regole vengono valutate: dato un indirizzo nel formato host:port, possono essere true o false. Per un dato indirizzo, i blocchi vengono valutati nell'ordine di dichiarazione. I blocchi possono essere disabilitati impostando il campo disable a true. Ciò consente una forma di "commento", non possibile in JSON. La valutazione si ferma al primo blocco che risulta true e viene restituito il nome della catena associata. Ogni server aperto (dalla sezione servers) è associato a una tabella di routing della configurazione. Le richieste ricevute su ciascun server vengono instradate in base alla tabella di routing corrispondente. Se tutti i blocchi vengono valutati false, viene utilizzata la route predefinita. Se default non è definita, le connessioni vengono scartate per impostazione predefinita.
Campi del blocco:
comment (stringa)rules (Rule o RuleCombo)route (stringa)disable (booleano)Campi della regola:
rule (stringa): tipo di regola, regexp, subnet.variable (stringa): variabile per la valutazione regexp, host, port o addr (host:port).content (stringa): contenuto della regola, dipende dal tipo di regola (vedi sotto).negate (booleano) [opzionale]: indica se negare la regola.Campi di RuleCombo:
rule1 (Rule o RuleCombo): operando sinistro.op (stringa): operatore, AND, And, and, &, &&, OR, Or, or, |, ||.rule2 (Rule o RuleCombo): operando destro.Tipi di regola:
regexp: confronta la variabile definita in variable (host, port o addr=host:port) con la regexp contenuta in content.subnet: verifica se l'host si trova nella sottorete definita in content. Se l'host è un nome di dominio e non un indirizzo di sottorete, la regola restituisce false.I blocchi di regole della sezione routes o la funzione PAC devono restituire nomi di catene dichiarati, non nomi di proxy. Se si desidera utilizzare un singolo proxy, è necessario racchiuderlo in una catena. Il nome drop è speciale e non necessita di essere dichiarato in questa configurazione. Se la funzione PAC o un blocco di routing restituisce drop come nome di catena, la connessione viene scartata.
Se bbs è compilato con il supporto PAC e l'argomento -pac punta a un file PAC, le route definite nel file di configurazione non verranno utilizzate. Il routing tramite file PAC non supporta più tabelle di routing. Lo stesso file PAC verrà utilizzato per ogni server aperto.
I listener aperti da bbs devono essere dichiarati nella sezione servers come lista di stringhe di connessione nel formato protocol://bind_addr:bind_port:routing_table o protocol://bind_addr:bind_port:chain:dest_addr:dest_port.
protocol può essere http o socks5 se viene fornita la routing_tableprotocol può essere fwd se vengono forniti chain, dest_addr e dest_portrouting_table deve corrispondere a una delle tabelle definite nella sezione routeschain deve corrispondere a una delle catene definite nella sezione chainsLa risoluzione personalizzata degli host (simile a /etc/hosts) può essere configurata nella sezione hosts come mappa di stringhe. Le chiavi della mappa corrispondono al nome dell'host e i valori all'indirizzo IP a cui l'host deve essere risolto.
Va notato che le chiavi della mappa possono essere anche indirizzi IP. In questo caso, l'indirizzo IP della chiave verrà sostituito dall'indirizzo IP del valore. Analogamente, i valori della mappa possono essere nomi di host e sostituiranno la corrispondente chiave della mappa.
Se definite, le risoluzioni personalizzate degli host avvengono all'inizio della fase di connessione, dopo la decisione di routing e prima di qualsiasi risoluzione DNS locale (se la catena è configurata con proxyDns=false) e prima di inviare l'indirizzo di destinazione ai vari proxy della catena.
Se bbs è compilato con il supporto PAC, il routing può essere configurato con uno script PAC invece che con un file di configurazione JSON. Tuttavia, ciò richiede l'utilizzo di una libreria Go non affidabile. Il percorso del file PAC deve essere fornito con -pac.
Lo script PAC deve definire la funzione FindProxyForURL(url, host). I valori restituiti da questa funzione devono corrispondere ai nomi delle catene (non dei proxy) dichiarate nella configurazione JSON.