Majordomo - interpretace výsledků

Dne 2014-11-25 19:21 Upraveno 2014-11-25 19:32

Hlouběji jsem se zanořil do výsledků majordoma na naši síti. V síti mám Turris jakou router a dále mám připojeny ještě dva Asusy 500gP jako switche, pro začátek jsem začal analyzovat provoz jednoho z routerů. První spojení chápu, router si skrze NTP aktualizuje čas, i když nechápu zrovna tuto adresu. V konfiguraci mám nastaveny NTP servery pouze od OpenWRT. Další spojení nechápu, proč se router připojuje k stream.cz? Možná dělám zásadní chybu v pohledu na věc a klienti za tím switchem se v majordomu zobrazují jako provoz tohoto routeru. Ale to přece není správné, router v režimu switchování pakety jen směruje na správné rozhraní a hlouběji je nerozbaluje? Možná by nebylo od věci napsat krátký článek jak tyto výsledky správně interpretovat. Děkuji za vaše komentáře k tomuto tématu.

pyrrha.fi.muni.cz      123/UDP      1      76.00 B      48.00 B      1      76.00 B      48.00 B
46.243.52.111      123/UDP      1      76.00 B      48.00 B      1      76.00 B      48.00 B
prg02s11-in-x15.1e100.net      443/TCP      0      0.00 B      0.00 B      69      20.17 KB      15.95 KB
ea-in-x6c.1e100.net      993/TCP      0      0.00 B      0.00 B      718      72.63 KB      28.54 KB
other      all/both      0      0.00 B      0.00 B      0      0.00 B      0.00 B
www.stream.cz      80/TCP      0      0.00 B      0.00 B      85      11.60 KB      6.59 KB
prg02s11-in-x08.1e100.net      443/TCP      0      0.00 B      0.00 B      9      1.53 KB      1017.00 B
fec0:0:0:ffff::3      53/UDP      0      0.00 B      0.00 B      27      2.25 KB      1006.00 B
2a00:1450:4001:80d::1008      80/TCP      0      0.00 B      0.00 B      1      72.00 B      0.00 B
login.szn.cz      443/TCP      0      0.00 B      0.00 B      16      2.45 KB      1.49 KB
2a00:1450:4001:80d::100a      443/TCP      0      0.00 B      0.00 B      22      3.03 KB      1.65 KB
prg02s11-in-x06.1e100.net      443/TCP      0      0.00 B      0.00 B      86      34.12 KB      29.04 KB
2a00:1450:4001:80d::1008      443/TCP      0      0.00 B      0.00 B      1      72.00 B      0.00 B
2a01:300:30::b00a:5109      80/TCP      0      0.00 B      0.00 B      7      530.00 B      98.00 B
fec0:0:0:ffff::2      53/UDP      0      0.00 B      0.00 B      28      2.33 KB      1.02 KB
bud02s21-in-x13.1e100.net      443/TCP      0      0.00 B      0.00 B      8      540.00 B      0.00 B
2606:2800:133:206e:1315:22a5:2006:24fd      80/TCP      0      0.00 B      0.00 B      7      981.00 B      549.00 B
prg02s11-in-x17.1e100.net      443/TCP      0      0.00 B      0.00 B      6      432.00 B      0.00 B
cl-668.prg-01.cz.sixxs.net      443/TCP      0      0.00 B      0.00 B      42      10.41 KB      7.91 KB
prg02s11-in-x05.1e100.net      443/TCP      0      0.00 B      0.00 B      21      4.31 KB      3.00 KB
oc2.cdn.szn.cz      80/TCP      0      0.00 B      0.00 B      8      480.00 B      0.00 B
2a02:26f0:78:28d::236      443/TCP      0      0.00 B      0.00 B      14      1.94 KB      1.05 KB
bud02s21-in-x1f.1e100.net      443/TCP      0      0.00 B      0.00 B      581      120.33 KB      86.24 KB
db3wns2010909.wns.windows.com      443/TCP      0      0.00 B      0.00 B      2      226.00 B      106.00 B
prg02s11-in-x04.1e100.net      80/TCP      0      0.00 B      0.00 B      7      1.81 KB      1.37 KB
2a00:1450:4010:c08::5e      80/TCP      0      0.00 B      0.00 B      8      485.00 B      5.00 B
ec2.cdn.szn.cz      80/TCP      0      0.00 B      0.00 B      1604      96.15 KB      2.08 KB
prg02s11-in-x0e.1e100.net      443/TCP      0      0.00 B      0.00 B      52      17.78 KB      14.65 KB
2a00:1450:4001:80d::1002      443/TCP      0      0.00 B      0.00 B      4      288.00 B      0.00 B
2a01:300:30::b00a:5108      80/TCP      0      0.00 B      0.00 B      12      723.00 B      3.00 B
prg02s11-in-x03.1e100.net      443/TCP      0      0.00 B      0.00 B      18      4.20 KB      3.09 KB
2a00:1450:4001:80d::100b      80/TCP      0      0.00 B      0.00 B      2      144.00 B      0.00 B
db3wns2011009.wns.windows.com      443/TCP      0      0.00 B      0.00 B      19      2.34 KB      1.17 KB
prg02s11-in-x0a.1e100.net      443/TCP      0      0.00 B      0.00 B      3      216.00 B      0.00 B
db3wns2010910.wns.windows.com      443/TCP      0      0.00 B      0.00 B      29      3.82 KB      2.04 KB
prg02s11-in-x04.1e100.net      443/TCP      0      0.00 B      0.00 B      15      4.47 KB      3.58 KB
2400:cb00:2048:1::c629:f9d2      443/TCP      0      0.00 B      0.00 B      14      1.70 KB      850.00 B
prg02s11-in-x01.1e100.net      443/TCP      0      0.00 B      0.00 B      17      6.28 KB      5.26 KB
prg02s11-in-x0e.1e100.net      80/TCP      0      0.00 B      0.00 B      8      2.07 KB      1.58 KB
db3wns2011109.wns.windows.com      443/TCP      0      0.00 B      0.00 B      4      489.00 B      249.00 B
db3wns4011610.wns.windows.com      443/TCP      0      0.00 B      0.00 B      4      453.00 B      189.00 B
prg02s11-in-x0f.1e100.net      443/TCP      0      0.00 B      0.00 B      8      576.00 B      0.00 B

Provoz z druhého routeru také příliš nechápu. NTP mám zde nastaven na tik a tak od Cesnetu, na niburu mám DB, kam se ukládají naměřené hodnoty teploměru. Další adresy opět nechápu, whois k IP adresám říká toto: "IPs for cloud servers" ale takového provozu si nejsem vědom(no oni to jsou vždy jenom dotaz a odpověď). Co to znamená? A žádného Marka33 také neznám, tak proč mu posíláme 780 Bajtů?

nibiru.zarea.net      80/TCP      16      1.61 KB      964.00 B      24      1.60 KB      628.00 B
46.243.48.111      123/UDP      1      76.00 B      48.00 B      1      76.00 B      48.00 B
srv2.trusted.cz      123/UDP      1      76.00 B      48.00 B      1      76.00 B      48.00 B
46.243.51.55      123/UDP      1      76.00 B      48.00 B      1      76.00 B      48.00 B
tik.cesnet.cz      123/UDP      1      76.00 B      48.00 B      1      76.00 B      48.00 B
tak.cesnet.cz      123/UDP      1      76.00 B      48.00 B      1      76.00 B      48.00 B
46.243.52.222      123/UDP      1      76.00 B      48.00 B      1      76.00 B      48.00 B
mark33.flirtising.com      80/TCP      0      0.00 B      0.00 B      15      780.00 B      0.00 B
other      all/both      0      0.00 B      0.00 B      0      0.00 B      0.00 B

Od Ondřej Caletka (>>>)

Dne 2014-11-26 10:15

Ta adresa NTP serveru je snadno vysvětlitelná. Pokud používáte projekt pool.ntp.org, pak jste nasměrován na některý z mnoha časových serverů, které se dobrovolně účastní poolu. Reverzní DNS záznamy, které zobrazuje majordomo, pak ukazují jméno konkrétního serveru, ke kterému vás právě v tuto chvíli pool navedl.

U všech HTTP spojení je velmi zajímavé, že mají nulový počet paketů směrem k vám. Tipoval bych to na nějaký proxy server vestavěný v zmíněném routeru, který stanice v síti nějakým způsobem autodetekují a zkouší používat.
Pokud si nejste jist, doporučuji na zmíněné routery nainstalovat OpenWRT :P

Od JFila

Dne 2014-11-26 11:13

Zdravím, děkuji za příspěvek. To je divné, jeden z routerů (první log) mám s posledním OpenWRT, který jsem si navíc o víkendu sám buildil. Jak je možné sledovat v routerech, který proces uvedená spojení dělá? Pomocí "netstat -a -p" to bohužel nezjistím, spojení asi trvá jen krátce. A pokud by se jednalo o útok, tak by jistě záškodník nenechával spojení navázané po celou dobu.

A co třeba ty spojení na stream.cz?

Od Ondřej Caletka (>>>)

Dne 2014-11-26 12:32

Jediné co mě napadá, je prodloužit dobu, po které se spojení čistí (sysctl net.ipv4.tcp_fin_timeout) a následně každých n minut sledovat obsah netstatu.

Od JFila

Dne 2014-11-26 13:48

Nastavil jsem si hodnotu 3600,

root@Router-Pracovna:~# sysctl -p
net.ipv4.tcp_fin_timeout = 3600

Pustil jsem si nc na seznam a potom opět netstat a nic. Kde může být chyba?

Od Jan Čermák (>>)

Dne 2014-11-26 14:40

A co na Turrisu pustit tcpdump s filtrem "ether host 11:22:33:44:55:66", kde specifikujete MAC toho podezřelého routeru? Ze získaného PCAP souboru by snad mělo být možné zjistit, co se děje.

Od JFila

Dne 2014-11-26 15:32

Toto jsem už pustil ale chtěl jsem hlavně dohledat, který program to na routeru dělá. Na druhém zařízení jsme zjistil, že spojení má na svědomí wget. Je možné zkontrolovat hash balíčku, v tomto případě se používá wget součástí busyboxu?

root@Router-Pracovna:/usr/bin# wget
BusyBox v1.15.3 (2012-01-12 19:17:27 CET) multi-call binary

tcp 0 1 Router-Pracovna.lan:57438 mark33.flirtising.com:www SYN_SENT 2120/wget

Od fojtp

Dne 2014-11-26 15:42 Upraveno 2014-11-26 15:56

btw.. resolvuje vam "Router-Pracovna" mark33.flirtising.com?

edit: nebude to "spatne" nastaveny reverz? na jakou IP ve skutecnosti wget pristupuje?
edit2: to opravdu staci spustit wget a naskoci SYN? nevola wget neco jinyho (DDNS apod..)?

Od JFila

Dne 2014-11-26 16:53

root@OpenWrt:~# dig mark33.flirtising.com

; <<>> DiG 9.9.4 <<>> mark33.flirtising.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43945
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mark33.flirtising.com. IN A

;; Query time: 13 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 26 15:52:33 GMT 2014
;; MSG SIZE rcvd: 50

Od Jan Čermák (>>)

Dne 2014-11-27 09:55

Opravdu to vypadá na IP adresu se špatným reverzním záznamem, doporučuji vypnout překlad adres na doménová jména a podívat se, která adresa to je. V seznamu z Majordoma jste měl dvě adresy 80/TCP, takže by snad neměl být problém tu IP identifikovat. Nebo můžete pustit netstat s flagem -n, pokud tam ta adresa pořád je.

Od JFila

Dne 2014-11-27 11:05

Tak jedná se o adresu 5.231.23.233:

IP Address: 5.231.23.233
Netblock: 005/8
Status: ALLOCATED
Detail: RIPE NCC

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '5.231.23.0 - 5.231.23.255'

% Abuse contact: for '5.231.23.0 - 5.231.23.255' is 'abuse@ghostnet.de'

inetnum:        5.231.23.0 - 5.231.23.255
netname:        DE-GHOSTNET-FRA-GN-HOSTING-VPS
descr:          GHOSTnet Network used for VPS Hosting Services
descr:          Assigned 20120912
country:        DE
admin-c:        GN-RIPE
tech-c:         GN-RIPE
status:         ASSIGNED PA
mnt-by:         GHOSTNET-MNT
mnt-lower:      GHOSTNET-MNT
mnt-routes:     GHOSTNET-MNT
remarks:        INFRA-AW
source:         RIPE # Filtered

% Information related to '5.231.23.0/24AS12586'

route:          5.231.23.0/24
descr:          GHOSTnet GmbH IP Space
origin:         AS12586
mnt-by:         GHOSTNET-MNT
source:         RIPE # Filtered

% This query was served by the RIPE Database Query Service version 1.76 (DB-3)

Od Ondřej Caletka (>>>)

Dne 2014-11-27 13:32

Nemáte náhodou někde v sítí Hamachi? Neleakuje vám do lokální sítě prefix 5.0.0.0/8, který si v Hamachi sprostě ukradli?

Od JFila

Dne 2014-11-27 13:56

Hamači to už je dávno, už ho dlouho nepoužívám. Jinak logy jsou z času kdy v síti byla zapnutá jen čtyři zařízení (Turris, router a router, VoIP - ten se připojuje jen ke svému SIP server). Všechny zařízení jsem zresetoval a během hodiny se uvedená adresa vždy zaloguje.

Od commar

Dne 2014-11-30 15:10

Napadla mě taková věc, kdy budu k prvnímu v měsíci chtít vymazat databázi Majordoma,
existuje něco jako majordomo_db -reset, nebo stačí smazat položky v /majordomo_db a restartovat router?
Díky...

Od NONES

Dne 2014-11-30 15:26

Ve výchozím nastavení je databáze majordoma nasměrována do paměti /var/..., jejíž obsah se smaže při každém restartu routeru. Tak pokud jste nastavení neměnil, nic mazat nemusíte a stačí jen provést restart routeru.

Od commar

Dne 2014-11-30 15:33

Právě že měnil, DB mám na flashce, /mnt/nas/folder/majordomo_db
Vyměnil jsem pár věcí v síti a nechci aby se mi staré MAC adresy stále zobrazovaly.

Dík...

Od JFila

Dne 2014-11-30 15:53

Stačí skutečně jen smazat soubory, klidně všechny, majordomo si je znovu vytvoří. Nebo je možné data smazat dle vlastního výběru, viz názvy souborů.

root@turris:# ls /tmp/majordomo_db/
majordomo_daily_2014-11-30        majordomo_hourly_2014-11-30-13
majordomo_hourly_2014-11-30-08    majordomo_hourly_2014-11-30-14
majordomo_hourly_2014-11-30-09    majordomo_monthly_2014-11
majordomo_hourly_2014-11-30-10    majordomo_origin_monthly_2014-11
majordomo_hourly_2014-11-30-11    majordomo_serialized_mac_vendor
majordomo_hourly_2014-11-30-12    majordomo_serialized_ptr

Od NONES

Dne 2014-11-30 17:01

Skoro to láká napsat to jako pravidelně spouštěný job v cronu - třeba každého prvního dne v měsící v 00 ráno. Jdu na to.

Od commar

Dne 2014-11-30 17:22

Už mě to taky napadlo... :grin:

Od NONES

Dne 2014-11-30 17:31

Já už to mám napsané a nastavené. Dnes o půlnoci první běh.

Od commar

Dne 2014-11-30 18:30

Já asi taky, prosím zkušené o kontrolu:

0 0 1 * * root rm -rf /mnt/nas/folder/majordomo_db

vloženo do:

/etc/cron.d/majordomo

Správně?

Od NONES

Dne 2014-11-30 18:50

Já mám na konci příkazu ještě hvězdičku - celý můj příkaz zní:rm -rf /mnt/nas/folder/majordomo_db/*
Bez té hvězdy na konci mi to mazalo i adresář "majordomo_db", o což jsem vůbec nestál.

Ještě mne napadá, zda-li by se stejného efektu - tj. průběžného odmazávání starých souborů - nedalo dosáhnout správnou kombinací parametrů "Počet ukládaných hodinových/denních/měsíčních souborů, ale nemám moc čas na experimentování. Mazaní k prvnímu dni v měsíci je sice trošku "brute-force", ale funkční a rychlé.

Od commar

Dne 2014-11-30 18:58

Aha, tak * jsem doplnil...
Mě to takhle stačí, uvidíme ráno... :grin:

Od commar

Dne 2014-12-01 09:23

Tak smazání neproběhlo, mazal jsem po půlnoci ručně...
Možná to chtělo po zadání restart, no uvidíme za měsíc...

Od NONES

Dne 2014-12-01 15:55

Mně smazání proběhlo korektně. Drobnou korekturu ale bude třeba provést, protože mi tam zůstali data za poslední hodinu včerejšího dne. Mazání jsem prováděl (respektive CRON :-)) přesně o půlnoci, ale minutku na to se v adresáři vytvořil soubor z hodiny 23:00 - 23:59, který si router držel pravděpodobně někde v cache a teprve po ukončení sledovaného časového rozsahu ho dávkově "vyplivl" do úložiště. Pro příští měsíc posunu čas mazání databáze majordoma na cca 5 min. po půlnoci.

Od commar

Dne 2015-01-02 10:22

Tak jsem to posunul taky na 5. minutu a smazání s koncem roku už proběhlo v pořádku...

Od commar

Dne 2015-02-27 12:14

Pozor kolego, instalace Turrisu 2.0 přepsala můj původní /etc/cron.d/majordomo
a smazala nastavené mazání dat, opravte si své nastavení...

Od NONES

Dne 2015-02-28 18:23

Děkuji za upozornění, kolego. Ale u mne je vše v pořádku - prozíravě jsem nazval svůj soubor pro mazání v cronu jinak než majordomo. Aktualizace mi s ním nic neprovedla a jen přidala nový soubor majordomo s příkazy od CZ.NICu.

Od commar

Dne 2015-02-28 19:59

Hm, člověk se pořád učí... :lol:

Od JFila

Dne 2014-11-30 19:02 Upraveno 2014-11-30 19:06

Tak update, příčina spojení prvního routeru byla nalezena. Bylo povoleno DHCPv6, po vypnutí této volby se již spojení v majordomu nezobrazují.

Interfaces -> LAN -> DHCP Server -> IPv6 Settings -> DHCPv6-Service Server Mode

Na marka33 jsem ještě nepřišel, nasniffoval jsem toto:

0.001704  2014-11-29 10:20:22.949847  192.168.1.2  5.231.23.233  TCP  0.001704  66  51268→80 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=2
2.999569  2014-11-29 10:20:25.949416  192.168.1.2  5.231.23.233  TCP  2.999569  66  [TCP Retransmission] 51268→80 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=2
6.000118  2014-11-29 10:20:31.949534  192.168.1.2  5.231.23.233  TCP  6.000118  66  [TCP Retransmission] 51268→80 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=2

Toto se stále opakuje.

Od Ondřej Caletka (>>>)

Dne 2014-11-30 22:29

Tak teď už tomu vůbec nerozumím. Tvrdil jste, že máte routery zapojené jako switche. Ale podle tohoto popisu to vypadá, že se vlastně chovaly jako routery. Tak jak to tedy vlastně bylo?

Pokud se chovaly jako routery, pak je logické, je jejich MAC adresou bude reprezentován veškerý provoz z počítačů za nimi.

Od JFila

Dne 2014-12-01 07:06

Ano jako switch, pro jistotu přikládám konfigurák:

config 'switch' 'eth0'
option 'enable' '1'

config 'switch_vlan' 'eth0_0'
option 'device' 'eth0'
option 'vlan' '0'
option 'ports' '0 1 2 3 4 5'

config 'interface' 'loopback'
option 'ifname' 'lo'
option 'proto' 'static'
option 'ipaddr' '127.0.0.1'
option 'netmask' '255.0.0.0'

config 'interface' 'lan'
option 'type' 'bridge'
option 'ifname' 'eth0.0'
option 'proto' 'static'
option 'netmask' '255.255.255.0'
option 'ipaddr' '192.168.1.2'
option 'gateway' '192.168.1.1'
option 'defaultroute' '1'
option 'peerdns' '0'
option 'ip6gw' 'xxxx:xxxx:xxxx:xxxx:0:0:0:1'
option 'ip6addr' '2xx:xxxx:xxxx:xxxx::20/64'
option 'dns' '192.168.1.1'

Od Ondřej Caletka (>>>)

Dne 2014-12-01 09:53

Tak už možná vím, proč se routeru komunikace nedaří. V konfiguraci switche máte všechny porty nastaveny jako netagované, ale v konfiguraci LAN máte nastaveno ifname eth0.0, takže se tam očekávají tagované rámce s tagem 0. Zřejmě nějakou chybou jedna strana přijímá i tagované rámce jako netagované a tím se to rozbíjí.

Od JFila

Dne 2014-12-04 16:07

Na radu jsem opravil nastavení bohužel, pokusy o spojení se stále objevují. Pro jistotu jsem nahrál do routeru nový image OpenWRT ale adresa mark33 se objevuje stále:

config switch 'eth0'
option name 'eth0'
option reset '1'

config switch_vlan
option device 'eth0'
option vlan '1'
option ports '0 1 2 3 4 5'

config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config globals 'globals'
option ula_prefix 'fd9f:f8a3:3101::/48'

config interface 'lan'
option ifname 'eth0'
option force_link '1'
option type 'bridge'
option proto 'static'
option netmask '255.255.255.0'
option peerdns '0'
option dns '192.168.1.1'
option defaultroute '1'
option ipaddr '192.168.1.2'
option gateway '192.168.1.1'
option ip6gw 'xxxx:xxxx:FF00:xxxx:0:0:0:1'
option ip6addr 'xxxx:xxxx:ff00:xxxx::20/64'

root@Pracovna:~# netstat -a -p
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address    Foreign Address    State    PID/Program name
tcp 0 0 0.0.0.0:www    0.0.0.0:*    LISTEN 851/uhttpd
tcp 0 0 0.0.0.0:domain 0.0.0.0:*    LISTEN 948/dnsmasq
tcp 0 0 0.0.0.0:ssh    0.0.0.0:*    LISTEN 808/dropbear
tcp 0 0 Pracovna.lan:ssh 192.168.1.1:37028    ESTABLISHED 10076/dropbear
tcp 0 1 Pracovna.lan:40852 mark33.flirtising.com:www SYN_SENT 10081/wget
tcp 0 0 :::9100    :::* LISTEN 814/p9100d
tcp 0 0 :::bacula-dir    :::* LISTEN 816/p9101d
tcp 0 0 :::bacula-fd :::* LISTEN 818/p9102d
tcp 0 0 :::www :::* LISTEN 851/uhttpd
tcp 0 0 :::domain    :::* LISTEN 948/dnsmasq
tcp 0 0 :::ssh :::* LISTEN 808/dropbear
udp 0 0 0.0.0.0:domain 0.0.0.0:*    948/dnsmasq
udp 0 0 :::domain    :::* 948/dnsmasq
raw 0 0 ::%4562148:58    :::* 58 765/odhcpd
raw 0 0 ::%4562148:58    :::* 58 765/odhcpd
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags    Type    State    I-Node PID/Program name Path
unix 2 [ ACC ]    STREAM    LISTENING 302 326/ubusd    /var/run/ubus.sock
unix 7 [ ]    DGRAM 1003 705/logd /dev/log
unix 3 [ ]    STREAM    CONNECTED 387 1/procd
unix 3 [ ]    STREAM    CONNECTED    1061 740/netifd
unix 3 [ ]    STREAM    CONNECTED    1109 765/odhcpd
unix 3 [ ]    STREAM    CONNECTED    1339 326/ubusd    /var/run/ubus.sock
unix 3 [ ]    STREAM    CONNECTED    1005 705/logd
unix 3 [ ]    STREAM    CONNECTED    1110 326/ubusd    /var/run/ubus.sock
unix 3 [ ]    STREAM    CONNECTED    1338 851/uhttpd
unix 2 [ ]    DGRAM 1391 740/netifd
unix 3 [ ]    STREAM    CONNECTED    1006 326/ubusd    /var/run/ubus.sock
unix 2 [ ]    DGRAM 1128 787/crond
unix 2 [ ]    DGRAM 1383 740/netifd
unix 3 [ ]    STREAM    CONNECTED 388 326/ubusd    /var/run/ubus.sock
unix 3 [ ]    STREAM    CONNECTED    1062 326/ubusd    /var/run/ubus.sock
unix 2 [ ]    DGRAM 1080 1/procd
unix 2 [ ]    DGRAM 1545 948/dnsmasq
unix 2 [ ]    DGRAM 1285 808/dropbear

16:00:22.673969 IP (tos 0x0, ttl 64, id 13567, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.2.40859 > mark33.flirtising.com.www: Flags [S], cksum 0xf657 (correct), seq 1574646652, win 14600, options [mss 1460,sackOK,TS val 6621059 ecr 0,nop,wscale 2], length 0
16:00:22.715928 IP (tos 0x0, ttl 54, id 56170, offset 0, flags [DF], proto TCP (6), length 52)
nibiru.zarea.net.www > 192.168.1.2.35031: Flags [.], cksum 0xb03c (correct), seq 262, ack 154, win 122, options [nop,nop,TS val 671984728 ecr 6621057], length 0
16:00:23.668706 IP (tos 0x0, ttl 64, id 13568, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.2.40859 > mark33.flirtising.com.www: Flags [S], cksum 0xf5f3 (correct), seq 1574646652, win 14600, options [mss 1460,sackOK,TS val 6621159 ecr 0,nop,wscale 2], length 0
16:00:25.668731 IP (tos 0x0, ttl 64, id 13569, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.2.40859 > mark33.flirtising.com.www: Flags [S], cksum 0xf52b (correct), seq 1574646652, win 14600, options [mss 1460,sackOK,TS val 6621359 ecr 0,nop,wscale 2], length 0

Od Ondřej Caletka (>>>)

Dne 2014-12-06 12:48 Hlasů 1

Tady je vidět, že o dané spojení se pokouší wget. Zjistil jste, kdo je rodičem toho procesu s číslem 10081?

Od JFila

Dne 2014-12-06 14:38 Upraveno 2014-12-06 14:58

Pěkné sobotní odpoledne, děkuji za radu. Udělal jsem si následující skriptík, už jenom počkám až se nám mark33 chytne. Co může dělat ta ostatní spojení, jak to najít?

#/bin/bash
while true; do
   pstree -a > /tmp/procesy.txt
   if grep -q "mark33" "/tmp/procesy.txt";
   then
      echo "Je to tam!"
      cat /tmp/procesy.txt
      break;
   fi
   #sleep 5
done

Od JFila

Dne 2014-12-07 21:04

Tak problém s markem33 vyřešen, kdysi jsem měl kdesi záložní server s databází a teploty z teploměru jsem ukládat na dva servery. Záložní server zanikl a někdo mu přidal tento reverzní záznam ale můj teploměr jsem už neopravil.

Jinak k uvedeným dalším pokusům o spojení na routerech jsem vypnul tyto démony:
odhcpd - IPv6 DHCP neměl by být potřeba DHCP dělá náš Turris
dnsmasq - stejné jako předchozí

Ještě nějaké jiné pokusy nebo rady?