Hallo Leute, Ich habe einen WebServer installiert. Darauf laeuft mod_ssl, mysql, jserv, php und ein eigenes Java-Programm das auf Port 26000 bzw. 26001 horcht. Ftp und SSH sollen fuer Wartung des Server laufen. Jetzt wollte ich euch fragen ob die Konfig der ipchains so wie unten aufgefuehrt OK ist. -------Begin ipchains -F input ipchains -P input DENY ipchains -P output ACCEPT ipchains -P forward DENY #SSH ipchains -A input --dport 22 -p udp -j ACCEPT ipchains -A input --dport 22 -p tcp -j ACCEPT #http ipchains -A input --dport 80 -p udp -j ACCEPT ipchains -A input --dport 80 -p tcp -j ACCEPT #https ipchains -A input --dport 443 -p udp -j ACCEPT ipchains -A input --dport 443 -p tcp -j ACCEPT #ftp ipchains -A input --dport 20 -p udp -j ACCEPT ipchains -A input --dport 20 -p tcp -j ACCEPT ipchains -A input --dport 21 -p udp -j ACCEPT ipchains -A input --dport 21 -p tcp -j ACCEPT #java programm ipchains -A input --dport 26000 -p tcp -j ACCEPT ipchains -A input --dport 26001 -p tcp -j ACCEPT -------End Fuer Denkanstoesse und Hilfe bin ich dankbar. Gruesse Ingo --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Ingo Holewczuk wrote:
Hallo Leute, Ich habe einen WebServer installiert. Darauf laeuft mod_ssl, mysql, jserv, php und ein eigenes Java-Programm das auf Port 26000 bzw. 26001 horcht. Ftp und SSH sollen fuer Wartung des Server laufen.
^^^
Jetzt wollte ich euch fragen ob die Konfig der ipchains so wie unten aufgefuehrt OK ist.
[ip-chains-Regeln] Hi Ingo, ftp ist unsicher, mit SSH kann man auch Dateien uebertragen. -Marc -- +-----Du hast eine nützliche Linuxseite? Du suchst eine?-----------+ | --> http://www.Links2Linux.de <-- | | | +---Registered-Linux-User-#136487------------http://counter.li.org + --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Marc Schiffbauer schrieb:
ftp ist unsicher, mit SSH kann man auch Dateien uebertragen.
Kannst Du mir sagen, wie? Würde mich auch interssieren, da ich ebenfalls nur ftp kenne (bin froh, ssh überhaupt eingerichtet bekommen zu haben :-)). Gruß Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Thomas Schwarze wrote:
Marc Schiffbauer schrieb:
ftp ist unsicher, mit SSH kann man auch Dateien uebertragen.
Kannst Du mir sagen, wie? Würde mich auch interssieren, da ich ebenfalls nur ftp kenne (bin froh, ssh überhaupt eingerichtet bekommen zu haben :-)).
Sorry, icg weiss nicht mehr wo ich es gesehen habe, aber ich meine es gibt eine Möglichkeit, bzw. eine Software, die ssh nutzt um Dateien uebers Netz zu uebertragen. Ansonsten kann man vieles mit ssh tunneln. Muss es ftp sein? Bei ftp gibt es ein paar Schwierigkeiten: Daten (Files, Dirlistings gehen ueber anderen Ports, lassen sich so AFAIK nicht tunneln) Was man machen kann, ist Port 21 zu forwarden, dann werden wenigstens Passwoerter und Befehle verschluesselt uebertragen. h -L 1234:localhost:21 user@remotehost dann (in anderer lokaler Shell!) ftp localhost 1234 Mit NFS gibt es angeblich auch Probleme. Vielleicht funktioniert das ja (durch die Brust ins Auge) mit nem Samba-Share und smb-mount? Das benutzt nur festgelegte Ports. Ich teste das mal. -Marc -- .~. *** /V\ ************************************************************ * // \\ Center of Excellence Linux * Marc Schiffbauer * * /( )\ * Siemens ITS GmbH & Co. OHG * ** ^`~'^ *********************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hi Marc, Thomas, Liste! Marc Schiffbauer wrote:
... es gibt eine Möglichkeit, bzw. eine Software, die ssh nutzt um Dateien uebers Netz zu uebertragen. Meinst Du scp?
Rgds. Heiko. -- Nuetzliche Samba-Doku online: http://de.samba.org/samba/docs/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Heiko Degenhardt wrote:
Hi Marc, Thomas, Liste!
Marc Schiffbauer wrote:
... es gibt eine Möglichkeit, bzw. eine Software, die ssh nutzt um Dateien uebers Netz zu uebertragen. Meinst Du scp?
yep. :-) Das wars. Aber meinste ich bin da noch drauf gekommen.... ;) Ich habs jetzt aber auch mal mit Samba probiert! Klappt! Man kann also auch per smbclient fpt-like Dateien uebertragen: 1. Shell: ssh -L 1139:<remote-ip>:139 user@remotehost 2. Shell: smbclient //remotehost/share -I 127.0.0.1 -p 1139 mbclient hat ca die gleichen Kommandos wie ftp. Man kann also jetzt mit get datei ein File ziehen etc. Gruss -Marc -- .~. *** /V\ ************************************************************ * // \\ Center of Excellence Linux * Marc Schiffbauer * * /( )\ * Siemens ITS GmbH & Co. OHG * ** ^`~'^ *********************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hi Marc! Marc Schiffbauer wrote:
... smbclient hat ca die gleichen Kommandos wie ftp. Man kann also jetzt mit get datei ein File ziehen etc. Danke fuer die Info!
Nun wuerde ich persoenlich nicht, nur um Dateien zu uebertragen, auf einem Server samba installieren. Da scheint mir denn doch ftp (oder vielleicht scp) "schlanker". ;-) Rgds. Heiko. -- Nuetzliche Samba-Doku online: http://de.samba.org/samba/docs/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Heiko Degenhardt wrote:
Hi Marc!
Marc Schiffbauer wrote:
... smbclient hat ca die gleichen Kommandos wie ftp. Man kann also jetzt mit get datei ein File ziehen etc. Danke fuer die Info!
Nun wuerde ich persoenlich nicht, nur um Dateien zu uebertragen, auf einem Server samba installieren. Da scheint mir denn doch ftp (oder vielleicht scp) "schlanker". ;-)
Es ging ja darum, dass ftp unsicher ist, da alles in Klartext ueber die Leitung geht. Wenn man so eine Art "sicheres ftp" haben will, sprich ftp zu tunneln, dann bekommt man bei ftp Probleme, da die benutzen Ports vorher nicht abzusehen sind (die DATA-Ports). Das tunneln des smbclient von Samba ist hier nur eine Alternative, die komplett verschluesselt ist, und (aehnlich) wie ftp zu bedienen ist. Klar ist fuer die Dateiuebertragung scp dann besser, weil schlanker, weil dafuer gemacht. Gruss -Marc -- .~. *** /V\ ************************************************************ * // \\ Center of Excellence Linux * Marc Schiffbauer * * /( )\ * Siemens ITS GmbH & Co. OHG * ** ^`~'^ *********************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hi Heiko, * Heiko Degenhardt wrote on 26 Apr 2000:
Marc Schiffbauer wrote:
... es gibt eine Möglichkeit, bzw. eine Software, die ssh nutzt um Dateien uebers Netz zu uebertragen. Meinst Du scp?
oder bei SSH2 sftp ? ;-) Gruß, Sebastian -- "No worries." - Rincewind Sebastian Helms - mailto:sebastian@helms.sh (PGP available) SuSE-Linux-Mailinglisten-FAQ: http://www.helms.myokay.net/faq/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hi Leute, Marc Schiffbauer wrote:
Thomas Schwarze wrote:
Marc Schiffbauer schrieb:
ftp ist unsicher, mit SSH kann man auch Dateien uebertragen.
Kannst Du mir sagen, wie? Würde mich auch interssieren, da ich ebenfalls nur ftp kenne (bin froh, ssh überhaupt eingerichtet bekommen zu haben :-)).
Sorry, icg weiss nicht mehr wo ich es gesehen habe, aber ich meine es gibt eine Möglichkeit, bzw. eine Software, die ssh nutzt um Dateien uebers Netz zu uebertragen.
der Befehl lautet scp (kommt glaube ich von secure copy) siehe auch man scp. Ciao Steffen --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Tue, 25 Apr 2000, Ingo Holewczuk wrote:
Ich habe einen WebServer installiert. Darauf laeuft mod_ssl, mysql, jserv, php und ein eigenes Java-Programm das auf Port 26000 bzw. 26001 horcht. Ftp und SSH sollen fuer Wartung des Server laufen. Jetzt wollte ich euch fragen ob die Konfig der ipchains so wie unten aufgefuehrt OK ist.
[some stuff deleted] h ist TCP. HTTP ist TCP. SSL ist TCP. FTP ist TCP. Ansonsten sieht das Teil doch ausreichend Faschistisch aus ;-) Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Carsten Meyer wrote on Tue, Apr 25, 2000 at 21:24 +0200:
On Tue, 25 Apr 2000, Ingo Holewczuk wrote:
[some stuff deleted]
ssh ist TCP. HTTP ist TCP. SSL ist TCP.
laut /etc/services auch für UDP definiert (wenn auch vermutlich praktisch null Bedeutung) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Ich habe einen WebServer installiert. Darauf laeuft mod_ssl, mysql, jserv, php und ein eigenes Java-Programm das auf Port 26000 bzw. 26001 horcht. Ftp und SSH sollen fuer Wartung des Server laufen. Jetzt wollte ich euch fragen ob die Konfig der ipchains so wie unten aufgefuehrt OK ist.
-------Begin ipchains -F input ipchains -P input DENY ipchains -P output ACCEPT ipchains -P forward DENY #SSH ipchains -A input --dport 22 -p udp -j ACCEPT ipchains -A input --dport 22 -p tcp -j ACCEPT #http ipchains -A input --dport 80 -p udp -j ACCEPT ipchains -A input --dport 80 -p tcp -j ACCEPT #https ipchains -A input --dport 443 -p udp -j ACCEPT ipchains -A input --dport 443 -p tcp -j ACCEPT #ftp ipchains -A input --dport 20 -p udp -j ACCEPT ipchains -A input --dport 20 -p tcp -j ACCEPT ipchains -A input --dport 21 -p udp -j ACCEPT ipchains -A input --dport 21 -p tcp -j ACCEPT #java programm ipchains -A input --dport 26000 -p tcp -j ACCEPT ipchains -A input --dport 26001 -p tcp -j ACCEPT -------End falls Du einen oeffentlichen Webserver installierst, solltest Du Dir dringend gute Literatur zulegen. IMHO fehlen bei Deinen Chains ein
Hi Ingo, paar Punkte. Wie sieht es mit dem ACK-Bit aus. Das wird von dem System im ersten Packet gesetzt, welches den Verbindungsaufbau initiert (nur bei TCP). Ausserdem sollten alle Policities auf deny gesetzt sein. Es ist keine gute Idee die output Policity auf ACCEPT zu setzen, so koennen alle Informationen ueber Dein System nach draussen. Die Source-IP repektive die destination-IP sollten soweit moeglich gesetzt sein. Es bringt Dir nichts wenn alles funktioniert und Deine Regeln gar nicht greifen, da die entsprechende Policity auf ACCEPT gesetzt ist. Wie gesagt, wenn Du einen oeffentlichen Webserver aufsetzt, wuerde ich sehr vorsichtig sein. Der Aufbau von chains welche wirklich nur das zulassen was Du moechtest ist relativ komplex, deswegen bringt es Dir glaube ich nichts, die einzelnen Regeln durchzugehen. Ein guter Einstiegstpunkt im Netz ist das Firewall HOWTO von Guido Stepken ( www.little-idiot.de ). Allerdings sind ein oder zwei gute Buecher darueber hinaus durchaus sinnvoll. by Joerg --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Jörg Zimmermann schrieb in 2,3K (58 Zeilen):
Ein guter Einstiegstpunkt im Netz ist das Firewall HOWTO von Guido Stepken ( www.little-idiot.de ). Allerdings sind ein oder zwei gute Buecher darueber hinaus durchaus sinnvoll.
Du hast 'absolut notwendig, um die Daten von little-idiot zu verifizieren bzw. durch Ergaenzungen zu korrigieren' flasch geschrieben. -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Ingo Holewczuk wrote:
Hallo Leute,
Hi Ingo! Neben dem, was die anderen schon schrieben: * Du solltest wirklich Regeln fuer Source- und Destination IP und Port(s) aufstellen. * Dabei musst Du bei aktivem FTP auf die Geschichte mit port 20/tcp aufpassen. * Du wirst mit ziemlicher Sicherheit DNS brauchen (die DNS-Pakete sollest Du dann nur von Deinen 1 oder 2 "vertrauenswuerdigen" DNS-Servern zulassen). * Es ist afaik mindestens "hoeflich" im Netz, wenn man icmp (allermindestens ping) zulaesst. * Joerg hat es schon angedeutet: Du kannst Pakete (von aussen) ruig blocken, die das ACK-Bit gesetzt haben, und nicht fuer Ports sind, an denen Dienste von Dir laufen, kommen. Rgds. Heiko. -- Nuetzliche Samba-Doku online: http://de.samba.org/samba/docs/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Heiko Degenhardt schrieb:
Neben dem, was die anderen schon schrieben: * Joerg hat es schon angedeutet: Du kannst Pakete (von aussen) ruig blocken, die das ACK-Bit gesetzt haben,
und nicht fuer Ports sind, an denen Dienste von Dir
laufen, kommen.
Meinst du damit das man bei ftp, ssh etc auch das ACK-Bit sperren soll? Ansonsten gehe ich davon aus das mit -P input DENY alle Ports gesperrt und somit auch die Packete die das ACK-Bit gesetzt haben nicht durchkommen. gr Ingo --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Ingo Holewczuk wrote:
... Meinst du damit das man bei ftp, ssh etc auch das ACK-Bit sperren soll? Ansonsten gehe ich davon aus das mit -P input DENY alle Ports gesperrt und somit auch die Packete die das ACK-Bit gesetzt haben nicht durchkommen. Ich meine z.B. folgendes (aus Deiner Config): ... #http ... ipchains -A input --dport 80 -p tcp -j ACCEPT ...
Damit akzeptierst Du alle Pakete von ueberall nach ueberall Port 80/tcp. (Davon abgesehen, dass Du besser das Interface und die Quell- und Ziel-IPs mit angeben solltest): Wenn Du keinen Webserver hast, haben Pakete, die das ACK-Bit tragen, nichts an Deinem Server Port 80/tcp zu suchen. Wenn Du einen hast, dann musst Du die Ports entsprechend freischalten. Ich habe z.B. sowas wie $IPCHAINS -A input -p tcp -y -s 0/0 -d $WWWIP ! 80 -l -j DENY auf meinem Web-Server. Rgds. Heiko. -- Nuetzliche Samba-Doku online: http://de.samba.org/samba/docs/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo, vielen Dank fuer eure ausfuehrliche Hilfe. Ich habe den Tag und die Nacht genutzt noch einiges zu aendern. Und bin jetzt guter Dinge das die schlimmsten Patzer drausen sind. Wenn jemand Lust und Zeit hat kann er sich die Konfiguration gerne nochmal anschauen. Ansonsten wird die Zeit zeigen ob die Firewall haelt. ------------------------Begin INTDEVICE=eth0 LOCALDEVICE=lo SOURCE=Meine Server IP LHOST=127.0.0.1 DNS=DNS-Server IP ipchains -F input ipchains -F forward ipchains -F output ipchains -P input DENY ipchains -P output DENY ipchains -P forward DENY #lo Device freischalten fuer interne Kommunikation ipchains -A input -s $LHOST -d $LHOST -i $LOCALDEVICE -p tcp -j ACCEPT ipchains -A output -s $LHOST -d $LHOST -i $LOCALDEVICE -p tcp -j ACCEPT ipchains -A input -s $LHOST -d $LHOST -i $LOCALDEVICE -p udp -j ACCEPT ipchains -A output -s $LHOST -d $LHOST -i $LOCALDEVICE -p udp -j ACCEPT ipchains -A input -s $LHOST -d $LHOST -i $LOCALDEVICE -p icmp -j ACCEPT ipchains -A output -s $LHOST -d $LHOST -i $LOCALDEVICE -p icmp -j ACCEPT #icmp ipchains -A input -i $INTDEVICE -p icmp -j ACCEPT ipchains -A output -i $INTDEVICE -p icmp -j ACCEPT #Belegte UDP Ports >1023 sperren ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 1524 -p udp -j REJECT ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 1525 -p udp -j REJECT ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 5002 -p udp -j REJECT ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 5555 -p udp -j REJECT ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 20012 -p udp -j REJECT ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 10080 -p udp -j REJECT ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 1645 -p udp -j REJECT ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 1646 -p udp -j REJECT ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 3306 -p udp -j DENY #alle input UDP-Ports freigeben ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 1024:65535 -p udp -j ACCEPT #DNS ipchains -A input -i $INTDEVICE -d $SOURCE -s $DNS -l --dport 53 -p udp -j ACCEPT ipchains -A input -i $INTDEVICE -d $SOURCE -s $DNS -l --dport 53 -p tcp -j ACCEPT #SSH ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 22 -p tcp -j ACCEPT #http ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 80 -p tcp -j ACCEPT #https ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 443 -p tcp -j ACCEPT #ftp ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 20 -p tcp -j ACCEPT ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 21 -p tcp -j ACCEPT #java programm horcht auf Port ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 26000 -p tcp -j ACCEPT ipchains -A input -i $INTDEVICE -d $SOURCE -l --dport 26001 -p tcp -j ACCEPT #Alle Output-Ports erlauben ipchains -A output -i $INTDEVICE -s $SOURCE -l --sport 1024:65535 -p tcp -j ACCEPT ipchains -A output -i $INTDEVICE -s $SOURCE -l --sport 1024:65535 -p udp -j ACCEPT ipchains -A output -i $INTDEVICE -s $SOURCE -l --sport 22 -p tcp -j ACCEPT ipchains -A output -i $INTDEVICE -s $SOURCE -l --sport 80 -p tcp -j ACCEPT ipchains -A output -i $INTDEVICE -s $SOURCE -l --sport 443 -p tcp -j ACCEPT ipchains -A output -i $INTDEVICE -s $SOURCE -l --sport 443 -p udp -j ACCEPT ipchains -A output -i $INTDEVICE -s $SOURCE -l --sport 20 -p tcp -j ACCEPT ipchains -A output -i $INTDEVICE -s $SOURCE -l --sport 21 -p tcp -j ACCEPT ipchains -A output -i $INTDEVICE -s $SOURCE -d $DNS -l --sport 53 -p udp -j ACCEPT ipchains -A output -i $INTDEVICE -s $SOURCE -d $DNS -l --sport 53 -p tcp -j ACCEPT -------------End Viele Gruesse Ingo --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Heiko Degenhardt wrote on Wed, Apr 26, 2000 at 13:25 +0200:
Wenn Du keinen Webserver hast, haben Pakete, die das ACK-Bit tragen, nichts an Deinem Server Port 80/tcp zu suchen.
Dann wäre aber kein Client in der Lage, eine TCP Verbindung zu Deinem WWW-Server auch nur aufzubauen (RFC739).
Ich habe z.B. sowas wie $IPCHAINS -A input -p tcp -y -s 0/0 -d $WWWIP ! 80 -l -j DENY auf meinem Web-Server.
IIRC bedeutet das: alle tcp-Packete (-s 0/0 ist default wenn nicht angeben), die SYN, nicht ACK, nicht FIN zu einem Port != 80 aufbauen wollen, blocken. Damit sollten FIN, Xmas Tree und Null scans gegen Deinen Server funktionieren, da SYN nie gesetzt sein sollte, und Deine Regel nie zutrifft, also nie geblockt wird. Ich weiß ja nicht, welche Regeln Du noch hast, aber grundsätzlich ist es vermutlich einfach, per Default alles zu verbieten, und dann die erlaubten Sachen freizuschalten. Dabei kann man dann auch kein UDP, ICMP, GGP oder so vergessen. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hi Steffen! Danke fuer Deine Mail! Hi auch Liste. Ich hatte gestern anscheinend zeitweise Ausfaelle in meinem Denksprachschreibmodul. ;-) Steffen Dettmer wrote:
* Heiko Degenhardt wrote on Wed, Apr 26, 2000 at 13:25 +0200:
Wenn Du keinen Webserver hast, haben Pakete, die das ACK-Bit tragen, nichts an Deinem Server Port 80/tcp zu suchen.
Immer, wenn ich in diesem Thread sowas geschrieben habe, meinte ich eigentlich SYN-Packete, also Pakete, die das SYN-Bit gesetzt, sowie FIN und ACK _nicht_ gesetzt haben! (War wohl gestern eindeutig zu warm hier auf Arbeit).
...
Ich habe z.B. sowas wie $IPCHAINS -A input -p tcp -y -s 0/0 -d $WWWIP ! 80 -l -j DENY auf meinem Web-Server.
IIRC bedeutet das: alle tcp-Packete (-s 0/0 ist default wenn nicht angeben), die SYN, nicht ACK, nicht FIN zu einem Port != 80 aufbauen wollen, blocken. Damit sollten FIN, Xmas Tree und Null scans gegen Deinen Server funktionieren, Es sollte eigentlich nichts zurueckkommen, da standartmaessig sowieso alles geblockt wird.
da SYN nie gesetzt sein sollte, und Deine Regel nie zutrifft, also nie geblockt wird. Sie wird aber angewendet. Dazu ein aktuelles Beispiel:
Aus "ipchains -nvL input" die Regel 8: (ich schneide das mal ein wenig zurecht) ... pkt byte targ prot opt ... if ... source destination ports 79 3800 DENY tcp -y--l- ... * 0/0 195.37.62.127 * -> !80 ... Hier nun eine Argus-Ausgabe: ... Wed 04/26 07:59:49 tcp 209.197.208.205.4251 |> 195.37.62.127.80 RST Wed 04/26 07:59:52 s tcp 209.197.208.205.4253 o> 195.37.62.127.3128 TIM Wed 04/26 07:59:52 s tcp 209.197.208.205.4252 o> 195.37.62.127.8080 TIM ... Die Verbindung auf port 80/tcp wurde vom Server resetted (war ein Proxy-Versuch), die anderen wurden DENYed. Dazu auch ein Stueck /var/log/kern: ... Apr 26 07:59:49 www kernel: Packet log: input DENY eth0 PROTO=6 209.197.208.205:4252 195.37.62.127:8080 L=48 S=0x00 I=58544 F=0x4000 T=110 SYN (#8) Apr 26 07:59:52 www kernel: Packet log: input DENY eth0 PROTO=6 209.197.208.205:4253 195.37.62.127:3128 L=48 S=0x00 I=13745 F=0x4000 T=110 SYN (#8) ... Die "normale" Verbindung auf Port 80 wurde nicht geloggt, der Rest doch und abgewiesen (von Regel 8). Ich bin sicher auch kein Guru auf dem Gebiet Sicherheit. Ich habe mir das alles soweit zusammengestoepselt, bis es so funktioniert, wie ich denke, dass es funktionieren sollte. Deshalb bin ich fuer Hinweise und Kritik auch extrem dankbar! Falls also jemand andere Vorschlaege hat... Danke Dir, Steffen, jedenfalls nochmal fuer die Hinweise! Rgds. Heiko. -- Nuetzliche Samba-Doku online: http://de.samba.org/samba/docs/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Heiko Degenhardt wrote on Thu, Apr 27, 2000 at 08:41 +0200:
Steffen Dettmer wrote:
[SYN <--> ACK]
(War wohl gestern eindeutig zu warm hier auf Arbeit).
:)
Ich habe z.B. sowas wie $IPCHAINS -A input -p tcp -y -s 0/0 -d $WWWIP ! 80 -l -j DENY auf meinem Web-Server.
IIRC bedeutet das: alle tcp-Packete (-s 0/0 ist default wenn nicht angeben), die SYN, nicht ACK, nicht FIN zu einem Port != 80 aufbauen wollen, blocken. Damit sollten FIN, Xmas Tree und Null scans gegen Deinen Server funktionieren,
Es sollte eigentlich nichts zurueckkommen, da standartmaessig sowieso alles geblockt wird.
Also: Die Regel sagt: blocke SYN != port 80, und eine weitere sagt dann: blocke auch Rest != port 80, ja? Na, Du mußt Deine Regeln ja lesen können :)
da SYN nie gesetzt sein sollte, und Deine Regel nie zutrifft, also nie geblockt wird.
Sie wird aber angewendet. Dazu ein aktuelles Beispiel: pkt byte targ prot opt ... if ... source destination ports 79 3800 DENY tcp -y--l- ... * 0/0 195.37.62.127 * -> !80 ... Apr 26 07:59:49 www kernel: Packet log: input DENY eth0 PROTO=6 209.197.208.205:4252 195.37.62.127:8080 L=48 S=0x00 I=58544 F=0x4000 T=110 SYN (#8)
Da war ein SYN bit gesetzt. Das ist ja bei FIN-Scan eben nicht der Fall.
Falls also jemand andere Vorschlaege hat...
Probier' das doch spaßes-/sicherheitshalber einfach mal aus: z.B.: nmap -P0 -sF -p70-90 www.you.tld (Aber wie gesagt, damit sollte man so erstmal auch nicht allzuviel anfangen können; muß man mal schauen, ob und welche Angriffe/DoS ohne SYN auskommen. Aber ein DoS gegen einen WWW-Server sollte sowieso einfach sein, also vermutlich kein zusätzliches Risiko.) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Heiko Degenhardt wrote on Wed, Apr 26, 2000 at 06:55 +0200:
* Du solltest wirklich Regeln fuer Source- und Destination IP und Port(s) aufstellen.
Was soll er denn da machen? Source kann jede sein, Destination sind alle lokalen, wo auch WWW läuft (vermutlich alle lokalen), wo kein httpd läuft, sollte eh nix anderes laufen (auf diesem Port). Aber Interface-gebundene Regeln sind sinnvoll (aber IMHO nicht nötig).
* Dabei musst Du bei aktivem FTP auf die Geschichte mit port 20/tcp aufpassen.
Aktives FTP fordert normalerweise, alle Hi-Ports zu öffnen. Also besser gar kein aktives FTP erlauben. Noch viel besser, gleich scp oder rsync via SSH verwenden.
* Du wirst mit ziemlicher Sicherheit DNS brauchen (die DNS-Pakete sollest Du dann nur von Deinen 1 oder 2 "vertrauenswuerdigen" DNS-Servern zulassen).
Genau, in Verbindung mit lokalem DNS kannst Du dann port53<-->port53 für diese zwei, drei IPs erlauben.
* Es ist afaik mindestens "hoeflich" im Netz, wenn man icmp (allermindestens ping) zulaesst.
ICMP type 3 (das sind die "Destination unreable" typen) sollte man _nie_ blocken. ICMP Type 3 ist z.B. für MTU discovery erforderlich. Allerdings würde ich fragmentierte ICMP Pakete blocken.
* Joerg hat es schon angedeutet: Du kannst Pakete (von aussen) ruig blocken, die das ACK-Bit gesetzt haben, und nicht fuer Ports sind, an denen Dienste von Dir laufen, kommen.
Du meinst sicher: Packete, die das SYN bit gesetzt, ACK und FIN nicht gesetzt haben, oder? Packete an Ports, an denen keine Dienste laufen, sollte man IMHO grundsätzlich blocken (um z.B. FIN scans zu verhindern). Zusätzlich kann man noch verbieten, das keine Pakete mit SYN, nicht ACK, nicht FIN rausgehen dürfen (das verhindert dann, das der Server von sich aus jemanden connected). Allerdings brauchst Du DNS, DNS kann auch TCP sein, aber AFAIK nur in der "Antwort", da eine Anfrage wohl nicht länger als 512 Bytes sein sollte. Einfach wirds, wenn Du irgentwie auf FTP verzichten kannst. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (10)
-
cmeyer＠mail.com -
heiko.degenhardt＠sentec-elektronik.de -
holewczuk＠gmx.de -
j.zimmermann＠xsiteing.de -
LKA364＠t-online.de -
marc.schiffbauer＠links2linux.de -
sebastian＠helms.sh -
steffen.telle＠hadiko.de -
steffen＠dett.de -
weissel＠netcologne.de