Antivirus et transfert de fichiers

Rédigé par gorki - - Aucun commentaire

Le problème :

Quand on est chez le client, il arrive qu'on doive transférer des fichiers dans un environnement "sécurisé". Il existe parfois des solutions de transfert :

  • espace de partage sécurisé (permet de logguer les transferts)
  • clé usb chiffrée

Et puis de temps en temps c'est galère (la clé n'est pas là, le transfert n'est pas accessible, ...) et votre fichier doit arriver chez le client. Or les .sh, .jar, .zip, .exe, sont mal vu... Normal. Les dropbox wetransfer, et autre FTP bannis, le partage WIFI bloqué, les fichiers scannés...

Pour autant la plupart des sites sont autorisés pour le travail (normal aussi).
 

Solution :

Il vous faut :

  • une habilitation sur un poste client (sinon pourquoi voudriez-vous envoyer des fichiers ?)
  • un espace disponible sur internet

Utilisez ce petit programme :

  • côté pile : on rajoute du bruit avant le fichier à télécharger. On met ce fichier sur un espace internet
  • côté face : on télécharge le fichier depuis cet espace neutre, on enlève le bruit

Si c'est un vrai virus, l'antivirus le verra lors de l'écriture du fichier sans bruit (enfin, on peut l'espérer). LE fichier n'est pas exécutable sans le "unhide", donc il faut une action humaine pour ça, donc ça limite parfaitement les risques.

Ca limite les risques, parce que si vous arrivez à faire exécuter ça à quelqu'un (transfert, compilation, téléchargement, unhide, exécution) alors vous avez largement les moyens de faire autre chose de mieux au niveau piratage.... social hacking.

Quand à savoir pourquoi on ne peut pas télécharger un fichier mais quand même l'exécuter, ça....

Ca dépanne de temps en temps.

package com.hidefile;

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.nio.channels.Channels;
import java.nio.channels.ReadableByteChannel;

import static java.lang.System.exit;

public class Hider {
    private static final byte[] bytes = "unelongueclepourquelesantivirusenaitmarrederegarder".getBytes();

    public static void hide(String filename) {
        try {
            String destFilename = filename + ".mdfy";
            ReadableByteChannel rbc = Channels.newChannel(new FileInputStream(filename));
            FileOutputStream fos = new FileOutputStream(destFilename, false);
            fos.write(bytes);
            fos.getChannel().transferFrom(rbc, bytes.length, Long.MAX_VALUE);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    public static void unhide(String filename) {
        try {
            String destFilename = filename.replace(".mdfy", "");
            FileInputStream fis = new FileInputStream(filename);
            ReadableByteChannel rbc = Channels.newChannel(fis);
            FileOutputStream fos = new FileOutputStream(destFilename, false);
            System.out.println("bytes.length = " + bytes.length);
            fis.skip(bytes.length);
            fos.getChannel().transferFrom(rbc, 0, Long.MAX_VALUE);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    public static void main(String... args) {
        if (args.length != 2) {
            System.err.println("Bad arguments : --hide|-h|--unhide|-u ");
            exit(1);
        }

        if (args[0].equals("-u") || args[0].equals("--unhide") ) {
            unhide(args[1]);
        }
        else {
            hide(args[1]);
        }
    }


}

Astuce, les extensions sont importantes : .png passe mieux que .jar.mdfy

Au pire, le bruit peut être un header PNG :

private static final byte[] bytes = new byte[]{(byte) 137,80,78,71,13,10,26,10};

 

Cannot process volume group "xxx" on boot

Rédigé par gorki - - Aucun commentaire

Le problème :

Je joue avec des VM en ce moment, copie, clone, etc... et lors de la mise au point je me suis amusé à modifier le nom des volumes groups.... Dont le volume group qui hébergait la partition "/" :)

Alors après ça ne démarre plus... curieusement...

failed to connect to lvmetad

volume group "xxx" not found

Cannot process volume group "xxx" on boot

On arrive à la fin sur le initramfs qui indique bien la cause probable : boot args, cat / proc/cmdline

Et en effet, dans ce cas, le boot_image pointe vers l'ancien nom du volume group. Quoi de plus normal.

Mais bon j'ai un peu galéré pour un truc super simple à corriger.

Solution :

J'ai cherché des disques de dépannage dont le supergrub2-iso qui ne m'a pas aidé (pas réussi à le faire booter celui-là).

Bref, la solution toute simple (parce que j'ai grub2 !), au démarrage :

  • booter une première fois jusqu'à avoir l'invite initramfs
  • lister les volumes logiques : ls /dev/mapper
  • repérer le nom du volume logique (qui contient -root en général)
  • reboot de la vm
  • lors du menu grub appuyer sur e pour éditer la configuration choisie
  • repérer la ligne qui contient /dev/mapper/<ancien nom du volume logique>
  • corriger le nom
  • ctrl-x

ça devrait booter.

Pour corriger complètement :

  1. Corriger le fichier /etc/fstab s'il contient encore la référence vers l'ancien volume logique
  2. Vérifier le disque initfsram :
update-initramfs -u

# Si des warnings sont affiché, vérifier la configuration dans : 
cd /etc/initramfs-tools
# particulièrement :
/etc/initramfs-tools/conf.d/resume
  1. Ensuite on demande à grub de se mettre à jour :
update-grub /dev/sda
grub-install /dev/sda

 

Spring Boot ne sert pas les ressources statiques

Rédigé par gorki - - Aucun commentaire

Le problème :

Avec une stack JHipster, spring-boot n'affiche pas les ressources statiques en mode développement.

Ddonc par exemple pas de index.html...

Pour autant si on lance la commande avec le war serverless (cf spring-boot-maven-plugin), ça fonctionne.

Je suis sous Intellij, à l'évidence quelque chose manque dans le lancement de la tâche Intellij spring-boot

L'architecture est mavenisé donc le root contexte est sous : src/main/webapp

Cependant spring-boot semble chercher ses ressources ailleurs : cf la documentation

Par quelle magie spring-boot doit-il trouver ses ressources dans src/main/webapp ??

Solution :

Beaucoup de recherches, de debug et autre (il y a un peu de spring-secu dans le lot). Au final les services jhipster classiques (health, dump, etc...) fonctionnent mais toujours pas de ressources statiques.

Vérification :

  • de la tâche de lancement Intellij, elle semble correcte.
  • des classpaths (on met src/main/webapp dans le classpath, on l'enlève) 
  • des paramètres de lancement (profil Spring et autre)

Au final la mise en debug m'a permis de trouver un log perdu parmi les autres :

[DEBUG] org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory - None of the document roots [src/main/webapp, public, static] point to a directory and will be ignored.

Tiens donc le Tomcat embarqué de spring-boot a ses propres chemins de recherches... (pas tout à fait décrit dans la doc Spring ci-dessus).

Breakpoint, watch, et paf, le chemin vers src/main/webapp en absolu n'est pas le bon.

Tout ça parce que le répertoire de travail de ma tâche spring-boot sous Intellij n'était pas fixé. Comment Intellij détermine cette valeur ? Mystère. En mettant donc le répertoire de travail égal au répertoire qui contient le src/main/webapp, tout roule.

[DEBUG] org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory - Document root: /home/qwbt2550/projets/portailLCRI/lcri-portal/src/main/webapp

 

 

Cinnamon and Gnome : org.cinnamon.SettingsDaemon

Rédigé par gorki - - Aucun commentaire

Problem :

After an update of my debian, I lost :

And when I tried to apply new screen configuration I had :

GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service

Many references on the net, many solutions :

  1. reinstall cinnamon
  2. remove configuration file
  3. start /usr/bin/cinnamon-settings-daemon
  4. ...

All tried, none work.

Solution :

Due to previous ressources and tests, I notice that when starting :

/usr/bin/cinnamon-settings-daemon

I had an error :

You can only run one xsettings manager at a time; exiting

After checking that is wasn't already started with :

ps -aef | grep cinnamon-settings-daemon

I perform a grep with :

ps -aef | grep settings

And I found that I had a gnome-settings-daemon running. Eurêka ! Gnome was my previous X manager.

So after a few checks :

sudo apt-get purge gnome-control-center gnome-settings-daemon gnome-control-center-data gnome-desktop3-data gnome-accessibility-themes

Restart, and all works.

 

 

 

 

Java threaddump sous windows

Rédigé par gorki - - Aucun commentaire

Problème :

Faire des threadumps un peu assisté pour Java sous Windows. Normalement, il faut :

  • repérer le pid
  • appeler jstack sur le pid
  • stocker le résultat dans un fichier unique

Mais j'avais besoin d'un script oneshot que les utilisateurs puissent lancer facilement et plusieurs fois

Solution :

Merci aux différentes ressources du net, voici un petit script rapide :

@echo off

SET JAVA_HOME=c:\Program Files\Java\jdk1.7.0_51\
SET OUTPUT_DIR=c:\temp\lzg_threaddumps
SET COMMAND_TO_CHECK=java.exe

setlocal enableextensions
if not exist "%OUTPUT_DIR%" md "%OUTPUT_DIR%"
endlocal

for /f "tokens=2" %%F in ('tasklist /nh /fi "imagename eq %COMMAND_TO_CHECK%"') do (


    SET DEST_FILE="%OUTPUT_DIR%\%%F_%date:~-4,4%%date:~-7,2%%date:~-10,2%_%time:~-11,2%%time:~-8,2%%time:~-5,2%%time:~-2,2%.txt"
    @echo Dumping %%F to file %DEST_FILE%
    rem echo "%JAVA_HOME%\bin\jstack.exe" %%F
    "%JAVA_HOME%\bin\jstack.exe" %%F > %DEST_FILE%
)

 

 

Fil RSS des articles