---

Hej,

Efter skift til en mere fast opkobling (TDC kabelnet) hoder jeg lidt
øje med min goe gamle Slackware (som forhåbentlig snart bliver
opgraderet).

Første forskrækkelse var da disken pludselig blev aktiv "uden grund",
og en find -mmin -10 afslørede at der blev skrevt i Apaches
access_log. Apache var åbenbart kommet til live da der kom
ethernetkort i dyret. Nogen prøvede at starte
div. Windows-programmer ad den vej. - Apache er aflivet igen!

Da jeg stadig så netværksaktivitet jeg ikke forstod, har jeg så
installeret tcpdump (og libpcap) fra www.tcpdump.org for at kunne
kigge med.

Kørte tcpdump -vvv pipet til en fil.

tcpdump output filtreret med

grep 8f-cc-f7 tcpdump.log |grep -v ns2\.

afslører denne trafik:

16:01:07.250925 168.126.168.1.4675 > min-mac-adr.k1.webspeed.dk.1433:
S [tcp sum ok] 573138929:573138929(0) win 8192 <mss 1460> (DF) (ttl 108, id 536
61, len 44)
16:01:07.251071 min-mac-adr.k1.webspeed.dk.1433 > 168.126.168.1.4675:
R [tcp sum ok] 0:0(0) ack 573138930 win 0 (ttl 255, id 2764, len 40)
16:01:08.049775 168.126.168.1.4675 > min-mac-adr.k1.webspeed.dk.1433:
S [tcp sum ok] 573138929:573138929(0) win 8192 <mss 1460> (DF) (ttl 108, id 557
09, len 44)
16:01:08.049864 min-mac-adr.k1.webspeed.dk.1433 > 168.126.168.1.4675:
R [tcp sum ok] 0:0(0) ack 1 win 0 (ttl 255, id 2769, len 40)
16:01:08.854421 168.126.168.1.4675 > min-mac-adr.k1.webspeed.dk.1433:
S [tcp sum ok] 573138929:573138929(0) win 8192 <mss 1460> (DF) (ttl 108, id 572
45, len 44)
16:01:08.854513 min-mac-adr.k1.webspeed.dk.1433 > 168.126.168.1.4675:
R [tcp sum ok] 0:0(0) ack 1 win 0 (ttl 255, id 2770, len 40)
16:01:09.661224 168.126.168.1.4675 > min-mac-adr.k1.webspeed.dk.1433:
S [tcp sum ok] 573138929:573138929(0) win 8192 <mss 1460> (DF) (ttl 108, id 592
93, len 44)
16:01:09.661310 min-mac-adr.k1.webspeed.dk.1433 > 168.126.168.1.4675:
R [tcp sum ok] 0:0(0) ack 1 win 0 (ttl 255, id 2771, len 40)

168.126.168.1 kan ikke identificeres med nslookup eller whois. Er det
en "internt brug" adresse?

Men den findes et eller andet sted:
root /home/mdc# traceroute 168.126.168.1
traceroute to 168.126.168.1 (168.126.168.1), 30 hops max, 40 byte packets
1 10.2.0.1 (10.2.0.1) 7.975 ms 5.98 ms 7.15 ms
2 194.239.10.225 (194.239.10.225) 6.576 ms 8.363 ms 6.259 ms
3 ge-0-2-1-2.1000m.boanxu1.ip.tele.dk (195.249.14.219) 6.695 ms 7.27 ms 7.064 ms
4 pos7-0.2488m.boanxg2.ip.tele.dk (195.249.4.254) 8.155 ms 6.817 ms 12.843ms
5 pos3-0.2488m.kd4nxg2.ip.tele.dk (195.249.7.230) 14.054 ms 12.028 ms 12.477 ms
6 pos5-0.2488m.amsixnxg1.ip.tele.dk (80.63.82.77) 23.611 ms 23.507 ms 23.665 ms
7 pos6-0.2488m.ldn2nxg1.ip.tele.dk (195.249.2.133) 30.427 ms 32.706 ms 32.273 ms
8 pos5-0.2488m.ldn2nxg2.ip.tele.dk (80.63.82.6) 31.672 ms 29.727 ms 31.415 ms
9 kt-london.router.fe2 (195.66.226.147) 30.191 ms 31.345 ms 31.062 ms
10 glgate194-p9-3.kornet.net (211.48.63.109) 107.604 ms 108.674 ms 107.638 ms
11 211.48.63.38 (211.48.63.38) 433.802 ms 454.974 ms 469.421 ms
12 211.48.63.197 (211.48.63.197) 340.808 ms 340.047 ms 339.569 ms
13 218.145.63.8 (218.145.63.8) 311.686 ms 312.947 ms 317.62 ms
14 203.234.255.174 (203.234.255.174) 310.163 ms 306.142 ms 305.742 ms
15 218.145.33.82 (218.145.33.82) 342.806 ms 340.976 ms 344.023 ms
16 211.195.72.7 (211.195.72.7) 307.488 ms 307.042 ms 309.435 ms
17 168.126.168.254 (168.126.168.254) 314.152 ms 315.194 ms 321.899 ms
18 168.126.168.1 (168.126.168.1) 366.703 ms 357.301 ms 368.308 ms

Kan nogen gennemskue det her?

Ved godt jeg burde overskrive det hele med en up-to-date distro, men det
tager jo også lidt tid.

--
Mogens Dybæk Christensen
e-mail mdc at mail dot tele dot dk

---

Mogens Dybæk Christensen skrev:

> 16:01:07.250925 168.126.168.1.4675 > min-mac-adr.k1.webspeed.dk.1433:
> S [tcp sum ok] 573138929:573138929(0) win 8192 <mss 1460> (DF) \
> (ttl 108, id 536 61, len 44)

Tilgang til port 1433 udefra er efter al sandsynlighed besøg af en orm
der går efter Microsoft SQL-server:

   <http://isc.incidents.org/port_details.html?port=1433>

> 168.126.168.1 kan ikke identificeres med nslookup eller whois.

GNU whois kan godt:

#v+
$ whois 168.126.168.1

OrgName: Korea Telecom Research Center
OrgID: KTRC

NetRange: 168.126.0.0 - 168.126.255.255
CIDR: 168.126.0.0/16
NetName: KORNET
NetHandle: NET-168-126-0-0-1
Parent: NET-168-0-0-0-0
NetType: Direct Assignment
NameServer: NS.KORNET.NET
NameServer: NS2.KORNET.NM.KR
Comment:
RegDate: 1994-04-20
Updated: 2000-03-24

TechHandle: KI-ORG-ARIN
TechName: KORnet IP Allocator
TechPhone: +82-2-766-5902
TechEmail: ip@ns.kornet21.net

# ARIN Whois database, last updated 2003-01-17 20:00
# Enter ? for additional hints on searching ARIN's Whois database.
$
#v-


// Klaus

--
><>    vandag, môre, altyd saam

---

Mogens Dybaek Christensen <mdc@mail.tele_.dk> wrote:

> S [tcp sum ok] 573138929:573138929(0) win 8192 <mss 1460> (DF) (ttl 108, id 592
>93, len 44)
>16:01:09.661310 min-mac-adr.k1.webspeed.dk.1433 > 168.126.168.1.4675:
> R [tcp sum ok] 0:0(0) ack 1 win 0 (ttl 255, id 2771, len 40)

Den fremmede maskine bliver ved med at proeve at etablere
forbindelse, og din bliver ved med at afvise den.

>168.126.168.1 kan ikke identificeres med nslookup eller whois. Er det
>en "internt brug" adresse?

Det ville vaere dumt, for saa kunne han aldrig faa svar.

>Ved godt jeg burde overskrive det hele med en up-to-date distro, men det
>tager jo også lidt tid.

Uanset om du opdaterer eller ej, kan du goere din maskine meget
mere sikker ved at sikre dig, at ingen daemons lytter paa dit
(udvendige) netkort. Proev at koere en 'netstat -anptu' og kig
paa output.


--
Allan

---

Allan Olesen wrote:

> Uanset om du opdaterer eller ej, kan du goere din maskine meget
> mere sikker ved at sikre dig, at ingen daemons lytter paa dit
> (udvendige) netkort. Proev at koere en 'netstat -anptu' og kig
> paa output.
>
Hvad på output vil indikere at en uønsket daemon lytter?

Hilsen Claus

>

---

Allan Olesen <aolesen@post3.tele.dk> writes:

>
> Uanset om du opdaterer eller ej, kan du goere din maskine meget
> mere sikker ved at sikre dig, at ingen daemons lytter paa dit
> (udvendige) netkort. Proev at koere en 'netstat -anptu' og kig
> paa output.

Tak for bidragene, jeg gættede også (til Klaus) ud fra pakkelængden,
at det var en connect der blev afvist. Men det er nogle år siden jeg
sidst brugte tcpdump.

Jeg prøvede Allans forslag, her er output:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 1 0 62.243.83.37:1052 216.239.35.119:80 CLOSE_WAIT 177/netscape
tcp 1 0 62.243.83.37:1048 216.239.35.119:80 CLOSE_WAIT 177/netscape
tcp 0 529 62.243.83.37:1043 216.239.37.101:80 LAST_ACK -
tcp 0 0 62.243.83.37:1033 62.243.74.162:119 FIN_WAIT2 -
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN 139/Xwrapper
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN 101/rpc.nfsd
tcp 0 0 0.0.0.0:700 0.0.0.0:* LISTEN 99/rpc.mountd
tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN 94/lpd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 83/rpc.portmap
udp 0 0 0.0.0.0:2049 0.0.0.0:* 101/rpc.nfsd
udp 0 0 0.0.0.0:697 0.0.0.0:* 99/rpc.mountd
udp 0 0 0.0.0.0:111 0.0.0.0:* 83/rpc.portmap

rpc.portmap har jeg selv kikket undrende på. Behøver jeg den? Faktisk mener
jeg ikke at have brug for nogen af rpc-services, og lpd behøver jeg jo heller ikke reklamere med. Men skal selvfølgelig bruge den lokalt.

mvh

--
Mogens Dybæk Christensen
e-mail mdc at mail dot tele dot dk

---

Mogens Dybaek Christensen <mdc@mail.tele_.dk> wrote:

>tcp 1 0 62.243.83.37:1052 216.239.35.119:80 CLOSE_WAIT 177/netscape
>tcp 1 0 62.243.83.37:1048 216.239.35.119:80 CLOSE_WAIT 177/netscape
>tcp 0 529 62.243.83.37:1043 216.239.37.101:80 LAST_ACK -
>tcp 0 0 62.243.83.37:1033 62.243.74.162:119 FIN_WAIT2 -

Trafik fra klienter paa din egen maskine. Kan ignoreres.

>tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN 139/Xwrapper

Grafisk fjernadgang. Sandsynligvis passwordbeskyttet gennem xdm,
gdm eller kdm, men hvorfor tage chancen?

>tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN 101/rpc.nfsd
>tcp 0 0 0.0.0.0:700 0.0.0.0:* LISTEN 99/rpc.mountd
>tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN 94/lpd
>tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 83/rpc.portmap
>udp 0 0 0.0.0.0:2049 0.0.0.0:* 101/rpc.nfsd
>udp 0 0 0.0.0.0:697 0.0.0.0:* 99/rpc.mountd
>udp 0 0 0.0.0.0:111 0.0.0.0:* 83/rpc.portmap
>
>rpc.portmap har jeg selv kikket undrende på. Behøver jeg den? Faktisk mener
>jeg ikke at have brug for nogen af rpc-services,

Det har du sikkert heller ikke. Som regel kun, hvis du koerer
nfs, men det boer man alligevel ikke goere over Internettet, da
nfs gaar for at vaere en af de saarbare services (naturligvis
medmindre man har pakket det ind i f.eks. SSH eller VPN).

>og lpd behøver jeg jo heller ikke reklamere med. Men skal selvfølgelig bruge den lokalt.

Korrekt. Lpd er faktisk en af de rigtigt usikre, som ofte har
vaeret vejen ind for en hacker/cracker. Saa hvis du koerer en
gammel version, ligger din maskine sandsynligvis aaben for, at
andre kan faa root-adgang.

Hvis du ikke kan lukke de ovenstaende daemons eller konfigurere
dem til kun at lytte paa lokalnettet, kan du lappe lidt ved at
lukke din maskine af udadtil med nogle ipchains- eller
iptables-regler. Der er eksempler www.sslug.dk/sikkerhed/ .

Til Claus:
Som du kan se i output ovenfor, adskiller linierne med lyttende
daemons sig markant fra de oevrige linier. Ved tcp-forbindelserne
staar der "LISTEN", og ved baade udp og tcp er fjernadressen som
regel "0.0.0.0:*".

(Og saa kan vi vaere glade for, at vi koerer Linux. Under Windows
vil en klientforbindelse ogsaa ofte vaere maerket "LISTENING", og
saa kan det jo vaere svaert at se forskel paa daemons og
klienter.)


--
Allan