 |
| first state |
Dienstag, 21. Oktober 2014
Montag, 29. September 2014
Second day and state: the physiognomy is a little bit better; nose still too short - chin, too; now I have to wait for it to dry before I can add glazes (I have just decided not to try painting alla prima here.)
Portrait Maja, first state. Commission. Gotta get lighter, more child-like, less chin. I'm satisfied with the colors and lighting so far.
Freitag, 16. Mai 2014
Re: die Gedanken sind frei
Als ich dies hier zu schreiben beginne, formt sich mir ein Frosch im Hals. - Bezüglich Amphibien sollten Sie im Übrigen noch etwas wissen:
setzt man einen Frosch in heißes Wasser, wird er sich springend ins Trockene retten.
Setzt man ihn jedoch in kühles Wasser, dergestalt, dass der Frosch sich wohlfühlt, und erhitzt man nun langsam das Wasser, wird er nichts bemerken, eingehen und sich gar kochen lassen.
Ich kann nicht weiterschreiben und beschließe, stattdessen eine Mail von vorgestern zu beantworten:
Die Raumfahrt hat ihren Ursprung in der Waffentechnik, die ersten Menschen auf dem Mond waren Soldaten. Die moderne Unterhaltungselektronik ist streng genommen nur ein Nebenprodukt der Propagandamaschinerie des Totalitarismus. Glorreiche Zeiten sind das, in denen wir leben, Zeiten, in denen - beispielsweise - ein Mitarbeiter von Foxconn sich das Leben nahm, weil ihm ein Drecks-iPhone geklaut wurde, das damals noch "geheim" war und das mittlerweile zum Elektroschrott gehört]
setzt man einen Frosch in heißes Wasser, wird er sich springend ins Trockene retten.
Setzt man ihn jedoch in kühles Wasser, dergestalt, dass der Frosch sich wohlfühlt, und erhitzt man nun langsam das Wasser, wird er nichts bemerken, eingehen und sich gar kochen lassen.
Ich kann nicht weiterschreiben und beschließe, stattdessen eine Mail von vorgestern zu beantworten:
Hallo Roland,
freut mich, dass du deine Reise machen konntest. Ich brauche auch mal so eine Veränderung, bin aber derzeit nicht so ein mutiger Einzelgänger, um das durchzuziehen. Japan fände ich reizvoll, vorher auch etwas japanisch lernen...
Job läuft gut, aber ich glaube, dass ich langfristig in der Computerwelt sehr unglücklich werden kann. Für sich genommen ist die Technik interessant und spannend, aber ihr Einsatz verändert sich zunehmend zum Schlechten. Es wird immer deutlicher, dass mit dem Internet nicht nur Zugang zu Wissen und Aufklärung ermöglicht wird, nein, vielmehr scheint es von Anfang an darauf ausgelegt worden zu sein, als Überwachungs- und Kontrollinstrument zu dienen, von Werbung durchsetzt, zur Abzocke geeignet und der Kriminalität ein Paradies.
Während unsere Körper in mehr oder weniger vernünftigen Staaten Steuern anschaffen gehen, konsumieren und Sozialleistungen beziehen, hat sich längst eine weltumspannende Hydra aus Unternehmen, Geheimdiensten und Spaßhehlern unserer Geheimnisse, Interessen, Gedanken und Sehnsüchte bemächtigt.[Bedenkt man, dass die ersten funktionierenden Computer gebaut wurden, um verschlüsselte Nachrichten zu knacken, merkt man, dass sich die Technik doch nicht so weit ihrer Wurzeln entfremdet hat, wie von mir anfangs gefühlt.
Das gleiche hätte ich schon vor sieben Jahren sagen können, als ich dem Hewel erklärt habe, dass ich Angst vor der technischen Entwicklung habe und deswegen Informatik studieren will. Nun aber weiß ich, dass alles, was möglich ist, auch gemacht wird und stecke so tief in der Technik, dass ich [mich selbst zensieren muss]. Ich bin teilweise also zu einem derjenigen Menschen geworden, vor denen ich mich fürchtete.
Die Raumfahrt hat ihren Ursprung in der Waffentechnik, die ersten Menschen auf dem Mond waren Soldaten. Die moderne Unterhaltungselektronik ist streng genommen nur ein Nebenprodukt der Propagandamaschinerie des Totalitarismus. Glorreiche Zeiten sind das, in denen wir leben, Zeiten, in denen - beispielsweise - ein Mitarbeiter von Foxconn sich das Leben nahm, weil ihm ein Drecks-iPhone geklaut wurde, das damals noch "geheim" war und das mittlerweile zum Elektroschrott gehört]
Als Alternative und Ausweg wird da für mich die Kunst immer deutlicher, wenngleich ich noch nicht weiß, wie sie mir was zum Essen auf den Tisch bringen kann.
Ich habe mir heute ein paar elektronische Bauteile gekauft, aus denen ich wieder einen Roboter bauen kann, der Musik macht.
Persönlich bin ich gerade etwas melancholisch; am meisten vermisse ich die Liebe. Mit dem Alter reifen auch die Ansprüche. Spatz/Hand | Taube/Dach, das funktioniert nicht bei jedem. Calligaris Vorstellung vom Musenmädchen hat aber was.
Die Malerei verläuft schleppend. Das muss aber nicht schlimm sein, schließlich denke ich trotzdem viel drüber nach.
Du kannst jederzeit nach Stuttgart kommen. Und da unklar ist, wer alles diese Email außer uns beiden lesen wird, kann ich das Ganze auch gleich online stellen. dann ist klar, dass es jeder lesen kann. Ich war sowieso gerade dabei, diese Gedanken für einen Text zur Privatsphäre aufzuschreiben.
Nastrovje!
Manuel
>Hi Manu,
>ja ich wollte mich einfach mal melden.
>Wie gehts dir? Dein Job und die Kunst?
>Ich bin erst vor Kurzem von meiner Asienreise (Nepal, Indien) >zurück.
>Habe noch ein bisschen Kulturschock. Die Welt ist so groß und so >vielfältig!
>Ich denke über ein Treffen in Stuttgart nach. Vielleicht irgendwann >im Sommer.
>Beste Grüße.
>roland.
Mittwoch, 30. April 2014
Sonntag, 23. März 2014
Dienstag, 11. März 2014
Sonntag, 9. März 2014
Donnerstag, 27. Februar 2014
Mittwoch, 26. Februar 2014
Montag, 24. Februar 2014
Mittwoch, 29. Januar 2014
Samstag, 4. Januar 2014
HowTo: Securing apache webserver with mod-security on Debian wheezy
The most common attack vector against publicly exposed servers is exploiting vulnerabilities in the services those servers provide. Webservers are a welcome target for crackers and script-kiddies: misconfigured servers or buggy software make an easy prey for hacking into.
The following is a very wide-spread, very simple and often successful attack that can be prevented by using mod-security:
The attacker finds a vulnerable script that has write access to the server's file system. This can be done by
- using security-scanner software,
- blind or educated guess or
- by using a known vulnerability in a publicly available service
Then the attacker uses this script to alter a file or upload malware to the server:
this may be a sneaky change to an already existing script which opens a backdoor or some kind of webshell or ircbot.
If that already happened to you: Congratulations, you're now the proud owner of a freshly infected zombie!
If you are a sysadmin and running one ore more webservers with apache you may have been wondering how you could protect those machines from being compromised. There are a few steps you should take before you follow this quick introduction to mod-security:
1. Make sure apache is configured properly. Try to restrict the server from sending unnecessary information about its version, installed services etc. Search and read articles about hardening webservices and apache. Understand how attackers gather information about your servers and what kind of vulnerablity they could be after.
2. Do not run exploitable software. Common targets are unpatched versions of Wordpress etc., webmail-services, and CMSs. If possible, try to restrict access to or avoid tools like phpmyadmin.
3. Make sure potentially exploitable scripts, like php, have no way to write on the filesystem. This is not always practical, but should be manageable: use a development system for file uploads and merge changes into your (read-only) public production system. You may want to use wget to take an html-only-snapshot of your development system for deployment on your production system.
4. If your web-folder (like /var/www) contains any files or directories with permissions like 0777, you're likely to experience problems in the near future. Be sure to understand what you are doing and try to explain your concerns to your users/web-developers. Database access should be configured read-only where no writing to the database is needed.
But now let's start with the HowTo:
mod-security is a very good tool for professionally securing webservers. Once you spent some time with it you wouldn't want to run a webserver without it. By design, mod-security is a web application firewall (WAF) that blocks potentially dangerous requests to your server. But even without taking any action, just by logging, mod-sec can show you how bots or attackers try to exploit your services.
I wrote this HowTo because I could not find any recent documentation on how to quickly set up mod-security on Debian wheezy. This really is only a quick and superficial way to get mod-sec working. Be sure to read further documentation on how to set up and maintain this magnificent tool. (And please point out to me any mistakes I made or possible improvements to this HowTo).
This documentation has only been tested on Debian wheezy (7.3 as of now). It is likely to be broken on any other distro or version.
I'm assuming apache is configured and running. Start by installing mod-security. Note that apache will be restarted in the process:
# apt-get install libapache2-modsecurity
The module is now up and running. It is in no way configured yet, so it still does nothing. Let's configure mod-sec: if your installation went right you now have a set of rules under /usr/share/modsecurity-crs
If you're using wheezy, the config-files are under /etc/modsecurity
Copy the default rules:
# cp -rp /usr/share/modsecurity-crs/* /etc/modsecurity
Make an initial configuration:
# cd /etc/modsecurity
# cp -p modsecurity.conf-recommended modsecurity.conf
# vi modsecurity.conf
Important: the first directive controls mod-sec's behaviour. Until everything is configured and your rules are O.K. it should look like this:
SecRuleEngine DetectionOnly # Do not block anything, just write logs
If you're satisfied, here is nothing more to do right now. Enable the configuration in apache:
# vi /etc/apache2/conf.d/mod-security
with the following content:
<IfModule security2_module>
Include /etc/modsecurity/*.conf
Include /etc/modsecurity/activated_rules/*.conf
</IfModule>
Activate all rules in /etc/modsecurity/activated_rules by setting symlinks:
# cd /etc/modsecurity
# for f in `ls base_rules/` ; do ln -s /etc/modsecurity/base_rules/$f activated_rules/$f ; done
### As the name says the following is optional.
### Some of those rules may lead to PCRE-recursion-limit
### exceptions or missing data errors,
### depending on your configuration.
# for f in `ls optional_rules/` ; do ln -s /etc/modsecurity/optional_rules/$f activated_rules/$f ; done
The preparations are done now. Test the configuration:
# apachectl configtest
You should be getting "Syntax OK" - If not, you're up to some trouble-shooting; please consult your search-engine of choice for solutions - there are plenty!
If you got a "Syntax OK" you're fine. Time to restart apache:
# service apache2 restart
if the server is very busy there should be plenty of false-positives now in /var/log/apache2/modsec_audit.log
That's O.K. for now: mod-sec is up and running.
If there is not enough traffic to trigger alarms you may want to use a security-scanner such as nessus etc. or some simple SQL-injection-attempt to trigger positive alarms.
Now you need to understand the logged errors and find false positives. The better way to cope with those errors is to modify the rule that triggered the alarm to your needs. The fast and insecure way is to deactivate the rule by whitelisting. You can create a whitelist-file with the following example content to whitelist rules:
# vi /etc/modsecurity/activated_rules/modsecurity_crs_99_whitelist.conf
content:
# This client is allowed to bypass mod-sec:
#SecRule REMOTE_ADDR "^192.168.0.3" phase:1,nolog,allow,ctl:ruleEngine=off
#SecRuleRemoveById 90001 # deactivated rule
To activate the changes you need to reload your apache-configuration (I prefer a restart).
When you're confident that the rules are set up correctly you can activate mod-sec's blocking engine in /etc/modsec/modsecurity.conf:
SecRuleEngine On
That's it!
To even further secure your server you could use a tool like fail2ban to block IPs after a certain amount of alarms or logcheck to send you email-notifications on security events.
The following is a very wide-spread, very simple and often successful attack that can be prevented by using mod-security:
The attacker finds a vulnerable script that has write access to the server's file system. This can be done by
- using security-scanner software,
- blind or educated guess or
- by using a known vulnerability in a publicly available service
Then the attacker uses this script to alter a file or upload malware to the server:
this may be a sneaky change to an already existing script which opens a backdoor or some kind of webshell or ircbot.
If that already happened to you: Congratulations, you're now the proud owner of a freshly infected zombie!
If you are a sysadmin and running one ore more webservers with apache you may have been wondering how you could protect those machines from being compromised. There are a few steps you should take before you follow this quick introduction to mod-security:
1. Make sure apache is configured properly. Try to restrict the server from sending unnecessary information about its version, installed services etc. Search and read articles about hardening webservices and apache. Understand how attackers gather information about your servers and what kind of vulnerablity they could be after.
2. Do not run exploitable software. Common targets are unpatched versions of Wordpress etc., webmail-services, and CMSs. If possible, try to restrict access to or avoid tools like phpmyadmin.
3. Make sure potentially exploitable scripts, like php, have no way to write on the filesystem. This is not always practical, but should be manageable: use a development system for file uploads and merge changes into your (read-only) public production system. You may want to use wget to take an html-only-snapshot of your development system for deployment on your production system.
4. If your web-folder (like /var/www) contains any files or directories with permissions like 0777, you're likely to experience problems in the near future. Be sure to understand what you are doing and try to explain your concerns to your users/web-developers. Database access should be configured read-only where no writing to the database is needed.
But now let's start with the HowTo:
mod-security is a very good tool for professionally securing webservers. Once you spent some time with it you wouldn't want to run a webserver without it. By design, mod-security is a web application firewall (WAF) that blocks potentially dangerous requests to your server. But even without taking any action, just by logging, mod-sec can show you how bots or attackers try to exploit your services.
I wrote this HowTo because I could not find any recent documentation on how to quickly set up mod-security on Debian wheezy. This really is only a quick and superficial way to get mod-sec working. Be sure to read further documentation on how to set up and maintain this magnificent tool. (And please point out to me any mistakes I made or possible improvements to this HowTo).
This documentation has only been tested on Debian wheezy (7.3 as of now). It is likely to be broken on any other distro or version.
I'm assuming apache is configured and running. Start by installing mod-security. Note that apache will be restarted in the process:
# apt-get install libapache2-modsecurity
The module is now up and running. It is in no way configured yet, so it still does nothing. Let's configure mod-sec: if your installation went right you now have a set of rules under /usr/share/modsecurity-crs
If you're using wheezy, the config-files are under /etc/modsecurity
Copy the default rules:
# cp -rp /usr/share/modsecurity-crs/* /etc/modsecurity
Make an initial configuration:
# cd /etc/modsecurity
# cp -p modsecurity.conf-recommended modsecurity.conf
# vi modsecurity.conf
Important: the first directive controls mod-sec's behaviour. Until everything is configured and your rules are O.K. it should look like this:
SecRuleEngine DetectionOnly # Do not block anything, just write logs
If you're satisfied, here is nothing more to do right now. Enable the configuration in apache:
# vi /etc/apache2/conf.d/mod-security
with the following content:
<IfModule security2_module>
Include /etc/modsecurity/*.conf
Include /etc/modsecurity/activated_rules/*.conf
</IfModule>
Activate all rules in /etc/modsecurity/activated_rules by setting symlinks:
# cd /etc/modsecurity
# for f in `ls base_rules/` ; do ln -s /etc/modsecurity/base_rules/$f activated_rules/$f ; done
### As the name says the following is optional.
### Some of those rules may lead to PCRE-recursion-limit
### exceptions or missing data errors,
### depending on your configuration.
# for f in `ls optional_rules/` ; do ln -s /etc/modsecurity/optional_rules/$f activated_rules/$f ; done
The preparations are done now. Test the configuration:
# apachectl configtest
You should be getting "Syntax OK" - If not, you're up to some trouble-shooting; please consult your search-engine of choice for solutions - there are plenty!
If you got a "Syntax OK" you're fine. Time to restart apache:
# service apache2 restart
if the server is very busy there should be plenty of false-positives now in /var/log/apache2/modsec_audit.log
That's O.K. for now: mod-sec is up and running.
If there is not enough traffic to trigger alarms you may want to use a security-scanner such as nessus etc. or some simple SQL-injection-attempt to trigger positive alarms.
Now you need to understand the logged errors and find false positives. The better way to cope with those errors is to modify the rule that triggered the alarm to your needs. The fast and insecure way is to deactivate the rule by whitelisting. You can create a whitelist-file with the following example content to whitelist rules:
# vi /etc/modsecurity/activated_rules/modsecurity_crs_99_whitelist.conf
content:
# This client is allowed to bypass mod-sec:
#SecRule REMOTE_ADDR "^192.168.0.3" phase:1,nolog,allow,ctl:ruleEngine=off
#SecRuleRemoveById 90001 # deactivated rule
To activate the changes you need to reload your apache-configuration (I prefer a restart).
When you're confident that the rules are set up correctly you can activate mod-sec's blocking engine in /etc/modsec/modsecurity.conf:
SecRuleEngine On
That's it!
To even further secure your server you could use a tool like fail2ban to block IPs after a certain amount of alarms or logcheck to send you email-notifications on security events.
Abonnieren
Posts (Atom)