Ports schliessen?!

[hydronic]

Hallo,

ich habe SuSE 8.2 Professionell und schaffe es einfach nicht folgende Ports zu schliessen:


Port State Service
1450/tcp open dwf
1455/tcp open esl-lm
6000/tcp open X11

Folgende Prozesse laufen:

CODE] PID TTY STAT TIME COMMAND
1682 tty2 S 0:00 /sbin/mingetty tty2
1683 tty3 S 0:00 /sbin/mingetty tty3
1684 tty4 S 0:00 /sbin/mingetty tty4
1685 tty5 S 0:00 /sbin/mingetty tty5
1686 tty6 S 0:00 /sbin/mingetty tty6
1733 tty1 S 0:00 -bash
1769 tty1 S 0:00 /bin/sh /usr/X11R6/bin/startx blackbox
1784 tty1 S 0:00 /usr/X11R6/bin/xinit4 /home/hydronic/.xinitrc -- /usr/X11R6/lib/X11/xinit/xserverrc -auth /home/hydro
1826 tty1 S 0:10 /usr/X11R6/bin/blackbox
1891 pts/0 S 0:00 -bash
2004 pts/1 S 0:00 -bash
2047 pts/2 S 0:00 -bash
2066 pts/3 S 0:00 -bash
2114 pts/2 SW 0:00 [su]
2127 pts/2 S 0:01 bash
2511 pts/4 S 0:00 -bash
2534 pts/4 S 1:02 kinternet
2652 pts/5 S 0:00 -bash
2669 pts/5 S 0:19 irssi
2685 pts/6 S 0:00 -bash
2719 pts/6 S 0:43 gkrellm
3812 pts/3 S 0:04 bbkeys -i
15529 pts/1 S 0:00 micq
2222 pts/9 S 0:00 -bash
18116 pts/2 S 0:00 su
18117 pts/2 S 0:00 bash
23198 pts/2 S 0:02 snort -v
23738 pts/8 S 0:00 -bash
23766 pts/8 SW 0:00 [su]
23780 pts/8 S 0:00 bash
27817 pts/11 S 0:00 -bash
27857 pts/11 S 0:00 [su]
27870 pts/11 S 0:00 bash
1178 pts/9 S 0:00 [su]
1193 pts/9 R 0:00 bash
7820 pts/9 R 0:00 ps a[/CODE]

könnt ihr mir sagen wie ich sie schliessen kann?


Vielen Dank im Vorraus
hydronic[

[derRichard]

Original geschrieben von hydronic
Hallo,

ich habe SuSE 8.2 Professionell und schaffe es einfach nicht folgende Ports zu schliessen:


Port State Service
1450/tcp open dwf
1455/tcp open esl-lm
6000/tcp open X11

könnt ihr mir sagen wie ich sie schliessen kann?

Vielen Dank im Vorraus
hydronic
hallo!

du kannst sie mit einem paketfilter schließen.
stichwort: iptables

//richard

[hydronic]

Hallo,

vielen Dank für die schnelle Antwort,
aber wie mache ich das genau mit Iptables?

gruss
hydronic

[derRichard]

hallo!

das ist jetzt aber nur eine sehr "einfache" variante...
iptables -A INPUT -p tcp --dport 1450 -j DROP
iptables -A INPUT -p tcp --dport 1455 -j DROP
iptables -A INPUT -p tcp --dport 6000 -j DROP

//richard

[hydronic]

hallo,

nmap zeigt die ports aber immernoch an:


Port State Service
1450/tcp filtered dwf
1455/tcp filtered esl-lm
6000/tcp filtered X11

kann man sie nicht komplett schliessen?

gruss

[derRichard]

Original geschrieben von hydronic
hallo,

nmap zeigt die ports aber immernoch an:


Port State Service
1450/tcp filtered dwf
1455/tcp filtered esl-lm
6000/tcp filtered X11

kann man sie nicht komplett schliessen?

gruss

_ganz_ schliessen gibt es nicht.
aber wenn nmap "filtered" anzeigt, dann sind die ports nicht mehr errichbar...
aber du kannst das mal versuchen:

iptables -A INPUT -p tcp --dport 1450 -j REJECT
iptables -A INPUT -p tcp --dport 1455 -j REJECT
iptables -A INPUT -p tcp --dport 6000 -j REJECT

//richard

[Matzetronic]

hi,


du kannst sie mit einem paketfilter schließen

stimmt, wenn mans genau nimmt, nicht - du sperrst ja nur den zugriff darauf...

für den port 6000:
in der datei /etc/X11/xinit/xserverrc einfach "-nolisten tcp" anhängen, dann sollte nach einem neustart des x-servers port 6000 dicht sein.

für die anderen zwei ports muss ich erstmal schauen, was das ist - melde mich dann nochmal...

mfg,
matze

[Matzetronic]

hi,

keine ahnung, was das sein soll....

1450/tcp Tandem Distributed Workbench Facility
1455/tcp ESL License Manager

was hast du denn da laufen ?

mfg,
matze

[hydronic]

hallo,

keine ahnung was das ist, ich will es garnicht laufen lassen. habe in /etc/X11/xinit/xserverrc "-nolisten tcp" angehangen und den Xserver neu gestartet, der port ist aber immernoch offen. komischerweise auch dann, wenn der xserver nicht läuft. ich habe oben meine prozesse gepastet, welche prozesse sind denn die beiden

1450/tcp Tandem Distributed Workbench Facility
1455/tcp ESL License Manager

sind.

gruss
hydronic

[derRichard]

Original geschrieben von hydronic
hallo,

keine ahnung was das ist, ich will es garnicht laufen lassen. habe in /etc/X11/xinit/xserverrc "-nolisten tcp" angehangen und den Xserver neu gestartet, der port ist aber immernoch offen. komischerweise auch dann, wenn der xserver nicht läuft. ich habe oben meine prozesse gepastet, welche prozesse sind denn die beiden

1450/tcp Tandem Distributed Workbench Facility
1455/tcp ESL License Manager

sind.

gruss
hydronic
hallo!

mit "lsof -Pni" kannst nachsehen, was wo hört...

//richard

[hydronic]

hi,


COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
micq 10154 hydronic 3u IPv4 10003 TCP 217.86.243.241:2646->64.12.25.158:5190 (ESTABLISHED)
micq 10154 hydronic 4u IPv4 10001 TCP *:2645 (LISTEN)
irssi 10256 hydronic 3u IPv4 10095 TCP 217.86.243.241:2647->151.189.0.165:6667 (ESTABLISHED)

die beiden sind garnicht aufgezählt. wie kann das sein?

gruss hydronic

[Matzetronic]

beende mal bitte dein icq und dein irc-chat und poste dann nochmal die ausgabe von "netstat -an|grep -i listen"

[hydronic]

hi,

hier werden die beiden ports auch nicht angezeigt


thunderdome:/home/hydronic # netstat -an|grep -i listen
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN

vielleicht liegts ja auch an meinem nmap?

gruss hydronic

[Matzetronic]

ok, du könntest den befehl nochmal ausführen, wenn dein irc und icq läuft, dann hast du sicher zwei ports mehr am "lauschen" ;)

aber nochmal zum 6000, wenn ich das richtig sehe, dann liegt deine xserverrc woanders, und zwar in:
/usr/X11R6/lib/X11/xinit/xserverrc

ich poste hier mal meine:

#!/bin/sh
exec /usr/bin/X11/X -dpi 100 -nolisten tcp

also versuch da nochmal bei dir das -nolisten tcp dranzuschreiben....

mfg,
matze

[hydronic]

die file sieht bei mir so aus:


#!/bin/bash

#
# move this file to ~/.xserverrc, if you don't want to allow
# everybody to get access to your X-Server
#

dspnum=":0"
args=""
done=no
if test -z "$XAUTHORITY" ; then
auth="$HOME/.Xauthority"
else
auth="$XAUTHORITY"
fi

xf86version="`/usr/X11R6/bin/xf86version`"
if test "$xf86version" == "XFree86-4.x"; then
xprog=X
else
xprog=Xwrapper
fi

while test -n "$1" ; do
case "$1" in
\:[0-9])
dspnum="$1" ; shift ;;
-auth)
done=yes
args="$args $1" ; shift ;;
*)
args="$args $1" ; shift ;;
esac
done

if test -x "`type -p keygen`" -a "$done" != "yes" ; then
if [ ! -x "`type -p hostname`" ] ; then
echo "startx: can't get my hostname - exiting" 1>&2
exit 1
else
host=`hostname -f`
fi

trap "echo" 1 2 15
cookie="MIT-MAGIC-COOKIE-1 `keygen`"
tcpip="$host$dspnum"
unix="${host%%.*}/unix$dspnum"

xauth -f $auth source - <<-EOF
add $tcpip $cookie
add $unix $cookie
add ${host}/unix$dspnum $cookie
EOF
cookie=

exec $xprog $dspnum -auth $auth $args
else
exec $xprog $dspnum $args
fi

[Matzetronic]

ganz oben:

args="-nolisten tcp"

ich hoffe, dass der port dann zu ist :)


mfg,
matze


edit: so, genug gegoogled...

http://www.google.de/search?hl=de&ie=ISO-8859-1&q=%22-nolisten+tcp%22+SuSE&btnG=Google+Suche

[Unforgiven_II]

Hi

Weil ich auch grade dabei bin frage ich einfach hier in diesem Thread:
Ich hab jetzt jeden Dienst bearbeitet bei mir und Regeln erstellt. Jetzt hab ich aber noch die Frage was "sometimes-rpc3" darstellen soll, und warum dass in nmap nur manchmal auftaucht? Ich hab für "X11" (da ich es auch nicht schaffe das abzustellen irgendwie) eine iptables-Regel erstellt. Jetzt hab ich aber eine (wohl dumme) Frage: Die iptables werden ja "vergessen" wenn ich neu starte, wie schaffe ich es dass sie automatisch gestartet werden beim booten? Wie und wo starte ich das am besten?

Danke für die Gedult :-)

[pablovschby]

stimmt, wenn mans genau nimmt, nicht - du sperrst ja nur den zugriff darauf... ich habe eine völlig abwegige frage hierzu:

meint ihr damit folgendes:
1>ein port ist aktiv und offen----> iptables filtert nicht..., der daemon läuft
2>ein port ist aktiv, aber zu--->du sperrst(wie oben geschrieben) den zugriff darauf...mit bspweise iptables, also iptables sperrt, aber der daemon läuft
3>ein port ist weder offen, noch aktiv...--->dies ist unmöglich mit iptables....iptables schliesst nur den port.....hierzu muss der daemon ausm runlevel genommen werden (oder einfach schnell gekillt, not persistent)

also......bei 1 haben wir eine firewall, die dem telnet-server erlaubt, auf dem telnet-port sein daemon ausuführen und auf anfragen zu reagieren..., daemon läuft
bei 2 haben wir einen telnet-server der läuft, und auch auf anfragen reagieren will, aber nicht kann, weil der port geschlossen wird..., die firewall sperrt
bei 3 haben wir den telnet-server NICHT GESTARTET........und gleichzeitig den port geschlossen.....firewall sperrt und daemon ist down

stimmt diese aussage..?
diese 3 zustände.......?

gruss&danke
pablo
p.s.: wenn das stimmt........dann lerne ich ..... wie ihr.... aber viel...(auch wie ihr....?.....)

[Unforgiven_II]

Nachtrag:

Ich die "lauschfunktion" des X11 jetzt abgeschaltet, bleibt die Frage nach "sometimes-rpc3"
Wozu, warum, ist es?
Und auch wichtig: wenn ich es auf "reject" setze (ist das überhaupt empfehlenswert?) wie schaffe ich es dass die iptables auch beim booten geladen werden?

[HangLoose]

moin


wie schaffe ich es dass die iptables auch beim booten geladen werden?


pack deine regeln in ein script, mach das ganze ausführbar, kopier es nach /etc/init.d und lege mit

ln -s /etc/init.d/myfirewall /etc/init.d/rc3.d/S99myfirewall

einen entsprechenden link in deinen default runlevel.

@pablovschby



also......bei 1 haben wir eine firewall, die dem telnet-server erlaubt, auf dem telnet-port sein daemon ausuführen und auf anfragen zu reagieren..., daemon läuft

richtig


bei 2 haben wir einen telnet-server der läuft, und auch auf anfragen reagieren will, aber nicht kann, weil der port geschlossen wird..., die firewall sperrt

jein, der server bekommt von den anfragen gar nichts mit.


bei 3 haben wir den telnet-server NICHT GESTARTET........und gleichzeitig den port geschlossen.....firewall sperrt und daemon ist down

solange kein dienst an dem port lauscht, ist der port auch geschlossen und bräuchte nicht *geblockt* werden, da die meisten firewallscripte aber erstmal alles verbieten und nur erlauben was auch erlaubt sein soll, stimmt das so schon.


Gruß HL

[Matzetronic]

@pablovschby
Eins, setzen ! ;)
nummer 3 ist der idealfall (wenn man den dienst nicht braucht)

[Unforgiven_II]

Moin!

Inzwischen weiss ich (dank "lsof -i tcp:32770")dass sometimes-rpc3 zu LIcq gehört. Schön und gut, aber wenn ich die Regel
"iptables -A INPUT -p tcp --dport 32770 -j REJECT" anwende, dann zeigt mir nmap den Port als "filtered" an. Da dieser aber zu LIcq gehört frage ich mich warum mein LIcq weiter ohne Probleme connecten und empfangen kann (senden sowieso)...?

[Unforgiven_II]

Original geschrieben von HangLoose
moin

pack deine regeln in ein script, mach das ganze ausführbar, kopier es nach /etc/init.d und lege mit

ln -s /etc/init.d/myfirewall /etc/init.d/rc3.d/S99myfirewall

einen entsprechenden link in deinen default runlevel.

Danke, ich hab dann ein Skript kopiert was schon in /etc/init.d war (ich hab keinen Plan von Skripten, wenn ich es einfach in eine Datei schreibe ist das ja eine Textdatei und kein Skript), diese editiert und mein "iptables -A INPUT -p tcp --dport 32770 -j REJECT" eingetragen. Dann hab ich das ganze gespeichert und mit "ln -s /etc/init.d/myfirewall /etc/rc5.d/S99myfirewall" verlinkt. (Hab den Pfad angepasst). Dann hab ich den Rechner neu gestartet, aber es hat sich nichts getan was ich geschrieben habe. Ich hab jetzt in einem anderen Thread entdeckt dass ich es einfach in "/etc/rc.local" eintragen kann. Das hab ich getan, und jetzt funzt es prima. Wüsste trotzdem gerne was ich davor falsch gemacht habe, vielleicht hat jemand eine Idee :(

[HangLoose]

moin moin

@Unforgiven_II


"iptables -A INPUT -p tcp --dport 32770 -j REJECT" anwende, dann zeigt mir nmap den Port als "filtered" an. Da dieser aber zu LIcq gehört frage ich mich warum mein LIcq weiter ohne Probleme connecten und empfangen kann (senden sowieso)...?

das wird wohl daran liegen, das du den falschen port erwischt hast. ich kenne mich bei icq jetzt nicht so gut aus, aber wenn ich mich nicht irre, verwendet der icq(server) den port 5190 und der port auf deinem client wird jedesmal *ausgehandelt*, kann also jedesmal anders sein. von daher müßtest du die regel auf den *festen* port umstellen, also den source-port.

iptables -A INPUT -p tcp --sport 5190 -j REJECT



Danke, ich hab dann ein Skript kopiert was schon in /etc/init.d war (ich hab keinen Plan von Skripten, wenn ich es einfach in eine Datei schreibe ist das ja eine Textdatei und kein Skript),

richtig, zu einem script wird es erst, wenn du es ausführbar machst => chmod u+x blablabla



Dann hab ich das ganze gespeichert und mit "ln -s /etc/init.d/myfirewall /etc/rc5.d/S99myfirewall" verlinkt. (Hab den Pfad angepasst). Dann hab ich den Rechner neu gestartet, aber es hat sich nichts getan was ich geschrieben habe


ist denn 3 auch dein default-runlevel? ich bin bei meinem posting einfach mal davon ausgegangen.


Gruß HL

[Unforgiven_II]

Original geschrieben von HangLoose
moin moin

@Unforgiven_II

das wird wohl daran liegen, das du den falschen port erwischt hast. ich kenne mich bei icq jetzt nicht so gut aus, aber wenn ich mich nicht irre, verwendet der icq(server) den port 5190 und der port auf deinem client wird jedesmal *ausgehandelt*, kann also jedesmal anders sein. von daher müßtest du die regel auf den *festen* port umstellen, also den source-port.

iptables -A INPUT -p tcp --[b]sport 5190 -j REJECT

Danke, aber ich wollte nur den "sometimes-rpc3" abdichten, das ist der einzige der wenn ich LICQ starte dauernd aktiv ist (und davor nicht). Der läuft auf dem Port und ist nun nach meiner Änderung auch "filtered". Was eignet sich in meinem Fall eigentlich besser für den Portt? DROP oder REJECT?




Original geschrieben von HangLoose
richtig, zu einem script wird es erst, wenn du es ausführbar machst => chmod u+x blablabla Danke



Original geschrieben von HangLoose
ist denn 3 auch dein default-runlevel? ich bin bei meinem posting einfach mal davon ausgegangen.
Gruß HL

Nein, das ist runlevel 5, aber ich habe ja auch in "/etc/rc5.d/" verlinkt. Ich hoffe das war das richtige. Wozu ist eigentlich das "S99" vorne dran? da gibts verschiedene Zahlen.

Danke für eure Gedult :)

[HangLoose]

hi


Was eignet sich in meinem Fall eigentlich besser für den Portt? DROP oder REJECT?

da streiten sich die gelehrten :D. bei einem drop bekommt die gegenseite nichts mit, bei einem reject wird eine *meldung* verschickt => z.b. tcp-reset


Wozu ist eigentlich das "S99" vorne dran? da gibts verschiedene Zahlen.

Start 99 <== die 99 gibt den *zeitpunkt* an, wann das script ausgeführt wird, erst script1, dann script2 ....


Gruß HL

[Unforgiven_II]

Original geschrieben von HangLoose
hi
da streiten sich die gelehrten :D. bei einem drop bekommt die gegenseite nichts mit, bei einem reject wird eine *meldung* verschickt => z.b. tcp-reset

Danke, ich hab mich für REJECT entschieden: Wenn jemand weiss dass ich da bin sendet sein scanner ja dauernd weiter wenn er keine Antwort bekommt, wenn er weiss dass der Port dicht ist hab ich nicht den unnötigen Traffic. Wirklich "stealth" gibt es nicht, wenn KEINE Antwort kommt weiss man genau dass jemand da ist und er den Port "stealth" hat.



Original geschrieben von HangLoose
Start 99 <== die 99 gibt den *zeitpunkt* an, wann das script ausgeführt wird, erst script1, dann script2 ....

Danke, ich hab da mehrere mit S99 drinne, denke die werden dann nach Namen abgearbeitet wenn welche dieselbe Nummer haben.

[Matzetronic]

Wirklich "stealth" gibt es nicht, wenn KEINE Antwort kommt weiss man genau dass jemand da ist und er den Port "stealth" hat.
halte ich schlichtweg für eine falsche aussage. wenn du von einer ip nichts zurückbekommst, woher weißt du, ob da ein rechner läuft ?

[HangLoose]

@Matzetronic

ganz unrecht hat Unforgiven_II nicht, imho gibt es scanner, die erkennen können, ob die pakete gedropt werden.


Gruß HL

[Matzetronic]

hmm, kannst du die funktionsweise näher erläutern - ich kann mir nicht vorstellen, wie das gehen soll.