How to troubleshoot "client certificate" related errors in 2 way HTTPS

If the server requests the certificate during the initial handshake, simply use Wireshark and look for the Certificate Request TLS message (just before Server Hello Done). If you look into the details of this package, you should see a certificate_authorities list giving you the list of acceptable CAs. Your local chain will need to match one of these.
If there is no visible Certificate Request message, it may be in a re-negotiated handshake. In this case, this second handshake will be encrypted, so not immediately visible. Recent versions of Wireshark let you use a pre-master secret (see "Using the (Pre)-Master-Secret section on the Wireshark SSL wiki page, and this answer of course). This is generally more convoluted, but this can be done.

More generally, to debug your problem, I would also look at other NSS environment variables, such as SSLDEBUG (and SSLDEBUGFILE), when using Firefox.

In addition, you could use openssl s_client -connect my.host.example:443 -servername my.host.example (with various levels of verbosity if required) to simulate a browser connection to your server. That should at least tell you which CAs are advertised in the Certificate Request message. If the server uses re-negotiation, you might need to write a minimal HTTP request looking more or less like this (adapted with what you need):

GET /my/protected/resource HTTP/1.1
Host: my.host.example

(In some complex settings, you might have to copy/paste the other headers you see from a browser request, using its developer tools.)

(You may also find the -prexit option useful in some cases, credit to this answer.)

Since it seems from comments that forging manually the HTTP request doesn't work for you, another possibility is to use curl --verbose https://my.host.example/my/protected/resource > /dev/null (you can also use finer debug levels such as --trace or --trace-ascii if required, see man page for curl). This should produce something like this, so hopefully you should see a Certificate Request somewhere:

* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Server hello (2):
{ [data not shown]
* SSLv3, TLS handshake, CERT (11):
{ [data not shown]
* SSLv3, TLS handshake, Server key exchange (12):
{ [data not shown]

Better, if you need the request to be more realistic, make your actual request from Chrome after opening the developer tools. Right-click on that and use "Copy as cURL", then paste it and use it with curl (add --verbose or other): this should copy the necessary headers. There's a video with an example here.


Why doesn't asn1parse parse all DER encoding strings?

With OpenSSL 0.9.8r, I get this:

$ cat crl.txt
MDYwNKAyoDCGLmh0dHA6Ly93d3cyLnB1YmxpYy10cnVzdC5jb20vY3JsL2N0L2N0cm9vdC5jcmw=
$ /usr/bin/openssl asn1parse -inform PEM -in crl.txt -i
    0:d=0  hl=2 l=  54 cons: SEQUENCE
    2:d=1  hl=2 l=  52 cons:  SEQUENCE
    4:d=2  hl=2 l=  50 cons:   cont [ 0 ]
    6:d=3  hl=2 l=  48 cons:    cont [ 0 ]
    8:d=4  hl=2 l=  46 prim:     cont [ 6 ]

If your OpenSSL does "nothing" then there is something wrong with it or with your computer.

Note that "PEM", stricto sensu, is for Base64 with header and footer: it shall begin with -----BEGIN FOO----- (from some "FOO") and end with -----END FOO-----. OpenSSL is quite urbane to accept processing your headerless Base64 (or maybe it does not, in your case ?).


It will depend on what you are concerned about. Using SMS as a means of 'out-of-band' communication is normal for many major services. But you have to come to your own conclusion as to whether that is still too exposed for your clients. Do you have independent verification of the SMS number before transmission, for example?

Without knowing the full environment or risk factors, I would caution against over-complicating security measures. Make sure you aren't creating a security infrastructure that costs more than the risks, and costs include usability and client relationships. But those costs are something only you can evaluate.


Flawed understanding of SQL Server Transparent Data Encryption (TDE)

No, your understanding of TDE is not wrong.  A user with the appropriate permissions on the SQL Server instance can access the data in the database, and with SQL Azure, even if TDE were enabled, the DBAs in charge of the instance would certainly still have full access to the data.

What can you do?  Well, you can encrypt the data in the application before you ever send it to the database.  This creates a whole slew of additional constraints on how you query and use the data however, and is generally only appropriate in very limited use cases.

Ideally, you'd convince the client that this is an acceptable risk.  The cloud providers business model is built around protecting their clients' data, not stealing it.  It isn't in their best interest to abuse their position of trust in that way.

To me this sounds like its probably a search for a technical solution to a problem that doesn't need solving.   I understand the concern, but in my opinion, the concern is out of proportion to the risk.


How to create custom exploit https requests to test a PHP framework

For Linux systems, gnutls-cli is available. For example:
gnutls-cli qnap --no-ca-verification
GET index.html

gets the index.html from my Qnap-NAS via port 443. You can of course easily make invalid http requests like your example this way.
If you just want to exploit all sorts of possible URLs with valid requests, then perhaps curl is the better tool.


Preventing 3rd party DNS Servers from being used

What are your goals?  I think your goal is to block sites by denying name resolution.  If that is your goal, it won't work.

Using IP addresses will still get to the sites.
Using a local hosts file (/etc/hosts) avoids the DNS protocol while providing for a limited subset of name resolution.
Running a local DNS server on the host, but tunneling DNS requests hides the requests from your network.

A much easier alternative to your scheme that still suffers the same weaknesses as above is to block port 53 from traversing your firewall, or inspecting packets and blocking any DNS traffic across the firewall that doesn't come from your DNS server.

  a proper network connection cannot be established

I'm not sure what you mean by this.  By the time you detect the host using a different DNS server, a network connection will have already been established.


SQL Injection Modify / Insert Table Values

Query stacking, ie select * from tbl; update ... -- is forbidden by most database management systems. In order to enable query stacking in PHP/MySQL,  the application must use the mysql_mutli_query() function to execute the query.  This function is uncommon in the wild.
In SQL injection without query stacking, the attacker is limited by accessible query operators, and SQL functions. The tool SQLMap allows an attacker to access functionality exposed by SQL injection with an easy to use shell.  The example sql injection vulnerability provided maybe blind sql injection, which can be exploited with SQLMap.
In MySQL,  an attacker can append a union select to access other tables:
select id from db where id = 1 union select password from users

or a sub-select:
select id from db where id = (select password from users)

Additionally an attacker could read file using the load_file() function:
select from db where id = load_file('/etc/passwd')

Only select statements can use the into outfile query operator:
select from db where id = 1 union select password from users into outfile '/var/www/backup.txt'

The into outfile operator requires the use of single-quotes and cannot be used in a SQL injection exploit when mysql_real_escape_string() is used.
The paper Hackproofing MySQL is still relevant, and covers these attacks, and more.


Using Google Cloud Platform to store credit card data

Note that it's not because you are using a platform which has been cleared for being PCI-DSS compliant in a single or several instances that you are also automatically PCI compliant. You will also need to go through all checks like regular ASV scanning, etc...

Note that there are certain pieces of information which you are simply not allowed to store if you want to be PCI-DSS compliant.

PCI is all about discouraging the storage of cardholder information, so if you are just doing it for the sake of convenience, I'm not sure it's worth the trouble.


how to ensure that the DNS server is giving me the legitimate information?

If you can collect the DNS info beforehand set that data in a prioritized host file. If not you'd have to force queries to near random DNS servers on the Internet, ideally from a completely separate network to avoid man in the middle modification (possibly via a cell phone on a carrier network) and compare the results to what you got from the questionable DNS server.

As to how to collect safe DNS/IP info verify the Certificates via TLS/SSL if the remote systems support TLS/SSL (possibly other protocols that also use certificates).

A well configured Split DNS implementation where the Internal DNS servers don't pull from your Externally facing DNS servers will prevent external poisoning of your internal DNS resolutions.

It's a great question and an interesting design flaw that we all have to work with.

I think the important part is knowing how to implement Split DNS properly so your internal hosts don't get poisoned.

You could also tunnel all of your DNS requests to a trusted server or set of servers to avoid the man in the middle problem.

The more complicated solution is to rewrite your DNS client to poll various trusted DNS servers to compare their results with your local one to detect DNS poisoning.


Putty store cleartext credentials in the Windows Registry; isn't that a very insecure approach?

In the context of ssh, "credentials" can have two meanings.

Cleartext password

It is true, that registering cleartext password as cleartext, i.e. without any encryption or so, is at least a bad practice from a security view. However, encrypting them correctly is simply impossible: Putty somehow needs to access them on authenticating with the remote server. To do that, it would need to decrypt it. It does not matter, how would it be done, the same could be done also by a potential attacker. Encrypting the password would be security through obscurity, thus it would have not a very much security gain.

Although using same encryption, or using an improved ssh protocol which somehow circumvents it, would be obviously better, the difference is not so huge, as it seems on the first spot.

Public/private key pair

The public key can be sent to anywhere, the private should be kept secret. For private key, the case is the same in this context, as for the password: if someone can read out the private key, can also manipulate the Putty process to extract it for him.

The most important thing to know: to get the credentials, requires access to the client machine (either as an admin account, or account to the user). Having this access, even an encrypted password could be eavesdropped, for example by using a keylogger, or by binary hacking your Putty process.

It is an inherent security weakness of all password or key-based authentication system. The only solution for that, if the authentication happens on a different channel, by a different system, from which the connection was initiated. The are multiple solutions for this, multi-factor authentication or Kerberos. Most ssh software (including putty and the openssh server) supports the second, although it is rarely used in the daily practice.

The daily practice is to not allowing physical access to anybody to your client machine. If they have access, they can access much more than only your ssh keys/passwords.

About Kitty

The same stays for Kitty. It might not keep cleartext password or keys in the registry, but it still needs to get somehow access to your passwords/keys. Even if it store on a lesser public way, what Kitty does to decrypt/access them, also a malware can do (or a modified Kitty binary can do). Thus, Kitty increases the security of your system only a little bit. But it might give the false sense of security, what could be even dangerous.


Does "Start the following program on connection" mean what I think it means?

It means once you've connected and logged in successfully.


Can a malware steal the content of the clipboard?

Yes. It can be done with Javascript too. The beef-xss toolkit has an attack which facilitates this. https://github.com/beefproject/beef/tree/master/modules/host/clipboard_theft


How to detect "forged" SSL certificates from the webserver end

The only way I can see is to open a XMLHTTPRequest over SSL and pull the certificate out of that connection:

MDN: How to check the security state of an XMLHTTPRequest over SSL
(archive)

This doesn't work from a web-page, but is required to be run from an extension.

As already pointed out the proxy can easily change the javascript to kill this.


Is it possible to make an xss with only html tags

Yes. It's trivial.

Might want to save your work before trying that, though - the alert might show repeatedly as you move your mouse across the screen.

Of course, a better attack would involve destroying the div as soon as the JavaScript is called, in order to make it look legitimate.

You should escape all output in order to avoid this.


Who is responsible for choosing a TLS cipher suite - the client or the server?

The client sends only what ciphers it supports in the order of their preference. The server then selects one of these ciphers - which means only the server ultimately decides which cipher gets used.

It is fully up to the server which cipher suite gets selected from the offered ones, i.e. the server might take the client preferences in account but might also completely ignore it. In fact, many servers have a configuration option which allows the server to use either the cipher preferred by the client or the cipher preferred by the server.


Does the glibc getaddrinfo vulnerability affect mobile applications?

Neither Android nor iPhone use glibc, so these are not affected.
Android uses as libc Bionic and iOS is also using their own libc implementation.


Is it possible to prove the content of a file hasn't changed since certain date?

While you cannot mathematically prove that a document was unchanged since a certain time, you can use a Trusted Timestamp Service to provide signed evidence that you haven’t tampered with it since the time you submitted it to be signed.


How do google or facebook know I'm behind a man in the middle proxy?

These sites set the HSTS header (HTTP Strict Transport Security). If you have visited these site without the Burp proxy before, your browser knows (cached) the HSTS policy and sees a mismatch.

The HSTS Policy specifies a period of time during which the user shall access the server in a secure-only fashion.

  HTTP Strict Transport Security (HSTS) is a web security policy mechanism which is necessary to protect secure HTTPS websites against downgrade attacks, and which greatly simplifies protection against cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections,1 and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797.

  The HSTS Policy[2] is communicated by the server to the user agent via
  a HTTP response header field named "Strict-Transport-Security". HSTS
  Policy specifies a period of time during which the user agent shall
  access the server in a secure-only fashion.

In order to make this work, the HSTS settings should be removed from your browser, this is different per browser.


Is it important for an ethical hacker to know the C language in-depth nowadays?

Of course, you don't necessarily have to know C, or the given platform's Assembly (read: instruction set), but knowing them is a great help in figuring out many possible low-level vulnerabilities.
It is not the C language itself that matters, but rather the fact that in order to know C, one must first understand many fundamental computer principles, which is what allows you to then (ab)use them in any other language. You could learn about all of them in theory, but without ever practically experiencing them (which is what you achieve by programming in C), you may not be able to use them very efficiently or even realize where they're best applicable.
Similarly, you don't have to know the exact packet structure of networking protocols. However, if you do, you may suddenly be able to figure out ways to break something, which wouldn't ever occur to those who make, often incorrect, assumptions about how these protocols function solely based on their high-level experience.


The other way is to check the cache, and don't allow two different ip address for a single mac address.

I want to start here because this is a very bad idea. There are many situations where a single MAC may have multiple valid IP addresses, especially in an IPv6 world.

  Wireshark can detect these kind of activites, and warn us by a 'duplicated ip address' message.

Wireshark is highlighting in these cases a IP address potentially has more than one MAC address in the traffic. This may be a duplicate IP address, but it also may be a valid configuration.

  Why doesn't the router act like this? ... I think it is easy to prevent, but network hosts are just let it happen. Why?

It all depends on the router, network and configuration in question.

Many routers will detect and log/alert when there is the possibility of a duplicate IP address. Some routers will not update an ARP entry in their tables until the old entry ages out or is manually removed.

Hosts can be configured to handle this in different ways as well, depending on the OS.

  Why isn't there a defense system against ARP poisoning?

There is, it is often called dynamic ARP inspection or DAI and it is present as a feature on many platforms. If you use an enterprise network solution, it is almost guaranteed to be there in some form; it becomes less common as you move down towards SOHO and consumer devices, but can still be found in some, often with simplified configuration and terminology (i.e. there may be a simple check box to enable a number of end point security features).

DAI often works in conjunction with features such as DHCP snooping (which helps to prevent rogue DHCP servers) and works by building a "binding" table between client IP and MAC addresses. If the information provided by an ARP packet doesn't match an entry in the binding table, it is discarded.


Getting an employer to secure their website immediately

There should be an entity responsible for security, such as an (chief) information security officer. It's a usually their job to take reports like yours and find the quickest way to solve the problem without compromising business. Giving it to the IT department often makes it a "support request without stakeholder" meaning you can still work so it's not that bad from their POV.

If you don't have that, you should write a friendly mail to management on the C-Level and inform them about the business risk that problems like this pose if they don't get attention right away. They can give that role of watching over these issues to an employee who is already working in the IT department so they don't necessarily need to hire someone.

Worked for me ;-)


Why is it bad to open ports to ip cams? How does a VPN fix this?

IP Cameras, like many IoT devices, were not built with security in mind. As the Mirai botnet showed us, many operate with insecure protocols (telnet) and have either hard coded credentials, or default credentials it does not force the user to change. Couple this with the fact that many will never receive a firmware update so long as they are online, and the replacement time on such a device can be up to 10 years and you've got a security nightmare in the works.

A VPN allows your cameras to operate behind your firewall, which means you are not directly exposing your cameras to the internet. You utilize the VPN to get "beyond" your firewall so you can access local resources, like the cameras in this instance.

Many cameras and other IoT devices also like to decide for themselves what ports to open and close, so for this reason I would also highly recommend disabling UPnP on your new router as well to further protect you from malice.


is the exit node now not the one seemingly responsible for any malicious activity?

Correct, the traffic appears to be coming from the exit node.

there is a real possibility (if not a probability) that traffic appearing to come from my IP was part of something totally illegitimate.

As a normal Tor user you are never an exit node. You are only a middle relay between other nodes. So all traffic from and to your IP is encrypted and your IP would never show up in any server logs of the clearnet.

Surely, at some point, in the history of Tor, somebody must have been contacted by law enforcement regarding traffic apparently originating from an IP they had?

Yes, that occasionally happens. But the Tor network keeps a history of all the IP addresses that were exit nodes at some point. For example, you can use ExoneraTor to check for a particular IP at a particular date. So law enforcement will be able to recognize that an IP involved in an illegal activity was a Tor exit node and searching their home would probably not make much sense (although it can still happen).
That's why the EFF discourages running an exit node from your home in the FAQ for relay operators:

Should I run an exit relay from my home?
No. If law enforcement becomes interested in traffic from your exit relay, it's possible that officers will seize your computer. For that reason, it's best not to run your exit relay in your home or using your home Internet connection.
Instead, consider running your exit relay in a commercial facility that is supportive of Tor. Have a separate IP address for your exit relay, and don't route your own traffic through it.


what does "HasSession" means in bloodhound tool

This corresponds to the "User-Hunter" Powerview script that finds admins who are authenticated to resources. Yes, I have confirmed that only RDP sessions are logged, and not PSExec or any other sessions, which is unfortunate, because those sessions are often just as valuable.

However, you can find SMB sessions using the PSLoggedon.exe Sysinternals tool. The Nmap script "smb-enum-sessions.nse" uses the same method and may also work.


Can you login to Facebook through a VPN or a proxy?

As far as I'm aware, Facebook don't actually block the new attempts from different IPs. Instead, they send an email to the registered email address with a notification that you logged into a new device, with a button to mark this as legitimate or malicious.

The tracking appears to work not only via your IP, but also a long-term identification cookie and other browser fingerprint data (e.g. user agent header) so that switching browsers or computers within the same network will still trigger it.


Benefits to using EV certificates with a privately hosted Certificate Authority

Extended Validation (EV) certificates exist to give the end-user greater assurance that the web site is who they say they are. This is because the enrolment process that is followed by the Certificate Authority (CA) has meet a minimum standard (http://www.cabforum.org/Guidelines_v1_3.pdf).

The actual certificate features are the same EV or no EV so the certificate itself provides no extra encryption or security technology. The only change to the certificate is that a Certificate Practice Statement (CPS) that is recognised by the browser as being EV. If the CPS object identifier (OID) matches a list of OIDs known to be EV and the normal certificate validation passes, green is displayed in the browser.

For an internal network, this should make no difference because the level of verification of the host and the requestor is normally the same. If it makes sense in your environment by all means do it, however if you are trying to increase security then implementing Online Certificate Status Protocol (OCSP - http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol) would be more helpful. OCSP is supported by Bluecoat, Windows 2008 R2 CAs and a range of other products.

Support for intercepting EV SSL certificates from a Bluecoat appliance works but the certificate seen by the user will not have a CPS attached to the certificate so it will not appear green in the browser.

Hope this helps.


Why do I see bridged devices when monitoring Wi-Fi activity?

In the absence of a technical answer about Kismet, I think your best bet is to run a packet capture. Although your ethernet devices might not broadcast, your network may be configured as an unswitched zone and every node can see every other node's traffic.

If you can see all that traffic on WiFi, then your answer isn't about Kismet at all, but about your network design. Try that first.


How to login and encrypt data with the same password/key

First of all, don't worry about the username.  The username is supposed to be public information — if it wasn't, it wouldn't be a username, it would be a password.  Just assume that an attacker will be able to find out the username(s) in any case, and design your system to be secure with that assumption.

Second, don't worry about the encryption (or hashing etc.) method being public, either.  That's Kerckhoff's principle — the encryption method should be treated as public, the only thing that needs to be secret should be the key (or password, in this case).

There are many good reasons for this, not the least being that it allows you to publish how the system works (and thus convince your users that it's secure, or to ask for help from security experts, or to just use an existing standard system designed and analyzed by such experts) without compromising its security.

Third, don't worry about the salt either.  The salt should also be treated as (potentially) public knowledge.  Its purpose is not to provide any additional secrecy, but to protect against attacks using precompiled hash tables by ensuring that every user's password is hashed in a different way, even if the actual passwords happen to be the same.

OK, so what should you do, then?

Well, first of all, you should use a secure key derivation function that implements key stretching (and salting, of course) to derive the user's encryption key from their password.  PBKDF2 should do nicely for that, although e.g. scrypt might be even better if you have it available.

Second, you obviously should not use the encryption key as the password hash.  In fact, you shouldn't store anything in your database that could be used to obtain the encryption key without knowing the password.  (For instance, the encryption key should not be a hash of the password hash.)

One thing you could do is derive both the encryption key and the password hash separately from the password using PBKDF2, but that would be kind of inefficient, since PBKDF2 is deliberately slow.  Instead, you could derive the encryption key from the password with PBKDF2, and then use a normal cryptographic hash (e.g. SHA-256) of the key as the password hash for logging in.  (Or, if you want to be extra careful, derive both the encryption key and the password hash from an intermediate key derived from the password using PBKDF2.)

Finally, to make changing the password easy, don't directly encrypt files with the user's encryption key.  Instead, for each file, create a random file key, encrypt the file with the file key and encrypt the file key with the user's encryption key.  That way, when the user wants to change their password, you only need to re-encrypt the file keys.


Remote extraction of passwords from browser password managers

Concept of "origin"

The "same origin policy" can only be as robust as the definition of an origin is. The origin is the entity the browser believes it talks to.

Quoting the paper:

  Next, by tampering with network traffic the attacker (...)

The idea that you can modify at least some server answers makes the origin of these vulnerable requests meaningless for security: if tampering is possible at all, it means that some (formal) "origins" don't correspond to the entity the browser is actually talking to; instead the browser is talking to the attacker, while believing it's talking to the legitimate HTTP server.

Without at least integrity of exchanged data (let's put privacy aside for a moment), you don't even have an origin.

(Of course without secrecy of the exchanged data, your password might be captured by an attacker when you log, so both integrity and secrecy matter.)

Note: These security properties doesn't have to come from robust cryptography, you could also log on a server on localhost with clear text HTTP. The OS will prevent the interception of the data on the TCP socket that uses only local routing.

If you don't have a well defined robust origin, you can't expect any protection from the browser mechanisms based on the origin.

When dealing with a remote server, with HTTP, and without lower level protections like IPsec or a secure tunnel protocol to the server, your data is vulnerable and "origin" is ill defined.

The most common vulnerable situation is using http: URLs on an open Wifi, but using the same URLs via a commercial "VPN" also exposes you, but not to the same party: using Wifi exposes you to local attacker (mostly an attack from the owner of the Wifi access point, but not only); using a "VPN" service exposes you to the manager of that service (who can spy on you).

Sound design of public websites (not private tools on an intranet) that deal with private information require the use of HTTPS. The paper insists on the fact that this is far from universal (at least when the study was done):

  It is especially easy for sites that serve their login page over HTTP
  (but submit passwords over HTTPS), which is a common setup discussed
  in the next section.

Hosting a "secure" form (one that sends data on a secure URL) on an insecure page is fundamentally, absolutely, definitely unsound. All webmasters should know that. Sadly it isn't the case as understanding of even the most basic facts of the security model isn't required from people who design websites.

Any HTTP request over the Internet is exposed to spying and tampering. Many ignorant Web page designers believe that "secure transport" (HTTPS, TLS) is only for secret data and is a significant and useless overhead for inherently non secret data, like the content of a login form (anyone can see the same login form).

And because they misunderstand the scope of "secure transport" they might put pages that inherently cannot contain private information on an insecure http: URL, making these vulnerable to tampering (and also spying on the who downloads that login page, but that one isn't usually a real concern).

The idea that "https:" URLs only exist for secrecy of informations exposed on a particular page, and the others can be in "http:" must die.

Sub-resources

Also don't forget that any Web page which includes any element that is allowed to contain Javascript code that runs in the context of the page is vulnerable to tampering, so this isn't limited to tampering with the HTTP content of main URL shown in the browser address bar; making HTTPS pages that include JS scripts or even CSS content loaded via HTTP is fundamentally unsound and modern browsers rightly refuse to load these insecure elements by default.

Special permissions for websites

You can't associate a meaningful "privileges" (or permissions) to an "origin" (like the right to access your webcam or your gyroscope) if the origin is insecure and can be usurped by an attacker with network access. That's why modern browsers restrict the permissions that an insecure origin can ask (or limit these privileges in time).

Human factor

It should be understood that these concepts aren't advanced or reserved for security professionals: they should be part of the basic common knowledge of at least all Web designers, and if possible of all users. It should be considered as elementary and obvious as "you don't start a car when the windshield is obstructed by an anti sun anti heat cover".

I didn't want to discuss psychology but there is a strong human factor that I want discuss here because that's what I see as one common reason for failure to take basic security measures.

One practical problem with computers and people is the often dismissive attitude that people who don't have even elementary knowledge have with respect to such knowledge; they often say that "they aren't experts, don't want to be, don't have the time to learn a lot" and "just want to get a job done" (probably as opposed to purists?) - as if more knowledgeable users were just pedants who wanted to have encyclopedic knowledge of computers, had unlimited time, or would want to get nothing done ever but in the most pure and elegant way. I know some people who have encyclopedic knowledge and allocate a lot of time to learn more, but they also want to get some task done (if only: to get to learn even more, which is a task).

Nobody wants nothing done ever, but that "nothing" done in the "purest" way. That's an oxymoron as getting anything done in the purest and most beautiful way would actually get something done and over. The frankly insulting undertone of these remarks is why some people never learn and why other give up on explaining how to properly use a computer to others (that is, to use it to something done).

Like any activity, using a computer for anything, including something as common as setting up a website, requires at least understanding of some basics. But when dealing with computers, almost nothing is really intuitive and we need to explain stuff without sounding pedantic.

Also for websites with millions of users, we need name and shame. Designing a website that doesn't even respect the most basic security principles should be seen as equally inane as driving with the windshield entirely obstructed, and pointing out the inanity of that conduct shouldn't be seen as pedantic.


Truncating the output of SHA256 to 128 bits

Though SHA-256 nominally offers a 256-bit output, no weakness about it is known when the output is truncated to 128 bits, except, of course, weaknesses inherent to the shorter output length; e.g. collision resistance drops from the infeasible 2128 to the possible (but hard) 264.

This is not a generic property of hash functions(*), but it is somewhat "obvious" from how SHA-256 is defined. In particular, when NIST defined SHA-224, a hash function with a 224-bit output, they merely took SHA-256, with a distinct initialization vector, and a truncated output.

(*) It can be shown that a given secure hash function, when truncated, cannot be awfully bad, but it can still be slightly worse than expected. For SHA-256, truncation seems safe.


Smart Lightbulb Using Common IRC port found in NMAP - anything to worry about?

Nothing serious to worry about from the data provided. It might be how it talks to a control station or receives commands. I'd run a packet capture on it to investigate further. I'd also want to run some IRC commands.

It does appear that it's unencrypted. But the risks on an unencrypted line of commands to a light bulb might be very low.

Is it "face-palm-worthy"? Oh yes. Is it a major security issue? Not from the data you provided, but I'd still want to see that packet capture to know more.

There is a possibility that IRC functionality means that there is a Linux server in the bulb, which means that an attacker might be able to log in, install things, and keep connection to the network in your home. But these things would have to be confirmed.

This is a reason why it is recommended that you place IoT devices on their own network. It segments off weird stuff like this away from your user computer devices.


Way to properly escape user input which gets run by shell_exec() in PHP?

The function escapeshellarg safely quotes a value (including escaping quotes in the name, etc) so that it can be used as an argument in a command string passed to a shell.

$user_input = $_POST['user_input'];
shell_exec('php some_file.php '.escapeshellarg($user_input));


Evaluation of cryptosystem for authentication and keyexchange

You say this:

  one requirement in the audit is dual layer of security on all channels

and that says it all. Your auditors don't understand how cryptography or even security actually works. If they were physicians, they would double doses for all medicines; when they transplant a kidney they would try to hook an extra kidney; when they have to cut off a leg they would remove the other one as well, just to be sure.

Given that the audit is going to be done under such irrational auspices, the best you can hope for is to do something which formally complies to the "dual layer" ritual, but is otherwise harmless enough. This would point at encapsulating two SSL: within a SSL tunnel, just run another one (with distinct algorithms, so that the auditors don't notice how ridicule they are). If you really want to overawe them, use another library for the inner SSL, e.g. OpenSSL on the outside and GnuTLS within.

Making your own implementation of an existing protocol is fraught with perils; designing your own protocol even more so. Don't do it if you can avoid it. Reusing existing protocols and existing implementations will save you a lot of time and yield much fewer vulnerabilities.


but I was just wondering if there actually is a password for it?

Yes. SSH uses your system users (that's the whole idea of it, to allow users to remotely access a systems account), so there is a password for it (stored in /etc/shadow)

  If there is one, is it possible to just disable it?

Yes. You can (and should, as you are not using your password as you don't even know it) set PasswordAuthentication no in your SSH config file (/etc/ssh/ssh_config for global, ~/.ssh/config for user specific config). Afterwards you need to restart SSH for it to take affect (sudo /etc/init.d/ssh restart)


Startup PIN security considerations for BitLocker

In all cases where multiple components are used for BitLocker, there is the possibility of them all being required, and this tends to be the default. This means that combinations of TPM and PIN or TPM and physical key contribute to the composite key used to protect the drive encryption key.

Therefore, unless you specified otherwise (there is a possibility for having just TPM while domain joined, and TPM+PIN if disconnected), you would need either both the TPM and the PIN to be provided, or the full recovery key to be provided, to be able to decrypt the drive. Each of these allows for the decryption of the drive encryption key, which is then used to decrypt the actual data on the drive.


It might depend on your definition of "thin client".

The thin clients I know download just enough from the server to do their job, and that includes things like programs. As such, they will download the installed AV package from the server. In this way, the thin client itself doesn't need one, because it "borrows" it from the server.

If the server that serves the thin clients does not have AV, then you've got a problem.


What was the security vulnerability behind Box and Dropbox and what's different now?

The referer header is a HTTP request header that is sent by the browser whenever you navigate to a different page - the URL of the page that contained the link you clicked is sent to the new page within this header (even if it is a different domain).
The referer isn't sent if you type in a URL, and it is not sent by most browsers if your current page is protected by TLS (https://).
This page can be used to find out if you referer is leaked to it, but this of course will depend on where you link to it from.
The Dropbox vulnerability is when a file is shared via the web and a public URL is generated. This URL is in the form https://www.example.com/s/123456qwerty/file.htm, where 123456qwerty appears to be a randomly generated token.
Normally these links only present a download link to the file, but you can modify the URL from https://www.dropbox.com/s/... to https://dl.dropbox.com/s/... which will then become https://dl.dropboxusercontent.com/s/... and would present the HTML file as being served from this domain. Also, the protocol can be changed to http which would disable the protection of the referer normally enabled by using the https protocol.
If you share this dl link with somebody, and the HTML file contains links to 3rd parties, the referer could be sent to the third party when links are clicked, exposing your private share URL with the third party. They would be able to view the referer header in their server logs or site analytics reports. This has also caused a second problem when users enter the generated links in a search engine instead of the browser's address bar, as when ads are displayed the PPC report to the advertiser shows the search term that was used, which happens to be the "private" URL to the file.
I'm not sure what the official fix is, bar the temporary deactivation of some shared links (although I haven't been notified of any disabled on my account). Computer Weekly reports:-

Dropbox has now disabled access to links that have been previously shared and implemented a patch to prevent shared links from being exposed from now on.

Possible fixes to this issue could include:

Parsing of the page to change links such as http://www.example.com to use a service such as https://href.li so the link becomes https://href.li/?http://example.com/ (or more probably, Dropbox's implementation of such a service). This won't work with more complicated links, such as those generated or redirected by JavaScript.
Parsing of the page to change links to use the HTML 5 noreferrer tag. This won't work with more complicated links, such as those generated or redirected by JavaScript.
Force HTTPS for all shared HTML pages. This won't work on all browsers.
Make HTML pages downloadable only instead of displayed inline - this could break some user setups though if they are using Dropbox as a static file server rather than simply sharing.
An auth cookie generated when a shared link is followed by the original recipient. This would set the cookie and then redirect to a new URL. e.g. https://www.example.com/s/123456qwerty/file.htm sets the cookie then redirects to https://www.example.com/s/auth/zxcvbn76543/file.htm which is only accessible if the auth cookie is present. This would make any leaked referer data useless as the URL can only be used in combination with the cookie. This would break any bookmarking of the shared links though, unless the original link was saved manually.
Setting a referrer-policy header to prevent the referer from being leaked in supported browsers.

You could test the final fix (whatever that may be) by this linking to a site from a shared Dropbox HTML file, checking the referer and finding out if you get the same result as the hidden version. At the moment of writing, these are still being sent by my Dropbox shared HTML page when accessed over http.
Update

The next paragraph in their statement says that they have patched the vulnerability. How was this done? It looks like if someone managed to get ahold of your shared link, they're still going to have full access to it. At least, when I created new links to my shared folder, I didn't see anything different.

Only recently have Dropbox added Passwords for Shared Links and Shared Link Expiration to their Pro accounts only.

If you’re a Dropbox Pro or Dropbox for Business user, you can set a password for any shared link that you create. This helps to ensure that only collaborators with the password can access your shared content.
If you’re a Dropbox Pro or Dropbox for Business user, you can set an expiration for any shared link that you create. This enables you to provide temporary access to content that you want to share.

These two features help resolve the vulnerability of files being accessible due to referer or PPC reports.
Update 2
As per https://www.dropbox.com/help/files-folders/public-folder:

As of September 1, 2017 public links have been disabled for all users.


Security of Bluetooth Low Energy (BLE) link-layer encryption

The attack actually works. I've been playing with the Ubertooth One that I acquired at DEF CON five years ago and have tested it against a variety of IoT devices that implement the BLE standard. Mike Ryan's paper is correct.

From the book, "Abusing the Internet of Things", the author discusses Mike Ryan's work and the implementation with the Ubertooth One.

ubertooth-btle -f -c ble.pcap

The author also discusses using the LightBlue iOS app for further troubleshooting, as it can copy Bluetooth devices and emulate them. It takes some work with BLE because it uses many channels, so turning the interfaces on and off during the network capture assessment is highly recommended.

Standard BLE encrypted data uses a key-exchange protocol by selecting an AES-based temporary key (TK). Mike Ryan released the crackle tool to brute force this key.

crackle -i ble.pcap -o decrypted-ble.pcap

This technique is not effective against OOB (128-bit optional key also defined by BLE) mode, however, as seen on the ubertooth mailing list, the development team is working to gather samples and troubleshoot the possibilities of breaking OOB mode.

A well-known blog on payment technologies and associated infrastructure has also been speculating on the demise of Bluetooth security, including some comments about breaking BLE OOB mode. 12/29/15 update: There is more discussion about BT 2.1. Also came across btproxy, which will hopefully support BTLE soon. Another tutorial I came across is entitled Sniffing and Cracking Bluetooth with the UbertoothOne.

However, (as seen in the book, "Hacking Exposed Wireless, 3rd Edition") the idea of repairing Bluetooth was first publicized in the paper “Cracking the Bluetooth PIN” by Yaniv Shaked and Avishai Wool (http://www.eng.tau.ac.il/~yash/shaked-wool-mobisys05). An adversary can use a “repairing attack” to manipulate the stored pairing status between two devices by impersonating the BD_ADDR of one of the two devices.

The tool bdaddr is the primary implementation of this technique.

gcc -obdaddr -lbluetooth bdaddr.c
hciconfig hci0
sudo bdaddr -i hci0 <new bdaddr>
(asks to reset device now)
sudo bccmd -d hci0 warmreset
(check that it changed)
hciconfig hci0
sudo hcitool cc <bdaddr of target to repair to>
sudo hcitool enc <bdaddr target again> enable

To return back to a clean slate

sudo bccmd -d hci0 coldreset
hciconfig hci0


Why do I need a certificate to pin an SSL connection with AF Networking 2?

It is specifically because you are doing pinning.  This would allow it to work regardless of if you had a self-signed certificate or a CA signed one.  Basically, you are including the certificate with the application and telling the application specifically "this certificate is valid".

While this does prevent connecting to a different certificate and should allow for use of a self-signed cert, it also complicates revocation of a certificate quite severely since the application would actually have to be updated before you could update the server side certificate.

Personally, I'd avoid using a library that required this.  Even if you wanted to do a self-signed certificate, the better way to do it is to setup your own CA and tell the application to trust the CA root certificate.  Then you can still do normal revocation and change the certificate.

The library you are working with may or may not support this, but that part would be a programing question rather than a security one.


Digital signatures do not create trust; they just move it around and concentrate it. You are right: if you distribute the public key with the package, you have gained nothing.

What digital signatures give you is the ability to handle your trust separately. You still have to find a way for verifiers (the "desktop applications") to make sure that a given public key is indeed the right public key from the authentic signer. But a public key is somewhat shorter (typically a few hundred bytes), can be shared (you can sign several blobs with the same key), and can be distributed in advance (you can "give" the public key to the verifiers before signing the blobs -- even before knowing how many blobs you will ultimately sign).

Public key is not the only source of trust. Indeed, the code within the application which uses the public key to verify signatures on data blobs must also be part of the "trusted realm"; if an attacker can alter that code, he can replace the verification code with something which just always says "that signature is good". Come to that, he could also plant a virus or a keylogger in the application. So not only you have to start trust somewhere, but the problem is not exactly new either.

Therefore we may assume that you already solved the issue of making sure that when a user gets the application on his desktop system, he gets the "right one" and not a maliciously modified variant. There are several ways (e.g. Web distribution through HTTPS; or installation performed on-site by your personal). This leads us to the following solution: embed the public key within the application itself.

Operating System vendors have done that for years, to enable safe system updates. When a Windows decides that it must download and install an update, it actually verifies a digital signature on the update blob before applying it, and it does so relatively to a public key which is already embedded in the Windows code.

(The system can be made more complex with certificates if you want to support key rollover without a software update.)


How Should a Midsized Startup Approach Information Security and Compliance?

First, if you are not PCI-DSS compliant and you are processing payment information, drop everything and address this first. If you address this in a robust way, then you can leverage the compliance activities to build a larger information security infrastructure for your organisation. This is your first gap!

I have been where you are.

Although a Risk Assessment is normally where organisations should start (and you should do one!), my guess is that it will only be a distraction for you at your stage of development. You have a more immediate task at hand.

You should not be seeing PCI-DSS as a threat but an opportunity to embrace. You need to embrace PCI-DSS and (SOC 2) as a tool to define what you should be doing and the infrastructure you need to be compliant. Do not "skimp" on this step, but take it on as a regulatory requirement to meet head-on and to fully satisfy.

This activity exists apart from risk as something that "just needs to get done". Focusing on this at the start removes the debates and the political tensions. Both PCI-DSS and SOC 2 require external auditors and expert guidance. Spend your time and money on these things, to start.

It would be even better (for secure processes and risk) if you used the ISO 27001 and/or NIST frameworks to design an approach first for which the PCI-DSS and SOC 2 can have a place, but this is simply not efficient for small companies, and not where the immediate value can be found. If you can do the first steps well and gain success and value, you will have an easier time getting the bigger stuff done.

I'm a fan of "Agile" security: get your entire needs mapped out as you understand them right now, but tackle the critical areas first (in the light of the coming needs). For you, you have technical security issues to address first (PCI-DSS). Design the approaches to address those needs in the light of a larger framework, but address those needs first! Then build iteratively from there.


Can I read the domain name from HTTPS before SSL handshake?

Yes, as long as the server and the clients support the Server-Name-Indication (or SNI) extension.   This extension allows for virtual hosting for HTTPS, where you have multiple independent domains and certifications bound to a single IP address.

Most clients these days do support SNI.  The place where you might have issues is if you have older clients using platforms like Windows XP, old versions of Android, or Java 6.


Reusing the same ssh host key on multiple servers is a security risk. If one server is compromised, the attacker can intercept all connections to your servers.

If the servers are administrated by another person, you should ask this person over a trused channel.
Trusted channels are:

Website with HTPPS and a valid certificate. for example github has published the fingerprints on their website: https://docs.github.com/en/github/authenticating-to-github/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints)
telephone
Messanger (signal, whatsapp, ...)

If you own the server you can use a local terminal. On a virtual machine, you can use the management interface to open such a terminal. Physical machines (bare matel) server should have some remote management devices like KVM Switches or built in the bios/uefi.
By default OpenSSH stores the keys in /etc/ssh.
Follwing command calculates the SHA256 hash:
for file in /etc/ssh/*.pub; do   ssh-keygen -lf $file; done

Older implementations of openssh generates MD5 fingerprints
for file in /etc/ssh/*.pub; do   ssh-keygen -lf $file -E md5; done

You have multiple keys with different algorithms. Depending on your server and your client, one of those keys are used.
Now you can compare the shown fingerprint from the client with the the calculated fingerprints.


How to handle CSRF protection in a single page application?

You can use the classic CSRF token strategies, but they can take some awkward effort to use in AJAX-based applications, and easier options are available for AJAX-specific endpoints:

Add an extra header to requests to your server like "X-Requested-With: XMLHttpRequest" or "X-Is-Local-XHR: true", and make your server require the header on authenticated requests. Users with old versions of Flash may be vulnerable (though old versions of Flash have had much worse vulnerabilities too, so your choice on whether this is important to you). See https://stackoverflow.com/questions/17478731/whats-the-point-of-the-x-requested-with-header
Verify either the Origin or Referer header is set and matches the domain in the Host header. The Origin header is sent for all POST requests by Chrome and Firefox but older browsers may not include it. The Referer header is disabled by some users for privacy reasons. The presence of either with a valid value is enough to verify the request.


Should a vulnerability in a service that is present on the device, but not running and not used at all, be mentioned in the vulnerability report?

It depends on how your organization uses these kind of reports.

If the people responsible for planning and/or implementing security controls read these documents once and then never look at them again OR see them more as a guideline than actual rules on how to set up an environment, I can see that you might want to refrain from adding too much information into the report. Just because you want to make sure that the vulnerabilites that are acutally present are met with saftey measures.

On the other hand if these are "living" documents that set rules on how controls have to be planned and implemented AND the people who are responsible update these documents if the infrastructure changes at a certain point, you definitely want to include these vulnerabilites.

IMHO as someone who organizes information security in an institution this is the kind of culture you should push for.

If you are afraid that your document will become too cluttered, you can always work with its structure. Something that was done in an organization I worked with, was, that vulnerabilites like this or possible future vulnerabilities were added in an annex to the main document. If the infrastructure was changed in any way, admins could check the annex first, if any of the changes would bring in the vulnerabilities listed there.

One last point I would like to make: although YOU didn't enable those features, this doesn't mean an attacker won't do it after he/she got access to the router. So implementing security measures just in case can be reasonable. This might be something that should be evaluated in a risk analysis though.

To quote ISO/IEC 27005:

  The presence of a vulnerability does not cause harm in itself, as
  there needs to be a threat present to exploit it. A vulnerability that
  has no corresponding threat may not require the implementation of a
  control, but should be recognized and monitored for changes.


Is rsyncd secure? (except for the lack of transport encryption)

It looks like you are backing up to a host on your private network (192.168.x.x).  Without any encryption being used with the rsync command, whoever controls the network may be able to 'listen in' on the transfer.  Or, they may even be able to impersonate the host that you are backing up to, so that you send all your files to the malicious host.  Even someone who does not control the network may be able to impersonate the host that you are backing up to, by mounting an ARP poisoning attack.
If you control the private network, then perhaps these types of attacks may be less likely.  But, these threats should be taken seriously if you are backing up over the public internet, where DNS poisoning attacks, MITM attacks, and the like, are quite real.
This why rsync is often run over some type of encrypted tunnel.  Perhaps the most common way to do this is to use an ssh tunnel.  This can be done easily using the -e option, like so:
rsync -e ssh

I generally use a command similar to the following:
rsync -az -e ssh /path/to/source/directory/on/local/host/ user@remotehost.tld:/path/to/destincation/directory/on/remote/host/

This will run rsync over an ssh tunnel to the remote host.  On the remote host, you just need to have an ssh server running.  Authentication can be handled using key-based ssh authentication to avoid having to hard-code a password.
In addition to the benefit of the transfer taking place over the encrypted ssh tunnel - you also benefit from ssh key-pinning in ssh.  If someone tries to MITM the connection or spoof the host (e.g. by way of a DNS poisoning attack), ssh will detect the attack because it will not recognize the public key of the malicious host.


How to configure iptables for must open ports?

Set the default policy to deny everything. (iptables -P INPUT DENY)
Allow ICMP
Add the minimum rulesets required for the services you need.

If you've got ports that are used only by local machines, set allow rules for that combination of port and IP range only.

iptables -A INPUT -p tcp --dport 80 -s 192.168.1.0/24 -j ACCEPT

Outbound traffic needs rules as well (permit DNS queries, permit services to respond to connections, etc). Using related / established rules can help with this. Even among otherwise locked-down firewalls, allowing all outbound traffic for simplicity is common.

If you've got the time, an ideal albeit laborious case would be using SELinux to restrict things even further such as by only allowing the DNS resolver libraries to query DNS, etc.

As for "protecting an open port" that comes down to configuring the software listening to it correctly and ensuring any security issues within it are addressed.


limiting automated domain creation by malware

I'm not sure you've quite understood how DGA implementing malware works. It doesn't actually register the domain names - it just generates them, and attempts to contact a subset of them.

The malware author can generate the same list, and pick one or two to register, and then the malware may connect to the registered ones in attempted to update - this usually isn't a certainty. For example, according to Wikipedia, Conficker.c generated 50,000 domain names per day, then attempted to access 500 of these (e.g. 1%), looking for a specific response. The malware author would only need to register 1 of those 500 to be able to update, which wouldn't be arduous, even with a OTP scheme as suggested.

This wouldn't give any certainty that a given instance of the malware would be updated on a given day, but given a long enough infection period, and a widely spread malware distribution, enough instances are likely to be updated to continue to cause problems.

What could be feasible would be for a domain registrar to prevent registration of any domain generated within known malware. However, this would probably encourage malware authors to adopt different techniques - perhaps by checking whether a domain can be registered, and activating if not.


Are two anti-virus better than one in protecting your computer?

Most anti-virus vendors advise not to use their products together with those from others. That's not (just) because they fear competition. Live virus-scanners scan files on access. When they notice that a process accesses a file, they try to access it before the process to scan it. They even try to do that when that process is another virus-scanner.

When you have two live-scanners on a system, both will try to be the first to open a file. When virus scanner A detects that scanner B opens a file, A will try to access it first to protect B from any viruses in it. B will register this attempt to read the file, and in turn will try to scan it before A does. The result is that both virus scanners are caught in an infinite loop.

This problem, however, only applies to live-scanners. When you use on-demand scanners which don't monitor file access and only scan a filesystem when they are prompted to do so, you can use multiple of them one after another.


Yes. And no.

One-time-pads are provably uncrackable because every solution is equally probable. They're also totally useless in all but a few cases.

RSA and AES are so different as to not really be comparable. RSA relies on the difficulty of certain computations, while AES doesn't use math in the traditional sense. It scrambles the bits very directly, so the best attack we have is a direct brute-force on the key itself. An "ideal" attack would involve finding a weakness in the way the bits were scrambled, such that you could find some statistical bias that could be exploited. But that's not math in the sense of factoring primes. You're not attacking the problem head on, you're looking for subtle mistakes.

Even DES, the first "strong" cipher we've ever had, is unbroken in the sense that the easiest attack is a brute-force one. It's just crippled by the fact that the key size makes brute-force relatively easy.

Finding a form of "unbreakable" symmetric encryption isn't really the problem.


I'd recommend getting a host based IDS configured and the signature database populated, removing any content supplied with Apache. Also overhawling the permissions model around logging so that you don't need to be root to read the files.

There's also several things you might want to do depending on what you do with the server - check the timeout and max post size for apache, set an open_basedir for PHP (along with the usual performance tweaks).


How to technically introduce my boss to computer file security?

... but I lack the technical arguments why ...

With such a position it is likely hard to convince your boss. And your boss is even probably right when arguing that what you want is weakening the security.
Digitally sharing data is usually not done because it is more secure, but because it is more convenient, allows faster work and collaboration etc. It is done because it reduces costs and increases efficiency. For a company it thus affects on how competitive the company can be in the market.
It thus provides new chances, but it definitely adds significant risks too. And these risks are not so much that the provider (Google, Dropbox, ...) might steal the data, but that it is more likely for employees to accidentally share data or even full access to many critical data with the wrong ones, for example when they fell for credential phishing. It also means a new dependency on getting the digital infrastructure working against threats like ransomware or even simple hardware failures. Sufficiently understanding and also addressing these new risks is not trivial.
Thus the arguments should likely focus on the business value, i.e. how much more efficient the work can be done and how much more competitive the company can be. And that these chances outweigh the risks. But if this is really true in your specific environment and how you can prove this is up to you, since this is specific to your environment.


Detecting the use of a valid but somehow compromised certificate is hard:

If the target site has their private keys stolen and did not realize it yet then the attacker to spoof the site perfectly, i.e. the client will not realize the difference to the original site.
If the site has it's private key stolen and realized it then it should revoke the certificate. In theory the browser will check if the certificate was revoked and refuse to connect in this case. But in practice this check cannot really relied on except in special cases (like EV certificates or sites deemed important by the browser vendor) since browsers either don't to an revocation check with OCSP at all or will ignore errors during the check - where such errors might be caused by the attacker.
If an attacker managed to get a publicly trusted certificate for the site  (for example by taking over the sites DNS long enough to get such a certificate, see recent issue with Fox-IT) it is also hard for the client to detect this as a problem since using a new certificate might actually be valid. Projects like Convergence might help in this case because they allow to detect if other users see a different certificate for the same site. Also, certificate pinning (HPKP) used by the site itself might help.

Since detecting the use the bad certificate is impossible in many cases this leaves only detecting the DNS spoofing:

IP monitoring like you suggested might help to detect if the attacker is using a target IP very different from the one usually used by the original site. Note that this does not help against ARP spoofing in local networks or internet wide BGP redirects since the target IP is not necessarily changed in this case - only rerouted.
If the site supports DNSSec it should be used to verify what the real IP is. Of course this only helps against local spoofing and not if the primary DNS server for the domain was hacked.
If the target does not employ DNSSec it might be useful to ask a DNS server which is not affected by the (local) DNS spoofing. For example one might use DNS over HTTPS so that the attacker is not able to spoof these DNS answers too. An attacker might of course try to make these sites unavailable for you in the hope that you fall back to the locally spoofed DNS.


Should an administrator be able to turn off TFA for a user

Should we allow the administrators of the site to turn off TFA for users?

This is a very interesting question. I suspect the answer very much depends on the individual site's risk assessment. Let's look at some pros and cons of allowing the administrator to turn off 2FA for an individual user.

Pros

Convenient for the user if he loses access to his authentication token.

Cons

Subject  to phishing attacks. An attacker could call/email the customer service representative and pretend to be the user asking them to turn off the 2FA. You might think your customer service representatives are smarter than that but you will be surprised. Mat Honan is living proof that this is a very real threat.

However, there might be a legitimate use case in which the user has lost access to his authentication token and needs it to be reset somehow. I would make the user go through the same process as he would need to when resetting his password. This could involve emailing him a link to trigger to process or something similar. The idea here is to make it as difficult for an attacker as possible to do this as he will need to compromise the user's email account as well.


Decrypting SSL traffic for Security Onion at or before the interface

To set up general TLS decryption Security Onion will need to have a certificate trusted by your endpoints.  Usually this certificate has a CN of * so it can sign anything.

So you'd generate a TLS keypair for encryption.  Its cerificate will need to be added to your root store either on your ActiveDirectory Domain Controllers, some other central store for other systems, or in the individual endpoints.  This keypair will allow Security Onion to act as a TLS proxy yet still be able to be trusted by endpoints.

The firewall cert is unrelated as TLS is end-to-end encryption where the server has the private key and no one else.  TLS decryption subverts this by introducing a proxy that can decrypt, inspect, and re-encrypt TLS traffic.  This only works if the certificate used for re-encryption is trusted by the endpoints.  It is a controlled MitM.

CAUTION: This is very dangerous if done improperly since it can enable malicious MitM if the keypair is stolen.


Is .NET XmlSerializer.Deserialize(TextReader) safe?

Took a peek into the XmlSerializer.Deserialize code

XmlSerializer.Deserialize(TextReader) internally calls the other override - XmlSerializer.Deserialize(XmlTextReader) with XmlResolver set to null, so it should be safe from XXE attacks, however if do you want to disable dtd processing altogether, below should be used instead.

var xmlTextReader = new XmlTextReader(xmlInput) { DtdProcessing = DtdProcessing.Ignore/Prohibit };
xmlSerializer.Deserialize(xmlTextReader);

However, I don't see any benefit in disabling DTD processing altogether(especially when it could potentially impact your time tested code). From my understanding, there are only two xml attacks - XXE & XmlBomb.

As previously mentioned, XXE should not be possible because XmlResolver is set to null.

XmlBomb should also be not possible because MaxCharactersFromEntities is set to a limited value instead of 0(0 means no limit).
If you do try this attack, you'll face an exception saying - "The input document has exceeded a limit set by MaxCharactersFromEntities." instead of having the application crash or have a DoS attack.


Can Bluetooth "headphones" be malicious?

Yes. I heard of pieces of art with passive antennae in it, and a pair of earphones is just a small computer so that could easily do anything a computer can: run exploits against your Bluetooth/WiFi controller or software, attack WiFi networks in the neighbourhood, indeed grab your contacts or try to initiate file transfers with malware, record with a hidden microphone and send audio via mobile data, GPS tracking... heck, it could record and transmit some low bandwidth data via some Bluetooth side-channel. Theoretically.

Practically, I never heard of such a thing. Which would be exactly why the secret services might do it: nobody suspects anything. But that doesn't mean it's likely. Things like mobile data connections would be measurable and the chips, if you know what to look for, probably identifiable. Attacking WiFi/Bluetooth is definitely visible in packet captures. GPS tracking also requires a data connection such that the attacker can actually receive the data (live, at least; recording is always an option).

Unless you have reason to suspect otherwise, this is probably not a pair of trojan headphones.


While this system may be functional and may deter the inexperienced and slow down others, this is ultimately not an effective defense.

The problem lies with the fact that the private key is embedded in the device, and the customer who has purchased said device has unrestricted physical access to it. Communicating with debug interfaces, taking memory dumps, shelling the device etc. may allow the private key and/or the proprietary software to be recovered. The ease of this may depend on the design of the device's hardware and software, but it is likely beaten with enough time and effort in any case.

In short, once someone else has possession of the device, you can't expect confidentiality of anything stored on or processed by it.


How to safely mirror network traffic for audit reasons?

In theory your solution should work just fine at a basic level with a caveat. You'll need to find a hub that works at the speed of your Internet connection or greater.  Depending on the speed of your Internet connection that might be tricky, especially has hubs are getting harder to find.

I guess a question is why you don't trust dedicated port mirroring hardware, as that would be the standard way of doing this.  Either setting a port on a switch to be mirrored, or using a network tap


I think you are asking the wrong question. Consider the following:

If you fix fewer vulnerabilities than emerge between scans, then the number of vulnerabilities will only go up (10 vulns - 3 fixes + 4 new vulns = 11)
If you do not fix all vulnerabilities, you will never get to 0
Scans can have false positives that you need to verify
Some vulnerabilities you might never fix or choose not to fix

So, the relevant question is "why is the number not going down the way you like?"

"Industry averages for vulnerabilities per asset" is impossible and a little silly. Printers, Windows 10, Windows XP, and Linux, for example, are a vastly complex set of assets that you cannot compare to each other. Strictly speaking, if the scanner's results are not false positives, you should get the vulnerabilities down to 0.

BUT

Are the existing vulnerabilities a problem for you? Just because the scanner reports something does not mean that it needs to be fixed. The vulnerabilities might not apply to the asset in the context you have it in. That's why a risk-based approach to assessing the vulnerabilities is required.

For example, I have organisations that are running Windows XP on business-critical systems. We can't change them. Scanners light up like a Christmas tree when they scan them. But the vulnerabilities cannot be "fixed". We put in other mitigations to protect the organisation. The "vulnerability" metrics will never change for those systems, but we also have accepted that reality.

In short, don't look to "industry benchmarks". You need to set the benchmark that makes sense for your organisation, based on risk, context, and your ability to resolve vulnerabilities.


Does backing up WhatsApp on Google Drive expose messages?

You're confusing message integrity and security with secrecy. WhatsApp provides end to end encryption, meaning the message you send can only be read by the recipient and vice versa. This protects you from third parties trying to eavesdrop on your conversation, and even prevents WhatsApp themselves from reading the messages. You can't demand WhatsApp to allow you to wiretap a conversation if WhatsApp themselves have no idea what's being sent.

However once the message is in the hands of the recipient, it's a different story. In order for it to appear in their chat history, it has to be saved on the phone. If a persons device is compromised, so is your chat history with that person. The person could also screenshot your conversation, or even use another phone to take a picture of your conversation. Backup to Google Drive is simply a way of backing up your chat history so if you change devices or reset your phone all your messages aren't gone.

Once the conversation is in Google Drive however, if a valid law enforcement request is made for your files, your conversation is now compromised, as Google only provides server side encryption, which allows them to decrypt your files. This even opens you up to further compromise if the recipients Google account was ever hacked, as the hackers would have access to your message history with that person.

In short, no, the warning is accurate. It's not ambiguous, it tells you exactly what it means, if you save the messages to Google Drive, anyone with access to that account can retrieve the messages. This all boils down to the level of trust you have in your recipient. If you're not 100% sure that the person you're talking to isn't going to rat you out, best not to voice your dissent of your government to them.


Penetration test limitations with a virtual machine

In my opinion performing a penetration test from a virtual machine is actually the preferred way of doing it from opsec perspective (i.e. to maintain separation between your clients' data).

Limitations may arise from the fact that you can't access the underlying hardware directly, in particular:

Wired network interfaces: some host operating systems (e.g. OSX) will continue using the wired network even if you explicitly disable it in host OS and bridge the virtual machine to it. From the network perspective that means two separate MAC addresses on the same port, which sometimes triggers the NAC.
Wireless interfaces: most hypervisors don't emulate wireless devices at all
GPU: if you want to use something like oclhashcat for password cracking, you need direct access to the GPU

That being said most of these problems can be solved by dedicating the necessary hardware to the VM (e.g. PCI or USB passthrough).


Are SMS,MMS stored on the network service providers' servers?

The telecommunications service provider (your cell phone company) has to transmit the SMS and MMS messages to their recipients; so yes, the provider has to store them, however briefly.

Most providers retain messages for varying, not-so-brief, periods of time.

Search [sms carrier retention period].


I think Meterpreter Bind Shells are what you want. They typically bind and listen on a specific port on the remote target, so no port forwarding is needed on your side. However, the target must have the ports Meterpreter uses open to the Internet, not only Local Area Network. Read more about Bind Shells here.


Updating computers over unsafe connections

Any good software updating process will be using digital signatures to ensure integrity. Every digital signature works by performing a mathematical operation on a hash of the files using a secret key known only to the operators of the software update infrastructure. The result of this operation is the creation of a digital signature. It's easy to verify that the signature came from a given secret key, but it is designed to be extremely difficult (impossible with current technology) to forge it.

The apt updater used in Debian-based systems automatically verifies digital signatures. If an attacker on the network modifies the update files, they will not be able to forge a matching signature. This will be detected and the malicious updates will not be installed. The worst an attacker can do is prevent you from updating. They cannot replace your updates with malicious ones without being detected.


What OS's will "brick" a stolen phone; preventing their use or resale by a potential thief?

Besides bricking, you could at least prevent further use of mobile networks by blacklisting the phone (via the IMEI) with your carrier. Your carrier can then further blacklist your phone by instructing the GSM Alliance, via their IMEI Database, to do so, so that the mobile can't connect to any networks.

This, however, as sebastian nielsen already said, does not prevent the use of the phone as a "WiFi-only" device.


Is embedding the EAX nonce inside the Associated Data considered safe?

The nonce is already authenticated. There is absolutely no reason or need for you to do this. Whether or not it reduces security, I can't say. However, it certainly doesn't improve security.

  but to me it makes more sense to have the nonce be a part of [the associated data]

I would, as a general rule, trust the cryptographers responsible for designing EAX over your own gut feelings.


metasploit openvas plugin not connecting to OpenVAS9-Manager

In the file /etc/init.d/openvas-manager, which manages the service, you will see that

it includes a file with parameters
and then uses the variables from that file as arguments.

# Read configuration variable file if it is present
[ -r /etc/default/$DESC ] && . /etc/default/$DESC

# Update DAEMON_ARGS with optional settings from /etc/default
[ -n "$LISTEN_ADDRESS" ] && DAEMON_ARGS="$DAEMON_ARGS --listen=$LISTEN_ADDRESS"
[ -n "$PORT_NUMBER" ] && DAEMON_ARGS="$DAEMON_ARGS --port=$PORT_NUMBER"

So in order to start the service with the listening ports active you must simply have a look at /etc/defaults/openvas-manager

There you can simply uncomment the lines for "LISTEN_ADDRESS" and "PORT_NUMBER" and set the values to your desires.

# Defaults for OpenVAS Manager initscript
# sourced by /etc/init.d/openvas-manager
# installed at /etc/default/openvas-manager by the maintainer scripts

# For more information see `man openvasmd`

# To set listening address:
#
LISTEN_ADDRESS="127.0.0.1"

# To set listening port number:
#
PORT_NUMBER=9390

Then simply restart the service.


Few questions about group keys family in WPA/WPA2

The GMK is generated by the Authenticator, not derived.
By definition:

  group temporal Key (GTK): A random value, assigned by the group source, which is used to protect group addressed medium access control (MAC) protocol data units (MPDUs) from that source. The GTK might be derived from a group master key (GMK).

Still generated by the Authenticator and sent to the Supplican/STA and is 16 bits long, two bits for the ID and 14 Reserved

GMK is 256 bits long.
I'm not sure what you mean by GEK but I'll guess you're referring to both PTK and GTK since these are used for the final encryption of unicast traffic and broadcast/multicast respectively, both are derived from PMK or PSK. Or maybe the Temporal Encryption Key (TEK) which is generated in TKIP and used to encrypt the packets, this one derived from PTK or GTK.
Uhm.... nope, sorry.
Well.... the passphrase has a limit of 256 bits, or 64 octets when in hex.

  It is difficult for a user to
  correctly enter 64 hex characters. Most users, however, are familiar with passwords and pass-phrases and feel more comfortable entering them than entering keys. A user is more likely to be able to enter an ASCII password or pass-phrase, even though doing so limits the set of possible keys.

[...]

  A pass-phrase is a sequence of between 8 and 63 ASCII-encoded characters. The limit of 63 comes
  from the desire to distinguish between a pass-phrase and a PSK displayed as 64 hexadecimal
  characters.
  Each character in the pass-phrase must have an encoding in the range of 32 to 126 (decimal),
  inclusive.

Not sure but I really hope this helps though.


Privilige escalation with CreateNamedPipe and Impersonation for Windows Server 2012

MS15-050 (CVE-2015-1702) and other vulnerabilities against tokens on the Windows Server 2012 platform do not appear to leverage the CreateNamedPipe method.

You can see a binary diff and vulnerability analysis of CVE-2015-1702 by Alex Ionescu in his blog entitled, Analyzing MS15-050 With Diaphora. There is also a Nessus plugin to test for the existence of MS15-050 available -- here -- but the scanner likely only checks the patch level.

You could always get the exploit code for CVE-2010-2554 (but not CVE-2010-2555, the other half of MS10-059) via Exploit-DB, CORE IMPACT, or CANVAS and then compare that code to Alex Ionescu's analysis, or the further work done on similar token impersonation privilege-escalation bugs by Google Project Zero (such as their work on CVE-2015-0002 that led to the development of the popular metasploit-framework exploit/windows/local/ntapphelpcachecontrol module). P0 even produced a nice set of tools to check for these sorts of things in sandboxes.


Is it okay to keep .zip files in the public_html folder?

It depends on what the file contains. If every file in the public_html directory is a file that is intended for public dissemination, in their original, plain-text content -- then yes, by all means. But for any website running a CMS or similar, there are probably files that contain information you don't want distributed -- like configuration information for a database on a WordPress or Drupal website. It would be foolish to rely only on an unlikely file name to keep your data safe.

Some backup services will keep .zip files in a public directory, but use some sort of protection within .htaccess (deny from all) to prevent these from being accessed. This is better than nothing, but still insufficient, because a minor change to the server configuration (changing the AllowOverride config) would render the .htaccess file powerless to control access to the directory, and the .zip files would be accessible.

My recommendation: keep ZIP files out of the public webroot, keep the permissions 600 for these files, and add a .htaccess with a "deny from all" directive in the folder as failsafe.


How does LDAP keep an authenticated session

It knows it's you because you're sending all requests over the same stream (TCP) connection. (And TCP knows that because the ports and packet sequence numbers all match.)

In other words, LDAP is a stateful protocol, and the whole session (including authentication) is implicitly bound to the underlying connection. (The same as with all other similar protocols, like IMAP or SSH.)

Of course, TCP itself isn't very good at that (e.g. just sniffing the sequence numbers would let someone to take over the connection), so usually TLS and/or SASL are used to provide encryption and integrity.

Note that as far as the LDAP server is concerned, the answer's the same – all requests arrive over the same stream connection. Only now TLS cryptographically enforces this.

(Side note: Yes, SASL is not just an authentication protocol – it also allows mechanisms to derive a session key and use that for 'sealing'.

The sealing feature of SASL is rarely used due to various disadvantages, though. LDAP is practically the only protocol supporting it, while everything else relies on TLS.)


How critical is encryption-at-rest for public cloud hosted systems?

Your threat model is focused on external parties breaking in. But the threats are broader than that.
Low-level hardware backups, VM snapshots, and disposed hardware can all contain data. And because these things tend to be seen to have lower risks, they are often mishandled. So, it's not a "Mission Impossible" style of threat that is likely. It's the "eh, the drive is old, just toss it" style of threat that's the problem. Even for large cloud providers.
And because, as you say, it's cheap and easy to implement encryption-at-rest, to not implement it is its own cause for concern and follow up questions.
Human factor issues, like password policies and secure coding practices, are also very important, but difficult to assure, insure, and be consistent. So, technical controls tend to be the focus, regardless of the overall priority.


Android SSL-TrustKiller does not simply work by putting a new trusted root CA into the trust store since an application could protect against this using pinning, like you do. Instead SSL-TrustKiller patches the SSL-API used by the program so that the usual way of pinning does not work any longer but that the application will not notice this.

While there might be a way to work around SSL-TrustKiller by using uncommon ways to pin a certificate which are not covered by the API patches it is impossible to find a general solution against TLS interception as long as the user fully owns the system (i.e. is root). Such a user could for example modify your application and disable the code for pinning or add hooks into the application to get to the plain text before encryption.


Should I use a cryptograpically secure random number generator when I generate IDs?

Math.random() is usually seeded from the current time of day. Therefore there is a chance that collisions will happen for objects that are generated around the same time each day.

From a security perspective, this means that these "random" values will be predictable by an attacker.

Even if seeded with something else, a non cryptographically secure pseudo random number generator can reveal its state should enough values be captured. This is why it is better from a security perspective to only use values generated by a cryptographically secure pseudo random number generator (e.g. crypto.randomBytes() that you refer to).

CSPRNGs have certain properties that make them suitable for use in security:

  Every CSPRNG should satisfy the next-bit test. That is, given the
  first k bits of a random sequence, there is no polynomial-time
  algorithm that can predict the (k+1)th bit with probability of success
  better than 50%. Andrew Yao proved in 1982 that a generator passing
  the next-bit test will pass all other polynomial-time statistical
  tests for randomness.
  Every CSPRNG should withstand "state
  compromise extensions". In the event that part or all of its state has
  been revealed (or guessed correctly), it should be impossible to
  reconstruct the stream of random numbers prior to the revelation.
  Additionally, if there is an entropy input while running, it should be
  infeasible to use knowledge of the input's state to predict future
  conditions of the CSPRNG state.

Using such a generator will satisfy your security requirements:

Prevents easy enumeration.
Does not give away order objects were
created.
Does not give away total number of objects or growth rates.

However, you shouldn't let the fact that these are now unpredictable from protecting the first case with proper access controls (authentication and authorisation). URLs should not be considered secret and there are many ways they can leak  (shoulder surfing with hidden camera, HTTP referrer header leakage, proxy and browser logs). Also, once a URL is known and you're relying on an unpredictable secret to protect it, the user accessing it will always have access and this cannot be revoked. Remember - they can easily bookmark it.

Using unpredictable values would definitely help your other requirements should they be deemed necessary for your application. I would recommend using a 128 bit random value which is more than enough entropy to prevent predictability and collisions.


Is it unsafe to allow apps other than Outlook to send email via the Exchange server?

Your customer is not wrong - or rather, might not be.

If there is no password requirement, any user or app on that computer can send emails - whatever they want, as much as they want, to whomsoever they want.
But even more than that - they can send the emails from whoever they want. E.g. from the CEO, or VP HR, or...

So authentication should always be a requirement.
Moreover, though this may be out of your scope - their Exchange server should be hardened, to never allow unauthenticated connections.

Now, is a password enough?
It depends...  can malware misuse your application to spoof and/or spam via their Exchange? (The answer is most probably yes - either via object models, DDE, .NET reflection, or even just stealing your app's password from storage).

Regarding Outlook, to the best of my knowledge, the object model requires user approval before sending mails from external apps.

Bottom line, you can make it more difficult, but not impossible - but then, you don't need to, since spam is already pretty cheap to generate even without you - you just have to make it hard enough.


To answer the subject line question, "Is promiscuous mode sufficient to sniff packets in a wifi network?", the answer is yes, catching the packets just requires a network adapter that can be put into "monitor" or "promiscuous" mode, ie both modes work...that part isn't that hard. (You mentioned both modes in your edit) This is assuming you are using a NAT router in conjunction with a DHCP server... and you are, right?

I admit all I've learned about networking has not been through school but, this being the scenario, I have a feeling the network switch might be an issue?

I've been drinking wine too, lol, but at my old place in Victoria, if you plugged into a port on my router, you would see NO traffic that I sent to the Internet. That is because the network switch knew where to send the traffic, and it only sent the traffic between the ports that needed to see it.

Alternatively, but more towards your question, if you looked at my wireless you would have no idea what I'm doing.. the switch only passes on Broadcast Traffic or Traffic to where it doesn't know the destination to all ports. Then the Wireless, which is a Bridge, will only pass on to Wireless what NEEDS to be sent to the Wireless part of the bridge.

That being said there are several methods of SNIFFING a switch, using either a Man-in-the-middle attack or port flooding.

Anyway, it's not sniffing the packets but more about deciphering, understanding, and making use of the traffic that is intercepted, which is an art form in and of itself. You mentioned you wanted to analyze the packets, too... Its rather difficult, and in a few cases, it just isn't practical to be done. I mean, to really analyze, it's beyond the skill level of the majority of users, although I'm sure there are some geniuses on Stack Exchange you should be having a beer with..

Best of luck in your learning experiences!


Is it possible for digital forensic evidence to be multiple types of evidence at the same time?

Let's first map out what each of these terms mean:

Direct evidence: "proves or disproves a fact directly." It's common for direct evidence to take the form of eyewitness testimony, but this doesn't have to be the case. Real or documentary evidence can be direct evidence, too.
Real evidence: used interchangeably with physical evidence, is "any evidence that is a tangible object, as opposed or oral testimony or documentary evidence, which records information that is offered as evidence." What's more, it's "used to prove a fact based on the characteristics of all or part of an object." For example, if I'm at a stoplight and I get rear-ended and my airbag deploys, the airbag would be an example of real evidence.
Best evidence: "requires that an original or a highly accurate copy of a document or other object be brought into court."

Now to your question: Can a piece of evidence fall into all three categories?

Yes, and here's a (common) example. Imagine an external hard drive with a terabyte of child pornography on it. If a forensic scientist can demonstrate that the external hard drive belongs to the defendant who is being accused of possessing child pornography, then the direct evidence condition has been met.

For real evidence, let's assume that the defendant covered his external hard drive with a variety of stickers. Upon examination, the defendant plays dumb, but the prosecutor reveals that a search of his apartment found sheets of the same stickers that were on his hard drive. The characteristics of the hard drive, the stickers, would be good reason to believe that the hard drive belongs to the defendant.

Lastly, the original hard drive of the defendant or a forensic copy  could satisfy the best evidence condition. Hashing the forensic copy can verify that the "image" (in the digital forensics sense, not necessarily a picture) is identical to the source media, which would mean that the forensic copy of the digital hard drive would satisfy the best evidence condition.

Sources:

http://www.rotlaw.com/legal-library/what-is-real-evidence-is-it-the-same-thing-as-physical-evidence/
http://www.rotlaw.com/legal-library/what-is-circumstantial-evidence-what-is-direct-evidence/


How do the following key formats rate in being more secure to less secure: RSA, ECDSA, ED25519

"Which is more secure" is not the best question to ask.  All of them are sufficiently secure as long as:

They are implemented and used correctly;
They're used with a sufficiently large key size.

ECDSA and Ed25519 are based on elliptic curves.  Their advantage is that they can achieve the same security target with shorter keys than RSA requires, which translates to better performance.  256-bit elliptic curve keys are generally understood to provide similar security to 128-bit symmetric ciphers like AES-128.  With RSA, 2,048-bit keys are considered the current minimum safe key size, providing something like 112-bit security (which no less secure in practice than 128-bit security).

The KeyLength site has various recommendations for key size for these algorithms.

Ed25519 is newer than ECDSA.  Its main advantages are speed, simplicity and foolproofing: both are secure if used correctly, but ECDSA is harder to use correctly.  The most famous ECDSA failure is the Sony PS3 signature bug, which was caused because Sony's programmers implemented ECDSA incorrectly.  Ed25519 is not vulnerable to the mistake Sony's programmers made, nor to some other "gotchas" that ECDSA implementations are.

So Ed25519 is widely held to be the best of the three, because it provides:

Sufficient security for the near future.  (All three will be toast if a practical quantum computer is built.)
Very good foolproofing—less vulnerable to programmer and user mistakes;
Smaller keys and very fast performance.

...but none of these factors should stop you from using ECDSA or RSA if, for example, you're using a system where one of these is available but Ed25519 isn't.  Likewise if you have a system that uses RSA or ECDSA, it probably doesn't make sense to upgrade it to Ed25519.  Also RSA and ECDSA has NIST and NSA approval and Ed25519 doesn't, so if that matters to you then Ed25519 is out.


IPtables Linux Firewall and IPsec traffic

Assuming that you mean "can host X, which terminates the IPSec tunnel, apply iptables filters to the de-tunneled traffic?" then the answer is yes.

Here's a Server Fault Q&A on this exact topic - With iptables, match packets arrived via IPSEC tunnel - which states

  You need to use the policy module, and specify the ipsec policy, to
  match this traffic.

and gives as an example:

iptables -A INPUT -m policy --pol ipsec --dir in -p tcp --dport 12345 -j ACCEPT

Unfortunately, documentation is pretty sparse.  Googling for it will find you things like this:

  I'm looking for for in-depth documentation for the iptables "ipsec
  policy match" module. It might be just the right thing to solve my
  iptables/ipsec-problems; but the information given with "iptables -m
  policy -h" is not very intuitive.

(and of course some help for using it is found in the ensuing thread).