wmbetts (1306001) writes "We want to provide you with an update on this morning’s reports of stolen passwords. We can confirm that some of the passwords that were compromised correspond to LinkedIn accounts. We are continuing to investigate this situation and here is what we are pursuing as far as next steps for the compromised accounts" Link to Original Source top
FTC Hacked, Defaced and data leaked by #Anonymous in the name of #antisec
wmbetts (1306001) writes "Today, well just now the hacktivist group anonymous has released a statement and mirror and data from yet another government website, this time being a ftc.gov subdomain business.ftc.gov which when checked appears to be offline for now." Link to Original Source top
wmbetts (1306001) writes "Important notification concerning your Trion Worlds account
We recently discovered that unauthorized intruders gained access to a Trion Worlds account database.
The database in question contained information including user names, encrypted passwords, dates of birth, email addresses, billing addresses, and the first and last four digits and expiration dates of customer credit cards." Link to Original Source top
wmbetts (1306001) writes "Hi all,
We are using libcurl on the server-side for the TF2 replay system, and could use some help diagnosing some problems.
Without getting into too much detail, the gist of the system is that replay-enabled servers use libcurl (7.21.2) to offload small chunks of data over FTP, every 15 seconds or so. Clients can then get at the data over HTTP.
One of the biggest issues server operators are running into is that things will be going along smoothly with no issues — uploading these chunks of data successfully — and then suddenly libcurl will error out with a "Couldn't resolve host name" message. Anyone have any clue what could be causing this?
I've pasted a simplified version of the uploading code below in case that's useful.
Thanks a bunch.
-Jon" Link to Original Source top
wmbetts (1306001) writes "On 27 April, ARIN placed Delegation Signer (DS) records into in-addr.arpa and ip6.arpa. Now DNSSEC validation will occur from the root down if you properly set up your DNSSEC-aware recursive resolver.
For most DNSSEC-aware recursive resolver operators, nothing needs to be done for this change to be in effect as long as you have configured your DNSSEC-aware server to use ICANNâs trust anchor for the root zone. For those who have used ARINâs trust anchors (in place since 2 July 2009) to take advantage of DNSSEC before the root or in-addr.arpa was signed, you MUST remove them within the next two months of this date. Otherwise, DNSSEC validation may fail due to a KSK change to ARINâs zones. Additionally, ARIN will also coordinate with Internet Systems Consortium, Inc. (ISC) to remove ARIN's delegations from their DNSSEC Lookaside Validation (DLV) registry after setting up these records in in-addr.arpa and ip6.arpa.
The DS records will remain the same as the current trust anchor for the next two months. After that time, ARIN will begin rolling a KSK for its authoritative zones, which will cause any DNSSEC-enabled resolvers that use ARINâs statically, configured trust anchors to fail.
wmbetts (1306001) writes "APNIC announced that as of Friday, 15 April 2011, its IPv4 address pool reached the Final/8 IPv4 address block, bringing the Asia Pacific region to the last Stage of IPv4 exhaustion. This is a very important milestone on the IPv4 exhaustion process at a global level." Link to Original Source