What's New
ArticlesPas de nouveaux articles
COMMENTAIRES last 2 daysPas de nouveau commentaires
TRACKBACKS last 2 daysNo new trackback comments
|
|
| Author: |
sioban |
| Dated: |
Sunday, 09 March 2008 @ 09:56 AM CET |
| Viewed: |
452 times |
|
 J'ai un serveur de mail et de temps en temps j'ai besoin de réémettre un mail tel quel car il y a eu une petite erreur dans le champ destinataire par exemple.
Voici une astuce si on a le mail brut et un sendmail sous la main.
Dans le mail brut avec les entêtes, il faut tout d'abord supprimer les champs suivants :
- lignes Received inutiles
- ligne "From:"
- ligne "To:"
- ligne "Return-Path"
Le reste peut être laissé sans trop de soucis (attention les lignes Mime et Content-type ne doivent surtout pas être supprimées).
Imaginons que votre mail original allégé des lignes est dans /tmp/mail_to_be_send
Donc la commande magique est la suivante :
(echo "FROM: [votre from]"; echo "TO: [votre to]" ; echo "REPLY-TO: [votre reply-to]"; cat /tmp/mail_to_be_send)| /usr/sbin/sendmail -t
et hop un beau mail avec un tout frais...
|
| Author: |
Admin |
| Dated: |
Friday, 10 March 2006 @ 10:31 AM CET |
| Viewed: |
1 097 times |
|
Je viens de décider de réinstaller mon Dell Inspiron 8000 sous Kubuntu Dapper Flight CD 4
Bonne idée je me dis...
Sauf que j'ai oublié de récupérer mon ancien fichier xorg.conf et donc pas de X en
1400x1050 (c'est pas la première fois que ça m'arrive).
Je passe donc sur le net pour récuperer des fichiers xorg.conf qui fonctionnent, mais
bizarrement aucun ne marche.
Jusqu'à ce que je tombe sur un xorg.conf qui défini le ModeLine du format 1400x1050,
les VertRefresh et HorizSync adéquats :
HorizSync 31.5 - 90.0
VertRefresh 60.0 - 60.0
ModeLine "1400x1050" 108.0 1400 1448 1462 1688 1050 1050 1053 1066
Sans cette information essentielle, il m'est impossible d'avoir ce format, car il semble
que le driver n'est pas capable de le trouver tout seul (ça marche pour tout les autres
formats, sauf celui-ci).
et comme je suis sympa, cliquez sur "en savoir plus" pour avoir le fichier
xorg.conf complet
|
| Author: |
Admin |
| Dated: |
Monday, 27 February 2006 @ 03:49 PM CET |
| Viewed: |
623 times |
|
C'est en lisant la mailing-list Full
Disclosure que je suis
tombé sur une réflexion intéressante
d'un des protagonistes.
Pourquoi ne pas utiliser un collecteur statistique sur des
requêtes DNS afin de détecter des comportements
anormaux (Projet
de recherche de l’université
d’Amsterdam par Antoine Schonewille et Dirk-Jan van Helmond).
En effet à partir d’un échantillon
‘normal’ on peut en déduire des
comportements anormaux, comme des requêtes vers des sites
réputés dangereux, ou des demandes pour des
requêtes non autorisées comme AXFR ou IXFR (je
verrouille personnellement ces requêtes entre mes deux NS).
Ou, si on voit passer des requêtes pour des serveurs MX
ne provenant pas d’un serveur de mail interne, on peut
s’interroger sur la possibilité que le PC faisant
les requêtes soit infecté par un logiciel de spam
ou un virus.
J’utilise déjà pas mal les logs des
firewalls pour ce genre d’analyse en me basant sur les ports
bloqués, on découvre assez facilement des
machines infectées comme ça (requêtes
sur le port 135 par exemple pour Blaster) et ça a permis
d’éradiquer nombres d’infections virales
dans mon
travail (comment ça il n’y a pas un antivirus sur
tous les postes ??? ;)).
A une plus grande échelle (au niveau d’un ISP), ce
système permettrait de détecter des
réseaux de Zombies.
Par conséquent je me suit lancé dans
l’installation de DSC – DNS Statistics Collector.
L’installation est relativement simple si l’on suit
le manuel (disponible dans l’archive) mais demande quelques
prérequis au niveau des librairies perl.
Je ne me suis heurté qu’à un seul petit
souci, en effet DSC est basé sur ploticus
dans sa version
« compilée » pour afficher ses
graphiques.
Or j’utilise une debian, et quand je le peux,
j’utilise les paquets debian (c’est plus simple
pour la
maintenance).
Donc par défaut, le script perl « ploticus
» est recherché dans le répertoire
« /usr/local/bin » alors que chez moi, il
était dans « /usr/bin », ce diagnostic
fait, un simple « ln –s » a
corrigé le soucis.
J’ai aussi installé le collector et le presenter
sur la même machine (et oui je n’ai qu’un
seul serveur ;)), pour cela il suffit de positionner la variable
« run_dir » au même endroit que le
répertoire « /usr/local/dsc/data/serveur/dns
»
Un peu de configuration apache, quelques remaniements dans les
répertoires et voilà que j’ai
de jolis
graphiques qui s’affichent !
Il faut maintenant, que je le laisse tourner un peu et que je regarde
ces statistiques de temps en temps pour essayer de détecter
des anomalies.
|
| Author: |
Admin |
| Dated: |
Friday, 20 January 2006 @ 12:54 AM CET |
| Viewed: |
2 235 times |
|
Depuis quelques temps, les sources debian sont signés par gpg.
Réguliérement, je me retrouve donc avec ce genre de messages d'erreurs quand je rajoute une source :
W: GPG error: http://etc.inittab.org ./ Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C514AF8E4BA401C3
Pour corriger ce problème, il faut rajouter la clé de la source avec apt-key.
et voici la procédure :
- il faut copier les 8 derniers caractéres [ceci n'est plus necessaire]
- il faut récuperer la clé d'un serveur de clés
- il faut l'ajouter à la base des clés de confiance.
- [nouveau] : il faut l'ajouter au répertoire des clés de confiance d'apt
gpg --keyserver wwwkeys.eu.pgp.net --recv-keys C514AF8E4BA401C3
gpg --armor --export C514AF8E4BA401C3 | apt-key add -
gpg --export C514AF8E4BA401C3 >> /etc/apt/trusted.gpg
|
| Author: |
Admin |
| Dated: |
Thursday, 12 January 2006 @ 09:41 AM CET |
| Viewed: |
1 287 times |
|
Ce truc ne marchera que si on a effacé un fichier, pas si on a écrasé son contenu ( si on l'a supprimé puis créé un fichier du même nom, ça marche. Sinon généralement on a une troncation et ça ne marche pas ) . Il faut également qu'un programme en cours d'exécution ait gardé ce fichier ouvert. Ce qu'il faut savoir, c'est qu'un rm ne fait que virer l'entrée du répertoire pointant vers le fichier ; mais il existe physiquement sur le disque tant que tous les programmes qui l'utilisent ne l'ont pas fermé. On peut penser à une espèce de compteur de référence.
Il faut retrouver le PID du process ayant ouvert ce fichier ; le plus simple c'est encore de faire un lsof | grep nom_du_fichier. La deuxième colonne est le PID dont on a besoin. Faire cd /proc/PID/fd. Dans ce répertoire, on trouvera les file descriptor utilisés par ce programme, c'est à dire les fichiers ouverts. Pour voir ce vers quoi pointent ces descripteurs, ls -la. Une entrée correspondra au fichier effacé sous la forme "N -> nom_du_fichier (deleted)", où N est un nombre. Il suffit alors de faire un cp N vers la destination de son choix ( pourquoi pas celle d'origine ) et voilà !
Évidemment l'ennemi absolu de la récupération de fichier c'est l'écrasement du contenu. Généralement les lourds outils récupérant ce qu'ils peuvent sur le disque ne pourront eux-même rien y faire. Attention que l'astuce ne fonctionne pas non plus sur un mount NFS par exemple.
|
| Author: |
Admin |
| Dated: |
Thursday, 20 October 2005 @ 03:49 PM CEST |
| Viewed: |
5 111 times |
|
Configuration
des
VLAN entre
un firewall PIX et
un switch DLINK
Mise en place des
vlans sur le pix.
Dans notre exemple nous avons créé 2
vlans : le
vlan2 et le vlan3, ils seront tous les deux associés
à
une interface logique.
Cisco recommande de ne pas utiliser le vlan1 (le
vlan par
défaut sur les switchs dlink) car on pourrait injecter des
paquets de ce vlan vers d’autres vlans, nous
réservons
donc ce vlan à l’administration du switch, mais
sans le
tagger.
On ne configure donc pas de vlan sur l’interface physique car
cela pose des soucis avec le dlink et on serait obligé de
tagger le vlan1, ce qui est contraire à la logique DLINK.
En fait nous avons deux théories contraires qui
s’affrontent,
Dlink a absolument besoin de son vlan default, toute
l’administration
se faisant sur celui-ci, et il est extrêmement
risqué de
vouloir utiliser un autre VLAN à ces fins (on risque de
perdre
la main sur le switch). D’un autre coté cisco
annonce
qu’il ne faut pas utiliser le VLAN default et qu’il
faut
associer un vlan à l’interface physique.
On arrive donc à une contradiction, je me suis donc
efforcé
de trouver un compromis entre risque sécuritaire et perte de
la prise en main du switch et c’est pour cela que je ne
configure pas de vlan sur l’interface physique mais
uniquement
sur des interfaces logiques. Je peux donc utiliser l’ip
adresse
de l’interface physique pour administrer le switch dlink sans
avoir a tagger le port 1 du vlan 1 (reset du PVID) ou à
déplacer l’adresse d’administration du
switch dans
un vlan autre que le vlan default (absolument
déconseillé).
Source : Cisco Pix Vlan - configuration guide.
|
| Author: |
Admin |
| Dated: |
Friday, 07 October 2005 @ 05:24 PM CEST |
| Viewed: |
752 times |
|
La clef de voûte de
la sécurisation des clefs ssh se trouve
dans des paramètres que l’on ajoute dans le
fichier .ssh/authorized_keys2 avant
la clef que l’on veut contrôler :
from="ip1,ip2" command="/home/user/.ssh/authorized_progs.sh",
no-agent-forwarding,
no-X11-forwarding,
no-port-forwarding,
no-pty ssh-rsa AAAB3N...9BF7c= admcft@sacftip1
La solution adéquate est un mélange de toutes les
options
afin de verrouiller au maximum les clés ssh.
Malgré les informations de
sécurisation ci-dessous, voici
quelques éléments qui démontrent que
tout n’est pas simple :
Les fichiers
authorized_keys* sont ouvert en écriture par le compte
cible…
On pourrait donc en cas de limitation scp ou sftp simplement
réécrire ce
fichier à notre convenance. Il faut donc absolument
empêcher la modification en
écriture de authorized_keys2 et tout script
définissant les droits d’execution
(ex :authorized_progs.sh).
En plus de ça des fichiers comme .profile,
.bash_profile, .bashrc sont aussi
susceptible d’être modifié de
façon inadéquate et
exécutés au prochain
login !
Il faut par conséquent fermer
complètement le répertoire home de
l’utilisateur distant et créer un espace
séparé pour déposer des fichiers, au
mieux vérifier que l’on écrit bien dans
cet espace.
|
| Author: |
Admin |
| Dated: |
Friday, 07 October 2005 @ 04:18 PM CEST |
| Viewed: |
3 865 times |
|
L'objectif est de faire en sorte qu'une connexion VPN sur un Pix Firewall soit
authentifiée par un serveur LDAP.
Pour cela on passe par un intermédiaire qui est un serveur Radius.
|
| Author: |
Admin |
| Dated: |
Friday, 07 October 2005 @ 03:52 PM CEST |
| Viewed: |
1 455 times |
|
En effet on peut forcer au niveau du client le cipher et le protocole que l'on veut utiliser.
Aujourd'hui les SEULs protocoles correctement sécurisés sont TLSv1 et SSLv3, tous les précédants possédants des failles.
Par exemple la faille "slapper" pour SSLv2 date de 2002 : http://xforce.iss.net/xforce/alerts/id/advise131
Et utiliser un CIPHER trop faible pour la clé pourrait amener à un décodage de celle-ci
(par exemple RC2-CBC ou même NULL !)
Je me suis penché rapidement sur le sujet afin de pouvoir tester quels Ciphers et quelles versions de SSL on peut forcer sur un serveur.
|
| Author: |
Admin |
| Dated: |
Friday, 07 October 2005 @ 03:44 PM CEST |
| Viewed: |
1 844 times |
|
Sur les routeurs qui sont des noeuds de réseaux il
fautrentrer un certains nombre de commandes afin
de les sécuriser eux-même contre des attaques du
type DDOS (Distributed Denial of Service).
D'autres Access-list sont aussi nécessaires lorsqu'on veut
faire du BGP afin de limiter les DrDOS
(Distributed Reflexive Denial of Service).
Des commandes d'automatisation de cette procedure existent (a
partir de l'IOS 12.3(1)):
|
First | Précédent | 1 2 | Suivant | Last |
