freddy333

Ending the work week having a little fun with my beater

Yes. What do you make of that?

Ok, now we are getting somewhere. I am embarrassed to say this, but we are running a very old version of BSD (4.11), which has not been updated for many years. Yes, I know. There are many reasons for this, which I cannot go into on a public site. But I can provide a few more details via PM if needed (the reasons are not really relevant to the problem). It is difficult to run anything based on the PID because it changes so often/quickly. Running /proc/PID/cwd returns 'command not found'. This may be due to our stale system. Running /proc/PID/cmdline returns either 'command not found' or a permissions error (I think this is due to the PID having changed). We blocked Yandex's IP a few years ago via htaccess & we upped this to blocking the entire range (ie., blocking '100.43') last week when this all began. Unfortunately, this does not appear to have had any ANY effect. On the positive side, I forgot about the access_log (I told you I was rusty). So I did a tail for their IP &, sure enough, I both caught them in the act & instantly figured out what script they were running & what they were doing (I have blocked our domain for security). The nph-proxy333.cgi is a perl script our admins used to use when conducting security evaluations of hacking attempts from foreign sites. Each GET request is coming in about 1/second, so you can see how they have been killing our bandwidth. I just disabled the script, but tail shows that they continue to run the script somehow without any slowdown. I do not know how they can do that since I have disabled the script??

Works for me, but you should always include at least 1 full frontal pic of the watch posed in normal orientation (ie, 12 at top of pic).

Welcome & be aware that having multiple accounts may get you banned here as well. So please read & adhere to our Rules (making note of item 9).

Yes, I have root access, but my bsd skills are very rusty.

Snatching up a franken that crossed Ziggy's bench is quite a coup these days. Congratulations on that well honed beauty.

A few more pieces of the puzzle - 1. The single constant IP that is always involved when our bandwidth has ground to a halt is 100.43.91.24, which is the Russian search engine, Yandex. Now, I know Yandex, like google, spiders websites intermittently throughout the day, adding them to their search index, which is fine. But this is something more insidious since they are actively running 1 of our perl scripts almost non-stop 24/7, the effect of which is almost like a DNS attack because the connection is so bogged-down that honest visitors are unable to connect to the server or view content. 1 question is whether Yandex is whether running perl is just a way to waste bandwidth for the purpose of blocking access to our server or are they using perl to run some other application that may have more nefarious purposes (eg, using us as a spam server or as a proxy to attack other sites or as something else?)? The whole point of this exercise is to figure out how to find out what Yandex is running on our server, how they are accessing it and then to find a way to either block them from doing so or block them entirely from accessing anything! As you can see in these screenshots I took when the problem is occurring, Yandex is always connected along with 1 of these other IPs (the 2 blurred IPs are our internal accounts used to monitor the console). Also, Yandex is always simply connected via an HTTP port, while their 'partner' IP is the 1 that is running perl - The other IP always changes. But here is the key - the other IP is always a major US government or commercial site like the state of Florida or Akamai or FBI that has little reason to be accessing this server. And they only appear while Yandex is connected. Once Yandex is booted, they are too. 2. I have found that if I kill the perl process, both Yandex & the other IP are instantly disconnected. No other actual visitor IPs are ever effected. Only these 2. This tells me that Yandex is either spoofing the other IP (I have no idea how they this?) &/or they have hacked into another legitimate server & are using it (without the owner knowing about it) as a drone or bot to attack other servers like ours. Trouble is that, within 20 seconds of being booted, Yandex is back again, but with a different secondary IP. Anyone see anything like this before or, more importantly, have an idea how to block Yandex? (We have had Yandex blocked via our htaccess for years, but, clearly, that has no effect.

Anyone?

Based on the tool marks around the interlocking pieces, it is pretty obvious the end links did not come on these bracelets from the Rolex factory. But he did a good job in not damaging too much.

It has been more than a decade since I last saw a $200 9315 in that condition. & if I needed another gen 9315, I would happily pay $1,180 for a mint 1. Next year, that price may seem like a bargain.

It is difficult, at best, to accurately compare newly manufactured aftermarket parts with 50+ year-old gen Rolex parts, if, for no other reason, than the gen parts are likely to have been worn, polished & had who-knows-what-else done to them during their lengthy lifespans. However, if you compare MQ's beveling to vintage advertisements & the best quality '38s out there, I think you will find that it is very accurate. Phong's, while good, fail to deliver in my opinion. Also, after successive polishings, the overall lug length gets shortened, so, if MQ's overall length is short (that is a big IF), I think it would be more accurate for a 50+ year-old gen watch. Just a quick 2 cents.

Well done.

Another option

Is there a command I can run on a *NIX web server (ps or netstat, etc) that will allow me to see what foreign ip address is accessing the server and repeatedly running a perl script? I have root access. For the past week or so, I have been seeing alot of unusual activity on our web server. Our page counters are not reflecting ANY new page views during these times. So whoever these 'visitors' are, they are not typical. However, top reports a constant cycle of 3-4 commands being run (I am not sure of the order?): accept, select, kqread, run, pipdwt, sbwait. These 4 processes repeat over & over again, with about a 10 second pause in between each cycle. When I run netstat, it outputs screens that often contain IPs and domains for university & state government websites, which are VERY rare to see on this server, especially, with 3-5 of them appearing at the same time. Between the increased activity and the types of sites, my gut tells me these remote servers have been hacked and are now being used as bots to either generate spam through some perl script on our web server or they are being used to constantly access the server to slow our connection & block other legitimate visitors. Again, my question is how to see what IPs are accessing which files on the server or running which perl scripts? Here are some screenshots of top running on the webserver so you can see what I am seeing. Again, these several processes keep cycling over & over & over again (without any page views), which is something I have not seen in the 18 years this server has been running - And here are 2 netstat screenshots that show some of the questionable items. Unfortunately, this screenshot does not include any of the .gov's, 'police.website.org' (or similar) items I keep finding & I often find several of these types of items appearing concurrently, which never happens on this server -

First wristie of 2015

Cats, having recently lost 2 family members to cancer, I have tended to remain silent during your struggle as there is little to say that you have not already heard. Still, I cannot tell you how sorry I am to hear the disheartening news. But try to hang in there as many new cancer treatments are in the pipeline which, while they may not provide a cure or long-term remission, may give you (usable) time & be a bridge to the next 'new treatment'.

Limiting to rep dials, this is probably my best, a V72-powered MQ painted to my specs with a gen coronet

Amazingly, still wearing 1 of my Newmans

Good thing it was not your wrist. You might have lost a watch!

'tis the day before Christmas & I am still wearing 1 of my Newmans

Exactly.

Well done. Someone is going to have a very merry Christmas.

Looks genuine to me.