Pinturas

Ésta vez con algo de información sobre características de los pintores...

Fuente:

http://culturainquieta.com/es/pintura/item/5576-como-identificar-varios-pintores-famosos-simpaticas-pistas.html Leer más...

[ SEGURIDAD ] Privilegios recomendables de directorios en linux para servidores

Presuming that a 'web application' runs on a server (like apache, nginx, etc) and is written in some dynamic scripting language (like PHP, Ruby, etc), you have a misunderstanding in who the 'user' is.

The user is not the person who is logged into your application - that, and their role in the application (admin, etc) is completely irrelevant to the scenario. The user is the linux system user that the process runs under. The code of your website is run as only one user - it may be the user of your webserver (which isn't really a good thing), or it may be a user specific to your site (which is much better).

On linux, users belong to groups - we can add a user to another group and assign privileges to that group.

A good setup will have your server run as one user (let's call this user 'webserver') and your dynamic scripting language run (e.g. via FastCGI) as its own user (one user per site - let's call our first user 'site1').

To serve your files, the webserver needs access to them, and the scripting language needs access to them. That means: 'site1' and 'webserver' need to be able to read your files. Only one of them, however can 'own' the files. The owner is the 'user' (in user, group, other). We also need our scripting language to be able to write to the directory (and read the files it has written). The user 'site1' therefore, needs read and write permissions. Since we want group and other permissions to be as restrictive as possible, our 'owner' will be 'site1', and the corresponding user permissions will be read and write.

Since we cannot specify the permissions for our webserver as another 'user', we will add 'webserver' to the 'site1' group (you could of course, create a different group with both 'site1' and 'webserver' in it. All members of this group will be given the same permissions. The most lax permissions (of the user, group, other set) will be applied to any given user to determine their permissions.

It is worth noting that a good setup should not require files to have execute permissions for a dynamic language. The files are not directly run, but rather are read into an interpreter - only read permissions are needed to run a typical script (one that doesn't write anything).

The 'execute' permission on directories has a different meaning - it permits traversal without being able to read the contents. In order to be able to read a file in a directory, a user must have 'execute' permissions on EVERY directory above it.

For a web application, every file must have read permissions by its owner - otherwise, it is a fairly pointless file. Whether a user or an admin uploads files (via your web application) the 'owner' (i.e. the dynamic language) needs write permissions. An efficient setup will try to serve static files directly via the web server, as dynamic languages tend to be slow at reading in large files and echoing out the contents. The web server therefore needs read access to your static files.

Therefore, the minimal file permissions may be:

• A file in a directory where user uploaded static files (images/swf/js files) will reside: 640
• A file in a directory where admin uploaded static files (images/swf/js files) will reside: 640
• A file in a directory where libraries used in the application reside: 400 (or 440)
• A file in a directory where executable/browsable server side scripts will reside: 400 (or 440)
• A file in a directory where the already existing files (txt or xml) will be edited by code on server side: 640 or 600
  • (depends on whether the web server will display these, unmodified at times)

While, the minimal directory permissions may be:

• A directory where user uploaded static files (images/swf/js files) will reside: 750
• A directory where admin uploaded static files (images/swf/js files) will reside: 750
• A directory where libraries used in the application reside: 500 (or 550) [should be 510 at least]
• A directory where executable/browsable server side scripts will reside: 500 (or 550) [should be 510 at least]
• A directory where the already existing files (txt or xml) will be edited by code on server side: 750 or 700
  • (depends on whether the web server will serve files from here, unmodified at times)

Once again - your web server must have 'execute' permissions on every directory above the one it needs access to - so even if the web server won't serve files from a given directory, we should grant it execute permissions.

It is fairly common to give the web server read access to most of the files (so change those 500 to 550). Default 'somewhat secure' permissions are commonly 755 for directories and 644 for files - no execute permissions, everyone can read, and only the user can write - you will note that the vast majority of files on a linux system have these permissions.

Keep in mind that the 'other' permissions refer to any system user who is not the owner or in the group (i.e. all remaining system users). Keeping your 'other' permissions restrictive is good, because these users are an unknown - you haven't explicitly given them permission. The other permissions are often the easiest to take advantage of on a compromised system (e.g. one of the reasons why /tmp is a common target).

In the context of the above, I don't think your last two questions are that relevant. Set your directory permissions to 550 (and file permissions to 440), and then grant the user write permissions for whatever directories your application will be writing to (i.e. directory: 750; file: 640).

(You will obviously need write permissions to upload the files - but if you wish, you can remove those afterwards - arguably though, if someone is writing to a directory which only the owner can write to - your account has been compromised - which is one of the reasons for keeping restrictive permissions).

fuente: http://serverfault.com/questions/345833/what-are-perfect-unix-permissions-for-usual-web-project-directories

Leer más...

Tratamiento de Imágenes con openCV (Muy recomendable)

Increible base de datos relacionada con la libreria openCV, para el tratamiento de imagenes, desde reconocimiento OCR, superposición de objetos, hasta detector de intrusos a traves de webcam...

LINK: http://opencv-code.com/ Leer más...

Reemplazo de texto masivo en varios ficheros con Perl

El comando para reemplazar un texto en varios ficheros es el siguiente

perl -p -i -e "s[texto_viejo][texto_nuevo]g" *.txt

Se utilizan expresiones regulares para que matcheen, en este caso son simples textos como "texto_viejo" y "texto_nuevo". Se pueden utilizar backslashes para caracteres especiales...

Es un comando MUY util Leer más...

Usar conexión USB como router de Internet en beaglebone (BBB)

Routeo de BBB hacia Internet mediante PC (USB)

En la beaglebone configurar la ruta y los dns:

# route add default gw 192.168.7.1

# echo "nameserver 8.8.8.8" > /etc/resolv.conf

En la pc donde tenemos conectada la beaglebone:

# echo 1 > /proc/sys/net/ipv4/ip_forward

# iptables -A POSTROUTING -t nat -j MASQUERADE

Testeamos conexión con ping:

root@beaglebone:~# ping yahoo.ca

PING yahoo.ca (68.180.206.184) 56(84) bytes of data.

64 bytes from w2.rc.vip.sp1.yahoo.com (68.180.206.184): icmp_req=1 ttl=54 time=201 ms

64 bytes from w2.rc.vip.sp1.yahoo.com (68.180.206.184): icmp_req=2 ttl=54 time=93.8 ms

64 bytes from w2.rc.vip.sp1.yahoo.com (68.180.206.184): icmp_req=3 ttl=54 time=88.9 ms

Eso es todo...

Leer más...

REMOTE HOST IDENTIFICATION HAS CHANGED

Recién, acababa de instalar una version de debian Wheezy en una beaglebone black, y al intentar conectarme por ssh me salió el siguiente mensaje:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:9
RSA host key for barrina.usr.xc.systemadmin.es has changed and you have requested strict checking.
Host key verification failed.
lost connection

Googleando encontré que esto sucede porque la identificación que posee ese equipo sobre nosotros ha cambiado, por algún motivo como reinstalación, desconfiguración, Y HASTA HACK!.

Al conectarse le enviamos nuestro key y al ser distinto nos rechaza. Lo que debemos hacer es, borrar la información local que tenemos sobre el host con

$ssh-keygen -R 192.168.1.20
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old

Y luego volver a generar el key entre las máquinas con una conexión del tipo:

$ ssh -l noc 192.168.1.20

The authenticity of host '192.168.1.20 (192.168.1.20)' can't be established.

RSA key fingerprint is 3f:3d:a0:bb:59:24:35:6d:e5:a0:1a:3f:9c:86:81:90.

Are you sure you want to continue connecting (yes/no)? yes

Con esto quedaría resuelto el problema

Leer más...

Renombre masivo de ficheros con SH

Buenas...
Les adjunto un script que encontré por la web que me resulto muy útil...

Es un script en la shell SH de linux (/bin/sh) que a través de un bucle recorre un sinfin de ficheros en el directorio actual que matchean con la expresion dada y cambia el string fuente por el destino...

Miren...

#!/bin/sh                        # HEADERS

for i in *.sh; do                # Lista ficheros que matcheen con *.sh

j=`echo $i | sed 's/sh/png/'`    # (Str) Reemplaza ".sh" por ".png"    

mv $i $j                         # Renombra fichero por texto indicado 

done                             # finalizando el bucle for

 Espero que les sirva... Saludos! Leer más...