Sledování net trafficu na OUTPUT chain u Turrise

Od fojtp

Dne 2016-02-25 11:03

tcpdump?

Od pflajshans.moje

Dne 2016-02-25 11:04

Tím ale nezjistím který proces to je.

Od fojtp

Dne 2016-02-25 11:06

zjistite zdrojovy port, pripadne muze pomoct netstat

Od pflajshans.moje

Dne 2016-02-25 11:25

Díky za nakopnutí.
Tak jsem zjistil, že se jedná o službu unbound, což je DNS server.

root@turris:~# cat /etc/unbound/unbound.conf
# auto-generated config file from /etc/config/unbound
server:
chroot: ""
verbosity: 1
interface: 0.0.0.0
interface: ::0
port: 53
outgoing-range: 60
outgoing-num-tcp: 1
incoming-num-tcp: 1
msg-buffer-size: 8192
msg-cache-size: 100k
msg-cache-slabs: 1
num-queries-per-thread: 30
rrset-cache-slabs: 1
infra-cache-slabs: 1
infra-cache-numhosts: 200
access-control: 0.0.0.0/0 allow
access-control: ::0/0 allow
username: ""
pidfile: "/var/run/unbound.pid"
root-hints: "/etc/unbound/named.cache"
target-fetch-policy: "2 1 0 0 0"
harden-short-bufsize: yes
harden-large-queries: yes
auto-trust-anchor-file: "/etc/unbound/root.key"
key-cache-size: 100k
key-cache-slabs: 1
neg-cache-size: 10k
prefetch: yes
prefetch-key: yes
python:
remote-control:
control-enable: no
control-port: 8953
server-key-file: "/etc/unbound/unbound_server.key"
server-cert-file: "/etc/unbound/unbound_server.pem"
control-key-file: "/etc/unbound/unbound_control.pem"
control-cert-file: "/etc/unbound/unbound_control.pem"

Je něco na tomhle v nepořádku? Dosud jsem na to nesáhnul, nevím, proč se to zbláznilo minulý víkend...

Od saky

Dne 2016-02-25 12:06

Toto se mi zdá v pořádku. Co máte v /etc/config/firewall ? Něměnil jste tam nějaká pravidla, která by pustila provoz z turrise ven? Dočasně by mohlo pomoci přidat pravidlo pro port 53 do FW. Zkuste sem dát ještě aktuální konfiguraci firewallu.

Od Jan Čermák (>>)

Dne 2016-02-25 12:40

Podívejte se tcpdumpem, co to je za dotazy. Ve starší verzi Majordomo (máte ho nainstalovaný?) docházelo k nějakému problému, který způsoboval, že router generoval velké množství PTR dotazů (na reverzní záznam IP adresy). To by ale už mělo být dávno pryč, pokud tam nedošlo k nějaké regresi.

Od Ondřej Caletka (>>>)

Dne 2016-02-25 14:24 Hlasů 1

Obávám se, že tohle značí že váš Turris se pravděpodobně stal participantem v nějakém DoS útoku. Nejspíš se chová jako otevřený rekurzivní resolver. Zkontrolujte prosím, že jste ve firewallu omylem nepovolil příchozí UDP provoz z WAN rozhraní na port 53.

Od pflajshans.moje

Dne 2016-02-25 14:52

Děkuji za nakopnutí správným směrem. Omylem jsem měl otevřen port 53 do světa a po instalaci pravidla, které vyhazuje příchozí pakety na port 53 zvenku, tak provoz z unboundu do světa se zastavil.

Od Ondřej Caletka (>>>)

Dne 2016-02-26 10:26

Tohle je zdá se docela zásadní vada, kterou by to chtělo řešit nějak systémověji – například nechat unbound poslouchat pouze na vyjmenovaných vnitřních adresách, nebo v něm nastavit ACL pouze pro vnitřní adresy. První řešení naráží na to, že u IPv6 žádné „vnitřní“ a „vnější“ neexistuje, druhé zase na to, jak určit všechny možné adresy. Obě společně pak na to, že je nutné unbound reloadovat po každé změně stavu síťových rozhraní.

Zkusím se nad tím zamyslet.

Od pflajshans.moje

Dne 2016-02-27 16:55

Domnívám se, že to byla moje blbost než vada konceptu. Ve firewallu mám jasně definovány zóny wan i lan a já jsem svojí blbostí povolit na inputu zóny wan Allow. Pokud se to budete snažit ošetřit nějakým blbuvzdorným řešením, tak to bude zase narážet u uživatelů, kteří z nějakého důvodu opravdu budou chtít mít u wan zóny na inputu Allow.

Od Ondřej Caletka (>>>)

Dne 2016-02-28 17:08 Hlasů 2

Systémové řešení téměř nikdy nespočívá v nastavení firewallu. Bezpečný systém má fungovat tak, že je plně bezpečný i s naprosto otevřeným firewallem. Tady je bohužel zásadní koncepční chyba, že unbound je nastaven, aby odpovídal každému, kdo se k němu dostane a firewall je naopak [em]jediným[/em] prostředkem k zajištění bezpečnosti. Což je podle mě špatně.

Od Elty

Dne 2016-02-28 17:51

Související dotaz k firewallu. Pokud není využívána IPv6, je možno toto nastavení odstranit/zneplatnit?

config rule
  option name 'Allow-DHCPv6'
  option src 'wan'
  option proto 'udp'
  option src_ip 'fe80::/10'
  option src_port '547'
  option dest_ip 'fe80::/10'
  option dest_port '546'
  option family 'ipv6'
  option target 'ACCEPT'

config rule
  option name 'Allow-ICMPv6-Input'
  option src 'wan'
  option proto 'icmp'
  list icmp_type 'echo-request'
  list icmp_type 'echo-reply'
  list icmp_type 'destination-unreachable'
  list icmp_type 'packet-too-big'
  list icmp_type 'time-exceeded'
  list icmp_type 'bad-header'
  list icmp_type 'unknown-header-type'
  list icmp_type 'router-solicitation'
  list icmp_type 'neighbour-solicitation'
  list icmp_type 'router-advertisement'
  list icmp_type 'neighbour-advertisement'
  option limit '1000/sec'
  option family 'ipv6'
  option target 'ACCEPT'

config rule
  option name 'Allow-ICMPv6-Forward'
  option src 'wan'
  option dest '*'
  option proto 'icmp'
  list icmp_type 'echo-request'
  list icmp_type 'echo-reply'
  list icmp_type 'destination-unreachable'
  list icmp_type 'packet-too-big'
  list icmp_type 'time-exceeded'
  list icmp_type 'bad-header'
  list icmp_type 'unknown-header-type'
  option limit '1000/sec'
  option family 'ipv6'
  option target 'ACCEPT'

Od Ondřej Caletka (>>>)

Dne 2016-02-29 10:24

Ano, zmíněná pravidla slouží k zajištění správné minimální funkčnosti IPv6, pokud se IPv6 nepoužívá, nemají žádný význam (ale zároveň ničemu nepřekáží).