DanielB
-
Gesamte Inhalte
493 -
Benutzer seit
-
Letzter Besuch
Inhaltstyp
Profile
Forum
Downloads
Kalender
Blogs
Shop
Beiträge von DanielB
-
-
Original geschrieben von DownAnUp
[...]
export http_proxy="<proxy-ip>:<proxy-port>"
[...]
Ich bin mir nicht sicher wie apt die http_proxy Umgebungsvariable abfragt, bei Verwendung eines Proxy Servers mit Programmen wie z.B.Lynx. muss auch noch ein "http://" mit rein :
http_proxy="http://<proxy_ip_oder_hostname>:<proxy_port>"
Falls apt es nicht benötigt, nm
-
Ja, wenn die Linuxkiste direkt am Netz hängt ist es besser, das ganze über ip-up zu regeln. Wenn die Kiste jedoch hinter nem Router hängt funktioniert es logischerweise nicht über ip-up. pppd übergibt auch diverse Verbindungsparameter an das ip-up Skript, so dass Du die IP auch über diese Parameter herrausfinden kannst (macht das lynx --source...) unötig.
-
Ja, starten solltest Du es über Cron. Für Dial On Demand solltest Du _vor_ dem Aufruf von lynx z.B. ein Ping ausführen, um sicherzustellen, dass eine Netzwerkverbindung steht bevor lynx sich mit www.whatismyip.org verbindet.
-
Hi,
meiner Ansicht nach ist DynDNS der bessere Weg, wenn Du jedoch wirklich mit einer Weiterleitung auf einer HTML Seite arbeiten willst, lässt sich das in etwa so erledigen :
/home/foo/html-update/page-template.html
<html> <head><title>IP Update</title></head> <body> IP : %IP% </body> </html>
/home/foo/html-update/update.sh#!/bin/bash HTMLTEMPLATE="/home/foo/html-update/page-template.html" HTMLFILE="/home/foo/html-update/page.html" NCFTPPUT=/usr/bin/ncftpput LOGFILE="/tmp/ip-log" TMPFILE="/tmp/ip-tmp" DATE=`date +%D` LAST_IP=`tail -1 $TMPFILE` CURRENT_IP=`/usr/bin/lynx --source [url]http://www.whatismyip.org[/url]` echo $CURRENT_IP >> $TMPFILE if [ "$CURRENT_IP" == "$LAST_IP" ]; then echo -e "$DATE : IP [$CURRENT_IP] has not changed.\n" >> $LOGFILE else sed -e 's#%IP%#$CURRENT_IP#' < $HTMLTEMPLATE > $HTMLFILE $NCFTPPUT YOUR_OPTIONS_TO_UPLOAD_$HTMLFILE RETVAL=$? if [ "$RETVAL" -ne 0 ]; then echo -e "$DATE : Error -> $RETVAL\n" >> $LOGFILE else echo -e "$DATE : IP [$CURRENT_IP] updated.\n" >> $LOGFILE fi fiDu benötigst hierfür NcFTP, wenn Du den Part für das Hochladen der HTML Seite per FTP nicht selbst mit in das Skript einbauen willst. Das HTML Template musst Du selbst anpassen, im Skript die Optionen für ncftpput auch. Das ganze ist nicht getestet, sollte aber funktionieren
-
In /etc/securetty lässt sich einstellen über welche Konsolen ein direkter root Login erlaubt ist. Falls Du PAM verwendest, finden sich in /etc/security/access.conf weitere Möglichkeiten Logins zu beschränken.
-
Etwas in dieser Art müsste funktionieren :
#!/bin/bash LOGFILE="/tmp/ip-log" TMPFILE="/tmp/ip-tmp" DATE=`date +%D` LAST_IP=`tail -1 $TMPFILE` CURRENT_IP=`/usr/bin/lynx --source [url]http://www.whatismyip.org[/url]` echo $CURRENT_IP >> $TMPFILE if [ "$CURRENT_IP" == "$LAST_IP" ]; then echo -e "$DATE : IP [$CURRENT_IP] has not changed.\n" >> $LOGFILE else # Aufruf deines DynDNS clients mit den entsprechenden Optionen hier # $CURRENT_IP an DynDNS client übergeben. # /usr/bin/ddlclient bla bla bla echo -e "$DATE : IP [$CURRENT_IP] updated.\n" >> $LOGFILE fiDie Datei /tmp/ip-tmp nicht löschen
Das Skript dann über Cron in beliebigem Abstand aufrufen. Es ist wichtig, dass eine Abfrage stattfindet, ob sich die IP geändert hat. DynDNS blockt den Account, wenn Updates mit der selben IP zu oft wiederholt werden.
-
Original geschrieben von Andreas73
ok, aber funktioniert das auch auf einem Rechner der sich hinter einem Router befindet ?
Wie erkennt das Programm das sich die dynamisch zugewiesene IP geändert hat ?
könnte sowas funktionieren ???
Ohne weiteres gar nicht. Dafür müsstest Du ein kleines Script starten, welches sich die aktuelle IP (z.B. von www.whatismyip.com oder von einem CGI Skript welches deine IP zurückliefert und auf einem Webserver liegt) besorgen. Diese dann mit deiner letzen IP vergleichen und dann, falls nötig den Client mit der neuen IP startet. Benutzt mal die Suchfunktion des Boards, ich meine vor längerer Zeit mal so ein Script gepostet zu haben.
-
Original geschrieben von stunned
Hallo!
ich hab folgendes "Problem"... ich hoffe das passt in den thread "security"...
[--- snip ---]
Schau mal unter http://www.honeynet.org unter Challenges. Die Leute vom Honeynet Project fangen mit Hilfe von Honeynets die neuesten Explots, Angriffsmethoden etc. Vieleicht findest Du dort was interessantes.
-
Original geschrieben von dr.disk
So hab ich das auch nie behauptet. Ich wollte damit sagen, daß OpenBSD, wie Du ebenfalls erwähnt hast, eine gute Grundlage ist für eine Firewall.
Ok, dann sind wir uns da ja einig
Das dort nix läuft hat aber auch einen anderen Vorteil: ich werde garantiert nicht vergessen irgendwelche Dienste abzuschalten
Jupp, das ist sicherlich ein Vorteil, keine Frage. Jedoch muss man dies auch in Zusammenhang mit "Werbeaussagen", wie "1 remote hole in the default install ..." sehen.
-
Original geschrieben von dr.disk
Vor allem wenn man bedenkt, daß in OpenBSD in den letzten fast acht Jahren nur eine Lücke entdeckt wurde. Ansehen lohnt sich auf jeden Fall! (www.openbsd.org)
Ein _Remote_ Hole in der _Default_ Installation. (Default Installation = es läuft quasi nix nach der Installation, lokal ausnutzbare Lücken sind hierbei nicht berücksichtigt)
Fehler gibt es auch bei OpenBSD. OpenBSD ist sicherlich eine gute Grundlage, wenn es um Sicherheit geht, jedoch ist es nicht _das_ fehlerfreie System zu dem es oft gemacht wird.
-
Original geschrieben von supersun
Linux ist für Firewalls große S_C_H_E_I_S_S_E
Aha, das wird vermutlich der Grund dafür sein, das es unzählige Firewall Appliances gibt, welche auf dieser "S_C_H_E_I_S_S_E" basieren. Aus dem selben Grund ergibt eine Suche auf Google nach "Linux Firewall" auch unzählige Ergebnisse. Natürlich sind all diese Firewall Tools und Extraprogramme nur aus eben diesem Grund für Linux entwickelt worden.
IPTables das größte Übel (keinen Menschenfreundlichen Syntax, Keine Configdatei sondern aufruf des Programms über Script, Bug- und Fehlerhistroy, Helpermodule und afaik auch ipt selbst Securityholes, Linux selbst ein einziges Chaos)
etc ppp
Du solltest nicht alles blind glauben, was Theo, OpenBSD.org bzw. die diversen Ad. Mailinglisten sagen und dieses dann hier posten. Der iptables Syntax ist keinesfalls menschenunfreundlich und eine Steuerung über Skripte ist sehr flexibel. Auf www.netfilter.org finden sich 6 Security Announcements von 04.2001-05.2003. Einige betreffen mich nichtmal.Damit kann ich gut leben.
OpenBSD's pf ist auch nicht fehlerfrei, keine Software ist das. Das Linux selbst ein einziges Chaos ist kannst Du Leuten wie Alan Coax erzählen, die vermutlich schon programmiert haben bevor Du diese Welt erblickt hast. Wie wäre es also mit _richtigen_ Argumenten. ?
-
Original geschrieben von sloopy
Mir wurde Netsaint empfholen: http://www.netsaint.org/indexold.php.
Ich hab es selber noch nicht eingesetzt, hab es aber schon gesehen und es sieht recht übersichtlich aus und einfach zu konfigurieren soll es auch sein.
Gruß, sloopy
NetSaint gibt es nicht mehr, das ganze wurde umbenannt und heisst jetzt Nagios.
Es ist nett und übersichtlich, allerdings ist die Konfiguration relativ zeitaufwendig.
-
Slackware (www.slackware.com) oder Debian (www.debian.org), wenn es Linux sein soll, ansonsten eventuell OpenBSD (www.openbsd.org).
-
Ich benutze Syslog-NG, Perl, MySQL um Logfiles zu filtern und in eine Datenbank zu schreiben, welche ich dann über ein Webfrontend auswerten kann. Sowas ist relativ schnell gebastelt. Wenn Du einfach nur über den Status der Systeme informiert werden willst, schau mal unter http://www.nagios.org/
-
PDF-Server
in Linux
Ist relativ einfach möglich. Schau mal hier :
-
Gimp fragt die Umgebungsvariable LANG ab. Diese kannst Du für dein System global in /etc/profile bzw. /etc/profile.d/ einstellen. Füge einfach ein Zeilt mit dem folgenden Inhalt hinzu :
export LANG="de_DE"
-
Originally posted by gurkenpapst
wenn deine Schnittstelle auf die die PPTP Verbindungen aufschlagen ppp0 ist, ja.
Würde das -i ppp0 dann aber auch bei der OUTPUT Chain verwenden.
Die Option -i lässt sich, logischerweise, nicht in der OUTPUT Chain verwenden, da es das eingehende Interface bestimmt. Für die OUTPUT Chain ist die Option -o zu verwenden, welche das ausgehende Interface definiert.
-
Portsentry
in Linux
Hi,
das Problem ist, wie die Fehlermeldung ja auch eindeutig sagt, dass die Konfigurationsdatei nicht gefunden werden kann. Kann Dir leider nicht sagen welchen Pfad der Packager des Programmes für die Konfiguration gewählt hat, aber diese wird, IIRC in der Datei config.h definiert. Lade Dir die Quellen für das Programm runter, entpacke diese und lies das README file. Dort ist erwähnt, wie Du das Problem beseitigen kannst.
-
Originally posted by nic_power
Ein segmentation fault tritt immer dann auf, wenn ein Programm auf einen Speicherbereich zugreift, der nicht allociert wurde. D.h. es handelt sich erstmal um ein Softwareproblem (beispielsweise eine defekte shared-library) .
Richtig, soweit zur Theorie. In der Praxis sind die segfaults, welche ich erlebt habe jedoch zu 95% auf Hardware und nicht auf Software zurückzuführen gewesen. Grade bei Standardprogrammen wie "ls" ist ein Fehler in der Software, welche die segfaults verursacht eher unwahrscheinlich. Eine defekte Library ist sicherlich möglich, würde aber sehr wahrscheinlich auch eine Menge andere Programme betreffen. Eine andere Möglichkeit, die in diesem Fall auch sehr wahrscheinlich ist, sind Probleme mit dem entsprechenden Verzeichnis bzw. Dateisystem.
Originally posted by nic_powerIch halte es fuer keine gute Idee, bei jedem segfault gleich mit dem Austausch von Hardware zu beginnen.
[...]
Das habe ich auch nicht geschrieben
Segfaults sind auch nichts alltägliches, wenn man nicht grade als Programmierer tätig ist. Glücklicherweise ist es relativ leicht und schnell zu testen, ob es ein Hardwareproblem ist, deshalb habe ich ich dieses vorgeschlagen. Es ist grade bei Problemen dieser Art hilfreicht bestimmte Dinge ausschliessen zu können.
Wenn bei den Tests, wie oben beschrieben, weitere Fehler auftreten ist es mit 99%tiger Sicherheit ein Hardware Problem. Ansonsten kann, im Falle eines Problemes mit shared-libs, mit Hilfe von "ldd" gecheckt werden, welche libraries von dem entsprechenden Programm verwendet werden. Danach kann ein Austausch der entsprechenden shared-libs vorgenommen werden bis das Problem nicht mehr auftritt.
Was aber weitaus wahrscheinlicher als shared-libs als Fehlerquelle in Frage kommt
sind Probleme mit dem Verzeichnis selbst. Die entsprechenden Frage für weitere Fehleranalysen hat Nic ja schon gestellt.
-
-
Segmentation faults weisen oft auf fehlerhafte Hardware hin. (i.d. R. Speicher, CPU, Board. Seg faults treten aber auch auf, wenn z.B. die CPU zu heiss wird.
Besorg dir einfach mal den Quelltext von einigen, möglichst grossen Programmen und fang an alles auf einmal zu kompilieren. Wenn Du Fehlermeldungen wie z.B.
cc exited with signal 11 oder Kernel Panics bekommst ist es ein Hardwareproblem und Du kannst anfangen Komponenten zu tauschen bis der Fehler nicht mehr auftritt.
-
Bei RPM Paketen kannst Du es so erledigen :
/bin/rpm -ql paketname
um eine Auflistung aller Dateien zum entsprechenden Paket zu erhalten. Bist Du Dir beim Paketnamen nicht sicher, hilft ein :/bin/rpm -qa | less
bzw./bin/rpm -qa | grep "paket_heisst_so_ähnlich"
-
Die AVM Treiber und isdn4linux sind 2 unterschiedliche Dinge. Die Treiber werden benötigt um auf die Hardware zuzugreifen, die isdn4kutils greifen später auf das ISDN device unter /dev zu. Ich erinnere mich an die Fritz Card PCI 2.0, welche zunächst nur mit dem CAPI Treiber von AVM funktionierte. Die Unterstützung für die isdn4linux Tools (isdncrtl, etc.) funktioniert aber trotzdem. Es kann sein, dass du bestimmte Module laden musst, um die Funktionalität für isdnctrl etc. zu bekommen. Eventuell musst Du auch noch die entsprechenden Device Dateien unter /dev/erstellen.
-
Originally posted by Flying Andi
Hallo!
Ist das Projekt für die Schule, zu Lernzwecken oder für einen Kunden ?
Bei letzerem würde ich Dir auf jeden Fall dazu raten die Firewall nicht mit YaST zu konfigurieren, Dich krätig mir der Materie auseinanderzusetzen (das ist nämlich nicht etwas was man in ein paar Stunden nebenbei macht) und eventuell auf eine andere Distribution auszuweichen.
[...]
Grundsätzlich gibt es ja nur die Chains INPUT FORWARD OUTPUT.
Konfiguriere ich mit yast kommt noch mehr hinzu, mit dem ich momentan noch nichts anfangen kann.
Ja, das sind die 3 Basis Ketten. Innerhalb dieser Ketten können benutzerdefinierte Ketten erstellt werden. Das ist sinnvoll um hinterher noch den Überblick zu behalten und auch besser für die Performance, da nicht immer alle Regeln abgearbeitet werden müssen.
Wir wollen jetzt, dass über den Proxy nur Anfragen über den Port 8080 laufen. Wie realisiere ich das am besten?
Das ist recht einfach zu lösen. Als erstes konfiguriert Ihr Squid mit transparent Proxy Support und er muss auf Port 8080 lauscht. Danach könnt Ihr mit folgender Regel alles auf den Proxy umleiten was auf den Ziel Port 80 (also http) geht :
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j
REDIRECT --to-port 8080
Kann ich die Policy erst mal auf DROP stellen und dann nur den einen Port öffnen?
Wie mache ich das und wann brauche ich das FORWARD Chain?
Jupp, du kannst und solltest die Default Policy auf DROP bzw. REJECT stellen.
Die Forward Chain benötigst Du, wenn Du kontrollieren willst ob bzw. welche Pakete von einem Netzwerkinterface auf das andere gelangen dürfen. Auf der Netfilter Homepage ist gute Dokumentation dazu vorhanden.
Münchener Rathaus-SPD entscheidet sich für Linux
in Small Talk
Geschrieben
Du vergisst anscheinend, dass die Umstellung nicht von irgendeiner Frickelbude mit 10 Leuten die sich Linux Admins nennen ausgeführt werden wird, sondern von Profis
Auch wenn es noch eine separate Auschreibung über die Umstellung geben wird, bin ich mir ziemlich sicher, dass IBM & SuSE den Zuschlag für die Umstellung erhalten werden. Es würde mich nicht wundern, wenn IBM & SuSE dabei ein Verlustgeschäft in Kauf nehmen, wobei IBM das aus der Portokasse zahlt.
Probleme wie "die Netzwerkkarte erkennt den Fiber Anschluss nicht" oder "das GUI ist nicht der Hit" wird es nicht geben. Die rein technische Seite einer solchen Umstellung ist für o.g. Firmen durchaus überschaubar und wurde sicherlich im Vorfeld durch diverse Studien etc. ermittelt. Beide Firmen werden sich hier sicherlicht nicht auf ein Softwareabenteuer ala "Ma gucken ob dat lübt " einlassen. Dafür steht, für beide, zu viel auf dem Spiel.