As others have said, the CISSP is perhaps the most well-known and recognized IT Security certification out there.  If you need to start more entry-level, CompTIA's Security+ is a good start, and actually can be used to take a year off of the work experience requirements of the CISSP.

After the basics are out of the way, the question you really need to ask is which certifying authorities are recognized and well-respected.  Then, choose a certification from among those offered by those authorities which properly reflects your experience level and skill set.

The key to remember here, is that a certification should be exemplary of skills that you already posess - not just an exam that you can cram your way through.  Before obtaining a certification, you should have at least some work experience to further demonstrate to potential employers that you actually have experience and knowledge in the subject represented by that certification.

The list referred to by @Rook covers a lot of territory.  There's a number of certifications and organizations on there I've never heard of, but it also lists most of the big industry players as well.

CompTIA offers a number of certifications covering several domains.  However, most of these are very entry-level.  The only Security-speicifc certification they have is Security+.  Other certifications primarily focus on system or network administration and troubleshooting.
(ISC)^2 is all about Information Security.  They have several certifications available, including the well-known CISSP.  A full CISSP certification requires passing a written test, five years of relevant and verifiable work experience, and endorsement by a current CISSP in good standing.  If you fall short of the work experience requirement, you may hold the title of "Associate of (ISC)^2" until such time as you meet that requirement.
EC-Council is most well-known for the CEH.  Most of their other certifications also center around security and penetration testing, but there are some on other topics such as Forensics and Programming.
GIAC was founded by SANS, which is a well-respected institute for security training.  As such, they have numerous certifications covering many different aspects of Information Security.  After obtaining a GIAC certification, you can also go the extra mile by elevating it to Gold status.  This requires you to work with a GIAC adviser who will guide you through the process of writing a research paper (expected to take 6 months) which must be reviewed and endorsed by your adviser and two others in order to be accepted.
Cisco is the go-to vendor for networking certifications.  The most notable of these is the CCNA.  They also offer some certifications which include a security focus.  Their highest-level certification is the legendary CCIE, which requires passing both a two-hour written exam and an eight-hour hands-on lab which is only offered at ten Cisco facilities worldwide.
Microsoft is, of course, where you want to go to get certified on Windows systems.  Perhaps the most well-known, current certification is the MCITP - Server Administrator (formerly known as MCSA).  Some of their certifications are also focused on security.

Full disclosure:  I currently hold certifications from CompTIA, EC-Council, and Cisco, and am pursuing certifications from Microsoft and (ISC)^2.


Is it necessary to understand Linux kernel internals to do binary exploitation?

Binary exploitation does not require you understand the Linux kernel in depth, unless you are exploiting the kernel itself. You only need to know the basics such as how signal handlers are registered, how syscalls work, and how Linux manages process-specific attributes that can be relevant to exploitation. A solid understanding of Linux is very useful, but this does not mean that you need to understand Linux kernel internals, however. You don't need to grok the kernel's internal API to exploit userspace binaries.
Understanding Linux in general is quite useful though, assuming your exploitation is being done under Linux. For example, understanding SROP (SigReturn-Oriented Programming) exploitation, a ROP-like attack that bypasses NX protections, requires knowing how the sigreturn() syscall works. Likewise an exploit might attack the vDSO, a shared library that the kernel provides to all processes.


Cross site scripting prevention removing &lt and &gt

This is not sufficient protection

There are many ways an attacker might be able to sneak in a byte sequence that will be interpreted by someone's browser as markup.

In your case, it might even be possible just to use ampersand encoding to pass < and > chars.

Failing that, double encoding could be used to bypass your filters, or even overlong utf-8 sequences (however this last one is a bit outdated and most software stacks don't fall for it).

Those are just a few examples, but there are many more ways of bypassing simple markup filters like yours. This bit in particular is relevant.


DNS Zone transfer is the process where a DNS server passes a copy of part of it's database (which is called a "zone") to another DNS server. It's how you can have more than one DNS server able to answer queries about a particular zone; there is a Primary DNS server, and one or more Secondary DNS servers, and the secondaries ask the primary for a copy of the records for that zone.
A basic DNS Zone Transfer Attack isn't very fancy: you just pretend you are a secondary and ask the primary for a copy of the zone records. And it sends you them; DNS is one of those really old-school Internet protocols that was designed when everyone on the Internet literally knew everyone else's name and address, and so servers trusted each other implicitly.
It's worth stopping zone transfer attacks, as a copy of your DNS zone may reveal a lot of topological information about your internal network. In particular, if someone plans to subvert your DNS, by poisoning or spoofing it, for example, they'll find having a copy of the real data very useful.
So best practice is to restrict Zone transfers. At the bare minimum, you tell the primary what the IP addresses of the secondaries are and not to transfer to anyone else. In more sophisticated set-ups, you sign the transfers. So the more sophisticated zone transfer attacks try and get round these controls.
SANS have a white paper that discusses this further.


What is the minimum secure length for gpg -c file.txt?

Misconceptions

Is 16 characters enough? for example would a password similar to "I own 32 houses." be bruteforcable?

"I own 32 houses." should not be considered a 16 character password.  A modern cracker would use a dictionary attack to break that one.  A 16 character password would be pretty strong 26^16 = 4.3608743e+22 possible combinations, but you would need to have random characters. Assuming a dictionary of 20k words (the common english speaker's vocab) and 33 special characters. The password you supplied is really 20,000 x 20,000 x 99 x 20,000 = 7.92e+14 possible combinations.
Answer
I'd recommend 16 characters for this scenario, but you need to use a high entropy password generator.
You can use this website to check lengths of passwords and how long they would take to crack for offline attacks, but remember you need a randomly generated password for this tool to work.


What advantages does it have if a password manager locks the DB automatically on locking the computer? Disadvantages of turning it off?

One of the key principles in defending systems is reducing the attack surface. Especially when it comes to critical systems like password managers, you want to apply very high security standards and expose them only when necessary. So it makes sense to lock the password manager whenever you do not need it.

Password managers can lock themselves after a certain (usually configurable) amount of time or at certain events. It makes sense to lock your password manager automatically when you lock your screen, as the password manager can be sure, that you do not need it at that moment. Why leave it exposed, if the rightful owner is currently away?

So what are the actual risks? Let's take a look at the two most probable scenarios:

Someone is able to unlock your computer for any reason (weak password or written down password, etc.). Unlocking your computer is all that's needed to access you password manager, if it doesn't lock itself down. Breaking your login equals breaking your password manager. No second line of defense means less security.
Someone compromises your system over the network. Just because no one is sitting in front of your PC doesn't mean no one can interact with it. If your system gets compromised over the network to a point where an attacker can access your desktop session, you are probably in deeper troubles anyway, but there is still no reason to hand the attacker all your credentials on a silver platter. The shorter the duration your password manager is unlocked, the less likely it is for an attacker to get access. There is a small downside to consider though. If the attacker uses a keylogger, he can get your password for the password manager when you log in again, so logging in less often may sound appealing, but in real life it won't really make a difference, once an attacker took over your PC. Sooner or later you will log into the password manager and the keylogger will be waiting for you.

As you can see, remote compromise is less of a concern, since you have lost everything in this scenario anyway. The main issue is someone logging into your machine and having direct access to your password manager. You basically lose the second line of defense the password manager is trying to provide.

Before I forget, you mentioned cold boot attacks. I assume, you don't have to worry about them. Performing a cold boot attack is really difficult and not many actors will go so far to perform them. If you are really such an exposed and high value target, that you have to worry about cold boot attacks, you shouldn't even consider leaving your password manager open even a second longer than necessary!

If disabling automatic locking is a risk worth taking to avoid entering the credentials for your password manager more often, is up to you to decide. I can only recommend to take the safer route, the decision is now yours.


In a cross-site request forgery attack, the attacker tries to force/trick you into making a request which you did not intend. This could be sending you a link that makes you involuntarily change your password. A malicious link could look like that:

https://security.stackexchange.com/account?new_password=abc123

In a cross-site scripting attack, the attacker makes you involuntarily execute client-side code, most likely Javascript. A typical reflected XSS attacking attempt could look like this:

https://security.stackexchange.com/search?q="><script>alert(document.cookie)</script>

Both attacks have in common that they are client-side attacks and need some form of user activity (e.g. clicking a link or visiting a website). Unlike RFI or SQLi vulnerabilities, you're attacking a user rather than the server. XSS is generally more powerful than CSRF because it usually allows the execution of arbitrary script code while CSRF is restricted to a particular action (e.g. changing the password). As @Lukas points out, a successful XSS attack also effectively bypasses all anti-CSRF measures.


What is the real use of certificates on the web?

is it trust-worthy because the CA authority did a background check on them?

No.
A SSL certificate is comparable to a passport: it says who the person is and which country the passport issued. But it does not say how trustworthy the person is.

The main use of the certificate is to make end-to-end encryption possible, that is protecting against man-in-the-middle attacks by checking, that that host name in your URL matches the name given in the certificate and that the certificate is issued by a trusted CA. No more, no less.

In most cases the only check the issuer CA will do is to see if you have access to a specific email address of the domain, i.e. hostmaster@example.com or similar. For EV certificates more checks will be done but nobody will do background checks of your criminal history or so.

Therefore the only trust you get from the certificate is, that the owner of the certificate probably owns this domain. And even that is not true in all cases because the CA might be hacked or the site had an insecure configuration so that the attacker was able to get a certificate etc.

In no case you can derive from the certificate if the site itself is trustworthy, if it is able to protect your private data, if it got hacked etc. And a certificate does not protect you against spoofed sites or bad guys claiming to be good guys.


Website Certificate with different public key

This would have been better here.

However we can still answer your question.
I inspected the site you referred to and the reason, why chrome shows you a security warning is because the intermediate certificate of StartSSL uses SHA-1 for signature-hashing.

Your certificate is in fact SHA-256/RSA-4096 as claimed, but because one certificate in the chain (the intermediate certificate) is "weak", the whole chain is considered "weak" and hence you get a warning.


Building a backdoor for full disk encryption

Keeping the keys with your parents as plan to do seems safe enough. It is indeed unlikely that someone would break into their house, then yours, just to get your data. The most likely disaster scenario is that a burglar breaks into their house, finds your house keys, and visits your house next just because they now have the house keys - AND find the printed papers and the disk, AND decide to use it when they get back in their lair. But the burglar is not likely to type in a long printed key.... although they might try it, to see if it revealed credit card numbers.

You could perhaps mitigate this risk. Your parents probably have an alarm system, so maybe that could be used to warn you also when a break-in happens.

There are a few other solutions, but since the assumption is that you are no longer be able to find the data yourself, they all rely on trusted third parties.

A notary. You would put the keys in a box, either on paper or on a memory stick. The notary would keep the box. The box itself could be locked, or in the notary's safe, or both... whatever the notary and you agree on.
An n-out-of-m key scheme. Several of your friends/relatives get a partial key. You would use n-out-of-m because something could happen to one of them, and you'd still want them to be able to reconstruct the key if not all of them were able to participate.


Why is Math.random() not designed to be cryptographically secure?

I was one of the implementers of JScript and on the ECMA committee in the mid to late 1990s, so I can provide some historical perspective here.

  The JavaScript Math.random() function is designed to return a floating point value between 0 and 1. It is widely known (or at least should be) that the output is not cryptographically secure

First off: the design of many RNG APIs is horrible. The fact that the .NET Random class can trivially be misused in multiple ways to produce long sequences of the same number is awful. An API where the natural way to use it is also the wrong way is a "pit of failure" API; we want our APIs to be pits of success, where the natural way and the right way are the same.

I think it is fair to say that if we knew then what we know now, the JS random API would be different. Even simple things like changing the name to "pseudorandom" would help, because as you note, in some cases the implementation details matter. At an architectural level, there are good reasons why you want random() to be a factory that returns an object representing a random or pseudo-random sequence, rather than simply returning numbers. And so on.  Lessons learned.

Second, let's remember what the fundamental design purpose of JS was in the 1990s.  Make the monkey dance when you move the mouse.  We thought of inline expression scripts as normal, we thought of two-to-ten line script blocks as common, and the notion that someone might write a hundred lines of script on a page was really very unusual. I remember the first time I saw a ten thousand line JS program and my first question to the people who were asking me for help because it was so slow compared to their C++ version was some version of "are you insane?! 10KLOC JS?!"

The notion that anyone would need crypto randomness in JS was similarly insane. You need your monkey movements to be crypto strength unpredictable? Unlikely.

Also, remember that it was the mid 1990s. If you were not there for it, I can tell you it was a very different world than today as far as crypto was concerned... See export of cryptography.

I would not have even considered putting crypto strength randomness into anything that shipped with the browser without getting a huge amount of legal advice from the MSLegal team. I didn't want to touch crypto with a ten foot pole in a world where shipping code was considered exporting munitions to enemies of the state.  This sounds crazy from today's perspective, but that was the world that was.

  why do browsers not replace it with a CSPRNG?

Browser authors do not have to provide a reason to NOT do a change.  Changes cost money, and they take away effort from better changes; every change has a huge opportunity cost.

Rather, you have to provide an argument not just why making the change is a good idea, but why it is the best possible use of their time.  This is a small-bang-for-the-buck change.

  I understand that it could not be re-defined as a CSPRNG as the standard explicitly gives no guarantee for suitability for cryptographic use, but there seems to be no downside to doing it anyway

The downside is that developers are still in a situation where they cannot reliably know whether their randomness is crypto strength or not, and can even more easily fall into the trap of relying on a property that is not guaranteed by the standard.  The proposed change doesn't actually fix the problem, which is a design problem.


Can an HTTPS server accidentally leak its private key?

Are there any known cases of HTTPS websites leaking the private key of their SSL certificate?

Yes - the Heartbleed bug involved memory leaks out of the HTTP server such that:

  We attacked ourselves from outside, without leaving a trace. Without
  using any privileged information or credentials we were able steal
  from ourselves the secret keys used for our X.509 certificates, ...

Aside from bugs like that,

  Is it even technically possible for a bad website admin to
  misconfigure a site to send the private key as part of the certificate
  chain?

Sure.  If you specify the wrong file in, for example, SSLCertificateChainFile then Boom!  There goes the private key.

As @duskwuff points out in the comments, there are protections against this.  Neither Apache nor NGINX will send a key PEM that's included in a certificate file; they will silently strip it out (which, I'm willing to bet, is a protection put in place after some number of events where people did what I suggested might work).

Other misconfigurations, such as incorrect web root combined with loose permissions or excessive web server privileges, will also leak the key, but those misconfigurations are both mundane and extreme (e.g., you really have to be trying to break things that badly).

Doing so is not recommended.


ESNI (Encrypted Server Network Identification) with HTTP CONNECT (HTTP Proxy)

The goal of ESNI is deny observability of the target domain when only passive sniffing of the traffic is done. This targets primarily deep packet inspection at the level of ISP which might like to create profiles of users or restrict/shape some traffic to some targets for their own gain or because laws require it.

This does not prevent the visibility of the target domain in the CONNECT request. But a CONNECT request is only issued by the browser if a proxy is explicitly configured in the browser. This need to be done by a person controlling the computer and is often pushed via company wide policies. Explicit proxies are usually used only within the company (or home) network - which means out of reach of the ISP. And traffic visibility and regulation inside these privately owned networks is commonly (more or less) accepted as necessity.


Why is Debian not showing the GPG signatures on keys that Arch Linux is?

The root cause here is that

  the GnuPG developers broke gpg completely in a panic reaction

  -- @knoblauchkeks on Twitter

As explained in the release notes for GnuPG 2.2.17,

  Ignore all key-signatures received from keyservers.  This
      change is required to mitigate a DoS due to keys flooded with
      faked key-signatures.  The old behaviour can be achieved by adding

keyserver-options no-self-sigs-only,no-import-clean

  to your gpg.conf.  [#4607]

Adding this line to my (previously non-existent) ~/.gnupg/gpg.conf and re-fetching the release key fixed the issue.

This does not happen on Arch Linux because the maintainers decided to revert the commit that introduced this behavior, which can be seen in the build scripts for the package:

prepare() {
    # ...
    patch -R -p1 -i ../self-sigs-only.patch
}

I reported this issue to Qubes, suggesting the documentation be modified to account for this in some way.


What is a better practice - RSA Encryption vs Windows authentication

There isn't really enough information here to answer that.  If you have a secure means of key storage (such as a good TPM (Trusted Platform Module) or an HSM (Hardware Security Module) that can store keys in hardware, then having an encrypted config file would be more secure than having the authentication in the clear.

That said, the information necessary to break either system is present on the computer since IIS can access it.  If an attacker has sufficient control of the system, neither system will help you that much since they can masquerade as IIS and submit the decryption.

Honestly, I think the Windows Authentication setup properly would be ok, but I would do it by having the site run as a particular user.  Then only give that user permission to connect to the DB.  For an attacker to breach the system, they would need to gain access to an account that has access to the credentials of the service account (at which point they would have control of the application either way) and if they have control of the application, getting the key isn't going to be that hard.

I don't know of any more elaborate ways to add security to the setup, though someone else may have a better idea than I do.


Probably not. See this for an example of the fragility of such a scheme:

    Did the Twitter account Fifndhs predict the exact World Cup results ahead of time?

  The account tweeted the components of every possible scenario ahead of
  time, then retrospectively deleted all the ones inconsistent with
  reality.

You either need accountability of the authority, verifiability or proof (as in mathematical or cryptographic). I don't think a social network provider has either.

Then again, it might be enough in some contexts.


Can I limit PHP include() to specific directory trees?

Depending on your setup, you may be able to use Mandatory Access Control to get something close to what you want.  For example, consider a system running linux with apparmor.  By using apparmor you can limit which scripts are allowed to access the uploads directory. This isn't a perfect solution since a couple scripts will still be able to "include" the files, but you can limit the number of scripts that can.

For Example, you could allow upload.php to access the uploads directory, but deny index.php access to that directory even though they are running as the same user.

I assume you can do similar things with other MAC systems like SELinux.


How to write an email regarding IT Security that will be read, and not ignored by the end user?

A small trick I learned years ago - lay your email out like this:

  Short Version

  Small number of very short succinct points
  If X, then you need to do this
  Else, then you need to do that (or don't need to do anything)

  Long Version or Full Details

  ...and here you lay out whatever full version you want.

97% of your users will never read the long version, so make the short version count. However, the key here is that most users will read the short version if they're given a choice between that and the long version.  When you put that "Short Version" section header in, you're enticing them to read that because they feel like they can "get away" with just reading the short version.  It's, like, psychology or something.

Many of your users still won't read messages no matter what you do.  I've gotten better hit rates with this method than not, though.


What keeps the private key safe if an attacker has both clear and encrypted copies of a message and the public key?

What you describe is known as a "known-plaintext" attack -  an excellent answer to this question can be found on the crypto stack exchange:

https://crypto.stackexchange.com/questions/6624/is-a-known-plaintext-ciphertext-and-public-key-a-viable-attack-on-rsa.

Short and straight: it is not possible.


Is encrypting the FireFox folder with EFS protecting saved passwords in case of someone accessing the hard drive?

For the specific scenario you outline (theft of your computer or hard disk), that will probably work. Note that EFS is based on your Windows password, and Windows' password hashing is incredibly weak by modern standards, so your password will need to be extremely good to prevent a dedicated attacker from brute-forcing the hash.

Additionally, EFS provides protection against a malicious (or compromised) program running in another user account on the same machine. If you care about that threat, then EFS is probably the way to go. However, be aware that EFS leaks some information about encrypted files (specifically, the file metadata like access time, file size, and so on) so make sure you don't care about that if you use EFS as your only layer of encryption.

A better option if you don't care about the same-machine-cross-user threat is BitLocker volume encryption. Although originally only available on the most expensive Windows editions and requiring hardware support, these days I think all Windows editions that support EFS also support BitLocker, and you can skip the TPM by using a boot-time password. This password is hashed far more securely than Windows user account password hashing. Additionally, BitLocker will also protect all the other sensitive data you might have outside of your web browser, like passwords/tokens stored in other desktop apps, documents, and multimedia files you keep electronically, and so on. There are lots of guides online for doing this; https://www.howtogeek.com/howto/6229/how-to-use-bitlocker-on-drives-without-tpm/ has a pretty good walk-through.


Is there a way the weblogic server with an established SSL connection
  can re-use the client's cert to connect to the db?

No, there is no SSL equivalent to SSH Agent Forwarding; the SSL server cannot forward the client certificate credentials to another server.

Now, that's not to say you can't leverage the credentials.  If your weblogic server validates the client certificate, and then inserts an "X-I-Authenticated-The-Client: username" header, the backend DB can then treat that as an authentication if, as you say, you have control over and trust between the weblogic and the database layer.

(That's harder if you're not using something like HTTP, but even database connections can do it; consider PostgreSQL 'Trust' or 'Ident' authentication methods.)


What kind of printers do the most secure companies use?

Mostly they use multifunctional printers of major vendors (I worked for few and I installed printers in banks, government offices, police etc.).
They have turned on every possible security features like HDD encryption, SSL communication, password/chip authentication, disabled USB ports etc. Sometimes even customized firmware. As "normal" installation took few minutes, at those places it usually took ten's of minutes.
There is also special procedure of replacing old/faulty machine including formating and (multiple) rewriting data on HDD and then certified destruction of HDD.


Why does getting a password wrong takes more time than not

It takes the same time to verify a wrong password and a correct one. But, when the password is wrong, the operating system makes you wait a bit. This is a security feature, to discourage people who try "potential passwords" (in particular people with some electronic skills, plugging in some circuitry which the computer will consider to be a keyboard, but which in reality tries a lot of passwords real fast).

Such things don't work as well in a network context (if the attacker wants to try 100 passwords quickly, he can open 100 connections in parallel) but the password verification code is often shared between network and local logon.


If an attacker replays old handshake messages, the trickery will become apparent with the Finished message from the attacker, because the message previously recorded was encrypted and MACed with distinct keys, and its contents won't match either:

The derivation from the master secret (resulting from the key exchange mechanism, e.g. RSA) into symmetric encryption and MAC keys involves the client_random and server_random from the two "hello" messages; the attacker replayed one of these values (e.g. the client_random if the attacker is replaying the client messages) but the other is from the peer, and is distinct from what was recorded.
The contents of the Finished messages are a hash computed over all the previous handshake messages, including the two "hello" messages, and thus, again, one of the "randoms" has changed and the hash won't match.

Note: if the server requires certificate-based client authentication, and the attacker is replaying the client part of the exchange, then the replay will get detected earlier, at the CertificateVerify message: the recorded handshake message is a signature (by the genuine client) computed over a hash of all previous handshake messages, including, again, the two "randoms". However, SSL server who ask for client certificates are relatively rare.

An attacker who begins but never finishes handshakes is doing a Denial-of-Service attack: he makes the server allocate resources and spend CPU cycles for nothing. Typically, the attacker would send a ClientHello claiming support of only "DHE" cipher suites; then, the server must respond with a sequence of messages, including a ServerKeyExchange message which necessarily involves a newly computed signature. The CPU cost for the attacker is minimal (only the effort of opening a TCP connection and sending a few bytes) while the server must do some cryptography.

Since that kind of DoS requires doing an actual TCP connection, the attacker's IP address is revealed; also, signatures are not that expensive: a PC can do thousands of signatures per second. Therefore, SSL-based DoS are usually done by botnets.


Is it possible to use custom DH parameters for IKEv1 / IKEv2 /IPSEC?

Does that mean that I cannot use my own custom DH parameters for IKEv1/2 (as generated by openssl dhparam)?

Yes, only predefined MODP and ECP DH groups may be used with IKE, the lists for IKEv2 and IKEv1 can be found at IANA.

If you don't care for interoperability you could, of course, define your own group and use an identifier from the private use range.


The authors of the page you are referring to fail to understand some basic concepts and make otherwise false statements. Because of that I don't think that you should take any statements or conclusions from this article for real.  Some examples:

  This certificate identifies itself (via CN field) as *.google.com despite being served during a putative session with google.fr (again, this kind of obvious certificate misconfiguration is all but impossible to imagine google doing in production systems):

While the certificate they cite has *.google.com as the CN as they correctly state they fail to recognize that the certificate contains *.google.fr in the subject alternative names (SAN) section. And obviously the authors don't know that if this section is present and contains DNS names like in this case then the browsers should not even look at the CN but only at the SAN. This means the certificate is matching the server and the trust chain is also correct, so it is no wonder that the browser does not complain about it.

  However, it's notable that the connection does not appear to represent an EV-class certificate. In other words, there's no 'green lock' as we see in any of google's other services. For example: ...

I don't know which "other services" they refer too but neither google.com nor youtube.com use EV certificates.

In summary: There are several obvious errors in this article. Therefore I recommend to simply ignore any statements and conclusions made in this article because the authors don't seem to understand what they are talking about.

Edit: I just found that this article is also heavily critized at https://news.ycombinator.com/item?id=10030820


Github account hacked and repo wiped - Github Response

From the OP:

  Ok looks like the source has been found.

  https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexas-1m-28-07-2015/

  Silly me! :)

  PREVENTION -

<DirectoryMatch "^/.*/\.git/">
  Require all denied
</DirectoryMatch>

  in your apache config.

  to restore your repo,

  git push origin HEAD:master --force

To make it self-contained, though, this happens when you serve an entire Git repo for your website. So, for example, if your deploy process looks like

Push your changes
SSH into the webserver
Pull your changes

Then you should take note.

Git has a .git folder which contains all the meta-information about your repo, including your remote URLs. If you embed your credentials into the remote URL (if it looks like https://user@pass:github.com/user/repo.git, you've done this) then those credentials can be used to access your repository and do anything to it that you could do.

There are a few mitigations, depending on your situation:

As stated above, you can just configure your webserver to not serve the .git folder. This is the quickest, easiest solution, but also not a great one, because you're still exposing the contents of the repo to anyone who knows the paths. If you have any proprietary elements in there at all, use another mitigation.
Put your website's code in some subdirectory of the repository. You still get the ease of deployment, but now anything you want tracked but not published, you just... don't put in the public directory. This is a higher migration cost, but a cleaner approach, and easier to get right in the long run.
Pull with SSH, not with HTTPS. The keyfile, unless you're doing something horribly wrong, won't be published, so no one else can access the repo even if they do have access to the .git folder. Be aware that, with just this solution, they can still access the .git folder, but for some projects (e.g. most open-source ones) this is irrelevant, since everything in there is already public. As a nice side bonus, your server's connecting to GitHub will be more secure.


Solutions to diagnose PDF files for exploits?

peepdf and pdf-parser.py from Didier Stevens. Various online malware scanners which support PDF is good to try either.


You've got multiple questions in one so I will answer what I believe is your main question.

Use one salt per password per user. This stops rainbow table attacks as an attacker now needs a rainbow table for every possible password with every salt you are using. For them to compute this would be infeasible. I would recommend using PBDKF#2 or bcrypt or one of the other password based key derivation functions (PBKDF). In this day and age hashing, even with salt, is now seen as a weaker solution than using a good PBKDF.


What settings should be entered into the blacklist file for zmap to map a local network instead of the entire internet?

From the zmap documentation:

  The blacklist file will list subnets to exclude, in CIDR notation (e.g. 192.168.0.0/16), one-per line. It is recommended you use this to exclude RFC 1918 addresses, multicast, IANA reserved space, and other IANA special-purpose addresses. An example blacklist file is provided in conf/blacklist.example for this purpose.

So work out what ranges you can blacklist without removing addresses you own and add them into the blacklist file.


What are the security risks of running a daemon as root even though SELinux is enforcing?

A process running as root has more extensive access to various system calls, which increases the attack surface area. Even if SELinux is correctly enforced, there will still be an increased risk of kernel exploitation. The reason for this is that many system calls have checks to ensure that the process is running as root (more specifically, the checks are usually for CAP_SYS_ADMIN). If the process lacks those permissions, it quickly returns EPERM or a similar error. If it has those permissions, then a bug in between the quick permission check and the much later LSM checks can allow a process to exploit the kernel and disable SELinux, or more.
A privileged process may be able to take actions which SELinux cannot restrict due to there being no appropriate LSM hooks, which mandatory access controls tend to rely on. These hooks are scattered throughout the kernel and, each time they are reached, check whether or not the LSM has restricted the action. For example, after DAC checks (standard Unix permissions), an LSM hook exists that checks whether or not accessing a given filesystem object is permitted. Because the kernel is so complex and has such an extensive relationship with userspace, it is not possible to restrict everything. For one example, the risky ioctl system call (a catch-all syscall against file descriptors which allows kernel drivers to register what is in effect their own system calls) is not restricted by SELinux. In order to provide more fine-grained restrictions, you would need to whitelist the individual syscalls and their arguments. This can be done using the seccomp syscall filter.
No matter how tight you think your SELinux policy is, there is always room for improvement. For example, do you restrict the process' resource limits? Root processes are able to override resource limits, which can have security implications (for example, it is possible to disable ASLR for newly executed processes if you are able to control the stack resource limits).
Overall, there are four main risks that I can think of when running a process as root:

As explained above, the increased attack surface area may be exploitable.

The lack of defense-in-depth will mean that a bug in SELinux could lead to exploitation.

SELinux is not able to hook every possible action a root process can take.

No matter how tight the policy is, it can always be improved (e.g. do you restrict rlimits?)

Unless it is prohibitively difficult to run the daemon as its own user, I would suggest you drop privileges appropriately as if you were using no access control system at all.


Best Practice for Suppressing Fortify SCA Findings

In general you should not suppress the issues unless you are really really sure, in the case of Fortify I dont consider a good tool for c/c++ projects for example, but I know that works for other languages quite well. You should make an analysis of the issue and decide if you want to suppress or not with a minimum of two persons for evaluate the risk of fixing or not the issue.

Another approach will be to use another tool and check if both of them agree on the same code line, that is another indicator.


SSL CONNECTIVITY: using self signed certificates

It is possible to get most client applications to accept a self signed cert from a server, however, in many cases it requires that you use a command line option or a setting in a config file.

If the cert is signed by a CA ... then it is not a self signed cert, it is a CA signed cert.  The only real question from there is the CA trusted by the client application.


Strict Transport Security -- max_age value

From the IETF draft [ http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-06 ]:

  10.1 HSTS Policy expiration time considerations

  Server implementations and deploying web sites need to consider whether they are setting an expiry time that is a constant value into the future, e.g., by constantly sending the same max-age value to UAs.

  For example, a max-age value of 778000 is 90 days:

Strict-Transport-Security: max-age=778000

  Note that each receipt of this header by a UA will require the UA to update its notion of when it must delete its knowledge of this Known HSTS Host. The specifics of how this is accomplished is out of the scope of this specification.

  Or, whether they are setting an expiry time that is a fixed point in time, e.g., by sending max-age values that represent the remaining time until the expiry time.

  A consideration here is whether a deployer wishes to have the signaled HSTS Policy expiry time match that for the web site's domain certificate.

  Additionally, server implementers should consider employing a default max-age value of zero in their deployment configuration systems. This will require deployers to wilfully set max-age in order to have UAs enforce the HSTS Policy for their host, and protects them from inadvertently enabling HSTS with some arbitrary non-zero duration.

Therefore, since the browser will update it's stored HSTS max-age on every max-age header recieved [over https], going with the longer time won't really cause any of this bad cache horror story that the gossip talks about. The only issue is if the cert changes. However, site owners should be aware of this and should have the max-age set low (5-8 minutes) right before (a full day or so) the cert change is done due to expiration. However, this is only to deal with an incoming cert expiration (which is mostly avoided by replacing the cert with a new one before the last minute), as can be seen by:

  14.6 Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack

  If an attacker can convince users of, say, https://bank.example.com (which is protected by HSTS Policy), to install their own version of a root CA certificate purporting to be bank.example.com's CA, e.g., via a phishing email message with a link to such a certificate. Then, if they can perform an attack on the users' DNS, (e.g., via cache poisoning) and turn on HSTS Policy for their fake bank.example.com site, then they have themselves some new users.

Which shows that cert change in the middle of a broswer's HSTS "session" would not cause problems unless there were problems with the cert (validation warnings or errors). This would render the whole point of your question moot because it assumes that browsers store some piece of information related to the cert sent with the HSTS header response to validate against the HSTS host. As the draft makes no mention of such a concept, I would say that it is an invalid assumption.

However, storing cert information to be used against HSTS hosts can be done with public key pinning. But this would be done at a "factory" level or by the user manually, and as such would also have no way of updating via a HSTS host. [see http://www.imperialviolet.org/2011/05/04/pinning.html for more information]

To answer your last question, there is a privacy concern in the use of HSTS to track users. It works by using javascript to check if a resource in a list of websites that is enumerated through is loaded via https even though it is specified as http. The point of having a moderately low max-age in this case would be to have the entries cleared so that user tracking would be hindered. [see http://haxsys.net/2011/04/the-double-edged-sword-of-hsts-persistence-and-privacy/ for more information]

@Jesper Mortensen: HSTS causes the browser to rewrite all http requests to https before sending them. Therefore you shouldn't have both http and https accesses to a given domain. And anyone implementing HSTS SHOULD (RFC2119) not have a real http facing site (ie redirect on http requests to https via 301 or do something else [see section 6.2]). And mixed context stuff (http to other non-ssl non-hsts domain resources are a problem that is supposed to be dealt with on an implementer basis (by both server and browser)). Also try not to mock its draft status as it is implemented in both Firefox and Google Chrome(ium) [ie. ~55% of all browsers].


1and1 Dedicated Server got compromised (Windows Server 2003)

I would recommend taking a look at the detailed guide created by the NSA

http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/operating_systems.shtml#microsoft

They compile best practices and were written with the help of Microsoft.


Theoretically, If you know the hash of a program one intends to install and you generate another file that hashes to that value what could you do?

Many application control products (aka, application whitelisting) use hashes to identify approved executables. If you duplicate the hash of an approved file, that would be sufficient to execute applications in most cases where such controls are used. Code signing also relies on file hashes.

The security of these products stems from two sources: first, it is very difficult to generate a preimage collision. (Your proposed attack is based on finding a preimage collision.)

Secure hashing algorithms are expected to be resistant to preimage collisions. This expectation can only be satisfied by mathematical evidence that stands up to examination by cryptography experts. There are a number of hashing algorithms that have no known, practical attacks. E.g., SHA256, SHA512, and SHA3.

Right now, the SHA1 algorithm is deprecated because a combination of new techniques and growth in compute capabilities have rendered it vulnerable to such collisions. The method requires thousands of dollars of compute (at bulk cloud compute rates), but it is feasible for well-funded organizations.

The other factor which makes preimage attacks difficult is that you may not know the hashing algorithm chosen by the target. It is essentially impossible to generate a collision for multiple algorithms. E.g., you cannot create a file that collides with the MD5, SHA1, and SHA256 hashes of another file simultaneously. So, you would need to know which algorithm to target.

In summary, there are serious implications if you can generate preimage collisions, but hashing algorithms are designed to make this virtually impossible for precisely that reason.


Once upon a time, some people tried to encourage discrimination between the terms "hacker" and "cracker".  There is nothing inherently illegal about "hacking"; if you've ever pulled a toaster apart to see how it worked you've hacked.  (Fully legally, so long as it was your toaster).

Likewise, the hacker mindset does not depend upon criminality.  It is an openness to new ideas, a willingness to take things apart and to dare to put new things together.

As it turned out, people with this sort of intellectual flexibility were drawn to, and good at, breaking systems, which is why people say "hackers" today to cover that sort of thing.  (And why the effort to separate that activity to the term "crackers" failed).

@Robert David Graham and @wax eagle make excellent points.  Playing around with things is how you become a hacker, and if you want to play around with security, you can do it with your own systems or with permission and stay legal.

With apologies to @Mike Samuel, there are many classes that teach hacking skills, but there are no classes to teach someone to be a hacker.  A true hacker is usually impatient with being taught; it is their willingness to teach themselves that makes them what they are.

(With that said, for the purposes of becoming a talent the gov't would be happy to hire, classes will do you just fine).


Can deleted snapchat messages be recovered?

Yes you can try Data recovery software available to restore snap-chat msgs
Many are there and you should use it .Although I wont promise 100% recovery of all deleted messsages but many will be recovered depending on overwriting/changes of data you done till now
https://www.drfonelab.com/recover-lost-snapchat-messages.html
https://www.ibeesoft.com/recover-iphone/snapchat-message-recovery-iphone.html
https://www.phonerecoverytool.com/recover/how-to-recover-snapchat-messages-on-iphone.html


The most common solution to this is to create physical security: you have a dedicated rack, and use a secure, lockable cabinet.

You can also create physical security for a single box by locking the case. There are some subtleties to getting this right: securing the BIOS, firewire ports, etc.

Disk encryption is an effective technique, although it is susceptible to advanced attacks. Remote boot techniques like dropbear are vulnerable to a remote variant of the evil maid attack. For example, someone with physical access could tamper with the dropbear partition, and have it leak the key on the next reboot.

TPM-based disk encryption could work well. It doesn't require a password on boot, but instead only reveals the encryption key to a trusted boot image. I've not seen this done on a server, but I think it would work. I expect an advanced attacker can get around this too.

An attacker with physical access can only read RAM if they are quite highly skilled - at least, assuming you secure the basics like firewire. Given advanced attackers have other routes in, I don't think Tresor buys you much. Mandos sounds like an automated way of supplying the boot password remotely; I expect it has the same risks as dropbear.

Ultimately, to make proper decisions you need to consider the threat profile of a specific system. In practice, if you don't trust your hosting provider, maybe the best option is to switch to one you do trust - even if this means bringing your data centre in-house.


Is it possible to decrypt Bcrypt encryption?

bcrypt is not an encryption function, it's a password hashing function, relying on Blowfish's key scheduling, not its encryption. Hashing are mathematical one-way functions, meaning there is no* way to reverse the output string to get the input string.

*of course only Siths deal in absolutes and there are a few attacks against hashes. But none of them are "reversing" the hashing, AFAIK.


With WannaCry specifically, there is a known bug in current strains in the wild where the authors don't clear data that allows recovery of keys that allow for decryption of encrypted files.  The blog you link recommends not rebooting because that would clear the contents of memory, thus preventing you from exploiting this flaw to decrypt your files without paying.

Besides keeping your systems up to date on patches, the best strategy for mitigating a ransomeware threat is maintaining backups of user data so that if the worse happens, very little data is permanently lost.  You can attempt to decrease the likelihood of infection through user education and AV solutions, but these should not be relied upon as a sole defense.  For systems that must remain up at all times, establish a disaster scenario for them being knocked offline by ransomware (or any other attack for that matter).

Also important to note is that by the time you've been hit by ransomeware, there will already be thousands of people attempting to reverse engineer it and find ways of stopping it and fixing any damage it may have caused.  Keep an eye on these developments, because like with WannaCry, researchers may find cracks that will allow you to fully recover encrypted files or defend yourself against further infection.


What security measures should be taken when running a Linux web server out of our office?

Unless you have a very good reason to do this, you are likely to find that this not only introduces potential risks for your site and office infrastructure, but also provides a detrimental experience to website users.

At the very least, you should use a firewall to drop all traffic to unexpected ports (probably 80 and 443, depending whether you use HTTPS or not), and ensure that the web server system is isolated from other office computers and networks.

Changing the default HTTP and HTTPS ports will cause you headaches relating to users having to specify a port in order to connect to your website, and provides very limited protection for any other service (it takes a matter of minutes to scan all possible ports on a given IP address - if someone is looking at your server, they would find that SSH was running on 2020 rather that 22).

You should also consider how your network could be affected by denial-of-service attacks, if you are sharing the internet connection with your web server. If you do not have complete isolation between the web server and the rest of the network, it would also probably be possible for a determined attacker to pivot from your web server to attack other systems, which are probably not hardened for attack in this way.

It would also be important to keep the web server patched with the latest security patches, since the impact of an attack could potentially extend beyond just the one server.

On the other hand, if you host your site through a managed hosting provider, they will have dedicated bandwidth, firewall systems to minimise connections between servers, may well install security patches as they are released, and, depending on the provider, may handle basic backups and fall over procedures.

There are very few reasons for any small to medium business to self-host, so any decision to do so should only be made if there are specific reasons which cannot be overcome in other ways.


"Is [x] secure?" or "Is [x] more secure than [y]?" is always a tricky question to answer. In the end, you have to boil each option down to the strengths and weaknesses of its components and then make the decision based on your own needs to balance security and usability.

Here, your method of protecting passwords is best compared to existing tools like KeePass and TrueCrypt. I'd like to give you my comparison of these options in terms of Confidentiality, Integrity, and Availability (three core tenets of security) as well as Usability. For our purposes KeePass and TrueCrypt are on roughly equal grounds, so I'll just lump those together. We'll call your method HashPass.

First, a few assumptions must be made in order to perform an objective analysis.

HashPass does not use any encryption. Otherwise, it may as well just be another layer on top of something like KeePass/TrueCrypt.
Users are using the same password on multiple systems, but perhaps not all. Whether you personally do this or not will affect the level of security offered by HashPass. However, to answer this question for the general case, one must assume a "normal" end-user and they very often re-use passwords.
HashPass uses a unique salt for each entry. This is general good practice for hashing passwords, to prevent a single pre-computed table from being able to break the entire database in one swing.
HashPass is using a tried-and-true hashing implementation based on a strong algorithm. Otherwise, we almost might as well not bother hashing.

Confidentiality

HashPass

Pros

Each password must be individually attacked.

Cons

Weak passwords may be compromised faster. These passwords may be weak due to user choice, or due to restrictions of the systems on which they are used - the latter being beyond the control of HashPass or the user.
Knowledge of one site's password greatly simplifies attacks on entries for other sites where that password is reused. This may be gained by any number of means, many of which do not require a compromise of the local system.

KeePass/TrueCrypt

Pros

The database password can be as long and complex as the user likes - potentially well beyond the limitations of some or all of the systems represented in the database.
The database may additionally be protected by the use of key files or other authentication mechanisms which go well above and beyond the protection of a simple password.
The database key(s) cannot be attacked or stolen without first compromising the local system, unless the database is protected by a password that is also in use on a remote system and it is not additionally protected by a key file(s) or other authentication mechanism. (In short, protection of the database key(s) is entirely within the control of the user.)

Cons

Compromise of the database key will result in simultaneous compromise of all passwords in the database.

Integrity

HashPass

Pros

I can't think of any, in comparison to KeePass/TrueCrypt.

Cons

Protection of the database's Integrity is entirely dependent upon the host system. Individual passwords may be deleted or overwritten without deleting or modifying the rest of the database and without any foreknowledge of any of its passwords.

KeePass/TrueCrypt

Pros

The database's Integrity is protected by the same key which protects its Confidentiality. Without that key, an attacker cannot modify or delete individual keys - they can only delete the entire database.

Cons

I can't think of any, in comparison to HashPass.

Availability

HashPass

Pros

You can forget one or more passwords, but still have the ability to verify other passwords in the database.

Cons

You need to remember every password in the database, to verify every password in the database. If you forget a password, there's no way to get it from the database.

KeePass/TrueCrypt

Pros

You only need access to one key (though it may contain multiple components, at your option) to gain access to all passwords in the database.
You never need to remember any of the passwords in the database.

Cons

If you forget that one password, or lose/forget any of the other key components, you cannot access any of the passwords in the database.

Usability

For the Usability section, I'm going to compare a few "forgotten password scenarios" and also throw in "No Password Management" as an option as a baseline.

No Password Management

If you've forgotten which password you used, but can guess it in the first few tries...

You will brute-force your passwords on the target system until you eventually gain access.

If you've forgotten which password you used, and it takes you numerous attempts to guess the correct one...

You may trigger an account lockout and/or imposed password reset/recovery. A password reset may not permit reuse of previous passwords. Account lockouts and/or imposed password reset/recovery is becoming more the norm, but many systems still do not implement this. Prohibitions on password reuse is still relatively rare outside of high-security systems, but are becoming more common.
If the system does not use account lockouts or imposed password reset/recovery, you will eventually gain access.

If you've forgotten the password entirely...

If not automatically triggered, you will have to initiate a password recovery/reset process.

HashPass

If you've forgotten which password you used, but can guess it in the first few tries...

You will brute-force the passwords in HashPass until you guess the correct one, then will have to re-enter the password on the target system.

If you've forgotten which password you used, and it takes you numerous attempts to guess the correct one...

You will brute-force the passwords in HashPass until you guess the correct one without risk of triggering an account lockout or imposed password reset/recovery.

If you've forgotten the password entirely...

You will need to initiate a password recovery/reset process and update the database entry.

KeePass/TrueCrypt

If you've forgotten which password you used or forgotten the password entirely...

You will authenticate to the KeePass or TrueCrypt database and immediately have access to the correct password.
KeePass can even be configured to enter the password for you automatically.

If you've forgotten which password you used or forgotten the password entirely, and you cannot access the KeePass/TrueCrypt database (forgot KeePass/TrueCrypt password, or forgot/lost key files or other KeePass/TrueCrypt authenticators)...

You will need to initiate a password recovery/reset process and rebuild the entire password database.

In terms of usability, I believe KeePass/TrueCrypt clearly wins outright while HashPass is only a little bit better than no password management at all. In my personal experience, I've rarely - if ever - triggered an account lockout or imposed password reset/recovery by brute-forcing my own account. Usually I'll give up on brute-forcing it (which I'd still need to do with HashPass) before I hit a threshold anyway. It's also much easier to keep the one password (and/or other authenticators) in mind than it is to remember all the passwords in the database - which you effectively still need to do with HashPass.

For overall security, in "CIA" terms, both password management mechanisms have some areas where they have good strengths, as well as some pretty bad weaknesses.

How does everything balance out? I personally would prefer KeePass/TrueCrypt for its great usability benefits, the fact that its key strength is not dependent upon outside restrictions, and the fact that its key is not inherently obtainable from outside systems. Of course, the end decision is up to you.


Could malware move during a scan to avoid detection?

The main reason malware can't evade AV this way is because the on-access scanner will catch that.

From the AV point of view, malware moving to different files is the same problem as new files being created during the scan. A very simple solution is for the AV to keep track of new files being created (which includes current files being renamed). This is done by hooking the OS API or other lower level hooks.

In theory, a perfect rootkit will be invisible to an AV. To increase AV chances against rootkits, the AV starts very early in the startup sequence, it uses low level ways of communicating to the OS and hardware, and it will monitor tampering activity on itself. Also, the first stage of a scan is on active processes and system binaries. That's done especially because in-memory malware can play tricks like you mentioned.

Also bear in mind that any strange activity on the side of the malware, like moving files, jumping through the memory of different processes and using rootkit-like methods will only attract attention to it because legitimate software will not have such behaviour. A strange behaviour will be flagged by the AV heuristics and that might help to detect the malware or the binary might be uploaded to the AV servers for further analysis and cross-checking.


Can you exploit an Internet IP adress just like a LAN IP address?

More or less, yes. Some things that might be different:

You will not be able to use layer 2 scans (like ARP scans).
If I would give you my public IP address, that would be the address of my router, and not my PC. Depending on the port forwarding settings on my router, you will most probably not be able to scan my PC directly, but only my router. That would limit the ways you could attack me and what exploits you could use.
Chances that you will be blocked by an IPS/WAF/Firewall are higher when doing scans on internet addresses than on local addresses, although it does not necessarily have to be like that.


Is it possible to encrypt communications without an external server?

It's hard to tell exactly what you're asking; you can send secret and safe messages, but not "standard sites". You can use end to end encryption without https. This is in the same way you can use E2E with postcards or radio broadcasts or pencil and paper using a simple tool I made

While i think PHP and JS can talk to each other (with prior co-operation) securely, you won't be able to serve a normal page using normal browser routines.

It would be possible to build a JS-enabled client that can safely shuttle data back and forth, like I used when I built nadachat.com. That uses a pubkey to ship a a session-only symmetric key. On top of such a system you could build authentication and a web-like user interface, but not use standard anything like links, images, etc.

It's going to be a lot of heavy-lifting on your part to implement such a system. The encryption part is pretty easy, it's making sure you're talking to the right server (authentication/verification) without a cert that's going to be harder. There are challenge-response routines than can handle that, but again, you're really going against the grain and risk rolling out a flawed implementation.

Don't roll your own crypto.


SSL establishes a secure connection channel between you (the client) and the web server. If your only worry is about someone sniffing your traffic and reading your communications, then this is good enough.

However, this implies that you must place your trust in the web server. Your chats will be stored here (e.g. HTTPS protected conversations in Google Hangouts). However, this also means that your messages can be read by the server.

What end-to-end encryption (e.g. WhatsApp) gives you is that only the involved parties can access the details of a communication, not even the provider (more details). Session setup now requires keys that only the two parties know, without any trusted source (e.g. in SSL, the browser trusts the root).

The situation gets even more complex for group chats (see discussion here). Now you need all parties involved to agree to a key, and you may want to revoke and create new keys every time group membership changes.


Why does openssl writes EC parameters when generating private key?

It is a quirk of OpenSSL. The ecparam command is meant for handling EC parameters -- namely, the definition of a curve to play on -- and allows the generation of a private key as a secondary feature. You can use the -noout command-line argument to suppress the production of the encoded EC parameters themselves:

$ openssl ecparam -name secp256k1 -genkey -noout
-----BEGIN EC PRIVATE KEY-----
MHQCAQEEIHyx/m9I6/ZbvqN5XJ/fZSM6P7PIuvNDnWdp8STjlGqQoAcGBSuBBAAK
oUQDQgAEVGRwTHlFRgxmhnJNO4Vfdojmg2pni44U4SMFEziNM8YVhd62UzwB5L0+
n8EXsvTIv5Uj7COQd/1cTsdL9kin4w==
-----END EC PRIVATE KEY-----

Also, the existence of an "EC parameters" stand-alone structure is justified by the fact that the private key encoding could lack the information; see RFC 5915 which gives the following ASN.1 type:

ECPrivateKey ::= SEQUENCE {
  version        INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),
  privateKey     OCTET STRING,
  parameters [0] ECParameters {{ NamedCurve }} OPTIONAL,
  publicKey  [1] BIT STRING OPTIONAL
}

where the parameters and publicKey fields are duly marked as "optional".

As for the internal representation of the parameters (either stand-alone or as part of the private key structure), the use of a simple OID is rather normal. Generating your own elliptic curve is substantially harder than producing new DSA parameters; also, sticking to a few standard curves makes implementation of EC cryptography both easier and faster. Therefore, most implementations out there are restricted to a few standard curves, often the P-256 and P-384 from NIST (actually from SEC, then "annexed" by NIST). Implementations which support all 15 standard NIST curves are a rarity; implementations which support "arbitrary" curves (where the full curve values are encoded in the parameters structure) are mythical (I never stumbled on one, although I got close to writing one at some point).


How could a scammer know the apps on my phone / iTunes account?

It's a game of probability and chances are high that you might have one of the most popular apps in history installed on your device.

My guess is that the scammer does not know anything about you. The app in question is widely popular and one of the most successful apps on both iOS and Android. An attacker may just send out large amounts of mails containing such "most probable apps"/"best guesses". It would have been the same if the scammer sent an invoice for WhatsApp, which you most probably have installed on your device.

This tactic can also be observed in other recent spam waves like the notorious sextorion scam where the attacker sends a rather ominous remark about your porn preferences:

  i installed a software on the adult videos (pornographic material) web-site [...]  1st part displays the video you were viewing (you’ve got a nice taste haha)

So to sum it up, this is most likely just a wild, but very probable guess, and you are not compromised. Countermeasures in this case: delete the email, go catch some Pokémon and have fun.


Is it safe to log into my bank website over a public wifi?

If your bank Web site uses HTTPS, and you dutifully check that the server name in the URL is indeed the expected name, and you don't disregard warnings about unverified or expired certificates, then yes, it is safe.

If these conditions are not met, then no, it is not safe -- but it would not be safe from anywhere else either. Public WiFi is not special in that matter.

What may make public WiFi especially unsafe is that public WiFi occurs in public areas. Public areas are full of strangers. When you enter your bank password, you don't want weird people to spy on your keyboard or tablet screen. That kind of physical security is quite harder to achieve in a park or a restaurant, than in the privacy of your home.


When using LUKS, which parts of the hard disk are not encrypted?

As you said the boot partition is not encrypted at all, because dm-crypt + LUKS does not support it.

As second point a typical encrypted partition under dm-crypt + LUKS setup is the sum of the encrypted data and a partition header (containing the master key, all the keyslots, and some encryption parameters).

This header has a well know structure so, even all the partition is full of random data, the partition header leaks the presence of such encryption.
You can easily backup it on a remote website and overwrite it on the disk with random data and later put it back at its original place.

yOu can even get all the parameters for your encryption and feed with all the data the dmsetup command to decrypt your partition without using cryptsetup or luks.

I'm not aware of other possible leaks.

More info about the header format: https://code.google.com/p/cryptsetup/wiki/Specification or see Question 6.12 here: https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#6._Backup_and_Data_Recovery

    Refers to LUKS On-Disk Format Specification Version 1.2.1
LUKS header:
offset  length  name             data type  description
0x0000   0x06   magic            byte[]     'L','U','K','S', 0xba, 0xbe
     0      6
0x0006   0x02   version          uint16_t   LUKS version
     6      3
0x0008   0x20   cipher-name      char[]     cipher name spec.
     8     32
0x0028   0x20   cipher-mode      char[]     cipher mode spec.
    40     32
0x0048   0x20   hash-spec        char[]     hash spec.
    72     32
0x0068   0x04   payload-offset   uint32_t   bulk data offset in sectors
   104      4                               (512 bytes per sector)
0x006c   0x04   key-bytes        uint32_t   number of bytes in key
   108      4
0x0070   0x14   mk-digest        byte[]     master key checksum
   112     20                               calculated with PBKDF2
0x0084   0x20   mk-digest-salt   byte[]     salt for PBKDF2 when
   132     32                               calculating mk-digest
0x00a4   0x04   mk-digest-iter   uint32_t   iteration count for PBKDF2
   164      4                               when calculating mk-digest
0x00a8   0x28   uuid             char[]     partition UUID
   168     40
0x00d0   0x30   key-slot-0       key slot   key slot 0
   208     48
0x0100   0x30   key-slot-1       key slot   key slot 1
   256     48
0x0130   0x30   key-slot-2       key slot   key slot 2
   304     48
0x0160   0x30   key-slot-3       key slot   key slot 3
   352     48
0x0190   0x30   key-slot-4       key slot   key slot 4
   400     48
0x01c0   0x30   key-slot-5       key slot   key slot 5
   448     48
0x01f0   0x30   key-slot-6       key slot   key slot 6
   496     48
0x0220   0x30   key-slot-7       key slot   key slot 7
   544     48

Key slot:
offset  length  name                  data type  description
0x0000   0x04   active                uint32_t   key slot enabled/disabled
     0      4
0x0004   0x04   iterations            uint32_t   PBKDF2 iteration count
     4      4
0x0008   0x20   salt                  byte[]     PBKDF2 salt
     8     32
0x0028   0x04   key-material-offset   uint32_t   key start sector
    40      4                                    (512 bytes/sector)
0x002c   0x04   stripes               uint32_t   number of anti-forensic
    44      4                                    stripes


How often do high-end attackers actually use zero-day exploits?

I drove a project that looked at this while I was at Microsoft.  The answer is that the vast majority of breakins do not use 0 day.  We used malware as a proxy for breakins, because data was more accessible and puts the use of 0days in perspective.

The data here doesn't break out sophisticated attackers, but the arguments you put forth as to why no one wants to use 0days are solid.  They were probably used in Stuxnet because of the air gaps.

https://blogs.technet.microsoft.com/mmpc/tag/sir-v11/

Since that's a long report, I should add that it's the opening section, "Zeroing in on malware propagation methods" which addresses the question.


How secure is the hashing/salting/stretching process as described in this diagram?

Hashing client side

  Secondly assuming that the connection is compromised because of an MiTM attack. The process of how the leaked hash of the password is created is still unknown because the salt and iterations (based on the pincode) are unknown.

In case of a MitM attack (made possible by say incorrect use of TLS) hashing client side will not help you. The attacker could just modify the JavaScript sent to the client so that it sends the password and PIN in clear text. Short of having the user read and verify the complete JavaScript code at every login there is no way to protect your password if an attacker breakes the TLS.

Using a PIN that is "never stored"

  I think the combination of salting and stretching locally based on a pin-code that is never stored but just known by the user makes it harder to guess the salt and also to reproduce the exact process without the user since the local used salt and amount of stretching will be unknown to the server.

If I understand you correctly, your goal is to make it harder to make an offline brute force attack on the password hashes, by using a salt that is never stored.

Let me recap the main points of your scheme to establish some terminology. We have a hash function: HASH(data, salt, itteration count). The user has secrets P1 (password) and P2 (PIN). P2 is hashed locally with N itterations and using P2 as salt: H1 = HASH(P1, P2, N). H2 is sent to the server, where it hashed again (with a user specific salt and M itterations) : H2 = HASH(H1, salt, M).

So how would an attacker in posession of H2 brute force this? She would just use a normal dictionary attack, looping through possible combinations of P1 and P2. First she would recreate the process on the client to get H1 and then she would recreate the process on the server to get H2, and compare it with the actual value to see if she picket the right secrets.

This would take N + M itterations per attempt, and she would have to make X ^ (LENGTH(P1) + LENGTH(P2)) (where X is the size of the alphabet) attempts to try all possible secrets.

Now compare this to a scheme where there would just be one password with the combined length of P1 and P2, that is only hashed on the server with N + M itterations. Would your scheme be any better than this? No, it would be exactly the same. That would also take N + M itterations per attempt, and X ^ (LENGTH(P1) + LENGTH(P2)) attempts in total.

Long story short, your scheme is no better than just using a longer password. The only difference is that you have split the password in two parts, complicated things a bit, and done some hashing on the client.

Or in more general terms: You can not increase security by doing something with the password client side. If you do F(P) and send that instead of P, the attacker will also do F(P) when she brute force and you have gained nothing.

Some thoughts about rolling your own

You are rolling your own here - that is, you are coming up with your own solution to a problem where an established best practice already exists. This has been discussed here many times before:

Is my developer's home-brew password security right or wrong, and why?
Is This Password Scheme Secure anti pattern/canonical question?

Rolling your own system when there are established solutiongs seldom leads anywhere. You add more complexity, but you seldom add any security. If you are lucky, at least you don't make things worse. But if you are unlucky, there is no limit to the problems you can cause for yourself.

In your case, I don't think you did any fatal mistakes leading to obvious vulnerabilities. But who knows? Not me, not you. And when you implement this complex system, there are so many more places where you can make a tiny mistake and ruin it.

That said, speculating about alternative solutions can be a very useful learning experience and help us understand existing practices and concepts better. So there is nothing wrong in proposing and discussing different systems, as long as you don't roll them out into production.


CTR mode is about encrypting data by generating a key dependent pseudo-random stream and XORing it with the data; so what you describe really is CTR mode, and you don't have to to the XOR yourself. Said otherwise, by encrypting a bunch of zeros and then XORing the result with your actual data, you are just doing a needless extra XOR with zeros.

(You are highly encouraged not to try to invent encryption modes by yourself if you do not completely master the design of cryptographic modes, and the people who are qualified to perform such designs actually consider wisely that even they cannot reliably do the job properly.)

CTR mode is highly vulnerable to key reuse, so you'd better make sure that you, indeed, never reuse a key value; alternatively, you may reuse a key if you use a "sufficiently distinct IV" (since CTR works by encrypting successive values of a counter, you can get away with reusing a key as long as you do not reuse a counter value), but the IV must be known to both sender and receiver, which may be a problem in some use cases (adding an explicit IV to each message increases size; implicit IV such as message counts cannot necessarily be used if messages can be lost or receivers are stateless). Apart from that, an unauthenticated mode has the generic weakness of, indeed, not being authenticated, which can be very troublesome when there are active attackers roaming around (and scenarios with passive-only attackers tend to be unrealistic). Also, CTR mode implies no padding, so the encrypted data length is equal to the plaintext data length, which is what you want, but also means that the plaintext data length leaks -- depending on your context, this may or may not be a problem.

Within the limits expressed above, CTR mode is as good as such things can get.


does private key go to a ssl certificate?

TLDR
Private key is not a part of certificate. A certificate is a confirmation of some trusted party (CA) that particular public key belongs to particular party.
The documentation of Splunk that you refer uses wrong wording. The file that they create is not a certificate.
Details
Here the documentation says:

Combine your server certificate and public certificate, in that order,
into a single PEM file.

This sentence is correct. The resulting file is just a PEM file. But it is not a certificate, it is not a certificate chain, it is just a PEM file that stores different cryptographic objects, in this case it is a private key and one or more certificates from the same certificate chain. There is no common term for this. (And no, a key store is also not a proper name for this store.) There are standard formats for that. For instance, PKCS allows to store bundles of private keys and related certificates (e.g. it could be used to store server certificate and corresponding private key), also it allows to store separate certificates (in case of Splunk this would be a certificate of the CA that issued this certificate, or the chain of CA certificates up to the root CA).
But because of some reason the developers of Splunk decided to use a home grown format. PEM is of course a standard, but the Splunk requirement that this file should contain, in the following order ... in decreasing order of hierarchy, up to the root can make it actually more fragile (in PKCS the order of adding certificates to the store has no meaning at all), can increase the number of configuration errors and thus increase the maintenance costs. On the other hand, if the number of objects in the PEM file is small, like 3-5, it is easy to work with it in any text editor, which maybe easier than dealing with PKCS.
Then the Splunk documentation says:

Here's an example of a properly concatenated certificate:

This sentence is wrong. What they show in documentation is not a certificate.
And this:

the completed certificate file might look like this:

Also this sentence is wrong. What they show in documentation is not a certificate.
The other page looks at the first glance fine. But when you read "Copy the server certificate" or "Absolute path to the certificate" and you remember the previous page, you may be in doubt: Do they mean a certificate file in the common sense, e.g. a file that contains a single certificate, or do they mean "certificate" in the Splunk special wording and actually they mean "a file containing a mix of private key and certificate chain"? From this documentation you cannot know it. Either you need to find better documentation, or try different files to find out what they actually mean.


What are the changes in PKI when i move from TLS protocol to IPSec Protocol?

TLS is authentication at the application level while IPSec is essentially authentication of a device. In TLS it is common that the client only authenticates the server while in IPSec both peers authenticate each other (i.e. mutual authentication). This means your PKI must now reflects devices and not applications and it needs to reflect both sides of a communication. How this affects your specific existing PKI is unknown.


avoid hitting DB to authenticate a user on EVERY request in stateless web app architecture?

Yes it is possible, and this technique is widely used.

It does have some minor drawbacks compared to stateful sessions:

It does not support strong logout. If a user clicks logout, the cookie is cleared from their browser. However, if an attacker has captured the cookie, they can continue to use it until the cookie expires.
The use of a server-side secret to create the tokens creates a single point of failure: if the secret is captured, an attacker can impersonate any user.

Deciding whether to use stateless or stateful sessions depends on your performance and security requirements. Online banking would tend of use stateful sessions, while a busy blog would tend to use stateless sessions.

A few tweaks are required to your proposed scheme:

Encrypting the token does not protect it from tampering. You want to use a Message Authentication Code (MAC) which does protect tampering. You may additionally want to use encryption, but that is less important.
You need to include a timestamp in the token and put a time limit on their validity. Somewhere around 15 minutes is sensible. Normally you would automatically re-issue shortly before the timeout, and usually the reissue would incur a database hit (although even that can be avoided)
Do not include the user's IP address in the token. Approximately 3% of users will legitimately change IP address during a web session, due to modem resets, changing WiFi hot spots, load balanced proxies and more. While you can include the user agent in the token, it is not normal to do that - consider it an advanced technique to use if you are sure you know what you're doing.
If an attacker captures a session cookie they can impersonate that user. There is nothing you can really do about. Instead, put all your effort into preventing an attacker capturing the cookie in the first place. Use SSL, use the "secure" cookie flag, fix all cross-site scripting flaws, etc. And have some user advice to lock their screen when their computer is unattended.

I hope this is helpful to you. If anything is unclear or you need further information, leave a comment and I will see if I can help you further.


VPN Access to PCI Environment Edge Devices

It's not a violation per se. I think it puts them and their equipment "in scope" for your PCI compliance efforts. Ask your QSA for clarification if you are unsure.


Looking at the excerpt, the following URL appears to be common across all the requests:

zukexupyqiv.wordpress.com%2F2013%2F05%2F06%2Fcreate-a-note-of-the-puppy-testimonials-purchasing-mal-shi-pups-for

The URL has been taken down by wordpress for unknown reasons - maybe because others also observed this kind of activity affecting their websites and complained to wordpress.

I suspect the intention of the activity is to simply spam your server, and force you as the system administrator to visit the URL above by consuming storage space on your disk and filling up the logs.

This is indicated from the following sentence in the requests:
"I know this site offers quality dependent articles and extra material, is there any other site which provides these kinds of things in quality"

PS: Incidentally, the GET requests appear to be structured in a format, as if someone is submitting an online form as seen from the parameter called "postcomment". This might be because it is easy to send requests like this.

UPDATE: I would mitigate this activity by parsing requests for common terms in all the requests e.g. the URL above, key terms listed above, and simply dropping these requests. Dropping the requests should reduce the load on your server. If you have a large website with global audience, you could consider a CDN service like Akamai which optionally provides a Web Application Firewall (WAF) to offload the work of mitigating DOS and other types of attacks.


Should I delete locally synced data if the user can't log in?

Scenario 1 will only work if the attacker is stupid. If a guy manages to steal the password of somebody and sync a cloud folder on his machine, the next thing he should do would be to save the content of the stolen data elsewhere just to make sure that a sync problem could not change it.

In that case erasing the synced folder will just have no  effect...


Random bluetooth pairing requests in public

This thread:
Security wise, is it safe to use bluetooth headphones?
I think answers your first question pretty well. However, occasionally vulnerabilities sometimes do show up, such as Blueborne:

https://www.schneier.com/blog/archives/2017/09/bluetooth_vulne.html

which could allow attackers to hit your bluetooth device without you doing anything. Double the problem when you consider that non-smart bluetooth devices may never get updates to patch these sorts of vulnerabilities.

To the second question: It's possible someone sees your device and is mistaking it for theirs, but if the requests keep coming, I would guess it's probably malicious.


How is typing "name at example dot com" safer than "name@example.com"?

The problem for the bot creator is trying to parse all the text to identify what is an obfuscated email. It's obvious to a human by reading the context, but a script is not going to have contextual awareness. However, the regex to parse a proper email address syntax is well-known.

Try to program a bot to identify hank dot chief one two three at gmail dot com in your post (without knowing the email to look for). There is not a lot there for a script to use to figure out an email.

Sure, a script could look for at [\c] dot com, but getting the name right will be quite a chore.

Some bots will be able to programmatically identify the context based on the form used, but that requires that the forum have an identifiable format to be able to say that "the text in this area is likely an email".


How to synchronize changing password in my app with the server?

Would it work to have the user select a list of devices to update when they change the password on the website?

If so, the app could generate a key pair, and post the public key to the server once they have connected/authenticated (they only need to do this once/rarely).  When changing the password, you would encrypt the new password with the public key and store it somewhere for the Android app to check on next boot.  Nobody will be able to decrypt the new password apart from that particular device.

(If the Android device is compromised and the private keys are read, then presumably the same thing would happen to any rotated password.  Maybe this is why the user is changing their password, at which point "select devices to update" is an important step.)


Issuing banks are subject to a different set of standards than the PCI DSS.  See the PCI Card Production standards for their specific rules (use the pull down to select Card Production.)

Yes, banks are required to file a Report Of Compliance, and of course they certainly could be out of compliance.  Being out of compliance doesn't mean they close the doors, though.  Their assessor would need to see a plan to get them into compliance, and they could keep operating. But operating without a ROC means taking on a lot of risk:  they're betting heavily that they won't have a data breach.  If they do, the full burden of fraud will fall on them, as well as fines, penalties, and class action lawsuits from their customers.

Of course, any company that's breached gets re-audited, and the auditors who look at them after the breach always find some reason they weren't in compliance.  The PCI doesn't appear to be willing to take responsibility for deploying a weak or ineffective standard, just as they're unwilling to own their share of the responsibility for having forced the current insecure protocols and systems on the banking and retail industries.


Benefits of Facebooks new "Trusted Friends" feature

This is a really interesting idea and I don't think it's just security theatre. Email accounts can be hijacked through technical means and/or social engineering. 2FA can be broken (via hacked email or exploited SS7 vulnerability).

This mechanism offers a way to always be able to retain control of your account. It does however rely on your friends to not be bribable and not fall for social engineering attacks from attackers trying to exploit this to this to hijack your account and humans are often a weak link in the security chain.


Can I prevent all employees from accessing customer data without being logged (especially IT)

If there's a way to access data without an audit log, secure the credentials required to access it that way and audit their access. Software such as Vault is geared toward this. Physical control of an MFA token such as storing it on a YubiKey and then putting that in a safe place with somebody who doesn't control the password would provide you with dual control.


How should output of fail2ban postfix-sasl look like

Looks like I've found answer to my own question, apparently fail2ban-client status will say that service is enabled, even if there is no filter rule for that particular ban.

The solution was to create postfix-sasl.conf in /etc/fail2ban/filter.d/postfix-sasl.conf
With following contents:

# Fail2Ban filter for postfix authentication failures
#

[INCLUDES]

before = common.conf

[Definition]

_daemon = postfix/smtpd

failregex = ^%(__prefix_line)swarning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: [ A-Za-z0-9+/]*={0,2})?\s*$

# Author: Yaroslav Halchenko

and reload configuration with

fail2ban-client reload

Then after a while iptables -L confirms it's working and banning IP's

Chain f2b-postfix-sasl (1 references)
target     prot opt source               destination
REJECT     all  --  systemip8.example.com  anywhere             reject-with icmp-port-unreachable
REJECT     all  --  systemip8.example.com  anywhere             reject-with icmp-port-unreachable
REJECT     all  --  12.215.34.226        anywhere             reject-with icmp-port-unreachable
RETURN     all  --  anywhere             anywhere


How to secure shared user on build server?

If the build account can execute arbitrary commands as a production user on a production server, it will need to be locked down.  Only a select group of privileged users should be able to use it, ideally without the ability to alter the (hopefully small set of pre-defined) commands.

Do you really need this ability?  Maybe there's a better solution, such as a drop area on the production server(s) that the build account can write to, complete with scripts on the production server(s) that quickly move the payload into the appropriate area (so it doesn't get overwritten), extract it, and then install it as needed.  The installation would be done with a application-specific user account rather than a generic build or deploy account.

When I have set this kind of thing up in the past, I made copious use of sudo and /etc/sudoers to limit individual users' ability to act as any role account (such as build).  I also used drop areas, which were typically either SFTP or revision control (subversion, git, etc).

Revision control is nice because the logs are more accessible than sudo logs.  Just add a tag and the cron job that runs every five minutes will recognize the tag, check out your update, and kick off a new build.  Successful completion of the build (and a smoke test suite) automatically triggers installation on a staging server, after which the QA team gets an email.  When QA is content, they add another repository tag and the staging package is installed in production.


How to store nonce and key when working with libsodium secretbox?

I am not an expert nor have I ever done anything with crypto before. I AM AN AMATEUR!!! Please do not take what I have to say as any knowledge or wisdom in this subject matter. Use at your own risk.

I actually have the same question. Much of the documentation and F.U.D. leave someone learning this stuff in a daze. I'm pretty sure this in intentional to help with security via obscurity and confusion.

Ok, jokes aside, I did want to expand on some concepts you outlined that I've discovered in my own journey down the same path. First off the plate is that the use of encryption and how you implement it is directly dependent on the use case. For example if you wish to address data at rest it will have a very different solution then exchanging secret messages over the wire. They all use the same algorithms and tools but the actual implementation for your app will differ.

Next, the key (in secretbox) is your life blood. It must be saved securely and hidden away. It is also permanent in the case of storing data at rest. In your example saving it outside the document root or possibly in a database behind a firewall might be best. Also many implementations will also encrypt the key with a passphrase (this is what GPG/PGP does) You could do this before writing it to disk and save the passphrase (randombytes_buf) in an environment variable.

The nonce is unique per encryption ...err... per ciphertext created. So in your case above I would serialize all three fields into one string and encrypt that with one nonce. Now to decrypt (read) you need to know the nonce. This is where the docs and blog posts get funny. I've only seen one example (libsodium-wrappers) where they concatenated nonce buffer with the ciphertext buffer making one large buffer with the nonce as a prefix.

I am presuming that another method would be to serialize both in a form parse-able by the reader. This is my question for the crypto world. Which is a better transport method?

One string/binary payload:

nonce
vvvvvv
bada55123456789abcdf
      ^^^^^^^^^^^^^^
      ciphertext

OR separate the two when serializing:

{
  "nonce": "bada55",
  "ciphertext": "123456789abcdef"
}


Best way to authorize and authenticate a user on web API

"Best way" is almost always subjective in questions like these. There are some very good ways, and you should consider them all and how they fit your hypothetical scenario in order to select the "best" one.

That said, one method that I would rank highly would be using mutually authenticated certificates, aka "Client Certificate" authentication.  TLS can require that both the server AND the client use certificates to establish the connection.  In order to connect to your service, the clients would need to prove themselves to a certificate authority and request a signed certificate, which they would send as a part of the TLS handshake process.

You could also require the certificate provider to issue the client certificates with a suitably short lifetime to make sure that the clients are authenticating to the cert provider on a regular basis.

Also note that authenticate and authorize are two very different activities.  Certificates are great for authentication, but you should probably be looking at a different mechanism for authorization.


Weird attack making my server CPU super high

Just based on the limited details This looks like it could've be a bitcoin miner disguised as the grep command. Deleting or killing it won't help because that is just the payload.

You need to look at your Apache access logs , ssh logs, etc and figure out how the attacker got onto your system (eg unpatched vulnerability? Default password ?) then close that gap. Also what backdoors or webshells or reverse shells has the attacker left behind already ? If you can't find them the attacker will likely just return and do it all over again.

Safest bet if you have poor logging or no clue how or when this happened is to rebuild the system and ensure everything is patched and all default password changed.


These days it's near impossible to thwart a traffic based DoS without some kind of hefty physical firewall in the network. However, if you're talking about other forms of DoS then there are a few things you can do to help.

Use asynchronous/non-blocking sockets. A malicious user could open up any number of connections to your sockets consuming all of your available threads. (Slowloris Vulnerability)
Control how many request-per-second a user can submit to ensure they aren't flooding your socket
Ensure the user cannot make the server perform anything too resource intensive