Winexe permet de lancer des commandes à distance sur un Windows depuis une machine Gnu/Linux.

winexe remotely executes commands on WindowsNT/2000/XP/2003 systems from GNU/Linux (probably also other Unices capable to compile Samba4).

J’ai testé aussi vers un Seven et ça fonctionne.

C’est probablement un peu l’équivalent de PsExec de Russinovich sous Windows.

Les sources sont disponibles sur le site, ou sinon un paquet deb était dispo du temps d’Intrepid.

Le paquet en question contient:

• winexe - Windows Remote Execution Service
• wmic - WMI client

wmic permet lui d’utiliser la partie WMI en utilsant la syntaxe [WQL

Et ce bon petit Copyright en message de bienvenue pour donner le ton…

Présentation des 2 outils Corkscrew et Proxytunnel:

Ils permettent donc de créer des tunnels TCP à travers un proxy HTTP (via la méthode CONNECT)…

On sera donc par exemple en mesure de monter une connexion SSH… Cette connexion SSH pourra être ensuite elle-même un tunnel chiffré dans lequel faire passer d’autres connexions… Je ne vous fait pas un dessin (option -D d’openSSH, tsocks…etc..

• Présentation

corkscrew is a simple tool to tunnel TCP connections through an HTTP proxy supporting the CONNECT method. It reads stdin and writes to std‐out during the connection, just like netcat. It can be used for instance to connect to an SSH server running on a remote 443 port through a strict HTTPS proxy.

proxytunnel is a program that open a tunnel through a HTTPS proxy.

• Fichier ~/.ssh/config

$ man ssh_config
ProxyCommand
Specifies the command to use to connect to the server.[…]

• Pour Corkscrew

Host mon.serveur.ssh  
Port 443  
ProxyCommand corkscrew mon.proxy.intra 8080 %h %p loginpassfile  

• Pour Proxytunnel

Host mon.serveur.ssh  
Port 443  
ProxyCommand proxytunnel -p mon.proxy.intra:8080 -F loginpassfile -d %h:%p   

On peut constater que le principe est le même.. et que la syntaxe est très proche.

• Syntaxe du fichier loginpass

• Pour Corkscrew

superLogin:superPass

• Pour Proxytunnel

proxy_user = superLogin  
proxy_passwd = superPass

• Création de connexion SSH à travers le proxy avec par exemple:

$ ssh -p 443 mon.serveur.ssh

ou

$ ssh -D 1111 -p 443 mon.serveur.ssh  

• Différences

Je n’ai pas trouvé beaucoup de différence entre les 2…pour mon utilisation:

• Proxytunnel affiche une petite ligne lors de la connexion SSH

Via mon.proxy.intra:8080 -> mon.serveur.ssh:443

• La dernière version de Corscrew semble dater de 2001.. et la dernière de Proxytunnel de 2008.

• Proxytunnel semble avoir une option pour chaîner 2 proxys (non testé).

• Proxytunnel semble avoir une option pour chiffrer la connexion entre le client et le proxy. (Non testé.. le proxy à dispo ne le supporte pas).

• Corkscrew à un logo plus sympa ;)

• Proxytunnel semble avoir une option pour faire du NTLM (non testé).

• Divers

• PuTTY a une option pour faire passer la connexion dans un Proxy…

• On peut ajouter la ligne suivante dans le ~/.ssh/config pour maintenir le tunnel si besoin

ProtocolKeepAlives 30

• On peut aussi faire du SCP de la même manière (dans les 2 sens)

$ scp -P 443 file mon.serveur.ssh:/tmp  
Via mon.proxy.intra:8080 -> mon.serveur.ssh:443  
file 100% 171 0.2KB/s 00:00   
$ scp -P 443 mon.serveur.ssh:/tmp/file .  
Via mon.proxy.intra:8080 -> mon.serveur.ssh:443  
file 100% 171 0.2KB/s 00:00  

N’oublions pas que ce n’est pas parcequ’on arrive à se connecter en SSH, que l’admin est forcément bigleux…
Il lui est tout à fait possible de voir qu’il s’agit d’un tunnel SSH et non d’une banale connexion HTTPS…

Je viens de faire la manip… donc voici un petit résumé.

• Introduction

Disons qu’on nous a alloué lé réseau 1.2.3.192/27. Ceci nous donne la plage utilisable de 1.2.3.193 à 1.2.3.222.

Vérifions quels sont les PTR actuels pour ce range:

$ for i in seq 193 222; do echo $i && dig -x 1.2.3.$i +short && echo "---"; done

Vérifions les serveurs DNS en charge d’une IP du range (prenons la .202):

$ dig ptr 202.3.2.1.in-addr.arpa  
[...]  
;; AUTHORITY SECTION:  
3.2.1.in-addr.arpa. 170940 IN NS ns1.provider.test.  
3.2.1.in-addr.arpa. 170940 IN NS ns0.provider.test.  

Vérifions les serveurs DNS en charge de la zone (le /24):

$ dig ns 3.2.1.in-addr.arpa. +short
ns1.provider.test.
ns0.provider.test.
$

Donc les noms associés à nos IPs sont gérés dans les DNS de notre provider.

• La problèmatique

Nous souhaitons avoir nous même authorité sur les reverse d’IPs de notre /27.
C’est à dire gérer nous-même les PTR sans avoir à demander à provider.test.

Comme nous avons le /27 et non pas le /24, on est obligé de ruser un peu pour ne pouvoir donner délégation que sur une partie de la zone 3.2.1.in-addr.arpa.
La “technique” consiste à passer par des CNAME et une nouvelle zone…

Voici les manipulations à réaliser:

Sur les serveurs DNS nsX.provider.test. il faut

• Supprimer les PTR existants
• Créer les CNAME suivants

[...]  
202.3.2.1.in-addr.arpa. IN CNAME 202.192-223.3.2.1.in-addr.arpa.  
203.3.2.1.in-addr.arpa. IN CNAME 203.192-223.3.2.1.in-addr.arpa.  
etc...

• Créer les NS suivants

192-223.3.2.1.in-addr.arpa. IN NS dns1.monDomaine.test.  
192-223.3.2.1.in-addr.arpa. IN NS dns2.monDomaine.test.

Le nom de la zone 192-223.3.2.1.in-addr.arpa. est plus ou moins au libre choix de l’administrateur.

Sur nos serveurs DNS dnsX.monDomaine.test.

• Créer la zone 192-223.3.2.1.in-addr.arpa.
• Créer les PTR dans cette zone

[...]  
202.192-223.3.2.1.in-addr.arpa. IN PTR cequejeveux.monDomaine.test.  
203.192-223.3.2.1.in-addr.arpa. IN PTR autretrucquejeveux.monDomaine.test.  
etc...

Plowshare is a command-line downloader/uploader for some of the most popular file-sharing websites…

On peut noter, entre autre, un OCR de capcha pour les personnes sans X ou avec déficiences visuelles ;)

En FTP passif, la connexion du canal Data s’initie depuis le client vers le serveur. Le serveur renvoit donc au client le port (et l’IP) sur lequel doit s’établir le canal Data.

Dans le cas où le serveur est dans une DMZ avec une adresse privée, de base le serveur va renvoyer au client cette adresse privée et la connexion avec Internet ne pourra donc pas se monter.
Il suffit donc d’utiliser dans vsftpd le paramètre pasv_address pour indiquer l’IP publique.

L’histoire pourrait s’arrêter là, mais maintenant que c’est l’IP publique qui est annoncée, il devient parfois délicat de se connecter depuis le LAN. (Problème de firewall, de routage etc..)
vsftpd permet d’utliser des fichiers de configuration différents en fonction de l’adresse IP de la machine qui se connecte, grâce à tcpwrapper. (vsftpd doit être compilé pour).

Il suffit donc d’utiliser 2 fichiers de configuration, chacun ayant une valeur différente de pasv_address.

$ grep vsftpd /etc/hosts.allow   
vsftpd: 10.: setenv VSFTPD_LOAD_CONF /etc/vsftpd_tcp_wrap_private_ip.conf  
$  
$ cat /etc/vsftpd_tcp_wrap_private_ip.conf  
pasv_address=10.20.30.40  
$  

Avec cette configuration, si c’est une machine du LAN qui se connecte (réseau 10.0.0.0), c’est l’adresse 10.20.30.40 qui sera renvoyée pour le canal Data en passif.
Sinon, ca sera l’adresse publique spécifié dans le fichier de configuration par défaut.

Extrait de /usr/share/doc/vsftpd/EXAMPLE/PER_IP_CONFIG/README

vsftpd: 192.168.1.3: setenv VSFTPD_LOAD_CONF /etc/vsftpd_tcp_wrap.conf

If a client connects from 192.168.1.3, then vsftpd will apply the vsftpd config file /etc/vsftpd_tcp_wrap.conf to the session! These settings are applied ON TOP of the default vsftpd.conf.

Extrait du man vsftpd.conf

pasv_address
Use this option to override the IP address that vsftpd will advertise in response to the PASV command. Provide a numeric IP address, unless pasv_addr_resolve is enabled, in which case you can provide a hostname which will be DNS resolved for you at startup.
Default: (none - the address is taken from the incoming connected socket)