Search Results

Search found 3 results on 1 pages for 'shackrock'.

Page 1/1 | 1 

• DNS Server Spoofed Request Amplification DDoS - Prevention

  - by Shackrock

  I've been conducting security scans, and a new one popped up for me: DNS Server Spoofed Request Amplification DDoS The remote DNS server answers to any request. It is possible to query the name servers (NS) of the root zone ('.') and get an answer which is bigger than the original request. By spoofing the source IP address, a remote attacker can leverage this 'amplification' to launch a denial of service attack against a third-party host using the remote DNS server. General Solution: Restrict access to your DNS server from public network or reconfigure it to reject such queries. I'm hosting my own DNS for my website. I'm not sure what the solution is here... I'm really looking for some concrete detailed steps to patch this, but haven't found any yet. Any ideas? CentOS5 with WHM and CPanel. Also see: http://securitytnt.com/dns-amplification-attack/

  Read the article

• Using TrueCrypt (software encryption) with an SSD

  - by Shackrock

  I use full drive encryption (FDE) w/ TrueCrypt on my laptop. I have a 2nd gen I7 with AES instruction support, so honestly I can't even notice a speed change on the system with it on. My question, is for those who know about SSD's a lot. I previously (early 2011) read articles about how software encryption will negate the speed benefits that an SSD provides - because of the need for the SSD to send a delete command, then a write command, for every encrypted write - instead of just writing over data like a regular HDD would (or something like this...honestly I can't remember...ha!). Anyway, any improvements in this field? Is it pointless for me to grab an SSD if I'm using FDE? Thanks all.

  Read the article

• Verify my form workflow

  - by Shackrock

  I have a form, with some sensitive info (CC numbers). My work flow is: One page to take all form items Upon submission, values are validated. If all is well, all data is stored in a session variable, and the page reloads and displays this info from the session variable. If everything is ok on the review page, the user clicks submit and the session variable is sent to another form for processing (sending payment). Upon success, the session is destroyed. Upon failure (bad CC number, for example) - the user is sent back to the form, with all of the fields filled in just like before, so that they can check for errors and try again (session is NOT destroyed). Does anyone see anything wrong with this, from a security or best practices stand point? UPDATE I'm thinking I can get rid of a step - storing the info in a session EVER. Just have a one page checkout, no review page... makes sense.

  Read the article

1