+1 on this comment. Don't forget the hosting providers who seem to "look the other way" while their co-located/vps/whatever scans the internet for weeks on end.
Most service providers I've had over the years will give you a second IP address on your connection. Put a switch behind your Cable/DSL Modem and give him his own IP. If they come looking for the offender, you might be able to say that IP was for his system.
I've run Cisco SOHO devices such as RV042, RV082, RV016, RVS400, RVL200, and WRV210. In my experience setting up VPNs and firewalls on these devices, they often have interoperability issues between themselves.
Also, I've worked with a SRW208 whose web management interface requires you to use IE to manage the device.
Based upon these experiences, I'd suggest that Cisco needs to work on interoperability between their own devices before they can provide guidance to others on how to make interoperable devices for home users.
1) Collect as much info as you can about the source of the attack.
2) Send an email to the abuse address on record.
3) Harden system some more.
4) Wait for some sort of response.
5) Publish the source IP, whatever response is received in the email response, and AS info (i.e. netblock) along with the details of the attack.
6) Block all future traffic from the AS.
Depending on the encryption approach, the ISP may only see the IP headers, which won't tell them squat about the payload. The destination IP might give them a hint, though.
There are a number of countermeasures you can take to make traffic analysis difficult. Data flows can be manipulated easily to make pattern analysis very difficult.
Slashdot Mirror
+1
+1 If you are too lazy to patch the system that you are responsible for...then you deserve to be treated as a threat. (this is based upon my own exp)
+1 on this comment. Don't forget the hosting providers who seem to "look the other way" while their co-located/vps/whatever scans the internet for weeks on end.
OMG...you so just beat me to the punch on this one. +1
android phone + wireless ap detection software of choice + conference management + exit door = problem solved. (find them and kick them out)
Done.
ClearOS is a great choice for what you're describing in terms of your needs of the OS and your abilities with linux.
Most service providers I've had over the years will give you a second IP address on your connection. Put a switch behind your Cable/DSL Modem and give him his own IP. If they come looking for the offender, you might be able to say that IP was for his system.
+11 on this.
I've run Cisco SOHO devices such as RV042, RV082, RV016, RVS400, RVL200, and WRV210. In my experience setting up VPNs and firewalls on these devices, they often have interoperability issues between themselves. Also, I've worked with a SRW208 whose web management interface requires you to use IE to manage the device. Based upon these experiences, I'd suggest that Cisco needs to work on interoperability between their own devices before they can provide guidance to others on how to make interoperable devices for home users.
I'm not too scared of the zombies, but vampires: [30 days of night] http://www.imdb.com/title/tt0389722/ that's something to be worried about.
I agree.
1) Collect as much info as you can about the source of the attack.
2) Send an email to the abuse address on record.
3) Harden system some more.
4) Wait for some sort of response.
5) Publish the source IP, whatever response is received in the email response, and AS info (i.e. netblock) along with the details of the attack.
6) Block all future traffic from the AS.
I second this assertion. Iptables could easily deal with this attack.
I'd vote for http://www.clarkconnect.com/. They've got a nice set of features.
Let's see ...
An old Soviet satellite takes out an iridium satellite which _may_ have been useful to the DoD over Russian air/space? hmm ...
How about we choose a term _no_ company will want to patent, say small F**KING laptop? Written from my D*LL Mini 9. Merry Christmas. B
traceroute to 62.176.17.200 (62.176.17.200), 30 hops max, 60 byte packets 1 _ 0.469 ms 0.323 ms 0.211 ms 2 _ 0.673 ms 0.801 ms 0.744 ms 3 10.134.0.1 (10.134.0.1) 20.591 ms 25.241 ms 29.104 ms 4 vistaggc01-gex0916.sd.sd.cox.net (68.6.11.70) 36.988 ms 36.993 ms 37.822 ms 5 fed1sysc01-gex0903.sd.sd.cox.net (68.6.8.108) 39.141 ms 43.944 ms 43.929 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *
I'd suggest using traceroute if they know the IP address.
Those are some BLAZING upstream speeds....cable with 1/2 Gbps upstream ... WOW!
Depending on the encryption approach, the ISP may only see the IP headers, which won't tell them squat about the payload. The destination IP might give them a hint, though.
There are a number of countermeasures you can take to make traffic analysis difficult. Data flows can be manipulated easily to make pattern analysis very difficult.
It could also be this: http://www.google.com/technology/pigeonrank.html
Only one thing to say about the Netherlands...I LIKE GOOOLLLLDDDD!
Or worse, with a video camera your ability to remain anonymous ceases to exist. Could be a nice way for people to be tracked without their knowledge.