Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
TCPview
08-03-2012, 17:16 door Anoniem, 10 reacties
Hallo,
Ik installeerde TCPview op mijn pc.
http://technet.microsoft.com/nl-be/sysinternals/bb897437
Wat mij verwonderde dat als ik het programma openzette na het afsluiten van de browser (IE8 op deze nog) het vrij lang duurde voor er een aantal links gesloten werden.
Dat zou toch direct moeten gaan zowiets of vergis ik mij?
Geen idee wat daar ook de reden zou kunnen van zijn dat die nog een geruime tijd blijven staan in het lijstje.
Ik installeerde TCPview op mijn pc.
http://technet.microsoft.com/nl-be/sysinternals/bb897437
Wat mij verwonderde dat als ik het programma openzette na het afsluiten van de browser (IE8 op deze nog) het vrij lang duurde voor er een aantal links gesloten werden.
Dat zou toch direct moeten gaan zowiets of vergis ik mij?
Geen idee wat daar ook de reden zou kunnen van zijn dat die nog een geruime tijd blijven staan in het lijstje.
Reacties (10)
09-03-2012, 10:37 door
SirDice
Dat zou toch direct moeten gaan zowiets of vergis ik mij? Geen idee wat daar ook de reden zou kunnen van zijn dat die nog een geruime tijd blijven staan in het lijstje.
Het was mij al opgevallen dat de TIME_WAIT status lang blijft hangen. De 'verbinding' is dan echter al verbroken.
09-03-2012, 11:13 door
dim
Dit is volledig normaal. Als een TCP verbinding is afgesloten, blijft hij nog een bepaalde tijd in TIME_WAIT staan. Microsoft heeft het hier zelf over 4 minuten, http://support.microsoft.com/kb/137984:
"NOTE: It is normal to have a socket in the TIME_WAIT state for a long period of time. The time is specified in RFC793 as twice the Maximum Segment Lifetime (MSL). MSL is specified to be 2 minutes. So, a socket could be in a TIME_WAIT state for as long as 4 minutes. Some systems implement different values (less than 2 minutes) for the MSL."
"NOTE: It is normal to have a socket in the TIME_WAIT state for a long period of time. The time is specified in RFC793 as twice the Maximum Segment Lifetime (MSL). MSL is specified to be 2 minutes. So, a socket could be in a TIME_WAIT state for as long as 4 minutes. Some systems implement different values (less than 2 minutes) for the MSL."
09-03-2012, 11:22 door
SirDice
Door dim: Dit is volledig normaal. Als een TCP verbinding is afgesloten, blijft hij nog een bepaalde tijd in TIME_WAIT staan. Microsoft heeft het hier zelf over 4 minuten, http://support.microsoft.com/kb/137984:
Normaal voor Windows misschien maar op FreeBSD zie ik dat niet. Vind die 4 minuten vrij lang. En ik kan me niet herinneren dat ik dat zo lang gezien heb met bijv. XP. Dit was eigenlijk het eerste wat me opviel toen ik over ging naar W7.(moest het even opzoeken maar op FreeBSD is het 60 seconden)
09-03-2012, 11:29 door
SirDice
Uit RFC-793:
Klaarblijkelijk hebben ze die waarde gewoon klakkeloos overgenomen. Nu nog die registry entry vinden om 'm naar beneden te schroeven ;-)
For this specification the MSL is taken to be 2 minutes. This is an engineering choice, and may be changed if experience indicates it is desirable to do so.
Klaarblijkelijk hebben ze die waarde gewoon klakkeloos overgenomen. Nu nog die registry entry vinden om 'm naar beneden te schroeven ;-)
09-03-2012, 11:41 door
SirDice
Ha! http://support.microsoft.com/kb/314053
Aangepast. Even kijken of dat helpt :)
TcpTimedWaitDelay
Key: Tcpip\Parameters
Value Type: REG_DWORD - Time in seconds
Valid Range: 30-300 (decimal)
Default: 0x78 (120 decimal)
Description: This parameter determines the time that a connection stays in the TIME_WAIT state when it is closing. As long as a connection is in the TIME_WAIT state, the socket pair cannot be re-used. This is also known as the "2MSL" state. According to RFC793, the value should be two times the maximum segment lifetime on the network. See RFC793 for more information.
Note In Microsoft Windows 2000, the default value is 240 seconds. For Windows XP and Microsoft Windows Server 2003, the default was changed to 120 seconds for the IPv4 stack to increase performance. The default value for the IPv6 stack is 240 seconds.
Key: Tcpip\Parameters
Value Type: REG_DWORD - Time in seconds
Valid Range: 30-300 (decimal)
Default: 0x78 (120 decimal)
Description: This parameter determines the time that a connection stays in the TIME_WAIT state when it is closing. As long as a connection is in the TIME_WAIT state, the socket pair cannot be re-used. This is also known as the "2MSL" state. According to RFC793, the value should be two times the maximum segment lifetime on the network. See RFC793 for more information.
Note In Microsoft Windows 2000, the default value is 240 seconds. For Windows XP and Microsoft Windows Server 2003, the default was changed to 120 seconds for the IPv4 stack to increase performance. The default value for the IPv6 stack is 240 seconds.
Aangepast. Even kijken of dat helpt :)
RFC's zijn er om te worden overgenomen. En inderdaad is Windows rechter in de leer geweest dan BSD of Linux. Ook al werd er destijds vaak het omgekeerde beweerd.
Door Anoniem: RFC's zijn er om te worden overgenomen. En inderdaad is Windows rechter in de leer geweest dan BSD of Linux. Ook al werd er destijds vaak het omgekeerde beweerd.
Ook linux staat standaard behoorlijk ruim ingesteld. Maar zijn dit niet de instellingen aan de server kant die deze lange tijden veroorzaken?
10-03-2012, 09:04 door
[Account Verwijderd]
[Verwijderd]
12-03-2012, 08:58 door
SirDice
Door Bergen:
Waarom zou het betrekking moeten hebben met een risico?Door SirDice: Uit RFC-793: [...]
Klaarblijkelijk hebben ze die waarde gewoon klakkeloos overgenomen. Nu nog die registry entry vinden om 'm naar beneden te schroeven ;-)
Waarom zou je dat willen? Puur voor het 'opgeschoonde' gevoel? Zit het dus tussen de oren? De connecties zijn al gesloten, dus je verkleint het risico er niet mee.Klaarblijkelijk hebben ze die waarde gewoon klakkeloos overgenomen. Nu nog die registry entry vinden om 'm naar beneden te schroeven ;-)
the default was changed to 120 seconds for the IPv4 stack to increase performance.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
