this is called portsweeping!
i saw another one, in China (Jinan, Shandong maybe), this one looking into port 6000, which can be used for remote keystroke recording.
somebody just sets up a program to search the internet for computers with vulnerable ports. it's like if someone could go and scan apartments for ones with unlocked doors or open windows - then send in the thieves! amazing!
Tuesday, April 20, 2010
MS WBT SERVER
watching the net monitor again, with network applications turned off. saw one unassociated address - tracked down to Henan, China. to look this up, i stopped the monitor and opened the web browser. then i started the monitor up again, and right away realized i had failed to check the port number.
luckily (or unluckily) i caught another one. this one was either in Georgia (.ge) or Turkey - i think the service is based in Turkey, but the address was in Georgia.
so, this address exchanged several TCP packets with my computer, none of which seemed to contain anything (i say this only because they had 'payload lengths' of zero - this is not something i have researched yet). they were exchanged through port 3389, which actually carried a label: MS WBT SERVER. what is MS WBT SERVER you ask? this is the port used by the 'Remote Desktop' utility in windows. obviously, this was something in the Caucasus searching for a computer with a somehow vulnerable port 3389.
how to tell if it's vulnerable? maybe if i was using the utility? i don't know. maybe he's watching me type right now, though i think then i'd be able to see him still. it was a total of 8 TCP packets, followed a couple of minutes later by 2 UDP packets.
very interesting!
luckily (or unluckily) i caught another one. this one was either in Georgia (.ge) or Turkey - i think the service is based in Turkey, but the address was in Georgia.
so, this address exchanged several TCP packets with my computer, none of which seemed to contain anything (i say this only because they had 'payload lengths' of zero - this is not something i have researched yet). they were exchanged through port 3389, which actually carried a label: MS WBT SERVER. what is MS WBT SERVER you ask? this is the port used by the 'Remote Desktop' utility in windows. obviously, this was something in the Caucasus searching for a computer with a somehow vulnerable port 3389.
how to tell if it's vulnerable? maybe if i was using the utility? i don't know. maybe he's watching me type right now, though i think then i'd be able to see him still. it was a total of 8 TCP packets, followed a couple of minutes later by 2 UDP packets.
very interesting!
Monday, April 19, 2010
skype port? broadcasts?
ok, very briefly because it's late.
if i leave the network monitor on for a while, it lists lots and lots of conversations between ARKIV (my computer) and other addresses out there in the world. most of these are UDP packets, but not all. of the ones that are UDP packets, i'm pretty sure that they're all associated with Skype. here is how i know:
the monitor does show when conversations are known to be controlled by a particular process like Skype. so, tonight, i record for a while, and i see two other addresses associated with Skype. one is jingping, i know, because tracert tells me that it's an insight address routed through Atlanta, and i already know that's our service in louisville. the other is somebody in new bedford MA, still in the comcast network. i don't know what that is.
anyways, so i can see jingping's IP address. it also shows up in the 'unknown' associated list of all those UDP conversations, with a different port number, 34268. all the other UDP conversations (most - i didn't look at each one) are also going to port 34268, so i deduce that they must also be associated with Skype.
so, apparently Skype is going to be an internet learning tool for me. it's very mysterious. are these other Skype users, using ARKIV as a waypoint for finding other users? i think that's what a supernode does, but from what i've read supernodes should have many, many more connections. so, i still don't know what this is all about, and skype's operations are kind of trade secrets which are hard to research online. still, i'm sure there's plenty out there for me to figure out.
okay, so there, i learned that i can identify a process by its port number. or, at least, i deduced it. it may be wrong.
if i leave the network monitor on for a while, it lists lots and lots of conversations between ARKIV (my computer) and other addresses out there in the world. most of these are UDP packets, but not all. of the ones that are UDP packets, i'm pretty sure that they're all associated with Skype. here is how i know:
the monitor does show when conversations are known to be controlled by a particular process like Skype. so, tonight, i record for a while, and i see two other addresses associated with Skype. one is jingping, i know, because tracert tells me that it's an insight address routed through Atlanta, and i already know that's our service in louisville. the other is somebody in new bedford MA, still in the comcast network. i don't know what that is.
anyways, so i can see jingping's IP address. it also shows up in the 'unknown' associated list of all those UDP conversations, with a different port number, 34268. all the other UDP conversations (most - i didn't look at each one) are also going to port 34268, so i deduce that they must also be associated with Skype.
so, apparently Skype is going to be an internet learning tool for me. it's very mysterious. are these other Skype users, using ARKIV as a waypoint for finding other users? i think that's what a supernode does, but from what i've read supernodes should have many, many more connections. so, i still don't know what this is all about, and skype's operations are kind of trade secrets which are hard to research online. still, i'm sure there's plenty out there for me to figure out.
okay, so there, i learned that i can identify a process by its port number. or, at least, i deduced it. it may be wrong.
Thursday, April 08, 2010
well..
oh man. i haven't learned anything today, except that there's only so far you can take a visual simulation before it breaks. so, i've been measuring thresholds for a simulated observer at different spatial frequencies, for content within photographs which has been thresholded depending on a trial-to-trial staircase. it works pretty well for the images themselves. the original image gets compared with the image containing a thresholded band, and the observer is able to converge at a measure of the threshold over several hundred trials, similar to a human observer.
what i do is this: the original image gets filtered at the frequency in question, and the filtered image (the output of the filter) is thresholded and added back into the original image minus the filtered image. so, we actually have the original image minus the subthreshold content within the filter. if the threshold is zero, these two images are identical, i.e. they are whole, unfiltered photographs. this is the experiment as i originally ran it on myself, trying to find the just-detectable threshold (the threshold-threshold). to do the experiment simulation, the thresholded image then gets filtered again, meaning that the filter picks up the thresholded content along with residual off-frequency content. this is the only reasonable way to get the test content, since 1) that off-frequency content is there in the image and would be seen by the filter, and thus can't be ignored, and 2) the filtered band contains harmonics which wouldn't be seen by the filter.
naturally, i eventually decided to do the same experiment without the complete image; i.e., just measure threshold-thresholds for the content within the filter. i thought this would be straightforward - i just use the filtered image as the 'original', and the thresholded filtered image as the 'test'. but then, i thought, ah, almost screwed up there: the thresholded filtered image should be filtered again, just like in the original experiment. so, you can see the problem. the original content is lifted straight out of the source image, while the thresholded content gets lifted out of the source image and again out of the thresholded image, which means it will be multiplied twice by the filter. so, even if the threshold is zero, the test and original images will be different.
this is a problem. in fact, it must also be a problem in the original experiment. but, the test and original images in the original experiment are the same when the threshold is zero - i assume this is because the off-frequency content amounts to the difference between the filtered and double-filtered content, and adding the filtered content back into the image basically restores the lost content.
i need to think about this.
what i do is this: the original image gets filtered at the frequency in question, and the filtered image (the output of the filter) is thresholded and added back into the original image minus the filtered image. so, we actually have the original image minus the subthreshold content within the filter. if the threshold is zero, these two images are identical, i.e. they are whole, unfiltered photographs. this is the experiment as i originally ran it on myself, trying to find the just-detectable threshold (the threshold-threshold). to do the experiment simulation, the thresholded image then gets filtered again, meaning that the filter picks up the thresholded content along with residual off-frequency content. this is the only reasonable way to get the test content, since 1) that off-frequency content is there in the image and would be seen by the filter, and thus can't be ignored, and 2) the filtered band contains harmonics which wouldn't be seen by the filter.
naturally, i eventually decided to do the same experiment without the complete image; i.e., just measure threshold-thresholds for the content within the filter. i thought this would be straightforward - i just use the filtered image as the 'original', and the thresholded filtered image as the 'test'. but then, i thought, ah, almost screwed up there: the thresholded filtered image should be filtered again, just like in the original experiment. so, you can see the problem. the original content is lifted straight out of the source image, while the thresholded content gets lifted out of the source image and again out of the thresholded image, which means it will be multiplied twice by the filter. so, even if the threshold is zero, the test and original images will be different.
this is a problem. in fact, it must also be a problem in the original experiment. but, the test and original images in the original experiment are the same when the threshold is zero - i assume this is because the off-frequency content amounts to the difference between the filtered and double-filtered content, and adding the filtered content back into the image basically restores the lost content.
i need to think about this.
Subscribe to:
Posts (Atom)