Log van IPCHAINS: is dit een hacker?

[SnoW]

In mijn logs zie ik momenteel de volgende regels verschijnen (en dat loopt nog steeds door):

Jun 25 16:55:54 s kernel: Packet log: input DENY ppp0 PROTO=6 148.235.242.195:1232 mijn.ip.adres:119 L=48 S=0x00 I=39446 F=0x4000 T=110 SYN (#20)

Het getal achter het IP-adres 148.235.242.195 loopt op vanaf 1032.

Wat is dit? Voert iemand een portscan uit? Ik ben (nog) niet echt een expert op dit gebied, dus alle hulp kan ik gebruiken. En wat moet ik hiermee? Kan ik dit ergens melden? En moet ik me zorgen maken?

[Verwijderd]

Nahh een hacker zullen we hem maar niet noemen he

Is iemand die probeert om bij jou op poort 119 (news; nntp) te connecten. Dit connecten gebeurt bij hem op een hoge poort (die inderdaad zal wisselen).

Als je niks op poort 119 hebt draaien (news-server: bijvoorbeeld INN), hoef je je nergens druk om te maken. Als je wel iets hebt draaien op poort 119 hoef je je ook nog nergens druk om te maken, aangezien je firewall (zoals je in je logs kan zien) netjes alles DENY-ed.

Controleer wel even of de persoon niet toevallig op nog meer poorten probeert te verbinden en controleer of je niet toevallig onnodige (voor de buitenwereld toegankelijke) services hebt draaien

Overigens gaf een DIG naar het genoemde IP-adres niks terug.
Reverse mapping (PTR-record) werkt dus blijkbaar niet voor dat IP-adres.

[SnoW]

Op maandag 25 juni 2001 17:10 schreef nelske het volgende:
Is iemand die probeert om bij jou op poort 119 (news; nntp) te connecten. Dit connecten gebeurt bij hem op een hoge poort (die inderdaad zal wisselen).

Gelukkig. Sorry als ik wat overhaaste conclusies trok, maar ik heb hier gewoon nog niet voldoende verstand van.

Nog een vraagje m.b.t. mijn firewall: iemand heeft 'm voor mij geinstalleerd en daarbij deze regels neergezet:
# Accepting all incoming traffic to ports of 1024 and up except 6000-6010 (X)
/sbin/ipchains -A input -i $internet -d 0/0 1024:5999 -p TCP -j ACCEPT
/sbin/ipchains -A input -i $internet -d 0/0 6010: -p TCP -j ACCEPT
/sbin/ipchains -A input -i $internet -d 0/0 1023:5999 -p UDP -j ACCEPT
/sbin/ipchains -A input -i $internet -d 0/0 6010: -p UDP -j ACCEPT

Is dit nodig? Ik draai behalve een webserver niks dat voor de buitenwereld toegankelijk hoeft te zijn. Kan ik die poorten niet beter dichtlaten?

[The Jester]

Meteen eruit slopen!
Je hebt ze inderdaad niet nodig. Waarom enkel 6000-6010 dicht worden getimmerd en niet bij voorbeeld 8080 is mij ook een raadsel...

Draai zelf Debian en die zet standaard alles gewoon dicht. Wel zo veilig

[The Jester]

F.y.i. je ongenode gast is een Spic:
UniNet S.A. de C.V. (NETBLK-UNINET-NET10)
Periferico Sur #31900, Jardines del Pedregal
Mexico, D.F. 01900
MX Netname: UNINET-NET10
Netblock: 148.235.0.0 - 148.235.255.255
Maintainer: UNSA Coordinator:
Uninet, IPs (IU1-ARIN) [e-mail]
(52)54-90-70-51 Domain System inverse mapping provided by: DNS.UNINET.NET.MX200.33.150.193
NSGDL1.UNINET.NET.MX200.23.242.193 Record last updated on 11-Apr-2000.
Database last updated on 23-Jun-2001 23:00:43 EDT.

Trace vanaf http://nitrous.digex.net/mae/mae-lg.html
Type escape sequence to abort.
Tracing the route to du-148-235-242-195.prodigy.net.mx (148.235.242.195) 1 dca1-core12-pos6-0.atlas.icix.net (165.117.48.205) 4 msec
dca1-core10-pos7-0.atlas.icix.net (165.117.48.193) 0 msec
dca1-core12-pos6-0.atlas.icix.net (165.117.48.205) 4 msec
2 dca1-core11-pos7-0.atlas.icix.net (165.117.48.198) 0 msec
dca6-core1-pos7-0.atlas.icix.net (165.117.48.105) 32 msec
dca1-core11-pos7-0.atlas.icix.net (165.117.48.198) 0 msec
3 icix.wilcom.net (165.117.67.50) 0 msec
dca6-core5-pos5-0.atlas.icix.net (165.117.48.78) 0 msec
icix.wilcom.net (165.117.67.50) 0 msec
4 dca6-core1-pos7-0.atlas.icix.net (165.117.48.105) 0 msec
64.200.95.73 [AS 7911] 0 msec
dca6-core1-pos7-0.atlas.icix.net (165.117.48.105) 64 msec
5 64.200.240.45 [AS 7911] 108 msec
icix.wilcom.net (165.117.67.50) 224 msec
64.200.240.45 [AS 7911] 80 msec
6 64.200.95.77 [AS 7911] 4 msec
64.200.87.74 [AS 7911] 80 msec
64.200.95.77 [AS 7911] 0 msec
7 chcgil1wcx3-oc48.ipcc.wcg.net (64.200.240.37) [AS 7911] 80 msec
64.200.240.45 [AS 7911] 88 msec
chcgil1wcx3-oc48.ipcc.wcg.net (64.200.240.37) [AS 7911] 80 msec
8 64.200.87.74 [AS 7911] 80 msec
64.200.103.77 [AS 7911] 80 msec
64.200.87.74 [AS 7911] 80 msec
9 dllstx1wcx2-oc48.ipcc.wcg.net (64.200.240.26) [AS 7911] 44 msec
chcgil1wcx3-oc48.ipcc.wcg.net (64.200.240.37) [AS 7911] 80 msec
dllstx1wcx2-oc48.ipcc.wcg.net (64.200.240.26) [AS 7911] 44 msec
10 64.200.103.77 [AS 7911] 80 msec
64.200.232.194 [AS 7911] 44 msec
64.200.103.77 [AS 7911] 80 msec
11 telmex.monterrey.oc-3.ipcc.wcg.net (64.200.226.14) [AS 7911] 84 msec
dllstx1wcx2-oc48.ipcc.wcg.net (64.200.240.26) [AS 7911] 44 msec
telmex.monterrey.oc-3.ipcc.wcg.net (64.200.226.14) [AS 7911] 80 msec
12 64.200.232.194 [AS 7911] 40 msec
tntroma3-3-33.telmex.net.mx (200.38.199.33) [AS 8151] 80 msec
64.200.232.194 [AS 7911] 44 msec
13 bb-mex-vallejo-1-p4-0.mex.uninet.net.mx (200.38.192.178) [AS 8151] 100 msec
telmex.monterrey.oc-3.ipcc.wcg.net (64.200.226.70) [AS 7911] 108 msec
bb-mex-vallejo-1-p4-0.mex.uninet.net.mx (200.38.192.178) [AS 8151] 100 msec
14 tntroma3-3-33.telmex.net.mx (200.38.199.33) [AS 8151] 88 msec
tntroma1-1-189.telmex.net.mx (200.38.192.189) [AS 8151] 100 msec
tntroma3-3-33.telmex.net.mx (200.38.199.33) [AS 8151] 88 msec
15 inet-yuc-yaxkin-1-pos3-o.yuc.uninet.net.mx (200.38.192.201) [AS 8151] 128 msec
bb-mex-vallejo-1-p4-0.mex.uninet.net.mx (200.38.192.178) [AS 8151] 104 msec
inet-yuc-yaxkin-1-pos3-o.yuc.uninet.net.mx (200.38.192.201) [AS 8151] 128 msec
16 tntroma1-1-189.telmex.net.mx (200.38.192.189) [AS 8151] 104 msec
inet-yuc-plaza-4-pos2-1.yuc.uninet.net.mx (148.223.223.50) [AS 8151] 124 msec
tntroma1-1-189.telmex.net.mx (200.38.192.189) [AS 8151] 104 msec
17 customer-38-202-104.uninet.net.mx (200.38.202.104) [AS 8151] 172 msec
inet-yuc-yaxkin-1-pos3-o.yuc.uninet.net.mx (200.38.192.201) [AS 8151] 132 msec
customer-38-202-104.uninet.net.mx (200.38.202.104) [AS 8151] 180 msec
18 inet-yuc-plaza-4-pos2-1.yuc.uninet.net.mx (148.223.223.50) [AS 8151] 132 msec
du-148-233-223-133.telmex.net.mx (148.233.223.133) [AS 8151] 184 msec
inet-yuc-plaza-4-pos2-1.yuc.uninet.net.mx (148.223.223.50) [AS 8151] 132 msec
19 du-148-235-242-195.prodigy.net.mx (148.235.242.195) [AS 8151] 440 msec
customer-38-202-120.uninet.net.mx (200.38.202.120) [AS 8151] 196 msec
du-148-235-242-195.prodigy.net.mx (148.235.242.195) [AS 8151] 420 msec

Je zou evt. z'n provider kunnen mailen met het verzoek uit te vogelen wat die Pancho aan het doen is. Wellicht probeert er iemand vanaf dat adres te spammen en kunnen ze 'em aanpakken.

[radi0man]

Op maandag 25 juni 2001 17:20 schreef SnoW het volgende:
# Accepting all incoming traffic to ports of 1024 and up except 6000-6010 (X)
/sbin/ipchains -A input -i $internet -d 0/0 1024:5999 -p TCP -j ACCEPT
/sbin/ipchains -A input -i $internet -d 0/0 6010: -p TCP -j ACCEPT
/sbin/ipchains -A input -i $internet -d 0/0 1023:5999 -p UDP -j ACCEPT
/sbin/ipchains -A input -i $internet -d 0/0 6010: -p UDP -j ACCEPT

Die regels staan standaard in de ipchains FAQ geloof ik. 6000-6010 zijn poorten die door X worden gebruikt. Als je wil dat iedereen zich met X op jouw machine kan aanmelden, moet je ze openzetten
De poortnummers t/m poort 1024 zijn vast toegewezen aan bepaalde protocollen (zie ook /etc/services). Alles boven poort 1024 is officieel vrij beschikbaar voor gebruik door andere applicaties. Als je met een computer het Internet opgaat, zal die dan ook gebruik maken van een poortnummer boven de 1024 (muv Windows, die zich daar niets van aantrekt). Als je die poorten dus helemaal dichtzet, zal je Internet verbinding niet veel meer doen

[Verwijderd]

Op maandag 25 juni 2001 18:31 schreef radi0man het volgende:

[..]

Die regels staan standaard in de ipchains FAQ geloof ik. 6000-6010 zijn poorten die door X worden gebruikt. Als je wil dat iedereen zich met X op jouw machine kan aanmelden, moet je ze openzetten
De poortnummers t/m poort 1024 zijn vast toegewezen aan bepaalde protocollen (zie ook /etc/services). Alles boven poort 1024 is officieel vrij beschikbaar voor gebruik door andere applicaties. Als je met een computer het Internet opgaat, zal die dan ook gebruik maken van een poortnummer boven de 1024 (muv Windows, die zich daar niets van aantrekt).

Dat doet windows ook netjes hoor

Als je die poorten dus helemaal dichtzet, zal je Internet verbinding niet veel meer doen

Tja toch is het wel zo verstandig om nieuwe verbindingen er even uit te vissen.
Ofwel je wil inderdaad wel Iput-reply verkeer (verkeer dat jij geinitieerd hebt op een hoge (unpriveliged) poort, richting een server) toelaten in de INPUT chain.

Een regeltje zou er dan zo uit zien:

code:

/sbin/ipchains -A input ! -y -p tcp -s 0.0.0.0/0 -d $EXTIP 1024:65535 -j ACCEPT

$EXTIP kan vervangen worden door je externe IP-adres.
Verder zou je er nog de optie "-i" bij kunnen doen, dat het alleen geldt voor de NIC die voor je Internet zorgt.

[Verwijderd]

de optie -y zou ik ook gebruiken

inkomendend verkeer van internet wil je alleen toelaten als de SYN bit er niet op zit, tenzij je een (web-)server hebt draaien.

"! -y" staat voor niet syn

[Verwijderd]

The_Jester: Je zou evt. z'n provider kunnen mailen met het verzoek uit te vogelen wat die Pancho aan het doen is.

du-148-235-242-195.prodigy.net.mx (148.235.242.195)

Met ISP = Prodigy van staatstelecombedrijf TelMex te Mexico?

Fat chance...

[Verwijderd]

Op dinsdag 26 juni 2001 11:50 schreef Zemanova het volgende:
de optie -y zou ik ook gebruiken

inkomendend verkeer van internet wil je alleen toelaten als de SYN bit er niet op zit, tenzij je een (web-)server hebt draaien.

"! -y" staat voor niet syn

Die (web)server draait normaal gesproken toch op lage poorten en zo niet, dan maak je even een los ALLOW regeltje aan voor die server he

Op dinsdag 26 juni 2001 11:55 schreef Arien het volgende:
The_Jester: Je zou evt. z'n provider kunnen mailen met het verzoek uit te vogelen wat die Pancho aan het doen is.
[..]

Met ISP = Prodigy van staatstelecombedrijf TelMex te Mexico?

Fat chance...

Ghe.....lijkt me inderdaad sterk dan