Schlagwort: Eset

Kategorien
Sicherheit

Umstieg von ESET Version 3.x auf 4.x (Linux/Debian)

 Hier eine kurze Zusammenfassung der einzelnen Schritte die beim Umstieg von Eset 3.x auf 4.x unter Linux (Ubuntu/Debian) zu beachten sind.

Probleme tauchen auf weil ESET das Verzeichnis in dem die Dateien liegen nach /opt verschoben hat – in der Doku von ESET steht allerdings noch der alte Pfad mit /usr/bin und /usr/sbin drinnen, was laut Doku nur bei SuSE und RedHat Versionen der Fall sein sollte…

Als erstes habe ich die alte ESET Version deinstalliert:

dpkg -r esets

Anschließend den Benutzer und das Kennwort aus der alten Konfiguration geholt:

grep „av_update_“ /etc/esets/esets.cfg

Und die aktuelle Version installiert:

dpkg -i esets-4.0.8.amd64.deb

Die neue Konfiguration anpassen und Benutzer und Kennwort eingeben (Minimum!)

vi /etc/opt/eset/esets/esets.cfg

Die Lizenzdateien der alten Installation ins neue Verzeichnis kopieren

cp /etc/esets/license/* /etc/opt/eset/esets/license/

Lizenzen überprüfen

/opt/eset/esets/sbin/esets_lic

Environment Variable setzen damit der Pfad auf die ESET Dateien verweist
(„/opt/eset/esets/sbin:/opt/eset/esets/bin beim PATH hinzufügen)

vi /etc/environment

Für die aktuelle Shell die Pfad-Variable setzen

export PATH=“/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/eset/esets/sbin:/opt/eset/esets/bin“

ESET Virenscanner Daemon neu starten

/etc/init.d/esets restart

CLI testen

esets_cli /tmp/

Bei mir musste ich das Update der Virensignaturen mehrmals starten damit es ohne Fehlermeldung durch lief

esets_update –verbose
esets_update –verbose
esets_update –verbose

Anschließend amavis-new anpassen

vi /etc/amavis/conf.d/15-av_scanners

Der primary-Scanner Eintrag muss wie folgt lauten:

  ### http://www.eset.com/
  [‚ESET Software ESETS Command Line Interface‘,
   ‚/opt/eset/esets/bin/esets_cli‘, ‚–subdir {}‘,
  [0], [1, 2, 3], qr/virus=“([^“]+)“/ ],

Nach dem Neustart von Amavis („service amavis restart“) sollten alle eingehenden E-Mails mit der aktuellen ESET Version auf Viren gescannt werden.

Test-Emails mit Viren kann man sich über folgenden Link schicken lassen http://www.h-online.com/security/services/Emails-with-virus-dummies-823268.html

Kategorien
Sicherheit

ESET Gateway Security Version 3.0.21 – Problem beim Zugriff auf https-Seiten

Wie’s scheint hat die am 7.01.2011 veröffentlichte Version von ESET Gateway Security einen Bug oder ein neues Feature. Auf jeden Fall kann man mit der Version nicht auf https Webseiten zugreifen.

Squid meldet im Logfile nur ein

1295888048.225      0 192.168.0.139 TCP_MISS/000 948 CONNECT
encrypted.google.com:443 – DEFAULT_PARENT/127.0.0.1 –

Den Support habe ich schon mal kontaktiert, mal sehen ob wir das Problem schnell eingrenzen können.

Bis dahin läuft jetzt erstmal die ältere Version 3.0.18 weiter…

2011-01-25 – Anmerkung: Der Support hat sich inzwischen gemeldet, wieder mal einen Bug gefunden. Wenn alles klappt, dann gibt es nächste Woche eine neue Version die den Fehler behebt.

ESET/NOD32 nod14FB.nup Problem – Anmeldung funktioniert nicht mehr!

 Wieder mal ein heftiges Problem mit dem ESET Virenscanner – nach einem Update heute so gegen ca. 14:15 Uhr trat beim Neustarten von PC’s das Problem auf dass man sich nicht mehr anmelden konnte.

Der Rechner (Windows XP SP3) blieb einfach bei der Login Maske stehen und nichts passierte mehr, lediglich ein Aus-/Einschalten brachte wieder etwas Leben in die Bude, allerdings keinerlei Abhilfe!

Im abgesicherten Modus konnte man noch auf’s Netzwerk zugreifen und auch sonst sah dort alles vernünftig aus. Im normalen Modus lief allerdings nichts mehr, man konnte im Netzwerk noch nachvollziehe wie der Rechner DHCP Pakete schickt und sich eine Adresse holt, wenige Ping’s später war er tot.

Nach kurzer Rücksprache bei meinem Kollegen Phil hatte ich Gewissheit, ein Update von NOD32 – genauer nod14FB.nup war Schuld an dem Problem. Wenige Stunden später war das Ganze dann auch schon behoben – der Viren- und Spyware Schutz wurde auf Version 1289 aktualisiert und damit läuft jetzt wieder alles.

Zur Not kann man auch im abgesicherten Modus die *.dat Dateien im ESET Verzeichnis löschen und neu starten, dann läuft der Rechner zumindest wieder bis zum nächsten Neustart oder bis das Update mit der laufenden Version installiert wurde.

Das Ganze ist natürlich extrem ärgerlich, vor allem weil es in kurzer Zeit bereits das zweite Mal ist dass ESET so einen garvierenden Bock geschossen hat. Immerhin sind dieses Mal nur Rechner betroffen, die während die falsche nod14FB.nup unterwegs war, neu gestaret wurden – allen anderen sollte das regelmässige Aktualisieren der Signaturen und Module geholfen haben.

Kategorien
Linux Sicherheit

ESET Signatur Reparatur – Hardcore Variante

Nachdem heute Vormittag eine defekte Signatur die Funktion vom ESET Virenscanner unter Linux extrem gestört hat, habe ich hier für alle betroffenen die Hardcore Variante zum reparieren der Signatur-Dateien…

Eset Scanner stoppen:

sudo /etc/init.d/esets_daemon stop

Defekte Signaturdateien löschen:

sudo rm -r /var/lib/eset/*

Signaturdateien aktualisieren:

sudo esets_update –verbose

Eset Scanner wieder starten:

sudo /etc/init.d/esets_daemon start

Und schon sollte alles wieder laufen…

ESET Remote Administrator Console – manuelle IP-Adresseingabe für Ferninstallation

Bei den früheren Versionen der Remote Administrator Console konnte man unter Push-Install immer mit Add eine IP-Adresse (oder mehrere) hinzufügen.

War ganz praktisch wenn die Installation im WAN oder dank falscher Namens-Auflösung nicht funktioniert hat.

In der Aktuellen Version 4.0.122.0 funktioniert das ein wenig anders als bisher!

Jetzt kann man in der „Remote Install“ Ansicht auf den Reiter „Computers“ klicken und im links erscheinenden Abschnitt bei „Custom/Custom List“ eine eigene Liste erstellen!

Kategorien
Linux Sicherheit

ESET Gateway Security mit Kombinationsproblemen

Einer meiner Kunden klagt seit kurzem darüber dass das Surfen im Internet unerträglich langsam ist, speziell bei Webseiten mit vielen Bildern drauf dauert der Seitenaufbau teilweise bis zu einer Minute oder länger.

Beim Kunden ist ein Squid Proxy Server (Version 3) und vorgeschaltet das ESET Gateway Security Produkt in Version 3.0.15.

Im Logfile von Squid sind keine besonderen Auffälligkeiten zu finden, lediglich am Windows Client mit IE oder Firefox merkt man’s beim Surfen ganz deutlich dass etwas nicht stimmt. Surft man von Windows mit w3m läuft alles gewohnt schnell.

Nach längerer Suche habe ich heute eine mögliche Ursache für die deutliche Verzögerung gefunden!
Der Gateway Rechner hat in der resolv.conf Datei folgende Name-Server eingetragen:

195.3.96.67
195.3.96.68

Beides Server der Telekom und beide antworten teilweise mit erheblicher Verzögerung auf DNS Anfragen!

Allerdings nicht immer und auch nicht bei allen Domains – und erst recht nicht wenn man die Kommandozeile mit „dig @192.3.96.67“ bemüht…

Es macht irgendwie die Kombination aus allem aus, gefunden habe ich das Problem im Logfile vom ESET-Daemon – /var/log/eset/eventlog.dat

Die Datei hat ein etwas eigenes Format, aber ein paar Infos kann man durchaus entnehmen!
Es fanden sich Einträge wie der folgende:

Bad host or service: profile.ak.fbcdn.net:0: Name or service not known|Cannot get source address – error in getaddrinfo

Was mich auf die Fährte mit dem DNS Server gebracht hat, immer wenn im Logfile ein solcher Eintrag zu finden war habe ich sogleich einen „dig“ Befehl abgeschickt und traf auf die 5 Sekunden Verzögerung.

Zur Lösung des Problems habe ich jetzt lokal am Gateway Rechner eine Bind9 Instanz installiert welche die beiden Telekom DNS Server als Forwarding-Hosts eingetragen hat und siehe da, Bind speichert die Abfragen brav zwischen und schon läuft das ganze wie am Schnürchen. 🙂

Warten wir mal ab wie lange das so bleibt!

Ein kleines Problem konnte ich bisher nicht wirklich lösen, der Zugriff mit dem Internet Explorer via Squid und ESET Gateway Security auf die Online Banking Seite der BankAustria klappt leider nicht – da kommen keine Daten retour. Mit dem Firefox läuft es aber ohne Probleme…

Kategorien
Sicherheit

ESET/NOD32 Problem mit dem Remote Admin nach Update


Da kommt man so schnell nicht drauf… 🙂

Gut daß es zuverlässigen Support gibt der einem die Lösung schnell schickt!

Nach der Installation der Aktuellen Version vom Remote Administrator und natürlich auch dem aktuellen Server habe ich bei einem Kunden entsprechend auch die Clients aktualisiert. Nach der Aktualisierung waren alle Rechner doppelt vorhanden – ein zweites Mal mit „00001“ angehängt!
Alles klein Problem, man erkennt den alten Eintrag ja an der alten Version und kann ihn einfach löschen…

Soweit die Theorie – in der Praxis hängt das Ding dann ordentlich und bringt wenn überhaupt eine Fehlermeldung 20009,3 -> die uns natürlich allen was sagt und sofort zur Lösung bringt! Eh klar.

Beheben kann man das Problem in dem man im Remote Administrator den Punkt Tools/Server Options/Other Settings und dort „Edit advanced settings“ wählt und wie im Screenshot zu sehen im Setup-Bereich unter Advanced den Punkt „Enable MAC address renaming“ auf yes setzt.

Anschließend lassen sich die alten Einträge problemlos löschen!

Kategorien
Linux

Amavis & Eset Virenscanner – Version 3.0.13, esets_cli funktioniert nicht mehr

Ich verwende schon lange den Virenscanner von ESET und bin eigentlich sehr zufrieden damit, seit der letzten Änderung in der Version 3.0.13 kann man allerdings nicht mehr das esets_cli Tool zusammen mit Amavis zum scannen eingehender E-Mails verwenden!

Meine Support-Anfrage an ESET wurde wie folgt beantwortet:
„Based on what I’ve been told by our linux dep., esets_cli needs license for mail
security to work. Unfortunately, there was a „bug“ which allowed you to use
esets_cli even with the license for file security. This has been „fixed“ in v 3.0.13
…“

Tja, für die paar E-Mails die ich bekomme hat mir das bisher ohne Mail-Server Lizenz voll ausgereicht – blöd halt dass die das jetzt auf einmal als „Bug“ einstufen und abgedreht haben!

Aber wo Schatten ist muss auch Licht sein – es gibt das Tool esets_scan mit dem man auf der Kommandozeile den Scanner starten kann, das Tool müsste man ja eigentlich genauso verwenden können. Mit ein wenig Pech ist es halt nicht ganz so performant, aber das juckt mich nicht weiter…

In der Datei /etc/amavis/conf.d/15-av_scanners steht bisher der Eintrag:

### http://www.eset.com/
[‚ESET Software ESETS Command Line Interface‘,
‚/usr/bin/esets_cli‘, ‚–subdir {}‘,
[0], [1, 2, 3], qr/virus=“([^“]+)“/ ],

esets_cli hat also die Rückmeldung „0“ geliefert sobald ein Mail virenfrei war (man esets_cli).

Für den esets_scan habe ich das ganze wie folgt angepasst:

### http://www.eset.com/
[‚ESET Software ESETS Command Line Interface‘,
‚/usr/sbin/esets_scan‘, ‚–subdir {}‘,
[0], [1, 10, 101, 102, 103], qr/name=“([^“]+)“/
],

Die Datei /usr/sbin/esets_scan hat von Eset die Rechte „-rwsr-x—“ verpasst bekommen, Amavis kann die Datei daher nicht ausführen und ignoriert sie vorerst – erst nach dem „chmod +rx /usr/sbin/esets_scan“ kann Amavis die Datei ausführen.
Nach dem Neustart von Amavis (/etc/init.d/amavis restart) kann man im Logfile /var/log/mail.info mitverfolgen welche Virenscanner erkannt und eingebungen werden:

Apr 23 05:49:36 server amavis[11471]: Found primary av scanner ESET Software ESETS Command Line Interface at /usr/sbin/esets_scan

So sollte das dann in etwa aussehen…

Damit funktioniert das ganze dann wieder ohne Probleme!