Remote System Administration of an Encryption-Switch-Encrypted Infrastructure I can't seem to find a decent explanation anywhere of the practicalities of remote system administration (e.g. SSH) of an encryption-switch-encrypted SAN-stored infrastructure.

The environment will be NetApp SAN with SafeNet encryption switch and a vSphere cluster with numerous Linux VMs.

Note that it is the system administration of the Linux OS that I am interested in - not the administration of the encryption-switch.

How am I able to work on the commandline with the data decrypted? Does one normally encrypt everything on disk (i.e. including the system files) or just certain volumes/partitions containing the data?

I assume that a key management server facilitates the process but could someone provide specifics?

Many thanks!

This is really a system administration question rather than security. However, I'm going to go ahead and attempt an answer. Most of Safenet's product's try to ensure a transparent form of encryption that the user doesn't notice. So, if it's encrypted storage the product performs the encryption just before it hits whatever integrated storage solution. If it's encrypted networking, they usually have two products (one for each side) that establish a tunnel and seemlessly move things through. Even the coprocessors are integrated with common libraries so you don't really have to modify some applications.

A proper setup with your storage using something like Storage Encryption product should cause no trouble. Your side of things should change little or not at all. They reiterate that in their datasheet:

"SafeNet StorageSecure offers a seamless, non-disruptive deployment that drops into the network between clients and servers, linking them with a high-speed cryptographic path. There are no hosts to configure or software to install. StorageSecure is ready to encrypt and secure storage transparently without any impact on user experience."


Is using VPN on a router more secure than using a dedicated VPN machine? I was looking at the features of the Asus RT-N66U router and noticed the built-in VPN feature. I am currently running an OpenVPN server on an ESXi VM, but I was wondering: would using the VPN feature on a router be more secure? After all, this way you wouldn't have to do any kind of port forwarding to the internal network, right?

Or perhaps, security-wise, there are no differences between the two approaches?

It depends; there are about three things you must consider:

Does the software provided meet your needs (security and performance)?

Since you're using OpenVPN Server on ESXi, you'd probably be fine using OpenVPN Server on a pfSense firewall.  IPSec VPN on that same pfSense box would also probably work for you, if you know how to configure it correctly.
The specific consumer router you listed appears to have PPTP VPN, which may or may not meet your needs.

Does the software contain known vulnerabilities as first obtained (installed or bought)?

This is always a "check current news" item.
So, you must ask - where can you find such news for a given product, i.e. how would you know?

Forums?
Contact the maker?
CERT?

When a vulnerability is found in the future, how will it be addressed?

Some vulnerability will be found, at some point in the future.  Such is the way of code written by humans.
Look at past performance: how well has a given maker addressed the recent big bugs, like Heartbleed and Shellshock, etc.?

On their current products?
On their older products?  Look for a product about as old as you hope to keep this one; see how they handle updates and patches.

My gut instinct is that serious firewalls will be quite good at handling all of these with their built-in VPN's, if they either have free maintenance or you buy the support plan, and the consumer grade stuff will not be kept up to date.

As far as port forwarding to the local network, you are correct; my pfSense installation simply asks which interface (WAN, in your case) to open the specific OpenVPN server port on.  However, I'd be hard pressed to see opening a single port for UDP only (or TCP only), to a single internal address which runs OpenVPN as a significant security flaw; this is, after all, what you use a firewall for.


How do you get a CA trusted by Certificate Transparency logs? How would one go about getting in contact with a popular CT logs operator's, let's say Google Pilot, and how would one get a CA root included in their log? Are there open CT logs that allow untrusted roots or don't have a root system/program?

So your question boils down to this:

We are a small CA supported by some browsers. We are trying to offer EV certs but are running into issues because we're not logging our certs to CT logs. How can we get the CT logs to accept our certs / SCTs?

I agree that it's surprisingly hard to find any information on this. My first hint comes from Chromium docs:

Locally-trusted CAs
For CAs that have been manually installed, provided those certificates are not or have not been publicly-trusted, it‘s not necessary to enable support for Certificate Transparency. Further, Certificate Transparency Logs will not accept certificates from those CAs, thus it’s not possible to support CT.

Alright, that's a hint that CT logs will only accept SCTs from publicly-trusted CAs. But what does that mean? The whole point is that logging to CT will increase your public trustworthiness, so that seems a bit ... circular.

Next bit of useful info: Chromium CT Log Policy:

When applying for your CT log to be included in Chrome the CT Log Operator must provide the following information about the new CT Logs in their application:

The set of Accepted Root Certificates of the Logs

So that tells me that each CT log operator gets to decide which CAs to accept into their log. That means each CT log is likely to have their own policies for who they accept.

From the same Chromium CT Log Policy, I see

Logging Submission Policy
Accepted Root Certificates
In order to maintain broad utility to Chrome and its users, CT Logs are expected to accept logging submissions from CAs that are trusted by default in Chrome across all its supported platforms, including ChromeOS, Android, Linux, Windows, macOS, iOS. If a Log Operator plans to restrict the set of Accepted Root Certificates, this should be clearly stated in the CT Log Operator Application as well as the rationale for this restriction. Note: This restriction may prevent a CT Log from being accepted by Chrome for inclusion.

The plot thickens. So while it's technically up to the CT Operator which Root CAs to log for, they had better log for all roots in the Chrome Root Program. It doesn't say that the CT log can only accept submissions from roots in Chrome. So you're not totally out of luck yet.

Here is the official list of CT logs recognized by Chrome.
As per the Chromium CT Policy (see section "Embedded SCTs"), you'll need to get your CA into:

2 CT logs if cert lifetime < 15 months
3 CT logs if cert lifetime >= 15 and <= 27 months
4 CT logs if cert lifetime > 27 and <= 39 months
5 CT logs if cert lifetime > 39 months

Of those at least one must be a Google-operated CT log and at least one must be a non-Google CT log.
Since you asked about Google Pilot in particular, here's a Chromium bug tracker thread that says:

HTTP(S) endpoint: https://ct.googleapis.com/pilot
Description: Google's first CT log, operating since 2013-03-25 (has been monitored by http://ct-watch.tom-fitzhenry.me.uk/#/logserver/google-pilot). Will log any certificate that is anchored in a root trusted by one of the major browser vendors.

Which is again a bit circular; "We'll log for you if the browsers trust you"
Soooooooooooo I think you need to pick some CT logs from that list and start sending emails. I expect you'll get asked A) if you're in the browsers, B) if you're eligible to be in the browsers. Sounds like if you're not compliant with CA/B Baseline Requirements, and have not passed a WebTrust audit, then you'll probably be fighting an up-hill battle to get them to include you.
... which I think doesn't really tell you anything you didn't already know. Sorry if none of this is helpful.


What is the meaning of the term "simple string" for the SALT string in Unix crypt using SHA-256 and SHA-512? In Unix crypt using SHA-256 and SHA-512 the author, Ulrich Drepper, introduces the SALT string as the following (highlight by me):

  For the SHA-based methods the SALT string can be a simple string of
  which up to 16 characters are used.

What is the rationale calling this string a simple string? What does it mean? What are the consequences? I'm especially interested in the edge-cases of providing a string of 16 NUL bytes for example.

The text means "simple" by opposition to what was used in the older traditional DES-based crypt() where the salt was a 12-bit value, represented as exactly two characters in a restricted set. Ulrich Drepper wants to say that his creation is less picky and can take as salt any sequence of up to 16 bytes.

Though the hashing function itself can work with any bytes (including zeros, which are not special in any way for a hash function), the C code shown in the text you link to uses a string-based API:

char *
sha256_crypt (const char *key, const char *salt)

i.e. the salt will stop just before the first byte of value zero, or just after the 16th byte, whichever comes first. Moreover, the value of the salt will be part of the produced output string, so the salt had better consist in printable ASCII characters and not include the '$' sign, since that's what is used as separator within that string.

A simple way to generate a "proper salt string" for this function is to generate a sequence of exactly 12 random bytes (taken from a good PRNG, i.e. /dev/urandom), and encode them with Base64. This will yield 16 random characters, in an alphabet containing letters (uppercase and lowercase), digits, '+' and '/' -- and none other, in particular no '$' and no troublesome control character. The salt will still have 96 bits of entropy, making salt reuse considerably improbable (so things will be fine).


How to know if my laptop microphone is recording automatically? (Ubuntu) How to know if my laptop microphone is recording during the day?

Is there any program for ubuntu to check if my laptop microphone is recording automatically by any application during the day?

If I am assuming correctly, you are asking because you have a concern about remote access to your laptop microphone by a hacker yes? If this is the case, and if you are using linux, you should be easily be able to tell if your microphone is activated using the netstat, ps, and lspci commands.

lspci will give you the hardware profile of your microphone.
ps will show you the processes running.
netstat will show you you current connections, what ports they are running on, and the name of the service/process/protocol using it.

You will want to see if any process or incoming connection are using VOIP protocol. Then disable your mic and then check to see if the VOIP connection is still active. If so, close that VOIP port and check once more.

If all else fails, you always have the option of physically uninstalling your internal mic and using a usb mic/headset if you are that paranoid about it.

An example of your lspci output could look something like this:

00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 06)

An example of your netstat output could look like this:

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 192.168.1.144:56685     104.16.105.204:http         TIME_WAIT
tcp        0      0 192.168.1.144:40857     edge-star-mini-sh:https ESTABLISHED
tcp        0      0 192.168.1.144:41160     81.17.30.48:https       ESTABLISHED
tcp        0      0 192.168.1.144:56267     stackoverflow.com:https ESTABLISHED
tcp        0      0 192.168.1.144:49811     104.16.115.182:http     ESTABLISHED
tcp        0      0 192.168.1.144:56887     yv-in-f95.1e100.ne:http TIME_WAIT
tcp        0      0 192.168.1.144:49806     104.16.115.182:http     TIME_WAIT
tcp        0      0 192.168.1.144:56281     stackoverflow.com:https ESTABLISHED
tcp        0      0 192.168.1.144:36785     195-154-9-161.rev:https ESTABLISHED
tcp        0      0 192.168.1.144:56686     104.16.105.204:http     TIME_WAIT
tcp        0      0 192.168.1.144:36098     104.16.111.18:https     TIME_WAIT
tcp        0      0 192.168.1.144:39585     edge-star-shv-01-:https ESTABLISHED
tcp6       1      0 ip6-localhost:39979     ip6-localhost:ipp       CLOSE_WAIT

And finally an example of your "ps" output could look like this:

root@anonymous:~# ps -v
  PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
 1249 tty4     Ss+    0:00      0    25 18322   964  0.0 /sbin/getty -8 38400 tty4
 1252 tty5     Ss+    0:00      0    25 18322   956  0.0 /sbin/getty -8 38400 tty5
 1261 tty2     Ss+    0:00      0    25 18322   964  0.0 /sbin/getty -8 38400 tty2
 1262 tty3     Ss+    0:00      0    25 18322   956  0.0 /sbin/getty -8 38400 tty3
 1266 tty6     Ss+    0:00      0    25 18322   952  0.0 /sbin/getty -8 38400 tty6
 2222 tty1     Ss+    0:00      0    25 18322   952  0.0 /sbin/getty -8 38400 tty1
 2253 tty7     Ssl+  39:09      9  2218 293637 49284  0.6 /usr/bin/X -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolis
 3172 pts/0    S      0:00      0   140 92211  2832  0.0 sudo su -
 3173 pts/0    S      0:00      0    30 91509  2428  0.0 su -
 3181 pts/0    S      0:00      0   955 25568  5144  0.0 -su
 25559 pts/0    R+     0:00      0    84 12459   892  0.0 ps -v

Using these command with specific syntax can also be used to show if an application on your machine is using your microphone as well.


Why does every site makes me acknowledge cookie usage? In the last year or so every other site on the net started showing different kinds of notification that they're using cookies and I should be aware of it. The sheer number of different sites doing this made me abandon the initial good-will-idea and rather think that there has been some kind of legislation forcing sites to show that notice, especially since until recently, it's been a trend on US-based sites. Now I'm seeing this also on german sites (I think I would have noticed an appropriate legislation), so I wonder -- what's the background for this overreaching user information? Why this intensity all of a sudden?

There is indeed an EU legislation : European Union Directive 2009/136/EC says that websites must get consent from their visitors about information they intend to keep/store/retrieve on their computer/device.

There is even a fine, up to £500,000 for those who don't comply.

Source :

ICO (Information Commissione's Office) Blog
European Comission 'Information Providers Guide'
Huffingtonpost
Cookielaw.org :)

[Edit] A more complete answer on superuser.com


Would this be a secure Authentication flow? Consider the following authentication flow.

User sends in their username and an RSA encrypted password
The password is decrypted and hashed with a salt (and possibly a pepper) and verified
If the hash matches a GUID is generated as a token and the token is given a TTL and expiration date and returned to the user. In addition the IP address of the caller is saved
That username with the token is then used for any future interaction with the DB (Any time the token is used its expiration date is extended). Only the IP which created the token can use the token.
Logging in from a new IP must first be verified using a second form of authentication (ex. a code sent to the users email)

What are the security concerns of such an authentication system?

I feel like such a system would be using tokens incorrectly as from what I've read it seems that the purpose of tokens are meant to be for authorization and not authentication. I feel as though the only benefit of using the token is that a password can be used to log in anytime and the token eventually expires so if it becomes expired it will eventually become useless.

One of my concerns would be if someone is constantly listening in and intercepting the token that would essentially mean they could use it to access the database whenever there is an active token (and can indefinitely refresh a token to keep it active). This is why the IP address would be stored and access would only be given to that IP address. Would this minimize the risk of the token being misused.

In general a token can't be passed back encrypted, how can anyone prevent a token from being intercepted and misused?

A couple things worth noting:

IP's change -- probably more often than you expect
You're screwed no matter what if someone is able to listen in
Any code executed in-browser can by bypassed if someone is listening in

What you're describing is what's known as a bearer token: whoever bears the token has the power of the token. This is exactly how most websites work, except they often just call them session cookies.

There are a couple things you can do to protect this token.

Enforce HTTPS using a real trusted certificate -- this is all an exercise in futility if you don't use HTTPS.
Enable HTTP Strict Transport Security; this'll signal to the browser that all requests to site must be over HTTPS, and therefore any man in the middle will probably be noticed because of an invalid certificate. This has limited effectiveness though because an attacker might strip the HSTS header before the browser sees it.
Consider public key pinning; this'll make it more difficult for someone to use a trusted but fake certificate while doing a MiTM. This is extremely effective if you're using a non-browser app because you can control the channel validation.

If you're still concerned about someone intercepting the request then you need something like a client certificate, so you can do mutual authentication. This will guarantee protection against interception because the key exchange can only occur between trusted parties.


Is it possible to trace a MAC address to an individual? Ethernet cards have a unique MAC address that is assigned during manufacture. If you capture a MAC address, and no other information, can you trace this to an individual?

Perhaps the manufacturers keep records of what MAC address goes in each batch? A retailer could connect a MAC address to a transaction, and reveal the identity of the buyer. If this is manufacturer-specific, I'd be interested in any manufacturers known to record this information. Also, any indication of how readily retailers would respond to such a request.

The context is that I'm writing fiction. The hacker is being traced, law enforcement have compromised his browser, but he's using Tails with physical separation. His one mistake is forgetting to change the MAC address on his internal firewall.

Technically, it would be next to impossible to trace back a random MAC address to an individual.

Notwithstanding the fact that MAC addresses can easily be spoofed or changed (which means that your defender has bad opsec if they are using the default hardware MAC on the network), they are, at best, linked to a specific network card. This is a single component of the connecting machine which means that to trace it back you'd have to first go to the component's manufacturer before going to the actual device manufacturer. that is, if the part wasn't actually sold independently through a retail channel in which case it would be impossible to trace it.

So, it would be pretty much as hard as tracing back the owner of a car knowing only the serial number of it's tires. It makes little sense in practice but that doesn't stop TV shows and movies from "doing" it.

A more realistic way of identifying the individual behind a specific MAC address would be to take into account the proximity element: MAC address are not carried beyond the local subnet boundary which means the capturing device and the defender's device must share a lot in common. It's not unthinkable to identify the terminal using a specific MAC address on the local subnet based on the network properties itself. For instance, if you're taking about mobile devices, it would be possible to use a directional antenna to locate the device in question (for instance, using something like this).


How to prevent manipulation of a chain of document? Specifically: medical records This is hypothetical problem, so remarks about whether it is feasible in practice are are off topic.

I have been designing a documentation system for medical records where the patient owns his/her own data (instead of how it currently works in most (?) cases where the data is stored in a big database at a hospital or similar - an excellent target for both black hats and authorities).

For example, by getting a physical printed paper after each visit to a doctor with the notes and other details of the visit on. The objection I always get when I suggest this is that it would be a problem in maltreatment cases and similar if the patient could manipulate the documentation.

My solution to this - and this is where I would appreciate input - would look something like this: each paper the doctor gives the patient contains a digital signature (checksum) calculated with the doctors private encryption key (e.g., a QR-code) in its footer. This prevents the patient from manipulating the document undetected.

Next problem is the document chain: the solution in the previous paragraph does not prevent the patient from handing in paper 1, 2 and 4 but ignoring 3. To solve this, every paper also contains the previous documents digital signature in it's body. If the patient presents page 1, 2 and 4 they checksum for the previous document on 2 will match the checksum on 1 but the the checksum for the previous document on 4 won't match the checksum on 2.

Would this work?

One problem remains: what if the patient just presents paper 1, 2 and 3 but not 4? Or if the patient on its fifth visit to the doctor just show 1, 2 and 3 - meaning you get two documents numbered 4? Any ideas for solutions for these problems? A separate log document? How is it solved in current solutions?

This is hypothetical problem

But if you add one "practicality" it becomes analogous to one already (more-or-less) solved problem.  The practicality to add is:

A doctor should always look at the full medical history of a patient.  What may look at first as an unrelated problem can be an important point in a diagnosis.

In other words, all medical records of a patient shall always be presented to a doctor.  This solves the discussion (in the comments) about whether presenting part of the documentation (e.g. 1/2/4) is meaningful.  So, if we can assume that a patient must always give all documents, the problem becomes analogous to a cryptocurrency.

Bitcoin, or any other cryptocurrency for that purpose, sings all transactions with the private key of the wallet from where the transaction originates.  Then, when the unit of currency is in another wallet, another transaction will be signed with the private key from that wallet.  We have an excellent discussion on that on the bitcoin.SE part of the website.

Therefore a solution where one participant sings a piece of data, the next participant adds more data and signs the result, and so on; does exist and is rather effective.  The stack of signatures can be unwind and each verified.

The difference is that with Bitcoin (or any other cryptocurrency for that purpose) the chain is public, because it can be.  Medical record are far from something public, but, as you said, the patient can keep them and still be unable to falsify a doctor's signature or tamper with the signed document.

Keeping all the medical records on some media that will store the chain of signed data would actually force a patient to always show his complete medical record to a doctor.  Which, in my personal opinion (I'm not a doctor or a lawyer), should be a good thing.

P.S. I'm not considering insurance companies in that last statement.


How does the TCP/IP lack security? I already know that some concerns of lack of security in TCP/IP are that TCP/IP does not support strong authentication of packets and no encryption of packets. What other weaknesses are there in the TCP/IP regarding security concerns?

Routing is a black box

You generally have no way to tell how your communication is routed through the internet. You never know which routers pass on your communication and who controls them. Routers can be configured to divert certain traffic to go across non-trustworthy servers and the endpoints have really no way to detect this. You might know about the traceroute (UNIX) or tracert (Windows) program which discovers the route between you and another host, but the network traffic generated by this tool looks and behaves a lot different than normal traffic, which makes this tool quite unreliable. Normal traffic might take an entirely different route than what traceroute shows you.

Address spoofing

Each IP packet includes both the IP address it is sent to as well as the address it orginates from. However, there is by default no verification that the source address is really the address of the host which created the message. This allows any host to forge an IP packet with the source IP of any other host and claiming it is routing it from it. This problem is much more serious for UDP/IP than TCP/IP, because TCP/IP requires a SYN/ACK/SYN-ACK handshake to establish a connection, which only works when the source-IP of the packet which makes the connection is correct. However, there is also...

Sequence number guessing

When two hosts have established a connection, each packet they exchange is numbered. When an attacker knows that two hosts are communicating with each other and they can guess the next sequence-number, they can spoof such a packet to inject forged data into the communication.

And another application of address spoofing is:

SYN-Flooding

This is a denial-of-service attack where the attacking host sends lots of SYN-packets (requests to open a connection) to the target host. However, it spoofs the source-IP with random addresses, so the server sends an ACK-packet (acceptance of the connection) to a host which never asked for it. It will then wait for the SYN-ACK packet (acknowledgment of acceptance by the initiator) until timeout. This can bind a large amount of resources on the host and prevent it from accepting legitimate connections. While this does not result in any data exposure or data manipulation, it is still a frequently used method to temporarily prevent users from reaching a certain host.

But what if you actually need to read the response of a host to a spoofed packet? Well, then you have:

ARP spoofing

Strictly speaking, this is not a flaw in TCP/IP but in the related Address Resolution Protocol which binds IP addresses to network interfaces. However, it affects the security of IP communication, because it allows one host to "steal" the IP address of another host so that any future IP packets get redirected. ARP spoofing usually only works in the same network segment. Also, an ARP poisioning attack can be detected and enterprise-grade network equipment is usually able to prevent it.

By the way: Needless to say, using any of the methods described here are illegal in many parts of the world. Nevertheless they are frequently used by criminals and government institutions all around the world.


what are security precautions to ask clients who send a USB or CD? We're launching a tender for a big project, and some of the businesses who want to make an offer are asking if they can send some brochures together with a USB stick or CD-Rom.

Since we're trying to take more precautions, we don't just want to plug in flash drives from random companies who we don't know whether they can be trusted.

What kind of security precautions can we take in advance? is there anything we can ask them to do that proves their drives or CD's are safe?

Most info I can find is on keeping the data on the drive secure, does it work in a two-way street where encrypted data or read-only drives cannot infect your computer?

Should we ask all of them to send Ironkeys (encrypted USB portable storage devices), or would that not be effective/a waste of money?

thanks for your replies!

The standard procedure is to:

Use only one PC to plug the sticks and read the CDs/DVDs
To have that dedicated PC isolated from the network except one (only one) network share to where the materials are copied
To have all Windows Updates and AV updates

The above will help you:

Avoid USB and DVD Trojans affecting any PC to where you would plug it in
Reliably run AV scan on every new material

The main point is, that you have reliable machine for such operations so you do not risk giving USB sticks and DVDs to random employees where AV may be switched off or not up to date.

And even there might be some advanced USB exploit, you do not risk much as you are isolated from the network (you don't have permission to browse internet except updates and one network share), and when you copy the files, these are AV scanned. The USB stick virus if crafted by hacking company can bypass AV software.

Frankly speaking, this happens sometimes. Depends how much of target you are, so the more you are, the better precautions must be taken.


File security when encrypting files directly with the openssl command / and what about SHA1 hashing password first? I've been using this command to encrypt files for a while now:

openssl aes-256-cbc -a -salt -in secrets.txt -out secrets.txt.enc

Then I type in a password.

Can someone tell me, roughly speaking, how hard it would be to crack this?

I see that it's using salt, but that shouldn't really improve security much unless you're actually storing the hashed password somewhere (like a database of website logins), right? As I said I'm just encrypting files locally, typing in my password manually each time.

I also understand that openssl only uses one iteration to generate the IV so I guess this is not a very time-consuming process! Correct me if I'm wrong please.

In your estimation, how secure is this really?

Bonus question: What if I SHA1 hash the password first?

echo -n "mypassword" |openssl sha1

and paste in the SHA1 hash when encrypting files? I know this reduces security, because now the cracker knows the format of the password for sure (SHA1 hashes), but how much do you reckon this reduces security in practice? Would it be feasible to loop through all (or enough of) the SHA1 hashes?

See the end of this answer: what OpenSSL does to convert the passphrase into an encryption key and IV is weak, because it is just a couple invocations of MD5, which is not slow enough. There is no way to simply change that within OpenSSL (no appropriate command-line option, this is hardcoded).

Pre-hashing you passphrase would not change things much. Doing a lot of nested hashing would enhance things a bit, but not to ideal levels since the salt would not be taken into account until the very last steps (a lot of shareable precomputations would still be doable by the attacker). Password hashing, with configurable slowness and salts, is not something which tolerates improvisation. At that point, it is much safer and simpler to ditch OpenSSL altogether, and use a better tool. I suggest GnuPG: the command-line tool, with its -c flag, does password-based symmetric encryption, and does it much better than openssl enc.


What is the best home wireless network encryption algorithm to use? What is the best home wireless network encryption algorithm to use?  I realize the best answer will probably change over time, and hopefully people can provide updated answers as new standards come out.  So far, my knowledge, as of early 2015 is:

WEP - Horrible / outdated, but still a bit better than nothing (or may even be worse than nothing because it provides a false sense of security as pointed out below).
WPA - Provides some security, but probably better to go with WPA2.
WPA2 - Pretty good (especially with AES encryption), but still not perfect.  It is the best I know though for a home network.

Are there any better encryption standards to use than WPA2 for a home wireless network, or is that the best there is?  If it is the best there is, is it easy to hack?

If it is true as others indicate that WPA-2 is not adequate, and nothing better exists, it seems like it would be a good idea, perhaps even a good money making opportunity for someone to develop something better!

Edit (July 1, 2019):
WPA3 is now a better option than WPA2.

From a security perspective, I think you are asking the wrong question. WPA2 is the basic answer. But it's entirely incomplete! A more complete answer will view WPA2 as one component of your wireless network defence. Of course there's strong encryption methods using certificates/vpn etc but these are too difficult for most people to set up and are usually reserved for businesses. So let's assume WPA-2 is the 'best' answer to the basic question. However... as you'll see, there's many weaker points that attackers go for, that ultimately reveal your WPA2 password, so I've included them in the points below.

  I'm assuming many people will land on this page and see answers saying
  'yeah just use a good password and WPA2 encryption', which is bad
  advice. Your WPA2 network is still completely vulnerable, as you
  will see:

the main thing you can do, is be the hardest person to hack around you. That's the biggest deterrent. If I'm going to hack you, but you're taking too long or are too expensive to crack, I'll try the next person. This will require some playing around in your router settings.
I'll assume you would never use WEP. 10 minutes on youtube and your mom can crack it.
Switch off WPS. this is EXTREMELY vulnerable to brute force attacks and can be hacked in seconds, even if you are using WPA2 with a ridiculously complex password. Tools like reaver and revdk3 or bully make light work of these. You're only a little bit more protected if your router supports rate-limiting, which slows down, but doesn't prevent brute force attacks against your routers pin. Better to be safe and just switch WPS off and be 100% safe against these attacks.
turn off remote access, DMZ, UPNP, unecessary port forwarding
turn on, any inbuilt intrusion detection systems, MAC address filtering (tedious to set up if visitors to your house want access to your wifi (you will have to add your friends device to the router's MAC white-list to enable access) This can be hacked by faking a MAC address easily, and getting your MAC is also easy with an airodump-ng scan, but nevertheless, this will slow down attackers, requires them to be near a client device (mobile phone, or laptop in the whitelist) It will be pretty effective against some remote attacks.
have a very long, non-human, complex password. If you have ever tried to decrypt a password you'll know that it gets exponentially harder to crack a password the more complex, less predictable and longer it is. If your password even remotely resembles a word, or something that could probably be a set of words (see: markov chains) you are done. Also don't bother adding numbers to the end of passwords, then a symbol... these are easily hacked with a dictionary attack with rules that modify the dictionary to flesh it out to cover more passwords. This will take each word or words in the dictionary, and add popular syntax and structures, such as passwords that look like this 'capital letter, lowercase letters, some numbers then a symbol. Cat111$, Cat222# or whatever the cracker wants. These dictionaries are huge, some can be investigated on crackstation or just have a look at Moxie Marlinspikes' cloudcrackr.com. The goal here is to be 'computationally expensive'. If you cost too much to crack using ultra high speed cloud based cracking computers then you're safe against almost anyone. So ideally you want to use the maximum 64 characters for your password, and have it look like the most messed up annoying symbol infused piece of incoherent upper-lower-case dribble you've ever seen. You'll probably be safe after 14 characters though, there's quite a bit of entropy here, but it's far easier to add characters than it is to decrypt.
change your routers default password and SSID. nobody does this, but everyone should. It's literally the dumbest thing. Also, don't get lazy. and don't keep the router's model number in the SSID, that's just asking for trouble.
update your router's firmware. Also, if your router is old. throw it out and buy a newer one, because it's likely your router is on some website like routerpwn.com/ and you've already lost the battle. Old routers are full of bugs, can be easily denial-of-serviced, don't usually have firewalls or intrusion detection systems and don't usually have brute-force WPS rate limiting among other things. just get a new one.
learn about evil-twin hacks. The easiest way to protect against this is to stop your device from auto-connecting. However, this might still snag you. Become familiar with software like wiphishing and airbase-ng, these apps clone your router, then Denial of service your router making your device connect to the attackers cloned router, allowing them to intercept your traffic. They'll usually try to phish the WPA2 password from you here. You're safer from these attacks if you actually know what your router's web console looks like, because the default phishing pages that come with these types of apps are usually pretty old looking, however a sophisticated attacker can create a good landing page. Put simply, if your 'router' ever wants you to type in a password don't type it! You'll only ever be asked when you are creating the password, when you specifically log in to the 192.168.0.1 or 10.1.1.1 user interface, then you are being phished and it's game over. To prevent this attack you could also artificially reduce the range of your router. pull out the antenna's and create a little faraday cage around it, leaving a small area that points to your most ideal wifi position. Alternatively, just use a cable to your laptop or computer until the attacker gives up.
handshake attacks are pretty popular, this is where the attacker sends a deauthorisation packet to anyone connected to your router using your password, then when that device (say an iPhone) tries to reconnect, it captures the '4 way handshake' which let's the device and router authenticate using your WPA2 password. This is what hackers use to crack offline using the password attacks in point 6. However if you have used a strong password (as described in point 6) then you've mitigated this attack already.
So i've focussed on router based defence, but there's actually even easier ways to be attacked. If the attacker knows who you are, you're screwed. With a tiny bit of social engineering, they can find your facebook your email or some other way to contact you and insert some malicious snippet of code that's invisible and hijack your entire computer, which therefore lets them simply check the wifi settings in your computer and obtain the ultra strong password you've spent so long making. One popular method is to send you an email that's junk, and keep sending it until you click unsubscribe, as you usually would for junk mail, except this link is exactly the worst thing to do. You've broken the cardinal law of email. Don't click links in emails. If you have to click one, at least check where it goes first.
If someone has access to any of your devices, or plugs/gets your to plug a device into your laptop, you're gone. things like usb sticks 'usb rubber ducky' can compromise your computer and reveal your WPA2 password to a relatively novice hacker.
if you use a wireless keyboard, and you live near an attacking neighbour, they can use things like keysweeper to compromise your wifi, and a lot more. This could be creatively used with an evil twin attack to increase the likelihood you type your password (it listens to wireless keyboard signals). The way to prevent this attack is to not use a wireless microsoft keyboard.

There's plenty of other ways, and you'll never prevent them all,

but usually if your router is locked down, has a nice password, has WPS off, WPA2 on, a strong (new) router with a password, no remote-web access, unnecessary ports are closed, MAC filtering is used and intrusion detection in the router is switched on you will usually prevent even pretty dedicated attackers. They'll have to try harder methods and will probably just give up.


Did PHP's rand() get better? I know that PHP used the system implementation for its rand() function, which is usually a weak LCG or LFSR implementation. Did this change?
In case it still does, I am using Fedora 32.

PHP states in its documentation that rand() does not create cryptographically secure values.

I've written a small script, that creates a 400x400px PNG by randomly coloring pixels black or white:

<?php

$resolution = 400;

header("Content-type: image/png");
$im = imagecreatetruecolor($resolution, $resolution)
    or die("Cannot Initialize new GD image stream");

$white = imagecolorallocate($im, 255,255,255);

for ($y = 0; $y < $resolution; $y++) {
    for ($x = 0; $x < $resolution; $x++) {
        if (rand(0, 1)) {
            imagesetpixel($im, $x, $y, $white);
        }
    }
}
imagepng($im);
imagedestroy($im);

?>

I cannot see patterns anymore when using the function in PHP7.3 though.
May there be patterns at a level I cannot display in my experiment?

rand():

random_int(),

  for use where unbiased results are critical

according to PHP's docs

If you can't see obvious patterns, that does not make it cryptographically secure! See also my answer to this question on our sibling site: What does it mean for a random number generator to be cryptographically secure?

At the risk of stating the obvious, rand() and mt_rand() are NOT SECURE for security purposes. Do NOT use them for things like shuffling a deck of virtual cards in games where there is (virtual) money at stake, generating security tokens, or any such thing. Such random functions are meant for fast randomness where security does not matter. Common applications for insecure randomness are simulations and games (the game AI repeating itself in 1 out of every 2 billion games is fine, but a secret key repeating itself 1 in every 2 billion keys can be crackable in a reasonable amount of time).

By coincidence I was looking at this 2 hours ago as well, since I was curious if they had finally aliased rand() to use mt_rand() instead, since mt_rand has been both faster and better since its introduction many years ago, but this does not appear to be the case. Therefore:

To generate insecure, fast random: $n = mt_rand(0, 10); generates a number from 0 through 10 (inclusive) (docs)
To generate secure random data: $data = random_bytes(32); generates 32 bytes of random data (docs)
To generate a secure random number: $n = random_int(0, 10); generates a number from 0 through 10 (inclusive) (docs)
Note that this only goes up to PHP_INT_MAX, which is at most approximately 264, so too small as a security key by itself. Use random_bytes() for generating secret keys, security tokens, etc. This function may aid in generating an unpredictable number, like for shuffling a deck of cards, where you may need a random number ≤52 instead of random bytes.


How does IPsec turn KEYMAT into Encryption and Authentication Keys? IPsec is a framework protocol that consists of the sub-protocols ESP and AH.  IPsec, inately, doesn't include a Key Exchange mechanism, and is therefore dependent on manually setting Keys (archaic), or using IKEv1 or IKEv2 to securely establish mutual keys between two parties.

From reading the IKE and IKEv2 RFC's, I know that both of them at some point generate KEYMAT, which is meant to be passed to IPsec so that IPsec can generate its own symmetric keys.

IKEv1 generates KEYMAT using this formula:

PFS Disabled:
KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b).

PFS Enabled:
KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)

IKEv2 generates KEYMAT using this formula:

For the first Child SA:
KEYMAT = prf+(SK_d, Ni | Nr)

For all subsequent Child SA's
KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )

In both cases, KEYMAT is passed to IPSec to (presumably) create its own symmetric Encryption and Authentication keys.  But I haven't been able to find anywhere the formulas IPsec uses to take the KEYMAT and/or derivative keys (SKEYID_d or SK_d) and create its own keys.

So my question is, What does IPsec do with KEYMAT in order to generate its own symmetric keys?  And also related, What keys does IPsec generate after being given KEYMAT?  Although I feel answering the first question will also answer the second.

The IPsec stack does not create it's own keys, or request any keys for that matter, instead the IKE daemon generates as much key material as required for the negotiated encryption and authentication algorithms using the PRF+ (which can basically return an arbitrary amount of key material). How key material is taken from the expanded KEYMAT is described in detail in RFC 7296 (IKEv2), section 2.17.
The resulting keys are then passed with the rest of the information about an IPsec SA to the stack. With the standardized PF_KEY interface, for instance, this is done with two Key extensions if encryption and authentication is used.


Is it a good idea to store Email addresses as hash only? I am currently building a web service at http://write-math.com similar to http://detexify.kirelabs.org/ that should help users to get LaTeX code from drawn formulae. It is part of my bachelors thesis and a main goal of this project is to make it easier to do research in the field of on-line handwriting recognition. That means I want to share all data I get from users.

The easiest way to do so would be to simply dump the database. This way I could do my back-up copy and a dump for researchers in one step.

There are only two pieces where I hesitate to share it with the public as soon as other users use my system: Email addresses and passwords.

Passwords

The password is stored hashed and salted (that means I store md5($userpass.$salt) and $salt which is an 8 character random string with characters from A-Za-z0-9 - the salt is generated for each user). Is that enough so that it would be ok to make this public?

The main part of the question is about the Email address: At the moment, I store it as plain text. But I am thinking about storing a hash of the Email address only. This hash could not be salted, because my login function works as follows:

The user enters $email and $password. Both get sent as plain text to the server. Then the server does (as pseudocode):

$pwdb, $salt = query(SELECT password, salt FROM users WHERE email = :email)
if (md5($password.$salt) == $pwdb) {
   Logged in
} else {
   Wrong password
}

Email addresses

It does not matter if :email is $email or md5($email) or md5($email.$applicationwide_random_str). But I can't make a new salt for each user without having to go through each user (which would probably be not too bad when I think I will never have more than 10,000 users).

Questions

How long would it take to "unhash" one Email (e.g. info@martin-thoma.de or mexplex@gmail.com) which has a random salt of 8 characters attached (e.g. FHCJ81ru) with "standard" hardware (< $1000) when you don't know the random string? Is it a matter of seconds, minutes, hours or days?
Is it bad if people can do that? I mean they could also simply send Emails and look what they get back. In my service, there is not much personal data involved:

handwritten symbols and formulae
eventually handedness
eventually when / where the person learned writing
eventually the language of the user

Why does no service hash the Email address (ok, I don't know if there are no services that do so, but I have never read that - hashing passwords is common, but hashing Email addresses? Never heard that.)
Is it a good idea to hash Emails if you want to use the Email only if the user has lost his password and to sign in? (I though about using OpenID, but most people don't know what it is)

In the end, there are two questions: what you should store, and what you should share.

What you should store

Storing the email address has the advantage that you can contact users. A lot of sites do want to be able to contact users who are not currently logged in. For example, merchant sites want to be able to notify users that their order has been dispatched or that their payment bounced. A lot of sites have configurable email notifications. Sites may want to inform users of a privacy or security breach — people tend to prefer being notified privately than learning it in the news. And that's not counting all the nefarious purposes (sendind ---spam--- “promotional offers”).

If you decide that you never need to contact users, store (slow and salted! Not MD5 or SHA-2, but PBKDF2 or bcrypt or scrypt.) hashes of emails. But be aware of the limitations.

I assume that you'll be using email addresses as user unique identifiers. This has a downside: sometimes people change emails. For example, in the academic world (which a lot of users are likely to belong to), people often use their email from their current institution, and then the next year this email becomes unusable. This can cut them off from accounts that are too strongly tied to an email address. Be sure to allow a way to transition (which can be tricky if you require access to the old email address to add a new one).

What you should share

Brute-forcing a salting hash requires enumerating all the possibilities. The time it takes to try one possibility is a configuration parameter of a slow hash — you should make it as slow as your server supports, but no slower. So the answer to “How long would it take to "unhash" one Email” is literally “whatever you choose”.

How long it takes to brute-force your email database is not really the decisive question anyway. Verifying that an email is in your database is obviously practical — your server will be doing it all the time — and this allows someone who knows the hashes to answer the question “does Bob have an account?”. This is already a privacy breach.

The same goes for the password: even allowing third parties to check their guesses of Bob's password is bad. Not as bad as revealing Bob's password, but still bad.

So the simple answer is: do not communicate email addresses or passwords, nor hashes of them, to third parties. If you accidentally leak even hashes, this is a privacy breach. When you share data, use meaningless identifiers for user accounts, for example sequential IDs or random UUIDs.

Also beware of scope creep in your database. If you store too much information about a user, this can allow identification and making connections. This is a common problem with medical databases — if you happen to know that Alice was at Riverside Hospital from 1997-02-25 to 1997-03-03 and from 2001-07-21 to 2001-07-28, and there is a single patient record who was admitted Riverside Hospital in February 1997, left in March, and was admitted again in July 2001 — Alice has been identified even if her name was never exposed. This isn't likely to be a concern with the information you're planning to store now, but keep it in mind.


How does automated query compromise other Google users? Sometimes when using TOR browser / tor proxy, Google refuses to process the request you issue, especially if it's in a different language (e.g. searching for Arabic word while using German proxy).

For me I thought that its some kind of DoS attack prevention as Google might think that you're a bot who is trying to overload the engine with spam search requests.

But why the message error says that it wont process the query in order to protect their other users?

Is there some kind of queries that compromise other client on the internet using same search engine?

You're correct in your assumption that Google blocks this traffic in order to prevent the search service from being slow, but there are indeed other reasons:

Automated searches allow malware to scan for vulnerable web pages, using "Google dorks", i.e. search queries designed to match content on vulnerable sites. This would increase drive-by attacks across the internet, so Google is right to say they are "protecting" users.
Automated queries, if allowed, would probably account for a sizeable chunk of requests. This would cost Google money that they could otherwise spend on making better services for their human users.
You may not realise that your machine is sending automated requests, so the verification page is a good way to alert users, especially since a large chunk of internet users are likely to visit Google at least once in a browsing session. This is a nice way to catch malware.
Tor is a source of a lot of bad traffic, so it's reasonable to expect Google to cut that down to human stuff only. Automated queries via Tor make log analysis and all sorts of other forensic efforts more difficult, so if Google did suffer a breach keeping the automated traffic to a minimum could help.

However, there isn't really a direct effect on a specific user from an automated query. It's not very likely that an automated query would be particularly important from a threat model perspective; if the user is already unknowingly doing automated requests it would imply that they're already infected with malware, at which point their keystrokes and files are compromised already.


How do I prevent data from leaving my network? I have a network of about 10 computers and I want to prevent sensitive data and source code leaks. To achieve that, I would like to block all file uploading / attaching.

What are the options available to me?
Are there hardware firewalls that allow me to do this?

I was asked about your problem several times in several occasions. What makes it really difficult to answer is, that this in fact isn’t really a tech-problem. It's much more a social/human problem.

There are many great firewall-systems like SonicWall/FortiGate/etc. (also VM-Based solutions) which will cost you maybe only 500$. They are all able to block protocols / ports / sites / etc for you but... in my opinion you would need to block every site and every connection between your source control network and the internet, because there is always a way to use an established connection to get the source-code out of your business-place.
Even if one uses something simple like putty to establish an ssh-connection over port 80 and tunnel ports trough it for all kind of protocols like FTP/SMTP/whatever.

My advice to you is, don't try to get to an expensive technical solution when this really is a human, social problem. There will always be a way to get your source-code out of your place. (usb, cd's, photo via mobile phone? If someone wants to do so they will succeed...)


Third-Party-Cookies Tracking - Google Chrome I've read an article about third-party-cookies which explained that in Google Chrome disabling third-party-cookies will not stop the browser from sending third-party-cookies. So when I visit Facebook every day and get first-party-cookies from them, they can still track me in the internet although I've disabled third-party-cookies.

At first I couldn't believe that, but I have checked the HTTP-headers and the cookies were sent to Facebook. Firefox doesn't send third-party-cookies.

What can I do about it? Is a trackingblocker like Ghostery the only way to protect myself from being tracked?

I just tested that Chrome option and it seems to work for me. But if it doesn't for you, the next best thing would indeed be using something like Ghostery or  EFF's Privacy Badger

In fact, I'd probably suggest using one of these tools anyway. Because rather than blocking ALL third-party cookies (some are useful!), they only block requests to domains that are actually using them to track you.


implementing an authentication mechanism for understanding the basics of client authetication I'm trying to implement a simple protocol to authenticate users and authorize them to access a certain web page/resource via a login form.

Please note that this is just something to use on my own and that it's just to get the basic idea of how such systems work.

My idea is to store the hash of a shared secret between Server and client on the server side and then use a challenge-response mechanism to authenticate the user. The user would type an username and the server will respond with a challenge that implies the use of the shared secret to get access to the resource. For example, hashing the password and the challenge together and sending it back to the server. The server would do the same with the user's stored password and check if both values are the same.

However, how can this authenticate a user A to a server B if, let's say user C can intercept A's response to the server and send it to the server as if it was C? Then the server would authorize C to the resource A was supposed to gain access to.

Isn't this the way protocols such as CHAP or EAP work? (in an over-simplified way). I think I have a bit of a mess in my head, but the only solution I can think of to prevent a MiTM attack is to use TLS/SSL. But how do websites authenticate users nowadays without TLS? Also, OpenID seems to me equally vulnerable to man in the middle attacks, but it must be something I don't understand or I'm missing.

For example, hashing the password and the challenge together and sending it back to the server. The server would do the same with the user's stored password and check if both values are the same.

In this scenario, the server would need to have the user's complete password, stored in plaintext or encrypted form. This introduces a security risk - if your database becomes compromised then the passwords are given to the attacker. It's better to store the passwords as hashes, 'salted' with a random value to prevent rainbow table attacks. This way the server cannot accidentally leak the passwords because it doesn't have them to start with.

  Also, OpenID seems to me equally vulnerable to man in the middle attacks, but it must be something I don't understand or I'm missing.

OpenID is only effective if it's over HTTPs. Otherwise it is indeed vulnerable to a man in the middle attack.

  However, how can this authenticate a user A to a server B if, let's say user C can intercept A's response to the server and send it to the server as if it was C? Then the server would authorize C to the resource A was supposed to gain access to.

Again, HTTPs deals with this. In the initial handshake between Client A and Server B, messages are encrypted using public/private key encryption. This public/private key is stored in an X509 certificate kept on Server B, and Client A can validate the public key by ensuring it's signed by a recognized certification authority.

Server C might attempt a man in the middle attack by substituting its own public/private key pair, but Client A will recognize that Server C's certificate is not signed appropriately.


Verify the requesting domain I have a both a http and websocket server written in nodejs (for now) and it will be receiving requests from many different domains. The request is made from the client using JS.

I need to verify 100% that the request is from that originating domain. When I receive the request I want to verify the third party domain from which it originated - to ensure someone is not submitting requests pretending to be another domain.

I can give each domain an identity, but the request is originating from the client side.

I am using HTTPS on my domain.

Let say I am running a server at A.com and I allow people to download my JS client-side SDK and make requests to my server. When I receive a request from B.com I need to ensure this is where the client actually is.

Is SSL / HTTPS enough? Should I assume that when my server receives a request from an SSL enabled site I can 99.999% trust the URL in the header?

I'm not entirely sure what you mean by this

  When I receive the request I want to verify the third party domain from which it originated - to ensure someone is not submitting requests pretending to be another domain.

For example, here's the HTTP request that my browser made to load this page:

GET /questions/196706/verify-the-requesting-domain HTTP/1.1
Host: security.stackexchange.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:64.0) Gecko/20100101
Firefox/64.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Cookie: ... snip ....
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

Nothing in there indicates which domain my web browser is coming from. I'm not even sure I know what that means.

Maybe you mean that your API will be accessed from pages served from other domains and you want to mine the Referrer: header?

Referer: https://my.domain.com/somepage

Either way, the client-server architecture of HTTP means that there is no security here; the client can literally put whatever it wants in the request and the server has no way to verify if it's "correct". Whether it's using HTTP or HTTPS makes no difference here.

Consider the following cURL command which shows that I can craft an HTTP request with any header text I want, and then send it to any server I want:

curl -X GET -H "Accept: text/html" -H "Referer: https://my.domain.com/somepage" https://someHostName/someEndpoint

Solution: Mutual-auth (aka "client auth") TLS

It sounds like the solution you're looking for is mutually-authenticated TLS, which is designed precisely to force the client to prove its identity before the server will open a connection.

This would involve issuing certificates to your clients (just like you do with your server), and then configuring your server to only accept incoming connections from trusted certificates.


Is Changing a File Type and Name an Effective Security Solution? Is renaming folders & files and changing file types an effective solution for file security of a PC?

I am an application programmer and have an extensive background in it. I have written a robust program that renames folders and files and also changes file types. It does not compromise the integrity of the file, although I have been able to do that as well and change it back.

I am just wondering, how secure this is. I know that if for example I change: test.jpeg to test.txt, if someone were to simply change it back, my security is compromised. I've obviously made it more complex than this, but is there a loophole? Is there a way to check PC logs for file changes or some other way a pro would decipher this. As I said, my program that 'encrypts' these files is very robust, I highly doubt anyone but myself would be able to understand / compromise it.

Some of the security vulnerabilities I do know about:

A user could simply rename all of the files and thus have beaten the
security

To solve this I would add a header line to files so that even if the file was renamed it could no be read by the program.
For images a user could check the system thumbnails

To counter this I clear all temporary files upon encrypting files.
PC backups that contain the non-encrypted file

Know and control your backups.

Any other ways to crack this security?

A further note to this, this security solution was thought of after having CryptoVirus attack my server. Awfully impossible to reverse the changes that that virus made. I thought why not apply the same methodology to my file security.

Another note is that I am building upon Windows 7, with thoughts to expanding to other Windows platforms.

What you are doing is no kind of encryption, it is just obfuscation. It relies on security by obscurity. It may be enough to hide your files from an amateur/casual observer, but anyone analyzing the files in a hex editor is going to be able to rebuild and access them.

Effectively your method is about equal in complexity to attempting file undeletion, for which there are a host of tools available to anyone versed in digital forensics.

By contrast, the CryptoLocker malware you mentioned uses valid public-key cryptography, which is probably a method you should consider.


How dangerous is disclosing a table's structure to users? I apologize if this is a dumb question.

I recently came across a website that embedded its error log out in a JSON response if the request to the website failed. In this case, it appeared there was a DB mismatch and it printed the SQL request, including the DB table's structure, to the console like so:

How unsafe/dangerous is this, and why?

My gut tells me this is bad practice and is not very safe, but I can't exactly pinpoint the reason why.

What you are referring to is potentially an error-based SQLi vulnerability, which falls under a larger category known as In-band/Classic SQL injection. Essentially, these vulnerabilities allow an attacker to both launch an attack as well as gather information about the database from the same communication channel. I say it is only a potential vulnerability because we are not sure if you've actually tried SQLi, rather you've just discovered an error. This can be confirmed via testing, assuming permission.

The error-based SQLi vulnerability you are potentially seeing provides information about database structure (as you've pointed out) which aids in enumeration of the database (potentially the entire database) for the attacker.

It's saying, "Hello friendly internet user who I have no reason to mistrust, the query you are trying to perform (with obviously no malicious intent) is unfortunately incorrect, so here is the exact structure of my database so that your next query can be more appropriately written to achieve success!"

Such a verbose error message should be disabled on a live site or logged to a file with restricted access. A better practice would be to, depending on the situation, provide the user with either a 400 or 500 error while being cognizant to not provide more information than is absolutely necessary.


Minimum SHA256'd UTF8 encoded passphrase length not stored anywhere For a passphrase that is UTF8 encoded and then SHA256'd, what is the minimum length to achieve a practically collision free result?

The implementation is for a 32 byte cryptocurrency ed25519 seed thus will not be stored anywhere by the implementation.

Of course I cringe at the idea of a simple hashing over a passphrase, but let's assume that it is actually OK in your setup.

The direct answer to your question is simple: practically, there are no collisions in SHA-256, regardless of input length. If you input two distinct sequences of bytes (e.g. two passphrases), you will get two distinct output. Mathematically, we know that collisions MUST exist (SHA-256 input space is larger than the output space), but we found none yet, and the best known methods for finding collisions have average cost 2128, i.e. a lot more than is feasible with existing technology.

Input length and encoding have nothing whatsoever to do with the subject. How you imagined that input length, furthermore minimum input length, or encoding, had an impact on collisions, is a mystery to me -- so I have to assume that you do not worry about SHA-256 collisions. Instead, maybe you worry about the probability of two distinct people coming up, out of (bad) luck, with the same passphrase ? (SHA-256 being there a red herring.)

If that is your actual question, then it depends on the process by which the passphrases are generated, which has only a very distant relationship with the passphrase length. See this answer for details on how to calculate entropy (because an entropy of "n bits" roughly translates to a probability of collision of about t2/n, as per the birthday problem).


Given a large enough sampling of public keys could one begin to identify a private key? For example, an ISP or government capable of tracking millions of keys being exchanged. Would that provide a sample large enough to be able to identify the private key on either end?

No.

Examining public keys gives you no insight, no matter how many you see, that would allow you to derive the private from the public key.


How to tell Mifare Plus from others? How would one determine what version of Mifare a system is using, if one only has access to the fob?

For example:
https://www.amazon.com/MIFARE-Blue-Key-Fobs-RFID/dp/B011PJXG0U

From the product info this cheap blue fob can be used for any of the Mifare standards. What is the minimum equipment that one would need to discern the version and whether or not it is encrypted?

I'm not specifically familiar with how the Plus works, but I can comment on the first two questions.

To identify a card, you can look at its SAK and, if applicable, its ATS. MIFARE card identification procedures are shown in this document, on page 7. This webpage has some additional information.

To interact with the card, you'll need an NFC reader, such as an ACR122U, as well as libnfc. Libnfc's nfc-list command will print out some basic information about any cards it detects, including the SAK and ATS (if applicable) needed to identify the card. I also made my own tool to print out basic information about a card and roughly identify it, and you can see how that works here.


Retaining institutional knowledge of a complex infrastructure (checkpoint, juniper, etc) In the next month my functions will be expanded to include IT security (firewalls, VPN, PKI) in a big complex infrastructure. Can I ask you for advice on how-to be well prepared for it?  What sorts of tools and checklists should I use when transferring institutional knowledge from colleagues who have decided to leave the company?

You'll want at a minimum:

1.) logical infrastructure diagrams

2.) physical infrastructure diagrams

3.) usernames/passwords at the admin (enabled) level

4.) peer router lists

5.) trusted user lists

From this point you can audit configuration settings and start baselining the current network activity. Where you go from there is up to you.


Disallowing new password if it contains sequency of 4 characters present in 10 previously used passwords I was forced to changed my password to an account (large institution) and it had a rule that the new password cannot contains a series of 4 consecutive characters that were in 10 previously used passwords. For example, if my current password had the sequence "abcd", the next 10 passwords cannot contain "abcd".

My first guess is that the institution is storing 10 previous passwords in a decodable manner. My question is thus: is there any way they could be doing such a procedure in a secure manner?

In another question we have a comparison to the current password which would be provided by the user, but it doesn't deal with 10 (!) previous passwords.

Yes this can be implemented securely through the use of an HSM.  there's an existing question on this here


How can I use the free version of Burp to identify input HTTP urls for my site I want to create (and update ongoing) a list of input vectors for my site, including forms (GET and POST etc).

I am new to pen tesing, and have been pointed at Burp (free). I have Spidered my site, and see a comprehensive sitemap.

What is the best way to filter that list (or otherwise) so I can get an idea around what points to look at protecting for XSS and CSRF?

You can filter or view parameterised requests (either GET or POSTs). These are shown in the site map. These will show you where input could possibly lead to an XSS or CSRF vulnerability.

However, be aware that XSS attacks can also happen via HTTP headers or cookies, or any other external source of data to the application.


How to encrypt sensitive user data and transport it between client and server securely? I'll try to be as brief as straight to the point as possible, i'm new to this so please bare with me!
I might be committing a massive mistake and not even realised! Please HELP! [facepalm emoji]

Application Requirements:

The frontend must be a website
User must provide his own API TOKEN and SECRET to a 3rd part API
While logged in on the website the user can manually trigger actions on such 3rd API through my application UI
While the user is logged out my service must do scheduled calls to the 3rd part service ( read as: one server must be able to read and send his keys via POST to a 3rd part service in plaintext )

Here are the steps i'm taking in order to decrease my surface attack:

Deploy a micro-service that will be responsible only for storing keys and doing background jobs
Generate an RSA key for my micro-service
Hide the micro-service from the user by only having the url on the backend side ( use my http server as proxy )

When the user manually execute an action through my UI:

I'll generate an RSA Key on the client side using his password ( must be strong ) as passphrase and generate a 1024 bit Key, send the public key to the HTTP Server which will send it to the SECRETS SERVER
On the secret server if the user was never registered i'll save this user_id and associated public key
When the user input his keys, i'll encrypt the keys with the PUB KEY of my SECRETS SERVER and sign with user's private key
Post it to my HTTP SERVER which will post to my SECRETS SERVER
My secret server checks if the message was signed by the pub_key he excepts and if it is, save the user data encrypted with it's own ( server ) private keys on the database

When a background job must be executed:

The SECRETS SERVER read the key from the database, decrypt the API KEYS, does the HTTP POST and remove the plaintext from memory

What could go wrong? ( as far as i understand! )

Someone gets access to my HTTP server, discovers my SECRET SERVER, crack into it, read the database credentials and the private key, get the API KEYS and run away.
Someone get access to my credentials, finds the secret server computer, manages to download the database, find the private key, get the API KEYS and run away.

Key questions:

What else could go wrong?
Generating an RSA key on the client side using user's password as passphrase is "good enough" ?
Will the RSA key generated on the client be constantly identical regardless of the computer they log in?
Does this even make sense?
On this thread if i understood correctly it's recommended to "stretch" the passphrase before generating the key, but since a user could reverse engineer the .js file on my website they would also discover how the key are stretched, right?

Thank you for reading it all through! I really appreciate any advice.

This seems like an overly complex solution to the problem.  An important thing to remember with cryptography is that even if the cryptosystem is implemented perfectly, if either of the endpoints is compromised, attacker can access the plaintext data.  Your microservice does not need to be made secret, nor does it really need to be made separate from your main web application.  Having it on a separate server really only adds complexity.

The best solution, if the 3rd party APIs allow for it, is to store and use OAuth tokens.  Only store the API tokens/secret if OAuth is not available.

Regarding transmitting the data to the server, you do not need to implement your own encryption in the browser.  Properly implemented SSL will solve the problem of transmitting the key securely.  Consider using Http Public Key Pinning (HPKP).  Be aware of the potential pitfalls of HPKP before you implement it.

Regarding the storage of the tokens, the OAuth/API tokens should be stored in a salted & encrypted column in the database using a symmetric block cipher, the key should be stored in some place outside of the database (to prevent it getting exposed via a SQL injection attack), and the web application/batch job should be able to access that key and decrypt the tokens.   The key you use to encrypt the data will be shared across all of the records, and should not be made available outside of the server that your records are stored on.


Did Mt. Gox lose their own or customers bitcoins? I understand bitcoin superficially, and the concept of the blockchain.

When I heard about Mt. Gox, I assumed that they had lost their own money. But apparently, they lost their customer's money.

If one can only give away their bitcoins by providing their private key, I would have assumed that hacking Mt. Gox would not have aided the hackers with any raid on Mt. Gox customers money.

Am I missing something?

OK, first a correction:

  If one can only give away their bitcoins by providing their private key,

No. You send bitcoins to another party by signing a transaction that transfers the bitcoins from your address (controlled by your private key) to another address (controlled by the other party's private key). Actual private keys should never be exchanged, ever.

What happened with MtGox is that their customers willfully transferred bitcoins to them in order to trade/exchange on their platform. By doing this they essentially gave MtGox full control of the bitcoins, and MtGox lost them.

So yes, MtGox lost their customers' funds.


Do I need to disable TLS 1.0 altogether? We recently went through a third party review of our systems where the consultants have reported a finding that we have TLSv1.0 enabled. In the report they are referring to this NIST document which recommends (Page 28):

  If the server supports government-only applications, it shall not be configured to support TLS version 1.0.
  If the server supports citizen or business facing applications, it may be configured to support TLS version 1.0.

We are not the government but for the sake of a security I decided to run the online SSL Analyzer and check if there are any issues. It did not show any red flags.  My question is, Do we really need to disable TLS 1.0 altogether.

We are dealing with Admin portal of a web application which does not contain any kind of payment features so PCI-DSS is not a requirement for us.

Before you disable this get an audit of browsers connecting to your site. You need to cross reference this with TLS 1.0 support. This will give you an idea of your customer base that requires this as if they can't support anything over TLS 1.0 you will be cutting them off.

As for do you need to cut it off, what does your app do?
What regulations does your industry follow?


stack buffer overflow in the main function? I am trying to exploit a stack based overflow vulnerability. All the examples I can find make use of a ret address though. The buffer overflow I found is inside the main function, and I cannot find any examples on how to do this.

The code looks like this:

int main(){
   while (1){
   //some code
      switch() {
         case 0:
         char id[128];
         sscanf(buffer,"%s", id);
         break;
      }
   }
}

The contents of buffer are controlled by the user.

You've run into the hardest part of exploiting a buffer overflow: determining how to get the code to execute. Injecting code is trivial once you've found the vulnerability, but getting the CPU to start executing that code, not so much.

Without a strong understanding of stack frame layout, you will find the rest difficult to follow.

One point of note is that in C, main, from the process's viewpoint, is just another function that is called (this is different in C++ see comment below). While you think of it as the beginning of execution, to the CPU it is a full function call with a return address on the stack. So exploiting a flaw in main is the same as exploiting a flaw in any other function.

As an attacker, all you can do with a buffer overflow is write to the data section of the process, you need to find a way to have the process read something from data that controls what will be executed. Basically, you need a place in data memory where the process will look to determine what should be executed next (ie: to determine the value of the program counter or PC).

The most common type of locations in data memory that affects the PC are a function's return pointer. When returning from a function, the CPU will read the return pointer off of the stack and set the PC to it (or the instruction after it - details CPU dependent). Unless you return from the main function it is very unlikely that you'll execute a successful attack. You'll need some place in data, preferably on the heap, where the processor will read data that is used to set the PC.

The other "common" (tho much less common) places in data memory that are used to exploit a buffer overflow attack are function pointers followed by a function call, and exception tables followed by an exception. Neither of these seem applicable to your application. So you probably have a non-exploitable stack buffer overflow vulnerability. The worst I suspect that you can do is crash your app.

The steps the attacker needs to take for a standard stack buffer overflow exploitation are:

Identify stack buffer overflow vulnerability.
Determine address of stack at time of vulnerability.
Determine address of function return pointer in current stack frame.
Write code (frequently called shellcode) for attack.
Create input that loads code and modifies function return pointer to point to shellcode on stack.

So now that you've found the vulnerability, you need to determine the stack address for call to main. The easiest way to do this is to print the address of id. Next, the return pointer's location. This is likely two words lower in memory than id. Something like (char *)id-2*sizeof(int).

The next step is to write your shellcode. I'd suggest you create a function in your program that prints the string "attack successful" and then exits. Make your shellcode a call to this function.

Now sit down and layout the data on the stack (this stack frame layout reference should help) including a return address jumping to your id variable's buffer. Convert the stack data to ASCII and input it to the program.

This page has a more concrete example of what I've described.


Why is Linux ASLR weak? Wikipedia says Linux kernel has a weak form of ASLR by default and only adding PaX or Exec Shield patches enables complete ASLR.

What is the weakness of default ASLR in Linux kernel? Has it been fixed/improved in recent versions? If not, is there a reason why the mainline kernel chooses to not provide a complete implementation?

The Wikipedia article continues:

  This places the stack base in an area 8 MB wide containing 524,288
  possible positions; and the mmap base in an area 1 MB wide containing
  256 possible positions.

The latter is way too small to be effective, and an attacker only needs to probe 256 addresses in one segment to find the mmap() address pointer.

What the article doesn't mention is the limited use of ASLR in Linux. Traditionally the 2.6 kernel only used ASLR for (network) processes in specific memory areas (when PIE compiled) while loading the VDSO to a fixed address. Such a measure is only effective if all the addresses are randomized. Newer kernels have better support for address randomization. Note that various Windows versions did the exact same thing.


lan-side denial of service affecting target's CPU performance Why does a LAN-side UDP flood take up the target's CPU resources and make it sluggish? i.e: the mouse doesn't respond properly, opening an application is slow...

Note: The computers are both connected to a switch which connects to the router. Also, the target noticeable becomes sluggish when opening a web-page, and even after closing the browser the slow performance remains at that same level.

Just in case I didn't clarify, the poor performance happens on the computer that is being flooded, not the computer performing the flood. As soon as the denial-of-service is stopped, the target returns to it's normal performance.

Why does a LAN-side UDP flood take up the target's CPU resources and make it sluggish?

This depends on a number of factors, one of the primary being what action is taking place on the system receiving the UDP flood. Let's take a look at the basics of the process.

To begin, the host receives the UDP traffic. All received traffic must be processed to some degree. At the very least, the destination port of the UDP traffic needs to be determined. This means the Ethernet and IP headers are removed as it moves through the network stack and is handed off to be processed as a UDP segment. There may also be firewall rules to process as well.

The destination port is checked to see if there is an application listening on that UDP port (either a service bound to the port or a port used by outbound traffic that may be expecting reply traffic).

If there is an application listening on the UDP port, the UDP headers are removed and passed to the application. The application then needs to process the data in whichever way it is configured to do so.

If there isn't, the host can respond in one of two ways: silently drop the data or to reject the data. Rejecting the data is generally considered more "friendly" and makes things like debugging easiers as a notice that the traffic is rejected is sent back to the source of the traffic using ICMP. This is good when traffic is accidentally sent to the wrong host or port and can cause the unwanted traffic to stop (if the sending host/application recognizes the traffic is unwanted).

So, we have a process. Now, in that process, most of the above can be done in hardware if the network adapter (and the driver, OS, etc) support it. What isn't done in hardware is done in software by running on the CPU.

Where can the use of the CPU come from? Largely from the following four possibilities:

Processing the received traffic (Ethernet -> IP -> UDP), including any firewall rules
Checking for applications listening on the UDP port
Application processing data received on a listening port
Generating return traffic (ICMP error messages)

Why a specific host becomes sluggish would be the result of it performing one or more of the above in software (i.e. CPU).

If a host processes the traffic (including firewall rules) and drops unwanted traffic (or processes the reject) all in hardware, there should be no impact on the CPU as a result of a UDP flood to UDP ports to which it has no application listening.

How a specific application is affected by receiving unwanted traffic to a port it is listening on would be entirely up to the application.


OAuth: Long running access in downstream systems - how to refresh token? In case of OAuth2 and OpenID Connect user authorized AppA to access AppB service. Now AppB needs to access AppC and it uses the bearer token received from AppA (suppose the scope of that token included both B & C):

AppA -Bearer-> AppB -Bearer-> AppC

But what if AppB needed access to AppC for long time (some polling happens for couple of hours). The Bearer token is revoked by that time and AppB doesn't have refresh token (AppA has). What are the options here?

Well, the simplest approach is to just push the refresh token down to App B as well and let it handle refreshing itself. This could lead to some unintended behaviors on App A though if the refresh token is refreshed on refresh as well (say that 5 times).

What you might consider doing is adjusting the authorization server to exchange an access token for an access/refresh token pair, so App A sends it's token to App B, and App B takes that token and exchanges it with the authorization server for it's own tokens. Then it manages the token on its own. That assumes you can modify the authz server though.


Is there malware on my mac? So, a funny thing just happened.

I have my (personal) mac connected to the wired enterprise network and have for several months. Today, a couple of guys from IT came busting through the door saying that they were seeing a malware threat from a computer hardwired to the network that matched my computer's device name.  Fair enough, let's take a look, I said.

Here's where I'm confused...

The MAC addresses (their reported threat and my computer) didn't match.
The malware they were seeing is win.trojan netwiredrc variant keepalive1
I ran malware-bytes for mac and it didn't turn up anything
I run AVG antivirus constantly to try to prevent things such as this

My questions are:

Does this trojan even affect Macs?
At the time they said they saw the report, I was running a Citrix instance to an application that is also hosted by my organization (the same IT group). Could this virtual machine have the above trojan? If so, would this explain why the MAC addresses didn't match but it still showed up as my computer name?
Is this a false positive? If so, how do I convince the IT department of that so they'll allow me to connect to the wired network again?

Thanks in advance.

UPDATE (9/11/18): Over a year has passed and this issue happened again with the same result. AVG scan with no issues, malware bytes scan with no issues.  The same trojan identified.

Can someone tell me the nuts and bolts of how these trojans are identified on a network scanner? In other words, are is it looking for particular packets of information being passed through or patterns of activity.

I would avoid using the Windows VM until you've investigated further - a fresh install of Windows may be warranted. As for macOS receiving a Windows Virus it's unlikely unless you use a tool like Wine. I would run an anti-virus scan on both your macOS install as well as the Windows VM. It's important that you communicate with the IT Staff and get the issue resolved they are hired there to help you - work with them to resolve the issue and networking can be restored.


Mars Curiosity Rover Security Does the software in the Mars Curiosity Rover have any security features built-in? I can't imagine how someone would hack into it, but if the rover does indeed have some protection against malicious hackers, what kind of attacks would it be protecting itself against?

I used to be a Command Controller (CC) at the Laboratory for Atmospheric and Space Physics (LASP) (http://lasp.colorado.edu/). I was one of the people who would sit in front of the console during the times when spacecraft were visible to the ground stations. I would read/record telemetry to ensure spacecraft health and often send up new commands that would be executed by the spacecraft.

In order to communicate with the ground stations (for both data and voice if necessary), the Mission Operation Center (MOC) at LASP had to have a connection to NASA's "red net". I am not sure if this was a LASP term or a NASA term. A google search turned up little information.

In order to be even let in the room with access to the "red net" background checks were required. Then, in order to actually interact with the console, you had to be a certified CC, or a CC in training being overseen by a certified CC. All CC activity is always overseen by a "Flight Controller" (FC) or even a "Flight Director" (FD).

In the training to become a CC, we all had to know exactly the packet structure of the communication protocol for every spacecraft we operated. While there were most certainly checksums in the protocol, I don't believe that there was any sort of encryption, authentication or verification of the data received by the spacecraft. The spacecraft are always designed to be very fault tolerant, and have fallback modes in case the RF communication is corrupted or there are other "single bit errors". Error detection and correction is a fundamental feature of RF spacecraft communication.

I also worked on one deep space mission, though not as a CC. Anything not in earth orbit would require much larger antennas and likely what NASA calls the "Deep Space Network" (http://deepspace.jpl.nasa.gov/dsn/). This makes an attack even more challenging.

The risks as I see them today are several fold. I am not sure if they have since been fixed as I haven't worked at LASP in many years. I am also completely unaware of the design of anything but a few scientific missions. The worst things I think an attacker could do would be:

Threaten to deorbit the spacecraft, or even simply waste precious propulsion fuel, for mischeif or for ransom.
Threaten to try to change the orbit which could possibly cause a collision with other spacecraft -- again, for mischeif or ransom.

Otherwise, I am not sure what could be gained by an attacker.

Here are the vectors I see that may make an attack possible:

Forged communication with the spacecraft. This would have to be done with knowledge of the spacecraft's ephemeris and with the ability to establish communication with the spacecraft. The ephemeris is fairly easy to obtain, but getting control of a ground station may require that the attacker be a state actor.
Man in the middle (MITM) attacks between the ground station and MOC. Getting onto the NASA "red net" would be highly challenging. This is the same network that the space station operates on. However, once there, it might be possible to somehow become a MITM and pass on good or forged telemetry to the MOC while sending arbitrary commands to the ground station (ignoring any commands sent by the MOC). This would also require that the attacker have fairly vast resources and prior knowledge.

In either of these cases, the payoff would likely not be worth the reward. Then again, I only worked with "smallish" scientific missions. It might certainly be worth the risk for one country to "steal" a military spacecraft from another as the cost for a country to design, launch and maintain such a spacecraft is likely much greater than the cost of the attack. I imagine these have much stronger security though.

To answer your question, I don't know how secure the Mars Curiosity mission is. However, due to the distance, it probably operates solely on the DSN ground stations (very large antennas, of which there are only a handful in the world). Any attacker would either have to commandeer one of these stations, or build his own (which would be hard to hide). Further, the security of the communications between the ground stations and mission operations is certainly a top priority for NASA and JPL.

In summary, communications reliability is a much greater concern when designing spacecraft -- it's really hard to talk to stuff so far away, with so much interference in-between and the constant bombardment of radiation that can affect just about anything in the process. While there may or may not be any sort of encryption, authentication or verification in the RF communication between the ground station and the spacecraft, the ability to actually interfere would likely only be available to nation-states. It would also be hard to hide who would be behind such an attack and the political fallout would likely be immense.


My WebSite is being attacked, should i be worried seeing the logs? Recently i just checked my server and found in logs that it is being attacked. Seeing the logs i am not able to exactly figure out, if i should actually be worried.i checked the attacker domain rating on opendns, it is not good.Follwoings are the logs of the request received:

31.210.102.114 - - [04/Mar/2017:16:31:37 +0000] "GET / HTTP/1.0" 200 2095 "-" "masscan/1.0 (https://github.com/robertdavidgraham/masscan)"
190.248.156.50 - - [04/Mar/2017:16:53:33 +0000] "GET /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 404 54 "-" "ZmEu"
190.248.156.50 - - [04/Mar/2017:16:53:33 +0000] "GET /phpMyAdmin/scripts/setup.php HTTP/1.1" 404 41 "-" "ZmEu"
190.248.156.50 - - [04/Mar/2017:16:53:33 +0000] "GET /phpmyadmin/scripts/setup.php HTTP/1.1" 404 41 "-" "ZmEu"
190.248.156.50 - - [04/Mar/2017:16:53:34 +0000] "GET /pma/scripts/setup.php HTTP/1.1" 404 34 "-" "ZmEu"
190.248.156.50 - - [04/Mar/2017:16:53:34 +0000] "GET /myadmin/scripts/setup.php HTTP/1.1" 404 38 "-" "ZmEu"
190.248.156.50 - - [04/Mar/2017:16:53:35 +0000] "GET /MyAdmin/scripts/setup.php HTTP/1.1" 404 38 "-" "ZmEu"
190.248.156.50 - - [04/Mar/2017:16:53:36 +0000] "GET /SQL/scripts/setup.php HTTP/1.1" 404 34 "-" "ZmEu"
190.248.156.50 - - [04/Mar/2017:16:53:36 +0000] "GET /myAdmin/scripts/setup.php HTTP/1.1" 404 38 "-" "ZmEu"
190.248.156.50 - - [04/Mar/2017:16:53:36 +0000] "GET /mysqladmin/scripts/setup.php HTTP/1.1" 404 41 "-" "ZmEu"
46.229.164.99 - - [04/Mar/2017:17:42:46 +0000] "GET /robots.txt HTTP/1.1" 404 23 "-" "Mozilla/5.0 (compatible; SemrushBot/1.2~bl;
+http://www.semrush.com/bot.html)"

Setup Fail2Ban, or it's equivalent, to monitor your weblogs and automatically block the IP address from people doing stuff like this. Always keep an eye on your logs but have plans in place for what to do when things happen.

Every system on the Internet gets scans like these pretty much daily if not hourly in some cases. Learn how to harden your server and applications so you don't have to worry and test it with everything you can. There is a lot to doing security well but tools like Fail2Ban can help a lot.

https://www.fail2ban.org/wiki/index.php/Main_Page