Condividi:        

WinXP Discussion

Hai problemi con i file Zip, vuoi formattare l'HD, non sai come funziona FireFox? O magari ti serve proprio quel programmino di cui non ricordi il nome! Ecco il forum dove poter risolvere i tuoi problemi.

Moderatori: Dylan666, hydra, gahan

Postdi dado » 08/11/01 16:55

In data 08/11/01 02:04, Triumph Of Steel ha scritto:

- = XP Firewall = -

Ho notato però che con ICQ i messaggi passano, e mi sta bene, ma se qualcuno cerca di spedirmi un file tramite ICQ, questo viene blokkato dal Firewall e non mi arriva neppure il messaggio di trasferimento file.

Ora... volevo sapere da chi usa un FW, come settare le porte di ICQ, visto che ogni volta cambiano! :( :(

Grazie!!





Non puoi scegliere tu a quali programmi bloccare e a quali no l'accesso al web??
Un pò come in ZoneAlarm...

House: "Vede, tutti pensano che sia un paziente a causa del bastone"
Wilson: "Allora perchè non indossa un camice bianco come tutti noi?"
House: "Perchè altrimenti pensano che sia un medico".
Avatar utente
dado
Utente Senior
 
Post: 16208
Iscritto il: 21/08/01 01:00
Località: La Città dei Sette Assedi

Sponsor
 

Postdi Triumph Of Steel » 08/11/01 17:35

No, li puoi aggiungere servizi ...

Quindi dare un nome, e una porta Interna ed Esterna...

ma se qualcuno sa se e come si può dire un intero programma... ben venga...
Avatar utente
Triumph Of Steel
Moderatore
 
Post: 7852
Iscritto il: 22/08/01 01:00

Postdi lachri » 09/11/01 01:14

Scusate la mia domanda sicuramente un po' sciocca: avete tutti XP originale??????
lachri
Utente Junior
 
Post: 99
Iscritto il: 08/11/01 01:00

Postdi dado » 09/11/01 02:35

In data 08/11/01 18:14, lachri ha scritto:

Scusate la mia domanda sicuramente un po' sciocca: avete tutti XP originale??????


Io non ce l'ho neppure... :D :D
Cmq credo che non prenderei mai un Win originale (l'unico che ho me l'han dato col pc!). :P

House: "Vede, tutti pensano che sia un paziente a causa del bastone"
Wilson: "Allora perchè non indossa un camice bianco come tutti noi?"
House: "Perchè altrimenti pensano che sia un medico".
Avatar utente
dado
Utente Senior
 
Post: 16208
Iscritto il: 21/08/01 01:00
Località: La Città dei Sette Assedi

Postdi Triumph Of Steel » 09/11/01 06:31

In data 08/11/01 18:14, lachri ha scritto:

Scusate la mia domanda sicuramente un po' sciocca: avete tutti XP originale??????


Secondo te?

Io ti dico che ho la Versione Inglese, come per Windows 2000

:P :P :P :D :D :D

Però vi dico la verità:
Non lo ho copiato :D :D
Avatar utente
Triumph Of Steel
Moderatore
 
Post: 7852
Iscritto il: 22/08/01 01:00

Postdi Triumph Of Steel » 09/11/01 07:48

Allora...

Altro problema, ma volevo avere la conferma che non fosse solo mio.

Attivando il Firewall di XP sulla connessione ad Internet, la prima volta che ci si prova a connettere subito dopo aver avviato windows ed essersi loggati, questa non si collega, e da un errore di PASSWORD ERRATA.

Aggiungendo la spunta al Firewall nella sezione ICMP e alla voce ECHO (ping ecc) la connessione va a buon fine.

Questo non succede più se si toglie nuovamente la spunta a quella voce e ci si riprova a collegarsi.

Mah?
Avatar utente
Triumph Of Steel
Moderatore
 
Post: 7852
Iscritto il: 22/08/01 01:00

Postdi dado » 09/11/01 19:15

Sarà un'altra protezione! Il firewall ti impedisce così l'accesso alla rete in quanto potenzilamente dannoso. E' un pò come se in Zone Alarm metti protesione totale: ti connetti ma non puoi far assolutamente nulla (posta o siti). Parlo sempre dalla mia gran esperienza in XP (nulla), ma provo ad ipotizzare!! :P :lol:

House: "Vede, tutti pensano che sia un paziente a causa del bastone"
Wilson: "Allora perchè non indossa un camice bianco come tutti noi?"
House: "Perchè altrimenti pensano che sia un medico".
Avatar utente
dado
Utente Senior
 
Post: 16208
Iscritto il: 21/08/01 01:00
Località: La Città dei Sette Assedi

Postdi Triumph Of Steel » 09/11/01 23:05

Immaginavo fosse per protezione... ma addirittura non collegarsi ad internet mi sembra esagerato!!

LOL
Avatar utente
Triumph Of Steel
Moderatore
 
Post: 7852
Iscritto il: 22/08/01 01:00

Postdi DarkAngel » 10/11/01 01:33

io ho provato di recente XP, a me non piace.. tutto troppo "integrato" e nascosto (compreso il firewall) e la cosa mi lascia molto perplesso e sospettoso sulla sicurezza di un sistema operativo del genere...

attenderò che esca il Service Pack 1 prima di sostituire il mio buon Win2000 Pro che non mi tradisce mai :)

e poi mi girano troppo se per cambiare sistema operativo devo cambiare anche computer!!! :)

p.s.: ho già notato che con XP il mio scanner e floppy non funzionano nemmeno (veramente non vengono nemmeno riconosciute), mentre la mia SCSI mi viene segnalato che il driver installato non è quello corretto!! (ovviamente sono i drivers che XP ha installato da solo durante l'installazione... :) ), per il resto... bho, aspetterò, ma non ci spero molto...
DarkAngel
Utente Senior
 
Post: 453
Iscritto il: 09/08/01 01:00

Postdi net-x » 10/11/01 03:20

Il bello che è già uscito qualcosa di molto simile al service pack!!!

Per quanto riguarda la licenza io sono messo come Thos....

Xp è Win Me migliorato con la stabilità di 2k.

il che per un professionista non serve a nulla ma per un gamer o per persone che navigano e fanno poche cose va bene.

Mentre per il professionista meglio win2k che è il + sicuro di microzz ora.
[+|*- Net_X -*|+]
net-x
Utente Senior
 
Post: 308
Iscritto il: 21/08/01 01:00
Località: Milano

Postdi dado » 10/11/01 03:51

In data 09/11/01 20:20, net-x ha scritto:

Mentre per il professionista meglio win2k che è il + sicuro di microzz ora.





Ma il 2k non è anche quello più perseguitato? Mi spiego... essendo il più sicuro, non è però quello che cercano più assiduamente di far crollare con virus, trojan & Co?

House: "Vede, tutti pensano che sia un paziente a causa del bastone"
Wilson: "Allora perchè non indossa un camice bianco come tutti noi?"
House: "Perchè altrimenti pensano che sia un medico".
Avatar utente
dado
Utente Senior
 
Post: 16208
Iscritto il: 21/08/01 01:00
Località: La Città dei Sette Assedi

Postdi Triumph Of Steel » 10/11/01 09:25

Bug di sicurezza su XP finora non ne hanno trovati... credo sia una cosa positva questa... no??



(le ultime parole famose.. d'oh!)
Avatar utente
Triumph Of Steel
Moderatore
 
Post: 7852
Iscritto il: 22/08/01 01:00

Postdi lachri » 10/11/01 19:50

Scusate la mia ignoranza... come' che funziona la storia delle installazioni limitate di XP???? C'e' un crack per ovviare a cio'???

alla prox
lachri
Utente Junior
 
Post: 99
Iscritto il: 08/11/01 01:00

Postdi Triumph Of Steel » 10/11/01 23:48

In data 10/11/01 12:50, lachri ha scritto:

Scusate la mia ignoranza... come' che funziona la storia delle installazioni limitate di XP???? C'e' un crack per ovviare a cio'???

alla prox


Mi spiace Lacrhi, non è il posto giusto per chiedere certe cose...
prova a mascherare la parola cr4c|< ... magari qualcuno ti risponde in privato :D :P

Per installare XP devi chiamare la MS e farti dare un codice di attivazione (non il SERIALE) che corrisponde al tuo HARDWARE ...
Se dovessi cambiare troppi componenti, allora devi richiamare la MS e farti dare un nuovo codice...
c'è un topic in cui un utente aveva segnalato un link (in italiano) che spiegava la cosa...
cercalo... e dagli una lettura
Avatar utente
Triumph Of Steel
Moderatore
 
Post: 7852
Iscritto il: 22/08/01 01:00

Postdi Triumph Of Steel » 14/11/01 00:58

/*****************************/
/* Remote Desktop Connection */
/*****************************/

Quando cerco di connettermi al mio PC tramite RemoteDC, se c'è già loggato un altro utente diverso da quello con cui mi voglio collegare, XP mi dice che l'altro utente deve scollegarsi perchè io possa accedervi ...

Mah?

Come faccio a dirgli:
Fregatene dell'altro e connettiti??
Senza disconnettere l'altro??
Pensavo che il RemoteDC funzionasse come il Terminal Service di Win2000 Server!!
Che consente + log-in ..

Non funge neanche se mi loggo come Admin!!

Help!

Ciauz & Wassuupp!!
Avatar utente
Triumph Of Steel
Moderatore
 
Post: 7852
Iscritto il: 22/08/01 01:00

Postdi DarkAngel » 16/11/01 00:28

Bug di sicurezza su XP finora non ne hanno trovati... credo sia una cosa positva questa... no??


cheeeeeeee scherzi????? bugtraq è piena di bug di sicurezza di XP che nemmeno immagini, soprattutto sul lato server e web server!!!!

qualche esempio?:

Some guys arround here are having fun with a little C program which causes
Windows200/XP to reboot:

#include <stdio.h>

int main(void)
{
while (1)
printf("ttbbbbbb")
return 0
}

--------------

----------------------------------------------------------------------


Xato Network Security, Inc.
http://www.xato.net

Security Advisory XATO-112001-01
November 7, 2001


WINDOWS 2000 AND XP TERMINAL SERVICES IP ADDRESS SPOOFING


----------------------------------------------------------------------


Systems Affected
================
Windows 2000 (All service pack levels)
Windows XP
Not Tested: Windows NT4 TS Edition


Overview
======== Terminal services has a bug that allows an attacker to cause
both the Terminal Services Manager and the Event Log to record a
spoofed IP address for Terminal Services connections. Although the
operating system itself is not fooled, if an administrator is not
aware of the issue he would not have reason to distrust the IP address
reported by Terminal Services. The vulnerability is exploited by
sending traffic through a router that uses Network Address Translation
(NAT). Note that although we have used the term "spoofing", this is
not related to other well-known TCP-IP spoofing techniques.


Details
=======
Although Terminal Services has no built-in logging facility, it is
possible to view the details of current connections by using the
Terminal Services Manager MMC utility. Among those details is the
Client Address, referring to the IP address of the connected client.
IP addresses are also recorded in the Windows Event Log although not
all logon/logoff events consistently record the IP address. An
example of what is recorded by the Terminal Services Manager can be
seen here: http://www.xato.net/reference/screen1.htm. Note that this
information is available as soon as a connection is established, even
if the client has not logged in.

The vulnerability lies in how Terminal Services gathers the client
connection information. When a Terminal Services connection is
created, the client provides certain information to the server to
establish how to configure the terminal. It also provides other
information such as the Client Name and the Client Address. This
information is transferred using the Remote Desktop Protocol which is
based on the ITU T.120 protocol. The problem is that rather than using
the TCP stack to determine the client's IP address, Terminal Services
just trusts whatever address the client provides. However, sometimes a
client behind a router does not know its public IP address and only
knows the internal IP address that it has been assigned. When creating
a Terminal Services connection, the client provides the IP address it
has been assigned internally since it knows nothing about any public
IP addresses.

For example, suppose a client is behind a router and is assigned the
internal IP address 192.168.0.10. Obviously, this is not a valid IP
address on the internet but the router provides Network Address
Translation to allow traffic from a public IP address to be translated
to an internal IP address. When that internal client connects to an
outside Terminal Server, it tells the server the only IP address it
knows: 192.168.0.10. Although there is a valid TCP-IP connection
betweeen the client and the server, Terminal Services records the
client's internal IP address.

So looking again at the example screen
(http://www.xato.net/reference/screen1.htm) we see that the server has
a connection from a client with the IP address 192.168.0.10. However,
if we use the command: netstat -n | find "3389" we will see the actual
IP address of the client.

With this knowledge, an attacker could change internal NAT'd IP
addresses (and perhaps adjust a few routes) to make it appear as if
the Terminal Services connection is coming from another IP address.
The impact is that one can use deception to conceal his IP address
when used in conjunction with other attacks. For example, suppose one
was to use a tool (coming soon) to brute-force passwords via Terminal
Services. The Terminal Services Manager would show active connections,
but may not show the correct IP address. Suppose also that one was
able to discover a valid password on that server. He could then
connect to the server using a spoofed IP address to conceal his true
location. One could use this vulnerability to hide their identity
while using up available client connections, locking out user
accounts, flood the Event Log with bad password attempts, or flood the
server with Terminal Services requests.

Another issue here is the fact that IP addresses logged by Terminal
Services and/or the Event Log are no longer credible and therefore
hardly useful as evidence in a court of law.

The bottom line: the IP address recorded by Terminal Services cannot
be trusted. One must rely on another logging mechanism to get the true
client IP address.

ALTERNATIVE LOGGING MECHANISMS

The most obvious method for logging Terminal Services connections is
to use your existing firewall or router. Another alternative is to
log connections right at the server by using a third-party tool. One
such tool we have found to be very effective is windump.exe available
at http://netgroup-serv.polito.it/windump/.

We recommend the following command:

C:>windump "tcp dst port 3389 and tcp[13] & 3 !=0"

This filter logs all Terminal Services packets that have the SYN or
FIN flags set. With this, you can log every time a client connects to
or disconnects from Terminal Services (without logging the flood of
packets in-between):

windump: listening
onDevicePacket_{940579A9-9084-4FBF-9022-7DA8A1199C49}

22:01:03.730687 ha.cker.org.3066 > ts.xato.net.3389: S
1887421511:1887421511(0)win 16384 <mss 1460,nop,nop,sackOK>

22:01:05.053519 ha.cker.org.3066 > ts.xato.net.3389: F
1887423387:1887423387(0)ack 2178985598 win 16730

22:01:06.112778 ha.cker.org.3067 > ts.xato.net.3389: S
1888029907:1888029907(0)win 16384 <mss 1460,nop,nop,sackOK>

22:01:06.755659 ha.cker.org.3067 > ts.xato.net.3389: F
1888031309:1888031309(0)ack 2179633419 win 16818

Other alternative logging methods are to use Snort (http://www.snort.org),
TCPView (http://www.winternals.com), or Microsoft's built-in Network Monitor.


CONCLUSION
==========

Microsoft was made aware of this issue in June of 2001. At that time
they decided that although it is an issue that needs fixing, it did
not warrant the immediate release of a hotfix. Microsoft was
investigating whether they should make this change in Windows 2000
Service Pack 3, but it appears that it did not make it in the beta.
They have not dismissed the issue, it is just not seen as a serious
threat requiring immediate attention. Part of their reasoning is that
if you are not logged in, it doesn't matter what your IP address is,
and if you are logged in, then you have already been authenticated
with your password.

Although we agree that this issue does not pose a direct threat to a
server's security and perhaps can wait to be fixed, we do feel that
administrators should certainly be aware that the IP address reported
by Terminal Services cannot be trusted. Because of the potential for
deception and the doubtful credibility of Terminal Services logging,
we recommend that a third-party logging mechanism be used to record
Terminal Services connections.


COMMENTARY
==========

In light of recent comments by Microsoft and others (see
http://www.microsoft.com/technet/column ... noarch.asp), we
thought it would be appropriate to end this paper by stating our own
opinion and policy on full disclosure, advisory exploitation, and
accountability.

We believe that the issue is not as simple as saying that full
disclosure is bad or that full disclosure is good. The attempt to take
sides is what sparks so much discussion whenever the topic is brought
up. We believe that although there are many benefits of full
disclosure, these benefits definitely come at a price.

The primary benefits of full disclosure are:

1. Administrators can Better Protect - Although many administrators
certainly do not care, a significant number do use public exploit
information, including actual exploit code, to better understand and
prevent attacks. Many use exploit details to build IDS signatures,
identify attacks in log files, and to prevent similar attacks in the
future.

2. Common Security Knowledge Increases - When details of an exploit
are made public, many (although not enough) software developers look
at their own code to see if they are making the same mistakes. By
studying the exploit as a community, we improve security across the
board for many current and future products.

3. Exploit Details Help Research - Many Microsoft hotfixes have been
updated and re-released more than once to address new variations of an
attack. Full exploit details allow other researchers to experiment
with variations of an attack and often turn up further
vulnerabilities. Furthermore, public exploit code can facilitate
regression testing when new patches are released. More than once a
hotfix has been released that reopened a previously patched hole. At
Xato, we often run old exploit code after installing new hotfixes or
service packs just to make sure these holes are still patched.

4. Public Exploits Level the Playing Field - The most common argument
for full disclosure is that by distributing exploit details and code,
admins are more knowleadgeable and therefore less likely to be a
victim of an obscure exploit.

5. Public Exploits Hold the Vendors Accountable - Many security
researchers have had the experience of reporting holes to software
developers only to watch them go to great lengths to avoid taking
responsibility for the vulnerability. Public disclosure always takes
care of that.

Nonetheless, these benefits of full disclosure come at a price:

1. Some irresponsible researches disclose vulnerabilities before a
patch is ready.

2. Some irresponsible researches disclose vulnerabilities on weekends,
increasing the exposure time before systems are patched.

3. Having detailed information requires little skill to exploit a
vulnerability having actual exploit code requires even less skill.
As a result, more people are able to exploit the holes.

4. Because of the media hype surrounding any Microsoft
vulnerabilities, it is easy for a security researcher to exploit this
hype for their own gain. Even a lame Microsoft hole brings a lot of
web hits.

Despite all these facts, the argument is often between those who
release exploit details and those who make software. However, most
security researchers are quite responsible when releasing exploit
details and Microsoft is usually good about acknowledging and fixing
holes. Yet despite all these best efforts, millions of systems were
affected by the rash of worms over the last few months. By now we
should realize that it really does not matter how much we disclose or
how much Microsoft patches if the system admins don't even bother with
security. It took something as extreme as a world-wide worm epidemic
to get people to install patches, often for the first time since
Windows was installed on their servers.

How is it that we have not yet held all these system admins
accountable? Why have they gotten away with being so irresponsible
with security for all this time? We are not just talking about
overworked admins in small IT shops, we are talking about some of the
largest companies, governments, and ISP's in the world. These are the
people protecting our personal and financial information. These are
the people who boast of their security because they have an SSL
certificate installed. These are the people who always ask for too
much personal information on web forms yet tell us they will keep it
private. And their lack of security affects us all.

Yet for some reason they have not been blamed. Instead the blame has
been bounced between security researchers and Microsoft. We worry that
all these public exploits are fostering script kiddies, but what are
we going to do about all the admin kiddies? Although we certainly do
not wish to condone worm propagation, we cannot deny the fact that the
most recent attacks made the internet world a bit more secure. If you
haven't already noticed, IIS servers are pretty secure nowadays.

Public exploit code, an outbreak of malicious worms based on that
code, script kiddies they all hold system admins accountable for
their network security something that so far they had failed to do on
their own.

It is therefore Xato's policy to continue to publish papers such as
this as the need arises. We feel that it addresses issues that the
public needs to be aware of. We believe that we are releasing this
information in a responsible manner. Although in this case Microsoft
has not provided a patch for this issue, we are providing workarounds
and other countermeasures to compensate. And yes, we do this because
it brings exposure for our business. But we don't seek that exposure
at the expense of Microsoft or others. We don't blame Microsoft for
having bugs in their software and we don't use advisories to add false
hype to an issue. Our goal is to increase Windows security in general
and our advisories help us achieve that goal.



ACKNOWLEDGEMENTS

Author: sozni (sozni@xato.net)

This document is located at:
http://www.xato.net/reference/xato-112001-01.txt


-------------------------------------------------------------------

THE INFORMATION PROVIDED IN THIS ADVISORY IS PROVIDED "AS IS" WITHOUT
WARRANTY OF ANY KIND. XATO, LLC. DISCLAIMS ALL WARRANTIES, EITHER
EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.

COPYRIGHT (c) 2000 XATO, LLC. ALL RIGHTS RESERVED.

XATO SPECIALIZES IN SECURING IIS. THE IIS SECURITY INSIDER NEWSLETTER
IS NOW AVAILABLE AT http://www.IIS-INSIDER.COM

-------------------------------------------------------------------

Additional Keywords:
Terminal Services, Security, SP3, IP Spoofing, TS

"Ignore the man behind the curtain"



questi due bug sono gli ultimi disponibili, ogni settimana ne spuntano fuori un paio...
DarkAngel
Utente Senior
 
Post: 453
Iscritto il: 09/08/01 01:00

Postdi DarkAngel » 16/11/01 00:30

ho appena finito di postare il msg precedente ed ecco l'ultimissimo bug in diretta:

Below you will find a quick recap of a few denial of service exploits I
discovered against Windows XP and selected versions of WinME. Microsoft
confirmed my findings: bulletin MS01-54. The paper is a narrative and
the author hopes it will be useful for newbies and an enjoyable paper
for the experts.

Do not hesitate to contact me at the following email address:
franklin_tech_unlimited@yahoo.com . It is also listed in the paper.

- 'ken'

----------------------------------------------

Just a side note: this paper really should be named 'I still haven't
found what I'm looking for': I expected a buffer overflow.

We are attacking a server named SSDPSRV bound to port 5000 running on XP
or selected versions of WinME. This is Microsoft's UPNP server that is
installed and runs by default on WindowsXP.

In two of the three hacks we are interested in a .dll named MSVCRT.dll.
This library has a page fault that can be used to crash the application.

The first DOS is simply due to bad code. We can send the application a
specific header and it will crash the server. There is a page fault at
0197:78004a16 in MSCVRT.dll.

The second DOS is due to the way the SSDPSRV handles input. We can chew
up memory by opening a connection, sending the proper header, and then
just strings and strings of 'A's (or whatever else you like). If one
connection is made and such strings are sent we will receive a page
fault in MSVCRT.dll again. This time it is at 0197:010083fe. But, if we
open approximately 200 connections and send the proper header followed
by a string of 'A's we can deplete the system resources. Using a Pentium
II 336Mhz machine I tested a Pentium IV 1.4Ghz with 128M of memory and
took the system resources from 65% to 48% in 20 minutes. The only
problem with this method is that it takes a substantial amount of time
to send these strings over the network.

The third and final DOS is the cool one. SSDPSRV cannot handle multiple
connections well. If one opens up 1018 simultaneous connections one can
temporarily freeze the machine. The user's keyboard and mouse input are
held in the buffer but do not appear to register. With this attack one
can sink the system resources under 4% in about a second. In a minute or
two the system corrects itself.
DarkAngel
Utente Senior
 
Post: 453
Iscritto il: 09/08/01 01:00

Postdi Triumph Of Steel » 16/11/01 01:22

Beh, io non uso webserver :)

Anche xchè quando arriverà FastWeb non potrò neanche aprire il server FTP :(
Avatar utente
Triumph Of Steel
Moderatore
 
Post: 7852
Iscritto il: 22/08/01 01:00

Postdi kyara » 16/11/01 05:18

Ti ringrazio Dark, per la fatica che mi hai risparmiato, infatti stavo appunto cercando una newsletter appena arrivatami, che mi informava dei bug di xp, da riportare qui sopra, ma mi hai preceduta.
Stavolta risparmio il taglia incolla.
kyara
Utente Senior
 
Post: 923
Iscritto il: 07/08/01 01:00
Località: web

Postdi alebiker » 19/11/01 18:43

ciao a tutti

qualcuno mi spiega in quale condizioni XP si collega ai server Microsoft e quando questo avviene? quali dati vengono scambiati? mi riferisco alla notizia della newsletter di oggi, in altrio thread non ho trovato niente (o forse non ho cercato abbastanza... maybe)
thanks
have a nice day...
alebiker
Utente Junior
 
Post: 78
Iscritto il: 22/08/01 01:00

PrecedenteProssimo

Torna a Software Windows


Topic correlati a "WinXP Discussion":

winxp updates
Autore: n6a7
Forum: Sistemi Operativi Windows
Risposte: 9

Chi c’è in linea

Visitano il forum: Nessuno e 121 ospiti