Indice del forum www.zeroshell.net
Distribuzione Linux ZeroShell
 
 FAQFAQ   CercaCerca  GruppiGruppi   RegistratiRegistrati 
 ProfiloProfilo  Log inLog in   Messaggi privatiMessaggi privati 

UNIX Defense & Network Security

 
Nuovo argomento   Rispondi    Indice del forum -> ZeroShell
Precedente :: Successivo  
Autore Messaggio
carlo



Registrato: 02/11/07 22:18
Messaggi: 6
Residenza: EU-Italy, Rome

MessaggioInviato: Sab Nov 03, 2007 12:12 am    Oggetto: UNIX Defense & Network Security Rispondi citando

Ciao,
come prima cosa desidero aggiungere anche i miei complimenti per l'idea geniale e per l'ottimo lavoro nella realizzazione di questa soluzione.

Da una decina di giorni ho installato alcune VM di test su alcuni server Win2K3 in ufficio e naturalmente una installazione anche sulla workstation di casa.

Ho valutato alcune soluzioni hardware Alix/AMD ed Asus/Intel (mi serve un throughput complessivo sui 200Mbps nel criptato 3DES possibilmente su unica ZS Box), a parte alcuni aspetti che, a mio avviso, sarebbe il caso di approfondire, il tutto mi sembra chiaro ed abbastanza semplice anche grazie alla consultazione di questo forum.

La mia osservazione è questa.

La ZS Box si propone come un possibile perimetrale e come tale deve rispondere ad una serie di prerequisiti di sicurezza che garantiscano la solidità della infrastruttura e possibilmente la sua impenetrabilità (ICMP ECHO ed ECHO FRAGGLE, SYN FLOOD, DNS ATTACK, ICMP/UDP ILLEGALY FRAGMENTED, TFN2K, altro...).

In riferimento al link di sintesi http://www.packetstormsecurity.org/defense/unix mi sono chiesto, quante di queste componenti sono attualmente prese in considerazione nella ZS Box ?

Nel sito di ZeroShell non ho trovato riferimenti, per favore accendetemi una luce Wink

Saluti,
Carlo.
Top
Profilo Invia messaggio privato
carlo



Registrato: 02/11/07 22:18
Messaggi: 6
Residenza: EU-Italy, Rome

MessaggioInviato: Gio Nov 15, 2007 4:53 pm    Oggetto: Rispondi citando

Ciao,
riporto in sintesi alcune delle violazioni alla sicurezza riscontrate con Nessus 3.0.6.1 Build W321 (un riconosciuto security scanner) verso una installazione ZS Box 1.0-beta7 di default.

Nella consapevolezza che non è cosa semplice intervenire a stretto giro, sarebbe opportuno e findove possibile eliminare quantomento i 5 Holes critici per passare poi ai warning, richiedo a Fulvio la sua visibilità sulla questione.

8 Open Ports, 34 Notes, 13 Warnings, 5 Holes

=======================================

Synopsis:
The remote service encrypts traffic using a protocol with known weaknesses.

Description:
The remote service accepts connections encrypted using SSL 2.0, which reportedly suffers from several cryptographic flaws and has been deprecated for several years. An attacker may be able to exploit these issues to conduct man-in-the-middle attacks or decrypt communications between the affected service and clients.

Solution:
Consult the application's documentation to disable SSL 2.0 and use SSL 3.0 or TLS 1.0 instead.

=======================================

Synopsis:
The remote host is running a version of Apache2 which is older than 2.0.51.

Description:
It is reported that versions prior 2.0.51 are prone to a remote denial of service issue. An attacker may issue a specific sequence of DAV LOCK commands to crash the process. If Apache is configured to use threads, it may completely crash the Apache process.

In addition to this, versions prior 2.0.51 are prone to a remote buffer overflow when parsing an URI sent over IPv6. An attacker may use this flaw to execute arbitrary code on the remote host or to deny service to legitimate users.

Solution: Upgrade to Apache 2.0.51

=======================================

Synopsis:
Arbitrary code can be executed on the remote host.

Description:
The remote host is using a version of mod_ssl which is older than 2.8.18.

This version is vulnerable to a flaw which may allow an attacker to disable the remote web site remotely, or to execute arbitrary code on the remote host.

Note that several Linux distributions patched the old version of this module. Therefore, this alert might be a false-positive. Please check with your vendor to determine if you really are vulnerable to this flaw.

Solution:
Upgrade to version 2.8.18 (Apache 1.3) or to Apache 2.0.50.

=======================================

Synopsis:
The remote web server is prone to multiple denial of service attacks.

Description:
The remote host appears to be running a version of Apache 2.x which is older than 2.0.50.

There is denial of service flaw in Apache 2.0.x that can be triggered by sending a specially-crafted HTTP request, which results in the consumption of an arbitrary amount of memory. On 64-bit systems with more than 4GB virtual memory, this may lead to heap based buffer overflow.

There is also a denial of service vulnerability in mod_ssl's 'ssl_io_filter_cleanup' function. By sending a request to vulnerable server over SSL and closing the connection before the server can send a response, an attacker can cause a memory violation that crashes the server.

=======================================

Synopsis:
The remote service is prone to a denial of service attack.

Description:
According to its banner, the remote host is using a version of OpenSSL which is older than 0.9.6m / 0.9.7d. There are several bugs in such versions that may allow an attacker to cause a denial of service
against the remote host.

Solution:
Upgrade to version 0.9.6m / 0.9.7d or newer.

=======================================

Synopsis:
Debugging functions are enabled on the remote HTTP server.

Description :
The remote webserver supports the TRACE and/or TRACK methods. TRACE and TRACK are HTTP methods which are used to debug web server connections.

In addition, it has been shown that servers supporting the TRACE method are subject to cross-site scripting attacks, dubbed XST for "Cross-Site Tracing", when used in conjunction with various weaknesses in browsers.

An attacker may use this flaw to trick your legitimate web users to give him their credentials.

Solution:
Disable these methods.

Add the following lines for each virtual host in your configuration file:

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]


Alternatively, note that Apache versions 1.3.34, 2.0.55, and 2.2 support disabling the TRACE method natively via the 'TraceEnable' directive.

=======================================

Synopsis:
The remote server is running with WebDAV enabled.

Description:
WebDAV is an industry standard extension to the HTTP specification. It adds a capability for authorized users to remotely add and manage the content of a web server.

Solution:
If you do not use this extension, you should disable it.

=======================================

Synopsis:
Some information about the remote HTTP configuration can be extracted.

Description:
This test gives some information about the remote HTTP protocol – the version used, whether HTTP Keep-Alive and HTTP pipelining are enabled, etc...


Plugin output:

Protocol version : HTTP/1.1
SSL : yes
Pipelining : no
Keep-Alive : no
Options allowed : GET,HEAD,POST,OPTIONS,TRACE
Headers :

Date: Thu, 15 Nov 2007 14:44:34 GMT
Server: Apache/2.0.48 (Unix) mod_ssl/2.0.48 OpenSSL/0.9.7c DAV/2
Last-Modified: Mon, 07 Aug 2006 11:59:15 GMT
ETag: "1aad9-363-3502aac0"
Accept-Ranges: bytes
Content-Length: 867
Connection: close
Content-Type: text/html; charset=ISO-8859-1

Solution:
This test is informational only and does not denote any direct security problem.

=======================================

Synopsis:
It is possible to disclose LDAP information.

Description:
Improperly configured LDAP servers will allow the directory BASE to be set to NULL. This allows information to be culled without any prior knowledge of the directory structure. Coupled with a NULL BIND, an anonymous user can query your LDAP server using a tool such as 'LdapMiner'

Solution:
Disable NULL BASE queries on your LDAP server

=======================================

Synopsis:
Remote DNS server is vulnerable to cache snooping attacks.

Description:
The remote DNS server answers to queries for third-party domains which do not have the recursion bit set.

This may allow a remote attacker to determine which domains have recently been resolved via this name server, and therefore which hosts have been recently visited.

For instance, if an attacker was interested in whether your company utilizes the online services of a particular financial institution, they would be able to use this attack to build a statistical model regarding company usage of aforementioned financial institution. Of course, the attack can also be used to find B2B partners, web-surfing patterns, external mail servers, and more...

=======================================

Synopsis:
The remote name server allows recursive queries to be performed by the host running nessusd.

Description:
It is possible to query the remote name server for third party names.
If this is your internal nameserver, then forget this warning.
If you are probing a remote nameserver, then it allows anyone to use it to resolve third parties names (such as www.nessus.org). This allows hackers to do cache poisoning attacks against this nameserver.
If the host allows these recursive queries via UDP, then the host can be used to 'bounce' Denial of Service attacks against another network or system.

Solution:
Restrict recursive queries to the hosts that should use this nameserver (such as those of the LAN connected to it).
If you are using bind 8, you can do this by using the instruction 'allow-recursion' in the 'options' section of your named.conf
If you are using bind 9, you can define a grouping of internal addresses using the 'acl' command

Then, within the options block, you can explicitly state:
'allow-recursion { hosts_defined_in_acl }'

=======================================

Synopsis:
It was possible to crash the remote host by sending a specially crafted IP packet with a null length for IP option #0xE4

Description:
An attacker may use this flaw to prevent the remote host from accomplishing its job properly.

=======================================


Saluti,
Carlo.
Top
Profilo Invia messaggio privato
fulvio
Site Admin


Registrato: 01/11/06 17:45
Messaggi: 1558

MessaggioInviato: Gio Nov 15, 2007 7:47 pm    Oggetto: Rispondi citando

Sono a conoscenza di questi problemi che saranno risolti dalle versioni non beta. Con l'uscita della 1.0.0 gli update di sicurezza saranno disponibili automaticamente con il sistema di autoupdate via web. Al momento sulle beta cerco di mantenere sicuro il kernel in maniera che il netfilter funzioni bene e permetta di proteggere gli attacchi quanto meno dall'esterno.

Saluti
Fulvio
Top
Profilo Invia messaggio privato
carlo



Registrato: 02/11/07 22:18
Messaggi: 6
Residenza: EU-Italy, Rome

MessaggioInviato: Mer Nov 21, 2007 1:10 am    Oggetto: Rispondi citando

Ciao Fulvio,
impegnando un hardware opportunamente dimensionato, sarebbe interessante poter disporre all'interno della ZS Box di uno strumento NIDS quale ad esempio SNORT con BASE/ACID (Perl e PHP4 su Apache2) ed attività di Guardian Active Response per iptables_block e iptables_unblock degli alarm in tempo reale, il database protebbe essere posizionato anche su di un opportuno server di rete privata.

Si potrebbe ottenere quindi:

    la possibilità di analizzare il traffico passante direttamente dal gateway con un Network Intrusion Detection System (utile anche con VLANs 802.1q) senza impegnare l'utilizzo delle SPAN-port;

    la possibilità di bloccare sul firewall il traffico degli end point ritenuti dannosi;

    la possibilità di interrogare l'attività dei sensori di allarme tramite interfaccia web (BASE/ACID);


Mi daresti gentilmente un tuo feedback ?

Saluti,
Carlo.
Top
Profilo Invia messaggio privato
Mostra prima i messaggi di:   
Nuovo argomento   Rispondi    Indice del forum -> ZeroShell Tutti i fusi orari sono GMT + 1 ora
Pagina 1 di 1

 
Vai a:  
Non puoi inserire nuovi argomenti
Non puoi rispondere a nessun argomento
Non puoi modificare i tuoi messaggi
Non puoi cancellare i tuoi messaggi
Non puoi votare nei sondaggi


Powered by phpBB © 2001, 2005 phpBB Group
phpbb.it