PHP Sicherheitssofftware CTXtra

So kaum ist die v1.5 raus geht es schon weiter mit der v1.6 - ihr seht wir stehn nicht still ;D

Schreibt mir bitte was ihr für die v1.6 wünscht...


ToDo v1.6

• Errorreporting hinzugefügt
  alle PHP-Errors und -Hinweise werden in /log/ct_php_errors.log gespeichert... sollten errors oder hinweise auftauchen, wird der user alle 7 Tage gebeten die logs zu senden... per klick wird eine email, mit mail(), gesendet und die datei ct_php_errors.log wird geleert. Ich denke das ist eine sehr gute debug funktion die uns jeden Fehler meldet.
• Pfadangabe geändert
  Text bei installation von "MIT /" auf "OHNE /" geändert
• globaler SPAM-Schutz hinzugefügt
  Unter "Einstellungen" brauch jetzt nur noch der Spamschutz an oder aus geschalten werden... alle $_POST Variablen durchlaufen den Spamfilter (ALLE)... jetzt braucht man nicht mehr extra eine Funktion für ein Forum oder Gästebuch schreiben damit der Spamfilter includet werden kann...
• SPAM-Schutz überarbeitet:
  • SPAM-URL anzeigen - ja/nein
  • SPAM-Bilder anzeigen - ja/nein
  • "mehr" hinzugefügt (wie wormprotector)
  • Spam wird nich mehr pro zeile in .txt gespeichert sondern in variablen, jedes spam in einem array... besserer schutz gegen scripte die eventl. versuchen den ctxtra dadurch auszuhebeln.
• Angiffs Signatur im Angriffsprotokoll hinzugefügt
• Useragent-Protector hinzugefügt
  • Gesucht wird nach guten oder bösen Bosts, Spidern oder Crawler die versuchen auf deine Seite zuzugreifen.
• IP-Filter erweitert... schnellere überprüfung
  in Arbeit...
• globaler PHP-Errorlog
  in Planung...
  

---

• behobene Bugs seit (v1.5.01):
  
  • "Käferbug" (http://ctxtra.de/smf/index.php/topic,118.msg639.html) behoben

vBulletin 3.7.0 integration, habe einige probleme mit meinen admin-aktionen (Threads verschieben, schließen, löschen, Add-Ons installieren / löschen) wird immer als Angriff geblockt...

hehe, leider ist dieser thread nicht mehr auf dem neuesten stand  ::)
sind schon paar mehr features enthalten...

1.6 wird dann alle bis jetzt von euch verwendenten scripte + foren unterstützen

ok, alles klar. super

Mir ist ein kleiner Fehler in der install_1.5.06.txt aufgefallen

Da heißt es:

Das ist jedoch nur möglich wenn man zuvor in der config.inc.php seine Domainadresse in der Variable $ct_borddir korrekt angegeben hat. Vielleicht sollte man die User bereits vor dem Upload (also Punkt 1) auffordern diese Angabe zu machen.

Außerdem könnte man bei Punkt 4 auch gleich die Zugangsdaten (Admin/password_dummy)  mit reinschreiben oder aber das Script so umschreiben, dass der User beim ersten Aufruf des ACP einen neuen Username/PW eingeben muss.

a)falsch...
wenn man install.php zuvor richtig ausgeführt hat ist ein manuelles bearbeiten der config unnötig...

b)mit standard user+pw einloggen kann man machen...
bei ausführung der install.php wird aber eben diese sache vom user definiert, so dass man es später nicht mehr machen brauch...

mfg

hi,

in den wurmtools (menu wurmangriffe) würde mich mir an irgend einer stelle wünschen, dass der query direkt ersichtlich ist (vielleicht als mousover/alt/title), auch wäre es toll, wenn nach dem klick auf "more..." ein direkter link für die whitelist, als auch ip-filtern / blocken da wäre - dann muss man nicht so viel navigieren.

auch ganz praktisch wäre es vielleicht, für die user, die versehentlich im bann landen, eine art capcha abfrage reinzupacken (wieviel ist dreipluszwei), damit sie sich selbst wieder entsperren können.

keep on going!

thomas

hi

1+2 ist in 1.6 schon eingebaut.. also zurück lehnen  ;D

captcha ist so ne sache, viele bots können captcha schon decodieren.
wir lassen uns aber mal was einfallen


mfg

hi,

wie gesagt, ich meinte kein reines captcha, sondern einen bestimmten text in ein feld einzugeben. bei mir im forum ist ziemlich ruhe, sein einfach nur das wort "keinspam" (oder KeinSpam,keinSpam) in ein feld eingetragen werden muss.

gruss,
thomas

und genau da ist das problem...

irgendwann kennen die "robots" den link, erstellen von jedem captcha nen md5, bei erfolg schreiben die es in eine datenbank......
und beim nächsten aufruf... md5abfrage... robots schreiben passenden string in textarea und schwupps.. sind die wieder freigeschaltet

aber mal sehen,
thx für info

der einzige link ergibt sich ja aus der < form >.
der rest könnte so aussehen
bitte schreiben sie keinspam in folgendes feld ____________ und klicken sie auf [ weiter ]...

die anzeige könnte man per js erzeugen, vielleicht noch codiert, ums noch schwerer zu machen.
ich habe bei mir in joomla einen erweiterten flood-protector drinne, der so einen link erzeugt, um weiter zu machen und die ip aus der db zu löschen. sicherlich nicht 100%tig, aber für die meisten reichts.

den rest kann man per white-/blacklist lösen; viele bots schliesse ich per .htaccess aus. das wichtigste sollte neben dem schutz einfach auch sein, dass die "guten" bots weiter machen können. wäre nicht so prickelnd, wenn man den googlebot aussperrt.....

gruss,
thomas

Man könnte zusätzlich entweder einen Salt verwenden oder aber das Ganze noch zusätzlich mit base64 kodieren oder rot13.

hi,

rein für den ip-filter - kennt ihr schon http://www.iplists.com/ ? (sicherlich ;) )

man könnte doch hier über eine art cronjob die botliste auf dem laufenden halten, und evtl. bestimmte bots gar nicht erst loggen (wenn bestimmte ip, return to caller). suchmaschinen bspw. landen bei mir regelmässig auf dem index, wenn sie nach xyz.html?christian suchen.

so long,
thomas

als kleiner schnellschuss  ;)

<?php
error_reporting(0);

if ($_REQUEST["update"]) {

echo "Updating...";

$engines = array(
"http://www.mcdar.net/dance/google_datacenters_offline.htm?nowritefs&nowritefs",
"http://www.iplists.com/google.txt",
"http://www.iplists.com/inktomi.txt",
"http://www.iplists.com/lycos.txt",
"http://www.iplists.com/infoseek.txt",
"http://www.iplists.com/altavista.txt",
"http://www.iplists.com/excite.txt",
"http://www.iplists.com/northernlight.txt",
"http://www.iplists.com/misc.txt",
"http://www.iplists.com/non_engines.txt");

$fh = fopen("s_engines.txt", 'w');

foreach($engines as $e) {
echo "$e<br />\n";

$cUrl = curl_init();
    curl_setopt($cUrl, CURLOPT_URL, $e);
    curl_setopt($cUrl, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($cUrl, CURLOPT_TIMEOUT, 30);
    curl_setopt($cUrl, CURLOPT_HEADER, 0); // 1
    curl_setopt($cUrl, CURLOPT_FOLLOWLOCATION, 1);
    curl_setopt($cUrl, CURLOPT_USERAGENT, 'Mozilla/5.0');
    curl_setopt($curl, CURLOPT_REFERER, 'http://www.iplists.com/');
    curl_setopt($curl, CURLOPT_AUTOREFERER, true);
    curl_setopt($cUrl, CURLOPT_MAXREDIRS, 10);
    $o = trim(curl_exec($cUrl));
//    $oo[] = $o;
    curl_close($cUrl);

fwrite($fh, $o);
}
fclose($fh);

} // end update

$oo = file("s_engines.txt");

if (in_array($_SERVER['REMOTE_ADDR'], $oo)) { echo $_SERVER['HTTP_USER_AGENT']." wurde in der Liste gefunden...<br />"; /* return; */ }
else { echo $_SERVER['REMOTE_ADDR']." wurde <i>nicht</i> in der Liste gefunden...<br />"; }

if (in_array($_SERVER['HTTP_USER_AGENT'], $oo)) { echo $_SERVER['HTTP_USER_AGENT']." wurde in der Liste gefunden...<br />"; /* return; */  }
else { echo $_SERVER['HTTP_USER_AGENT']." wurde <i>nicht</i> in der Liste gefunden...<br />"; }

?>
<hr />
<a href="s_engines.txt">s_engines.txt</a>

eine täglich aktualisierte whitelist aus o.g. quellen kann hier (http://mahakala.de/whitelist.txt) gefunden werden

mh,
curl haben viele kleinere provider nicht installiert.
die grösseren schon.

curl hatten wir schon mal drin, lief auch gut, nur haben eben viele kein curl und somit ist ctxtra auch  nicht so vielseitig einsetzbar, das es auf jedem server funzt...

unser ziel:
minimalste servervorraussetzung mit maximalster sicherheit...

ausserdem haste pn...  8)

um an die listen zu kommen, musste ich curl einsetzen, file etc. lief nicht, da der server sie blockt - auch soll es schneller sein.
wenn ich ctx recht verstehe, telefoniert es sowieso regelmässig nach hause, um die liste zu aktualisieren, von daher könnt ihr gerne auch die daten aus dem link -sprich von mir- haben. aktualisiert sich per cronjob täglich.
da ich mich schon bei google ausgesperrt hatte, brauchte ich die funktion für if (!in_array($_SERVER['REMOTE_ADDR'], $whitelist)) {require_once("ctracker..... somit ist das ganze schon etwas idiotensicherer...

gruss,
thomas

fehlt noch class=" in der vbulletin whitelist

delete.php wird leider auch noch benötigt...

Poste mal die url... "delete.php" durchzulassen ist sehr bööse

funzt ctxtra auch 100%ig unter dem webserver lighttpd ?

sollte auch funzen.
habe da allerdings noch keine erfahrungen.
über rückmeldung wären wir dankbar

mfg

ich meine,weil lighttp nicht mit .htaccess umgehen kann ;)und er auch keine news anzeigt wegen updatenews ... lighttp kann ich nur empfehlen ... läuft schneller,insofern man nicht auf die module vom indianer angewiesen ist.

lighttpd verwendet statt der Datei .htaccess das Modul mod_auth
Wenn also ctxtra eine .htaccess Datei erzeugt, dann wird diese vom Server nicht gelesen/ausgewertet und ist somit sinnlos.
Allerdings können die Daten aus der .htaccess (in etwas modifizierter Form) in die mod_auth Konfigurationsdatei eingetragen werden - und damit ist die Welt dann wieder in Ordnung.

wird mal drüber nachgedacht....

delta, kannst du in erfahrung bringen (detaliert) wie und wo diese configs sind?
kann man über optionale multifähigkeit dann auswählen, ggf automatisieren...

mfg

Sorry - aber zunächst sollte mal darüber nachgedacht werden, wie die nächste Version des ctxtra schnellstmöglich auf den Weg gebracht werden kann.

Hab den Server hier, neben anderen, als Testsystem laufen.
Die Dateien liegen im Root-Bereich des Servers - von außen darauf zugreifen ist also nicht möglich (wäre auch schlimm wenn es anders wäre).
Allerdings könnte ein Admin-Script das unter bestimmten Rechten läuft, durchaus Config-Dateien schreiben - Voraussetzung ist natürlich, das der Server auf dem System des Users läuft und der User als Admin eingetragen ist.

Näheres ist in der Doku des lighttpd nachlesbar.