Licence : GPL niveau 2. Société InnoBase, filiale depuis 2005 de la société Oracle.
Version de MySQL : Par défaut depuis la version 4.0 de MySQL mais il y est possible de l’installer sur une version 3.23 de MySQL.
Type : Transactionnel
Domaines d’application : Application nécessitant une fiabilité de l’information avec une gestion des transactions
X-A. Description
InnoDB, est le moteur transactionnel le plus utilisé à l’heure actuelle dans les secteurs dit sensibles, c’est-à-dire nécessitant une cohérence et une grande intégrité des données. Jusqu’à la version 5.1 incluse, c’est le seul moteur supportant les contraintes de clés étrangères (intégrité référentielle).
Il n’est pas concevable d’avoir des informations faisant référence à quelque chose d’inexistant. Peut-on imaginer un numéro de sécurité sociale qui ne soit pas associé à une personne ou un code postal associé à aucune ville ? Il y a des domaines d’application où les données doivent être fiables à 100%.
Au-delà de l’intégrité référentielle, InnoDB propose des mécanismes transactionnelles présentant une grande compatibilité aux critères ACID.
X-B. Organisation interne
Avec une base de données composée de tables utilisant le moteur InnoDB, il est important de ne pas utiliser les mêmes méthodes qu’avec une base contenant uniquement des tables MyISAM. Avec les tables utilisant le moteur MyISAM, il est facile de copier, supprimer une base de données : il suffit de copier le répertoire se trouvant dans le répertoire /Data/ portant le même nom que la base de données. De là, il est possible de le déplacer vers un autre serveur, de réaliser une autre base de donnés à partir de celle-ci, d’effectuer des sauvegardes. Par contre, si la base de données comporte des tables utilisant le moteur InnoDB, il faudra faire plus attention. En effet, toutes les données de toutes les tables de toutes les bases sont stockées dans un espace de tables commun. De ce fait, la base devient un peu plus rigide.
28/11/2023Categories: RéseauTags: WindowsComments off
As the connection between your internal network and the rest of the world, public Web servers always deserve an extra measure of protection. Find out one way to lock down these servers.
Serving data to users outside of an internal network, public Web servers are typically the first point of contact for an external attack. In addition, internal networking ports are the most revealing and most often attacked ports on a server. That’s why you need to make sure you’ve disabled the services that are specifically for intranets.
The two biggest culprits that you need to worry about are the Server Message Block (SMB) protocol and NetBIOS over TCP/IP. Both services can reveal a wealth of security information and are reoccurring vectors for hacks and attacks. They’re unnecessary for the operation of a public Web server, and you should take steps to shut down both services on these servers.
Disable NetBIOS
NetBIOS was once a useful protocol developed for nonroutable LANs. In this case, it acts as a session-layer protocol transported over TCP/IP to provide name resolution to a computer and shared folders. NetBIOS uses these ports:
UDP 137: NetBIOS name service
UDP 138: NetBIOS datagram service
TCP 139: NetBIOS session service
Since external users — or hackers — don’t need access to shared internal folders, you should turn off this protocol. To disable NetBIOS over TCP/IP, follow these steps:
Got to Start | Control Panel, and double-click the System applet.
On the Hardware tab, click the Device Manager button.
Select Show Hidden Devices from the View menu.
Expand Non-Plug And Play Drivers.
Right-click NetBios Over Tcpip, and select Disable.
Close all dialog boxes and applets.
This disables the Nbt.sys driver, which stops NetBIOS from listening to or initiating sessions over TCP 139. While SMB normally uses this port for communication, it will now switch to TCP 445 — also known as the Common Internet File System (CIFS) port. That’s why you need to disable SMB next.
Uninstall SMB
SMB uses TCP 139 or TCP 445 — depending on which port is available. There’s one way to disable SMB on a non-domain controller. However, I recommend completely uninstalling this service to prevent some well-meaning individual (or program) from re-enabling the service.
To uninstall SMB, follow these steps:
Go to Start | Control Panel, and double-click the Network Connections applet.
Right-click Local Area Connection (i.e., the Internet-facing connection), and select Properties.
Select Client For Microsoft Networks, and click the Uninstall button.
After the uninstall finishes, select File And Printer Sharing For Microsoft Networks, and click the Uninstall button.
Close all dialog boxes and applets.
Understand the ramifications
You’ve now disabled both SMB and NetBIOS. If an attacker manages to compromise your Web server, he or she won’t be able to use NetBIOS or SMB to further explore and exploit your network.
Of course, security measures are often a balancing act of functionality and security. In this case, disabling these services takes away your ability to remotely manage Web servers through Active Directory’s Computer Management console. However, you can still connect to and manage these servers through the Remote Desktop Client.
Final thoughts
While it’s a common practice to block these ports at security boundaries, nothing beats disabling them on the machines themselves. Remember, as the connection between your internal network and the rest of the world, Web servers always deserve an extra measure of protection.
I have tons of PDFs in multiple sub-folders in /home/user/original that I have compressed using ghostscriptpdfwrite in /home/user/compressed.
ghostscript has done a great job at compressing about 90% of the files however the rest of them ended up bigger than originals.
I would like to cp/home/user/compressed to /home/user/original overwriting files that are only smaller than the ones in destination while the bigger ones are skipped.
Si vous souhaitez rendre vos règles de firewalling persistantes les développeurs de iptables ont prévu deux commandes : iptables-save et iptables-restore.
Ces commandes permettent de créer une copie de la configuration actuelle et de charger une de ces copies.
Il se trouve que nos amis de chez Debian ont prévu un petit script permettant d’automatiser le chargement des règles iptables au démarrage : iptables-persistent. Nous allons donc dans un premier temps installer ce paquet. Nous verrons ensuite comment sauvegarder notre configuration actuelle.
Installation de iptables-persistent
L’installation est très très très simple … voyez plutôt !
# aptitude install iptables-persistent
Et le tour est joué !
À l’installation il vous sera demandé si vous souhaitez sauvegarder les règles de firewalling actuellement en place. Vous pouvez répondre oui ou non.
Ce paquet vous a créé plusieurs fichiers dont
/etc/iptables/rules.v4 : Le fichier qui sera lu par le script de démarrage pour charger vos règles IPV4.
/etc/iptables/rules.v6 : Le fichier qui sera lu par le script de démarrage pour charger vos règles IPV6.
Sauvegarder nos règles
Comme je le disais plus haut, il existe la commande iptables-save qui nous permet d’exporter la configuration actuelle. Petit exemple
La seul chose que nous avons à faire est de rediriger la sortie de cette commande non plus dans le terminal mais dans le fichier rules.v4 ou rules.v6 utilisés par iptables-persistent.
The OTPW package consists of the one-time-password generator otpw-gen plus two verification routinesotpw_prepare() and otpw_verify() that can easily be added to programs such as login or ftpd on POSIX systems. For platforms that support the Pluggable Authentication Method (PAM) interface, a suitable wrapper is included as well. Login software extended this way will allow reasonably secure user authentication over insecure network lines. The user carries a password list on paper. The scheme is designed to be robust against theft of the paper list and race-for-the-last-letter attacks. Cryptographic hash values of the one-time passwords are stored for verification, either in the user’s home directory or in a dedicated system directory.
Introduction
A well-known classic vulnerability of the Internet application protocol suite is the frequent cleartext transfer of passwords in the telnet, rsh, and ftp protocols. Modern replacements for these protocols such as Tatu Ylönen’sSecure Shell allow comfortable and secure remote sessions and file transfers over network connection that are not trusted to provide confidentiality.
However, traveling computer users often want to connect to their home system via untrusted terminals at conference hotels, other universities, and airports, where trusted encryption software is not available. Even Secure Shell does not protect against keyboard eavesdropping software on the untrusted terminal. A loss of confidentiality is often acceptable in these situations for the session content, but not for reusable login passwords. One-time-password schemes avoid the transmission of authentication secrets that are of any value after they have been used. This provides a reasonable level of protection against the widely encountered password sniffing attacks. The goal of a one-time-password login scheme is merely to provide a significant increase of security over the classic telnet/rlogin login procedure. It does not aim to protect from sophisticated active attacks such as session hijacking, host emulation, man-in-the-middle, etc. against which ssh and SSL based protocols should be used if this level of protection is required.
A widely known one-time-password scheme is S/KEY [Hal94, HM96]. OTPW is not compatible with and is not derived from either S/KEY or OPIE. It is a completely independent and different design, which I believe fulfils my functional and security requirements better.
How it works
One-time password authentication with the OTPW package is accomplished via a file containing hash values of passwords. Depending on the installation option chosen, this can either be a file ~john/.otpw located in the user’s home directory, or it can be a file ~otpw/john in the home directory of a dedicated pseudo user “otpw”. In the latter case, the otpw-gen tool for generating new passwords must be owned by pseudo user “otpw” and have the SETUID bit set. As long as users do not have such a hash file, the one-time-password facility is not active for them.
A user who wants to setup the one-time-password capability just executes the otpw-gen program. The program will ask for a prefix password that the user has to select and memorize and it will then write to standard output a password list such as:
Normally the output of otpw-gen should be sent directly to the printer as in
otpw-gen | lpr
or should be first formatted with an ASCII to PostScript converter where necessary.
Fetch the printed list immediately from the printer, fold it, and keep it with you. The list shows the machine name and the creation time to allow users to find the latest list for the right machine. It does not show the user’s name, because nobody is supposed to have the list of anyone else, but printer drivers such as a2ps might add it. Only a single list is required for a set of networked machines on which the user has a common home directory.
By default, otpw-gen generates 60 lines of output. Use the command line options -hlines, -wcolumns, and -spages to specify the length of the output. No more than 1000 passwords will be generated at a time.
Where one-time-password authentication is used, the password prompt will be followed by a 3-digit password number. Enter first the prefix password that was given to otpw-gen, followed directly (without hitting return between) by the password with the requested number from the printed password list:
login: kuhn
Password 019: geHeimOdAkH62c
In this example, geHeim was the prefix password. The spaces in the password list are just there to increase readability and can be dropped.
A clever attacker might observe the password being entered and might try to use the fact that computers can send data much faster than users can finish entering passwords. In the several hundred milliseconds that the user needs to press the return key after the last character, an attacker could on a parallel connection to the same machine send the code of the return key faster than the user.
To prevent such a race-for-the-last-key attack, any login attempt that is taking place concurrently with another attempt will require three one-time passwords to be entered:
This might look inconvenient at first, but remember that three passwords will only be requested when someone tries to login simultaneously, which in itself should already cause suspicion. The three requested passwords are randomly selected but they will never include the single password that was requested in the first of the concurrent login attempts. Only the first requested single password will be locked, not any of the requested triples. This way, the three-password method ensures that an attacker cannot disable the OTPW mechanism by locking all passwords. The triple challenge ensures that many ten thousand network connections would be necessary to perform a race attack on the same password triple, which is not practical. The OTPW package creates a symbolic link .otpw.lock in the user’s home directory to lock the first requested password while its input is pending. If a system crash created a stale lock, it will be removed after 24 hours.
