Do as many mitigations as you can.

Your goal is to force a wide variety of potential attackers to spend more effort, resources, computer time (and thus electric bill), and most especially "skilled" (rare or scarce, and thus valuable) person-hours. No one protection works against every threat.  Not every threat can be protected against while still remaining on the internet.

However, a large number of threats (script kiddies and low skilled or low resourced attackers) can be defeated almost all the time by having a defense in depth - many layers of good, solid security, each of which should - theoretically - be enough to defeat many threats on its own.  Thus, when your system's iptables rules let someone in by accident, the SSHD certificate authentication keeps them out.  When your SSHD service has a flaw, your VPN prevents anyone from seeing it.  When both your VPN and your SSHD have a flaw at the same time, your firewall rules prevent most of the world's IP addresses from even attempting it, leaving only locals and large botnets to be able to try and exploit the vulnerabilities, which you patch as soon as possible.

Thus, I say again, put in as many mitigations at as many levels as possible.  You cannot know in advance which ones have undiscovered vulnerabilities, and which order those will be exploited in.

Make certain you only allow SSH v2

sshd_config

Protocol 2

Stay patched
Use your iptables to allow ONLY the IP addresses or ranges you actually use
Set up your SSH to allow access ONLY by certificate, not by username/password, per the Ubuntu help site SSH/OpenSSH/Configuring page

sshd_config

PubkeyAuthentication yes
PasswordAuthentication no

If you use an encrypted home directory

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

If not, the normal setting for home directories can work

AuthorizedKeysFile    %h/.ssh/authorized_keys
Make sure there's not excessive permissions to it.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod go-w ~

And set up as strong a certificate as you can.  Generating keys is covered at the Ubuntu help site SSH/OpenSSH/Keys page

I'd start with a 4096 bit RSA key or an ed25519 key with a long, strong passphrase.  Be sure to generate it locally, type in a long, strong passphrase when prompted, use -o to ensure the new OpenSSH 6.5 key format, and make sure the server never has anything but the public key.

ssh-keygen -o -t ed25519 -f ~/.ssh/id_ed25519
ssh-keygen -o -b 4096 -t rsa -f ~/.ssh/id_rsa
To check length on an existing key, use ssh-keygen -e -f mykeyfile

If you can, restrict keys in the authorized_keys file to a specific IP address or set of hostnames

from="192.168.1.2" ssh-rsa ABCDE...012 test@test.test
from="*.test.test,!BadPC.test.test" ssh-ed25519
ABCDE...012 test@test.test

If you're on OpenSSH 6.8 or higher, you can restrict authorized keys to certain types as well in sshd_config

PubkeyAcceptedKeyTypes ssh-ed25519*,ssh-rsa*

Use fail2ban to make brute force attempts take more effort (i.e. make them use a botnet instead of only one machine, or make them take a lot of time)

Setting up certificates (keys) is superior if you're asking which one to do first

Reduce your login grace time

If you're using certificates, you have the option to crank it WAY down unless you use very, very slow connections

LoginGraceTime 8

Otherwise, well, how fast do you type?

LoginGraceTime 20

Control your cipher suite choices with information from Mozilla.org Security/Guidelines/OpenSSH

Since it's your server, and only you are getting in, you can select a very, very tight grouping such that only the most modern clients are allowed.  Perhaps
HostKey /etc/ssh/ssh_host_rsa_key

sudo ssh-keygen -o -N '' -b 4096 -t rsa -f /etc/ssh/ssh_host_rsa_key

or
HostKey /etc/ssh/ssh_host_ed25519_key
sudo ssh-keygen -o -N '' -t ed25519 -f /etc/ssh/ssh_host_ed25519_key

obviously match your HostKey filenames exactly!

or both (most preferred first)
remove all dsa keys entirely; they're fixed at a pathetic 1024 bits for SSH

Use ssh -Q directives to determine what your system supports for the cipher suite options
KexAlgorithms curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com
Or whatever specific choices make you feel safest
And keep up with the literature; when there's a flaw in something you've chosen, choose something that doesn't have known flaws at that point in time.

Use your iptables (or firewall) with blocklists from I-blocklist
Use your iptables (or firewall) with geographical or ISP based IP lists; one such source of geographical lists is maxmind.com
Switch to a port in the dynamic (ephemeral) port range of 49152 to 65535 per RFC6335

And only bind to the IP addresses required

Block everything other port on that server via iptables; chances are you're getting hit by a LOT of attacks

Especially harden your MySQL database, if any - I see a LOT of MySQL (and SQL Server) attacks on my IDS, and I've never run either one or had either port open.  Set them to local, non-routable IP's only, etc., long passwords, disable them, etc.
Especially disable any web servers, set them to local, non-routable IP's only, etc.

Use port knocking per the Ubuntu help site or a DigitalOcean article
Rate limit new connection attempts, per this answer to ServerFault question "Hundreds of failed ssh logins"

  iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 5 --name SSH --rsource -j DROP

  iptables -A INPUT -p tcp --dport 22 -m recent --set --name SSH --rsource -j ACCEPT

Consider using chroot per the Debian documentation
"OpenSSH SFTP chroot() with ChrootDirectory"
Ensure rhosts is disabled with the sshd_config option

IgnoreRhosts yes
RhostsRSAAuthentication no
RhostsAuthentication no

Add more restrictions to the pre-authentication unprivileged process

UsePrivilegeSeparation sandbox

If you aren't using fowarding or tunnelling, disable it in sshd_config

X11Forwarding no
AllowTcpForwarding no
GatewayPorts no
PermitTunnel no

Prevent other insecure setup in directories or permissions

StrictModes yes
And then go through your permissions and settings until it works again :)

Disable host based authentication

HostbasedAuthentication no

Note that per This Serverfault answer to "OpenSSH daemon ignores ServerKeyBits directive", the old ServerKeyBits sshd_config directive is no longer applicable, since you don't allow SSH v1 in the first place.
Don't allow root in sshd_config

PermitRootLogin no

Don't allow different users - perhaps service users on some package you install - to have other options

PermitUserEnvironment no

Install a separate, all-up firewall like pfSense or a Ubiquiti Edgerouter Lite between that machine and the outside world.

And then use the built-in VPN IN ADDITION TO your hardened SSH login
Also with certificate based logins, not username/password based logins
If you use OpenVPN

Make sure to use a --tls-auth "ta.key" pre-shared key as well
And choose better ciphers than the default

And use the blocklists mentioned above at this level also

As DeerHunter mentioned, changing ssh and/or iptables and/or other firewall settings without any other way in can result in a lack of ability to SSH in.


RDP Attempts From Unknown IPs, How to Protect?

Not exactly proven security, but Port Knocking can allow you to open up closed ports by sending a special set of packets to the server first.

You could also rent out a cheap server with a dedicated IP address and set up a VPN, then explicitly set the firewall to only allow connections from the VPN IP.


Does sending hashed password over url path parameter secure?

Not really a direct answer, but way too long to be a comment.
I once had to design a system where I had to securely authenticate over a plain HTTP (not HTTPS) connection using an insecure network. And I finally ended with a manual implementation of a Diffie–Hellman key exchange using asymetric crypto tools. BTW after the authentication phase, the shared secret was used to crypt and sign the packets (and the packets were of course numbered)
The rationale is that:

it only used well known secure implementations (at library level) - roll you own is highly dangerous in security, because the devil hides in the details
no secret was ever transmitted in clear text
the protocol was by construction immune to replay attacks

My conclusion was that Diffie-Helman was not used by accident in TLS...
It is slighty more complex to implement than directly sending a secret, and only makes sense if you cannot trust an underlying TLS layer to protect the exchange, but for having implemented it, it is not that hard once you can find a nice crypto library.
BTW, if you want to be super-safe, ephemeral Diffie-Helman allows Forward Secrecy and is easily implemented with good crypto libraries.


How to use sqlmap to perform SQL injection on a clean URL?

You need to look at the actual HTTP requests that are happening as the page loads. When a page uses an MVC framework, like in your example, there will be Javascript that runs in the browser, which reads the fragment (the part of the URL following the "#"), and makes some ajax requests to load the page's content.

The ajax requests are likely to have parameters that you can attack with sqlmap.

There are many tools you can use to record the ajax requests as the page loads, including Chrome's Developer Tools (press F12 and look at the Network tab), or Burp, ZAP, Fiddler, Firebug, and many others.


Does the Content Security Policy header provide a false sense of security if a page is served over unencrypted HTTP?

Does it then give the developer a false sense of security ....

You understanding of the issue is correct. But if this gives the developer a false sense of security depends on the knowledge of the developer.

A properly educated developer should know that with a successful MITM attack everything can be changed in the traffic. This is not only restricted to modifying the CSP or for ad injection but in fact the whole contents and code on the page can be replaced with something completely different. That is instead of nice fluffy kittens it could serve some ugly malware.


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?

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.


Google Analytics use of JSONP, what are the security risks?

Any time you include script from an external domain you are trusting that domain. e.g. if you site is example.com and you have the following code on your home page

<script src="//example.edu/tracking_script.js"></script>

then example.com is fully trusting example.edu not to do anything malicious inside tracking_script.js. example.edu will have full control of client-side scripting and could do anything a client-side script hosted on example.com could do.

The same goes with Google Analytics - you are adding the script code to your page that creates the external js reference. If Google wanted to, they could adapt their script to do anything client-side to your pages. The same goes for a situation where Google Analytics website is compromised - any attacker will control all domains using Analytics.

Discounting anything malicious, the advantage of this to Google is that they can update the Analytics client-side code without webmasters having to do any updates on their side. So if they update a server-side function, they can update the client-side counterpart appropriately and every site in the world will automatically run the new client-side code for their visitors.

postMessage, while it maintains a security perimeter between your domain and GA's, would not permit any client-side script updates that may be necessary for GA to function after a server-side update. (Note that you do not need an IFrame for secure cross-domain communication, CORS enabled on Google's side would allow your site to send a HTTP POST request to register each page visit.)

When using a Google product, you will be pretty safe including the script referencing - so there is little requirement for this to be done in a different manner. However, having script references to lesser known entities whose security might not be quite upto the standard of Google's may be of cause for concern. In those instances it would be prudent to rely on a more secure client-side technology rather than that of JSONP.


HSTS preventing MiTM cookie hijacking attacks

If you are visiting a web page for the first time, even if it uses HSTS, you are at risk of MiTM attacks as the initial connection is made over HTTP and tools like sslstrip can be used to exploit that (by basically forcing you to stay on HTTP). But if you have already visited a page before and your browser is aware that that is a HSTS page, than sslstrip will not work.

Most major browsers even have preloaded lists of some HSTS sites, which means that even if you visit a site from that list for the first time, you are protected against MiTM attacks.


What real-world entities have key pairs?

You can tell if a web/mail/ssh etc. service is using public-private key encryption by looking at the address bar, and look for "HTTPS"

for example this website (stackexchange.com) is a real world entity that uses public key cryptography.


I think the linked Wikipedia article covers it quite simply.

Consider how many home users like to use a Dynamic DNS service to be able to reach their computer no matter what IP it has. The one computer reports its IP address on a regular basis, to a service which updates the DNS entry whenever the address changes. That way the DNS entry will always point to that computer no matter where the computer is or what IP it's using.

Now take that and blow it up into a botnet that's sharing a DNS entry. Each bot takes turns acting as the registered machine for the DNS entry. A short TTL is used on the entry so that it expires quickly, and doesn't point to the same IP for more than a few minutes. When the TTL is due to expire another bot is registered. Repeat the process ad infinitum until you're done needing the DNS entry or the Registrar shuts you down.

This is used to get around IP-based filtering or IDS which might otherwise inhibit the functionality of malware or other tools which rely upon access to an attacker-controlled network. The only way to block it is if you have a local DNS server you control that can black-hole lookups to the domain for your network, or if a Registrar agrees to shut the domain down.


You can know if a font is dangerous by the following method:

Install a system in a virtual machine.
Shutdown it.
From the "outside" (i.e. another OS), access the virtual disk for the VM, and compute a hash value for every single file.
Restart the VM. In the VM, open the font. Then shutdown the VM again.
From the outside, recompute the hash values for every single file.
Compare the two lists of hashes to see what has changed.

If some non-font-related files have been altered, then the font is definitely fishy.

A malicious font is something else. Malice means intent. A file has no mind, thus no intent. A "malicious font" is a font file which has been crafted so that it triggers a bug in the software which will read the font file, such that the consequences of the bug have an effect which is, ultimately, beneficial to whoever crafted the font file that way, and detrimental to the machine owner. This is "malicious" if the font file maker was aware of the bug and did it deliberately; otherwise, it is "just a bug".

In any case, detecting whether a font file is "malicious" is no easier than detecting whether an executable file is "malicious". This means that it cannot be done generically. Instead, we rely on the file source: we are wary of files which come from a source which is not known to be trustworthy.

Since a font is "just data", it can have an adverse effect only when opened with some software which has an exploitable bug in its code. It would be very hard to craft a "malicious font" which can, say, install a virus on a Windows system, but otherwise works "correctly" (as a font) on a Linux system (and vice versa). Since there are much fewer Linux desktop systems than Windows desktop systems out there, opening font files with Linux first, switching to Windows only if the font file looks good on Linux, ought to be "safe" (at least safer than the opposite).


Given Hash digest, calculating any random input

No. Given some output x, any input m such that h(m) = x is called a preimage. Though there are a lot of possible preimage, finding any of them is unfeasible -- that is, if the hash function is indeed cryptographically strong.

The three classical properties of cryptographic hash functions are:

Resistance to preimages: given x, it is not feasible to find any value m such that h(m) = x.
Resistance to second preimages: given m, it is not feasible to find any value m' such that m ≠ m' and h(m') = h(m).
Resistance to collisions: it is not feasible to find m and m' such that m ≠ m' and h(m') = h(m).

In other words:

If I give you a hash output, you cannot find a matching input -- not only the one I used in the first place, but you cannot find any other as well.
If I give you a hash output and a matching input, you cannot find another, distinct input that yields the same output.
Even if I let you choose messages as you wish, without any constraint, you cannot find two distinct inputs that yield the same output.

Of course all these resistances are up to some (very high) computational effort. For instance, finding a preimage can be done with a method called "luck", i.e. trying random inputs until a match is found. If the hash function offers a 256-bit output, then luck will find a matching input in an average of 2256 tries, which is totally out of reach of existing and future technology (by a very very long margin). A function is said to be "cryptographically strong" if the hash function output size is such that luck is nowhere near practical, and there is no known better method.


Is sending a string (representing a HTTP message) over SSL the same as sending a HTTPS message?

HTTPS is HTTP over SSL. SSL first connects to the host, so the host name and port number are transferred as clear text. When the host responds and the challenge succeeds, your  client will encrypt the HTTP request. This is said, and by putting in mind how the communication between layers in the OSI model occurs:

As SSL acts in the Session layer (5) and HTTP  on the Application layer (7), SSL encrypts HTTP request (including the HTTP headers themselves), and since the HTTP request format (simplified) looks like follows:

You can conclude that you are referring to the same notion expressed differently.


How useful are file shredders for nand flash memory (ios memory)

They aren't, in general. The point about spare space which is unreported is that it's for internal use only - any software accessing the memory through normal methods doesn't know whether the data goes on what was previously spare space, space which has never been used before, or if it's overwriting some data which is marked as deleted.

If the memory unit (drive/chips/whatever) has some specific "wipe" method, it might be that this specifically overwrites spare space, but the only way to check would be to access the data in a non-standard way, since the normal methods would just show the data on the currently readable parts. You'd also have to trust that the method which was provided by the manufacturer actually did what it said it did.

However, if you've used full disk encryption (or equivalent - full device encryption, perhaps, with a phone), it all becomes academic. If the keys are destroyed, any data is practically unreadable, whether you can pull it off spare space or not. That's why the general advice for SSD/flash memory use is to encrypt before writing anything important to disk - it means that even if there is some data you can no longer overwrite reliably, it still can't be used.


Some doubts about SQL Injection examples, how exactly works?

You've misread the injection, specifically this part:

""=""

This isn't checking if the Name is an equal sign, but rather if an empty string is equal to an empty string.  It's effectively the same thing as 1=1 (and they could have used 1=1 just as well here), and is therefore the equivalent of TRUE.  So this clause:

Name = "" OR ""=""

Is the same as Name="" OR 1=1 as well as Name="" OR TRUE

It's easy to misread something like that.  I'm sure that's all you need, since you otherwise understand these concepts clearly!  Just to be a pedant though, the query basically boils down to:

WHERE Name="" OR TRUE AND Pass="" OR TRUE

What happens next might depend on the exact order of precedence, but it will probably be fine.  Another trick you could use would be to end the username with a backslash remove Pass from the query all together (although this may not work in all flavors of SQL).  Imagine injecting User=\ and Pass= OR 1=1 -- (ends in a comment).  You'll end up with this query:

SELECT * FROM USERS WHERE Name="\" AND Pass = " OR 1=1 --"

Because of the backslash it will be searching for a Name of " AND Pass = (which won't match anything), but then the OR 1=1 will make it match everything.  The ending comment gets rid of the last double quote which would otherwise cause a syntax error.  This form gives you a bit more control over the query by effectively nuking the search on the Pass column and therefore ditching all the AND/OR clauses.  For instance, you could search for an actual ID by changing your Pass condition to OR ID=10 (presuming there is an ID column).


PHP command injection create_function eval

Why using 'array_walk_recursive' function seems to fix the code injection in this case?

It's not array_walk_recursive that is fixing the issue. The problem is that there is no issue in the first place.

You can't use the create_function functions arguments for code injection, as those are treated as variable strings, and can't be used to break out of the current context.

The injected parameter would need to come from outside. For example:

<?php
$arr = ['a' => 'b', 'c' => 'D'];
$func = $_GET['x']; /// eg x=strtolower
array_walk_recursive(
    $arr,
    create_function('&$value, $key', '$value = ' . $func . '($value);')
);
print_r($arr);
?>

Now you could gain code execution:

x=strtolower($value);phpinfo();

Detailed explanation

<?php // I would suggest to copy-paste the below code to somewhere that supports syntax-highlighting, it helps in understanding the issue
$arr = ['a' => 'b', 'c' => 'D'];
$func = $_GET['x']; /// eg x=strtolower
array_walk_recursive( // apply the function created below to all array elements
    $arr,
    create_function(                      // creating a new function
        '&$value, $key',                  // arguments for the function
        '$value = ' . $func . '($value);' // the function itself.
            // function uses $func from outside this string context (this is the essential part).
            // $value is the value from the previous parameter. It is just a string here.
    )
);
print_r($arr);
?>

When this is called with x=strtolower($value);phpinfo();, the function that create_function creates from the given string is basically:

function (&$value, $key) {
    $value = strtolower($value);phpinfo();
}

And then this function is called for each array entry. We can see how this will lead to code execution.

If we compare that to the code from the OP, the function that is created would be:

function (&$value, $key) {
    $value = strtolower($value);
}

There is no code execution in this function, as no value from outside was used in the string that created the function.


Best practices to copy private keys to mobile devices

You might want to try using a QR code to copy the key over. Generate the QR code on the laptop and scan it using your phone's camera. Obviously, dont use an online service to generate it, linux has a qrencode library which does that.

I have tried converting my PGP public key into a QR code and the phone successfully read it. However, if your ssh key is too long, you might have to split it up into sections.


What is more secure: single long hash, or combination of two shorter?

Your "random strings" are what cryptographers would call keys: a key is a secret value with no implied internal structure (as opposed to a password which is "a key which fits in a human brain").

In your first case, users will be granted access based on their ability to present a specific sequence of 10 characters in the a-zA-Z0-9 alphabet. These are 62 possible signs, so there are 6210 = 839299365868340224 possible keys. An attacker trying to force his entry in will have to "guess" the sequence, which he cannot do except by trying possible keys in any order (we assumed "no implied internal structure", which means "uniform probability"). On average, the attacker will have to try half of the possible keys before succeeding, and that's 419649682934170112.

Now suppose that we are in the second case: the user will be accepted only if he enters two 5-character strings in two text fields. Both values are to be right if access is to be granted. In that situation, there are 625 combinations for each string, for a grand total of 625*625 = 839299365868340224 possibilities, which is exactly the same count as previously, so it does not matter.

That is, unless you botch it. "Botching it" would mean, here, telling the user if he got one of the two 5-character strings correct, even if the other is not. For instance, the two entry fields are in successive pages, and your server will show the second page only if the first string was correct. In that case, the attacker can crack both 5-character strings one after the other: that's 625/2 = 458066416 tries on average for the first string, then 458066416 again for the second string. The attacker then succeeds in (on average) 916132832 tries, i.e. 458066416 faster than with the non-botched implementation. That's what I call an epic fail. (Such a failure has already happened, from Microsoft themselves.)

It is simpler, and safer, to require entry of all 10 characters in one go. How you display them, as one text field, two text fields, or a bunch of heart-shaped balloons floating in the screen, has no importance, as long as you do not leak information about which ones are correct. The only information that the verification system should give is whether all characters were correct, or at least one was not.


How to get sticky bit like ACL but for specific Linux user only?

If everone who needs to remove or rename files can do so via the shell and you don't need arbitrary programs to be able to rename/unlink files then you can combine sudo and the sticky bit for this effect.  Set the sticky bit on the directory.  Set the directory to be owned by a dedicated user.  Grant everyone bar the restricted user the ability to execute rm and mv as the dedicated user via sudo.


What security mechanisms are used in BGP and why do they fail?

A word on BGP

BGP is the routing protocol that makes the internet work. The current revision is BGP v4, and has been in use since 1995. Internet Service Providers (ISPs) are in control of one or many networks, and they use BGP to advertise their networks to their peers by exchanging routing information (internet routes) about the network they control. Those networks are independent routing domains called Autonomous Systems (AS). Each AS is attributed a unique identifier (AS Number, or ASN), and there are about 40'000 ASN allocated today. The process of routing between those ASes is called interdomain routing, and BGP is the protocol used to achieve this.

Each BGP router contains a Routing Information Base (RIB) which stores the routing information. When a router decides to update its RIB, it will subsequently propagate this information to all of the other neighboring BGP routers to which it is connected by saying "Hey, I can route to network 1.2.3.0/12 via AS numbers X,Y,Z". They will in turn decide whether to update their own tables and propagate the information further.

Note that there is no automatic peers discovery in BGP, instead peers have  to be manually configured to exchange routing information.

BGP exposure to attacks

The BGP protocol itself doesn't provide many security mechanisms.

BGP design did not include specific protections against attacks or deliberate errors coming from peers or outsiders that could cause disruptions of routing behavior. Examples of such attacks include:

As stated in BGP-VULN (RFC4272), there are no  mechanisms internal to BGP that protect against attacks that modify,  delete, forge, or replay data, any of which has the potential to  disrupt overall network routing behavior. As a TCP/IP protocol, BGP is subject to all  TCP/IP attacks, e.g., IP spoofing, session stealing, etc. Any outsider can inject believable BGP messages into the communication  between BGP peers, and thereby inject bogus routing information;
When a router advertise new routing information, BGP does not ensure that it uses the AS number it has been allocated, which means a BGP router can advertise routes with any AS number;
An AS can advertise a prefix from address space unassigned by or belonging to another AS. This is called prefix hijacking and it can be used to perform man-in-the-middle attack which was initially demonstrated at DefCon 16 by Alex Pilosov and Anton "Tony" Kapela;
BGP does not provide a shared, global view of correct routing
information that would make it much easier to detect invalid or
malicious routes.

In short, BGP is highly exposed to false route advertisements and there is no plan today to remediate this situation.

BGP Security protections

So it looks pretty bad on a security standpoint. But on the other hand, there are also some positive security aspects in BGP:

BGP peering associations tend to be long-lived and static. This means
that those associations between peers and route advertisment can be
monitored efficiently, and allows for a quick reaction from the
various stakeholders in case of an internet hijacking. There are a
lot of services providing BGP monitoring (some free and
open-source and commercial products);
BGP routers can implement route filtering, which allows to perform
inbound announcement selection, although there is no largely deployed standard for that and this is up to each ISP to decide if and how they want to implement it;
BGP implements a TCP MD5 signature option (a MAC, as defined in
RFC 2385) to protect BGP sessions    against TCP Reset (RST) Dos
attacks. It is currently supported by most router manufacturers (e.g.
Cisco) and open-source OSes (e.g. FreeBSD). But this
protection only cover a limited number of attacks, and relies on weak
technologies;
The lack of cumbersome security protection measures also allows quick
reactions against DDoS and malware spreading via sinkholes and
blackhole routing.

Future improvements

Recent efforts within the standards bodies and in the research community have attempted to provide new architectures for BGP security. This includes:

Using Public Key Infrastructure to share public cryptographic keys
between peers and allow routers to establish the integrity of BGP
announcements on a global scale, as well as attesting that an entity is authorized to advertise a particular resource;
Using IPsec to secure the BGP session and messages passed between peers;
Establishing an independent authority for validating interdomain
route information. This third-party authority would be used by BGP
routers to verify the announcements they receive.

A major update to BGP would be required to remediate those issues and offer an adequate level of protection against sophisticated BGP attacks. RFC 4278, a maturity study of BGP security mechanisms, considers the marginal benefit of such schemes in this situation would be low, and not worth the transition effort.

Additional resources you might find interesting:

Implementing the TCP authentication option TCP-AO
and The TCP Authentication Option RFC

What is the purpose of BGP TTL security?

BGP Looking Glass: As per their website:

  BGP Looking Glass servers are servers on Internet which can be
  accessed remotely for the purpose of viewing routing info.
  Essentially, the server acts as a limited, read-only portal to routers
  of whatever organization is running the Looking Glass server.
  Typically, publicly accessible looking glass servers are run by ISPs
  or NOCs.


Should I follow up on vulnerabilities that were disclosed over a year ago but have not been fixed?

I would not pursue this any further.

To summarize: You actively and extensively looked for vulnerabilities in their network (likely illegal, depending on your location). You admitted doing this and were luckily not punished, but told to not do it again. And then you did it again.

Your first exploration can be explained by youthful ignorance of laws and school rules (and could maybe even have been excuses by "accidentally" discovering these issues during normal activity), but the second one cannot (it is mainly a legal problem, but doing something to things you do not own against the expressed will of the person responsible for it is unethical in many cases as well; this is even true when considering that the school is also acting unethical here by not fixing serious issues in a timely manner).

What you should have done

This is not helpful now, but if you are in a similar situation in the future: Ask.

The school might actually have been happy to allow you to re-check these issues. Or they might not have been. But the only way to know is to ask.

If you wanted to make sure that the issues do get fixed, you could have offered to help fix them; by suggesting possible solutions, by offering to re-check their solutions, or by actually helping to implement these solutions (this maybe could have taken place in the form of extracurricular activities which maybe could have even been mentioned on a resume or college application).

What to do now

I don't see a way to pursue this without getting into trouble.

IANAL, but going to the press, suing, or even just saying that you know that the systems are still vulnerable could very well get you into legal trouble.

If you really want to, the best approach may still be to contact them and ask if they were able to fix the issues, and if they would like you to re-check them, or if they would like your help in fixing them (for free; anything else could also get you into legal trouble). If you do this, don't mention that you already re-checked without permission (and hope that they do not have any monitoring in place that could disclose your previous activity).


Why do syn scans not work over proxy set up through SSH's dynamic port forwarding?

SSH port forwarding and also proxychains forward the payload of TCP connections and not the original raw IP packets. A SYN scan does not create a TCP connection and does not have any application payload so it will not not work with port forwarding or other TCP proxies.


You could use HTTPS with public key pinning. This way, only your certificate is valid for the communication. A man-in-the-middle attacker can no longer create a valid certificate to sniff the traffic.

Key pinning is quite common for mobile apps. You should check whether the HTTP framework you use supports it.


Web Application encryption key management

While some good information has been provided in previous answer, there is a critical design flaw, which is not really noticed - but comes from some of the implicit assumptions in the question.

The difference should not be between:

Web app and DB on same server
Web app and DB on different servers
application vs. db encryption

The design should start from:

Who needs access to the encryption / decryption key(s)  ?

Or, actually even more correct:

Who is responsible for protecting the confidentiality of the data ?

Which, in turn, comes from:

What threats are you trying to protect against?
Or
Who are you trying to prevent from reading your data?

Only based on these questions, can you design a properly engineered cryptosystem. (And prevent the crypto-fairy dust that @D.W. referred to).

So, some example scenarios:

The user should be responsible for encryption, preventing even the app admins from seeing the data
The client application should be responsible, without having to involve the user - but this still needs to be done client-side (e.g. a backup program).
The appserver applicatively and specifically encrypts selected data, as part of the business logic (even the dba cannot see the data)
The database server should automatically and transparently encrypt stored data. (This protects only against theft of the db file / physical disk, with caveats...).

For simplicity, let's assume that encryption should be done server side, responsibility lies on the server, and the end-user (and administrator) has no influence on the encryption.

The main question, then, is the encryption performed by the application server, or the database server? (Actually not so simple, there are other options...)
This, as most security issues do, comes back to a tradeoff:

Will you manage your own keys, or do you prefer the infrastructure abstract this automatically? (the original question... more info below...)
Are you worried about malicious (or incompetent inexperienced) programmers?
Are you worried about malicious admins?
Are you worried about unauthorized application usage?
Are you worried about unauthorized SQL access?
Are you worried about unauthorized direct file access?
Are you worried about physical disk / server theft?

And so on.   (Note that some of the above questions are irrelevant, and cannot be solved by server encryption).

Now, let's assume you made your decision, based on the above, between appserver encryption and database encryption.
Note that whether the web server and the db are on the same server or not, has almost no effect here - if the app is encrypting, then it's just sending "special" data to the db, otherwise it's moot. However, this does affect the above threats discussion - some issues are obsoleted by the design, some are enhanced...

Web / Application server encryption

The encryption key (EK) you use to encrypt the data, should be itself encrypted by a key encrypting key (KEK).
The encrypted EK should be stored in a protected place - this can be a file, a registry key, whatever - the important thing is restricting access to it, to the appserver's user only (and, perhaps the admin - see below).
The KEK also needs protection - this is a bit trickier.
If you're on Windows, you have easy access to DPAPI - this provides OS-level key management, so you can have the OS encrypt your KEK and transparently manage the keys for you. (Behind the scenes, DPAPI eventually relies on knowing the user's password (in USER_MODE), so that is the final, weak point of an actual known secret - but noone else should know the server's password in the first place, right?)
Another option is external device / HSM, discussed further below.
The KEK also needs access control, of course - restrictive ACLs and all that.
There are several reasons you want to separate the EK from the KEK: you don't want to encrypt huge amounts of data with a single key; if you need to replace the key, it becomes a lot easier (just re-encrypt the EK with the new KEK); you can use stronger, slower, more complex encryption/storage on the KEK; if you need to be PCI compliant, you can implement split-knowledge on the KEK; and more.
Both the EK and the KEK should not be stored long-term unencrypted - depending on your platform/language, this means e.g. not storing it in a String object in .NET or Java. Instead, store it in mutable byte arrays, and always ensure you dispose of it as soon as possible.
Some frameworks even go a step further, and provide specific protected objects. E.g. in .NET you can use the System.Security.Cryptography.ProtectedMemory and/or System.Security.Cryptography.ProtectedData classes to keep the keys protected, even in memory.

Database encryption

If you have your database server perform the encryption, this becomes a lot easier: the tables / fields are configured to automatically encrypt any data stored in it, key management is completely transparent (from the PoV of the application, not the DBA), and so on.
For example, Oracle and MS SQL Server both support automatic built-in encryption. For MSSQL, the key management is complex, yet similar to what I described above. Simplified: There is an EK, stored in the database, that the dba can configure to use to encrypt/decrypt tables or fields. This is in a protected table, encrypted by a KEK, in turn encrypted by a server level KEK, in turn encrypted using DPAPI on the MSSQL's service account.
Alternatively, MSSQL also supports using asynchronous encryption, e.g. storing public/private key pairs - this can be useful in specific scenarios.

Third option: external encryption storage, or HSM (hardware security module). This can be a shared hardware appliance, server, or a hardware card or dongle... etc.

These devices are designed to very securely protect small bits of data - e.g., your KEK.
Again, another reason why to separate the EK from the KEK - this will enable you to efficiently encrypt and decrypt the masses of data with EK, while still securely managing the KEK.
The HSM is usually accessed via a special driver or API, it may be possible to plug these into the database encryption too (depending on product, etc).


NaCL: Encrypt file to multiple recipients

The actual format of NaCL's output is not completely specified -- or, rather, it is specified as being the raw output from some cryptographic primitives (as described there). The format is thus non-extensible and does not include any feature supporting multiple recipients. Ability to send a message to multiple recipient appears to be a functionality that has been sacrificed on the altar of simplicity.

If you want to use NaCL and still send a single message to multiple recipients without duplicating the bulk of the data, then you must design your own format, basically doing this:

You generate a random secret key K.
You use K to encrypt the message (with crypto_secretbox).
You encrypt K as if it was the "message" with crypto_box.

But then you are defining your own protocol, built over existing primitives. This is the exact kind of things that NaCL was meant to prevent. Or, said otherwise, if you are back to doing your own protocol design then why would you use NaCL ? And, in any case, you would be on your own, both for the security analysis and the implementation (since you would not interoperate with anybody else).

If what you need is what OpenPGP provides, then use OpenPGP.


Why doesn't the official CVE database list the names of the reporters?

The CVE database does allow "Discoverer(s)/Credits" to be recorded, as shown on the MITRE CVE form:

However, the help for that field states:

  Please indicate the individual(s) or organization(s) that found the
  vulnerability or reported the vulnerability to you. This information
  will not be included in the public CVE entry.

Back in 2000, Steve Christey had this comment on the CVE editorial board mailing list:

  With respect to Marcus' comments, it is clear that some vulnerability
  discoverers want proper credit for discovering something, and it is
  becoming a more common practice (consider Microsoft's acknowledgement
  policy and recent SGI advisories).

Which implies that back when CVE started up there was an assumption that discoverers didn't want credit.  Today, that seems strange; reporting vulnerabilities - responsibly - is a respectable job which you can even get paid for.  But 25 years ago, that was far from the case.  People could rightly fear legal reprisals, and reputational damage, if they were responsible for publishing a vulnerability.  For how would they ever have found it if they were not evil hackers?

The CVE process has been one of several agents of change, making it possible to "own" discovery of a vulnerability more easily today.

The common method of attribution is via the announcement; and in many cases, the References field of the CVE (which is public) will point to the original advisory announcement.  (I seem to recall 8lgm had noteworthy 'tude on their releases back in the 90s).  The recent trend of fancy ALLCAPS vuln names with trendy websites is just more of the same.

(This leaves unanswered how to convince a 3rd party (well, 4th -   Discoverer/Reporter, MITRE/CNA, Vendor - those three talk.  You're asking about someone separate from those three, and I don't know the answer to that.)


Flask/Jinja2 SSTI to get RCE.  not in object subclasses

After further research, I think I figured out why. It seems that the latest versions of Python are not vulnerable to the metodology briefly explained in my original post.

The Flask web app I was using as target was indeed running inside a Docker container, with the latest version of Python installed.

A simple way to check it out:

Python 2.7.10

>>> object.__subclasses__()
[<type 'type'>, <type 'weakref'>,..., <type 'file'>, ...]

Python 3.7.1

>>> object.__subclasses__()
[<class 'type'>, <class 'weakref'>, ... ] # no <type 'file'> or <class 'file'>


How do I avoid the initial text portion when creating a PEM certificate with openssl?

This is not a programming or development question or problem and will probably be closed, but from the man page for ca(1ssl?) or maybe openssl-ca(1) on your system (unless Windows)  or on the web:

-notext
Don't output the text form of a certificate to the output file.

Although as commented it's also trivial to fix the file afterwards with standard text-handling tools; that's one of the many reasons PEM format is textual.


What personal information is safe to share publicly?

IMHO, the less the you share online the lower the risk of being targeted in some by spammers, hacker, identity thieves, phishing scams, ex-boy/girl friends,thieves etc.

Given the context (an online CV) lets look at each piece of data, and determine its risk/requirement for the context of an online CV.

  email address

I would strongly suggest you do not provide your primary email address here, as you will certainly be targeted by email spammers, and your inbox will suddenly be filled with Viagra offers, lottery 'winning' notifications, urgent parcel delivery notices, PayPal refund notices, etc etc.  All spam or phishing attempts. You do want to be contacted by prospective employers, not by spammers. Lower the risk Use a Disposable email address service here, and you are safe.

  mobile number, land line number

Again on an online CV, a phone number is nice, but not absolutely required if you have posted a disposable email address.  This again invites possible spam SMS messages, unwanted phone calls, and loss of privacy - assuming its your home phone, I would treat that like my home address: nobody gets that unless they are actual friends/colleagues/family.

  ID number

Careful with this one. In the US anyway, our ID numbers are Social Security numbers, and are really not shared.  SSNs any are primary identifies associated with tax returns, bank accounts, credit reports. etc. Even when communicating with trusted providers that have my account information, they will only ask for the last 4 digits for identification purposes.

  year of birth

This data is fine I suppose, but again, why provide it in this context? One can simply guess your age based on your educational and work history, usually. I like to keep them guessing a bit on my age anyway.

In summary, name and a disposable email is all I would share.  If you used LinkedIn, that type of data is always good to see on a CV.

Perhaps I am paranoid, but I would only offer Name and Email as data.  If they like your CV, all they need to do is send an email! You provide more details as needed.


Powershell scripts inside meterpreter sessions

Use the Metepreter PowerShell Extension. In this case, your PowerShell will run in-memory without shelling out. If you shell out, then cmdscan or consoles in Volatility or Rekall (or any similar technique, which every EDR and DFIR tool utilizes) will flag the process space and deliver obvious results of compromise.


Is it possible to securely run user defined python code in AWS?

This is not an AWS question, this is a python sandboxing question.

Real OS-level sandboxes like seccomp can be used to prevent a process running the cpython interpreter running attacker-supplied code from escaping and doing harm. Securely communicating with it to feed input into it and get the result out of it is complicated.

Virtualization can be used, but there have been escapes for Xen, KVM, VMWare, etc.

QubesOS does this, kinda, for desktop use.

Google gvisor is used by GCP to guard customers from other customers.

I would trust a system that really launches a new AWS EC2 instance for each customer to run their script.

Creating a new AWS Lambda to run once and then delete the Lambda function would also work (provided the 5 minute cap on Lambda running time is ok).

Creating a container and running it on AWS EKS and then killing it should also work.

Regardless of the way you run it, you must have a dead-simple impossible-to-do-wrong secure way to get results out, i.e. you must make the format of the result extremely simple, no de-serialization, so it will not be possible to attack your main server through this channel.


Is it allowed to specify IP as DNS name for SAN certificate ?

According to RFC 5280 dNSName is a IA5String which means in theory you could put the string of an IPv4 or IPv6 address as string inside it. And sometimes it is also necessary even though the proper type for IP addresses in SAN is iPAddress since:

MSIE and MS Edge tend to ignore iPAddress and expect the value as string in dNSName. Same does Python 2.
but Chrome, Safari, Firefox don't expect an IP address as dNSName but need it as iPAddress. Same does Python 3.

Thus the best compatibility can actually be reached by giving the IP address both as iPAddress and dNSName.


A SOCKS proxy is in a position similar to a router: it sees all traffic. It is thus in ideal position to commit various felonies on your data. You should consider it as you would consider any router on the Internet (including your ISP): it fulfills a service but you do not trust it. Using an external proxy is no less risky, but no more risky either, than doing proxy-less connections(*). The short mantra is: SSL protects you, as well as it protects you over the Internet in general.

The error would be to believe that a proxy which asks for authentication somehow makes your data "secure" in some way. Don't be fooled ! The authentication is for the protection of the proxy, not yours.

A special case is proxies which claim to offer anonymity. Nothing guarantees that; that's a promise the proxy makes and you cannot enforce it. For Tor (Tor is just boosted proxying), risks of hostile proxies is mitigated by chaining them, so that your anonymity is preserved as long as at least one of the proxies is trustworthy.

Of course, if the proxy is your friend and is really trustworthy, then it can help in defeating attackers. For instance, a SOCKS proxy through a SSH connection (ssh -N -D 5000 othermachine, and set your browser to use 'localhost:5000' as SOCKS proxy) is a cheap but effective VPN for your Web-based traffic, between your machine and the network where othermachine is located (I was doing that a lot when I was working for a company which was physically on another continent).

(*) Ok, that's not entirely true. Low-grade attackers, as opposed to, say, oppressive governments, could find it uneasy to make Man-in-the-Middle attacks on your data; they would have to ressort to crude methods such as DNS poisoning. If you accept to forward all your data through the attacker's proxy, then you make the task easier for him in practice. But you should not assume that not using proxies makes you immune to low-grade attackers. Also, this does not change anything high-grade attackers who control infrastructure routers: by using their proxy, you are not giving them any power over you that they did not already possess.


Protect sensitive data from sysadmin prying eyes

Well, the hard truth is that if somebody has physical access to your hardware, they basically will find a way somehow. Using encryption is still worthwhile in that it will slow down attacks and prevent "casual" release of data, but as long as you don't control your own hardware, you're limited.

In the business world, this is covered by contracts and certifications which are backed up by audits. For example, Amazon's EC2 has a laundry list of accepted data protection standards..


Why would a website allow answers to security questions to be used interchangeably?

In short, somebody misplaced an OR where an AND should be. Indeed a big mishap on the part of the developer. Your assumptions about its security are correct.


Is this authentication method simply not supported on windows?

Correct.  The Windows VPN client simply does not support using Group Security in an IPSec VPN.  Additionally, the Cisco IPSec VPN client is EoL, so they don't really support it anymore (preferring customers to pay for AnyConnect SSL VPN licenses).

There are some free alternatives out there, as well as a number of ways to get the old Cisco VPN client installed on Windows 10, (it installs fin on 8 and 8.1) but frankly, all the options for this type of VPN on newer versions of Windows leave a lot to be desired.


Properly implemented strong crypto systems

By "properly implemented strong crypto systems" he means "cryptographic systems in which the design or the implementation was neither unwillingly weakened through designer/implementer incompetence, nor willingly weakened through deliberate alterations".

NSA/GCHQ did not break encryption mechanisms; they bribed (or otherwise forced) the designers, implementers and providers of some cryptographic systems into adding backdoors for them to use. Backdoors can be deliberately weak design elements, data leakage... my favourite is poor PRNG, because such alterations can be disguised as incompetence (e.g. the rumours on OpenBSD a few years ago).

A properly implemented strong crypto system is a system:

which is strong, i.e. whose design has been done according to the state-of-the-art and can be argued to "look solid" (subject to the usual caveat that "you cannot test for security");
whose implementation was not botched in some way.

For the first point, this mostly means: complies with standards which have been published for quite some years, and for which cryptographers have not found anything bad to say (or anything that could not be fixed), but still got interested in it. E.g. SSL/TLS or OpenPGP. For the second point, this mostly means open-source, with reasons to believe that "many eyes" have gone through the code; e.g. OpenSSL or GnuPG.


Crypt-analysis methods for breaking or finding weakness in an encryption algorithm?

For cryptanalysis, the usual three-point method applies:

Write down the problem.
Think real hard.
Write down the answer.

And that's about all that can be said generically.

The methodology of a cryptanalyst is about the same as that of researchers in any other science. The core of the daily work of a cryptographer is to read, read, read all the papers. Accumulate knowledge and ideas. Then, when the cryptographer sees the design of some cryptographic algorithm, his subconscious mind may recognize the pattern, manifesting itself in the cryptographer's brain as something like: "mmh, this looks like the kind of structure that Schrupkovski was breaking in his article presented at NoWhereCrypt'93, except that this one is in bitslice mode with an extra FFT". Ultimately, Research is all about putting together ideas and concepts originating from many distinct sources.

Security of a cryptographic algorithm cannot be tested, let alone proven (though one can have some nice reduction proofs, which unfortunately cover only part of the problem, by definition). What can be demonstrated is insecurity: if you find an attack, then the algorithm is broken. To ensure that an algorithm is probably secure, let some cryptographers try to break it; lots of cryptographers for a lot of time. If none could break it, then the algorithm might be fine. This is the whole idea of the AES competition, for instance.

The difficult trick is to attract cryptographers. You have to do several things:

You must do your homework. The algorithm must be described completely, in a readable mathematical way (not as code in any language).
You should also explain why some generic classes of attacks don't apply to your design (e.g. differential cryptanalysis).
The algorithm must be interesting, which basically means that it must be more efficient than the existing alternatives. For symmetric encryption, this means that the algorithm must be faster than the AES, or as fast as the AES but with constant-time implementations, or amenable to extremely compact implementations, or some other similar advantage. Nobody will invest time trying to break an algorithm which would not get used anyway since it is too slow or too big.
Patents. Do not apply for a patent. Most cryptographers run away when they see a patent, because they don't fully grasp the consequences of working on patented algorithms (they are specialists on cryptography, not on patent law). Patenting a cryptographic algorithm is, in practice, an extremely good way to ensure that the algorithm will not receive external scrutiny and won't be used.


Security implications of adding nobody to docker group

The nobody user was originally used for NFS. However people started using it to run daemons that did not need to run as root. This was fine when used by just one daemon, but it is no longer recommended when multiple daemons are running as that user. Linux only provides inter-user isolation, not intra-user isolation, meaning user X and user Y cannot tamper with each other's processes, but one process running as user X can tamper with another process running as user X. If Docker is running as the this user, anything running as the same user will be able to compromise it, for example by attaching debuggers and modifying memory via ptrace() and similar syscalls, sending signals via kill() or fcntl(), or even changing resource limits via prlimit64().

The recommended solution is to run an unprivileged daemon under its own user or group.


What are the recommended steps involved in creating an encrypted file format?

It is entirely up to you. In Java for example, there are libraries (cryptographic functions should not be implemented from scratch) for AES encryption that let you use this cipher to encrypt a byte stream with a given key and IV. So most often, even when using libraries, you are still left with the problems you mentioned:

Where should meta information be stored? (Version, original file name, original path etc.).
Where should the encryption parameters be stored?
Where to store IVs
Where to store the salt

It really depends on the application you are creating. I would consider storing the essential information (IV, salt) inside the encrypted file in a custom header. Embedding essential information inside the file has the advantage, that all you need to decrypt it is the encrypted file itself and the key.

You could put the meta information inside the header too, or if your application demands it, store it in an external database. Since meta information is non-essential, encrypted files can still be decrypted even if the database becomes corrupt or lost.

  There needs to be some unencrypted data in the file out of necessity
  (magic/version number, encryption parameters/salts/IVs) as well as
  some way to verify that those unencrypted parameters have not been
  tampered with.

I'm not sure why exactly you need that, but you could reserve extra space in your custom header for a checksum calculated over IV + encryption parameters. That way you could always tell if the parameters were modified. You could however not restore a corrupt IV for instance, at least not without brute force.

  The result should be secure enough by today's standards for a target
  audience of private users and small companies.

If your encryption algorithm is considered safe and you are handling the user passwords correctly (this is the biggest caveat!!), then there is not much you can do wrong with the file format. IV, salt and encryption parameters can be made public (read: stored in plain text). This should not have an impact on the security of your chosen encryption.


Signing using RSA is done by first applying a cryptographic hash and then "encrypting" it with the private key of the sender (i.e. A). "Decrypting" the signature using the public key of the sender thus results only in the hash value, but not in the AES key. Since the hash function is one-way the original input (i.e. the AES key) can not be derived from the hash value.

Validating the signature by the recipient is instead done by first re-computing the hash value of the input (which is known after decryption) and then comparing this against the hash value returned by "decrypting" the signature with the public key of the sender. If they match the signature is valid.


Full disclosure, I work for a DDoS mitigation company protects companies against DDoS attacks.
A few ways you can dodge DDoSers can be through blocking the attackers by IP or country. Blocking by IP will block access from those specific attackers, so long as they're trying to access your site via that IP, they will be blocked. Blocking by country can also be useful if you know you don't do business with certain countries. According to Incapsula's recent DDoS Report, most attacks can be routed or sourced through China or Russia. If you know you don't serve those countries, you may be better off to block them.
Most attacks are sourced through Botnets, or a number of computers that are hacked and used to attack your website. Slowing down your website will do nothing to deter them because they're bots, they don't care. Your users will notice and they will be pissed though so it's best not to do that.
I recommend adopting a service like Incapsula. You can block bots under a certain point.
Hope that helps!


Because of possible session fixation: http://en.wikipedia.org/wiki/Session_fixation

  In computer network security, session fixation attacks attempt to
  exploit the vulnerability of a system which allows one person to
  fixate (set) another person's session identifier (SID). Most session
  fixation attacks are web based, and most rely on session identifiers
  being accepted from URLs (query string) or POST data.

Another problem: if user has same session id after logout (even if session contents are cleared), attacker gains possibility to prolong usage of stolen session id.
Alice logs in to some site;
Attacker steals cookie with session id;
Alice logs out of site;
Attacker can't use stolen cookie to access the site;
Alice logs in to the site;
Attacker can use stolen cookie, because Alice's session id is the same;

Rule of thumb is to change session id as often as you can.


Is HttpUtility.HtmlAttributeEncode considered for single-quotes attributes?

Experimentally, HttpUtility.HtmlAttributeEncode() does NOT replace apostrophes when using .NET framework 3.5 (and older). It does replace them with framework 4.5. So one has to assume that the behaviour changed; this can be seen by comparing the documentation for .NET 3.5:

  The HtmlAttributeEncode method converts only quotation marks ("), ampersands (&), and left angle brackets (<) to equivalent character entities.

with the documentation for .NET 4.5:

  The HtmlAttributeEncode method encodes characters appropriate for insertion into an HTML attribute value.

Note that even the new documentation still says that the quotation is safe only for double-quoted attribute values. My guess is that while the intent is still to target double-quoted attributes only, Microsoft developers finally realized that most developers don't actually read documentation and will use HtmlAttributeEncode() for single-quoted attributes, so adding an escape for apostrophes was a nice, formally backward-compatible way to make the world slightly better.


Is Google Play enough to protect an outdated device?

However, actually how important is this lack of security updates for
  an end-user?

Very very important.

  Reading through Android security bulletins, often the updates fix
  things that cannot be attacked unless you have either physical access
  to the device or you are using a bogus app.

This is not true. The 2019 August Security bulletin itself talks about fixes for multiple vulnerabilities which could be exploited remotely.

  This leads to the point of my question, given that a device no longer
  receives security updates, is Google Play enough to protect it?
  Assuming every app is installed from Google Play, and with a reasonable privileges.

No, because unpatched system level vulnerabilities may allow local privilege escalation.


What are the options for acquiring disk image from a Linux computer that can't be removed from a crime scene?

Simply turning on the machine can already alter/destroy data that can be potential evidence, let alone booting its original OS.

The best solution is to remove the hard drive, connect it to another computer through a hardware write blocker and then grab a complete image of it with dd or some equivalent. The write blocker is necessary to prevent accidental write to the device that may alter potential evidence (although a basic Linux installation that doesn't mount drives automatically won't do any writes by itself, Mac OS and Windows will definitely do).

If that's not possibly then you need to go with the forensics Live-CD route, but since it involves booting the computer you may already trigger some firmware-embedded code designed to alter/destroy potential evidence (hard but not impossible to do, it depends on what kind of criminal you're after).

Note that in the end, it doesn't matter what OS was installed on the computer since you shouldn't boot that OS anyway, and a bit-by-bit copy doesn't care about the data or even the filesystem that's on the drive (you can copy encrypted drives, but that won't help you much if you don't have the key since the copy is still encrypted).


How can one create one's own anti-virus scan server at home?

This can be done using techniques like:

Docker
virtual Machines
Jails
Clusters (out of scope for home use)

The trick here is to NOT use a single user environment like Windows. but use a environment where you could safely test any file without risk of infection. So you need a READ-ONLY Environment (full OS, not just the location being tested) which makes using a *NIX ideal.


Can ssh connected computer control the source

No, you're simply accepting the way that destination server authorizes itself as the original server.

For example if somebody would try to spoof the IP/Domain that you are using, then you could find that attempt of attack, by verifying the fingerprint, to make sure that this is the same server, that you have accepted previously.

In simpler words, once you have connected to the server one time, your source server will make sure it is the same machine every time.


SAML and OpenID, centralized and decentralized

These are not really parallel technologies, but simplistically:

When you are using the SAML model, you typically respect a single issuer of SAML tokens (or perhaps a handful, but pre-defined by the service). That is, there is a single, central repository of user credentials, and all the "consumers" accept its' tokens and validate against that one.

With OpenId, you are typically accepting any OpenId provider, based on the user's input - it could be Google, or Facebook, or StackExchange, or your corporate OpenId provider, or your own home server. Either way, it doesn't matter.

This is not just a question of numbers, either. With SAML, you explicitly trust the SAML server to authenticate and verify your actual identity - which you can later rely on.  With OpenId, you don't necessarily have any trust relationship with the OpenId provider - you accept whatever it tells you, and you don't actually care: you just need some form of assured identity (actually more of a "placeholder" in this case).

So, to sum up: SAML is centralized because you expect to control identities, OpenId is distributed because you have given up that control.


How difficult is it to protect your storage from data recovery

Yes, it will be enough to fill the drive with zeros to defeat any data recovery program. However, a specialized laboratory breaking apart the drive and using special tools to inspect the platters may still be able to recover some data.

Tools for disk wiping overwrite the contents several times with some patterns (eg. 00, FF…) and/or random data with the goal that such recovery can't get anything useful.


is there a low-overhead way to log every new file created on a Linux host?

Inotify monitors directories individually. To monitor a directory tree, you need to monitor each subdirectory, and to attach to new subdirectories when they are added. I'm note sure if it's possible to do this without a race condition.

If you want to log the files that are created in a directory, there are better ways. You can put the files to watch on a loggedfs filesystem, which implements the logging in userland. Alternatively, you can use the kernel audit facility. See https://unix.stackexchange.com/questions/6068/is-it-possible-to-find-out-what-program-or-script-created-a-given-file/6080#6080 for more technical information.

I don't have practical experience with either method in production, but I doubt that RAM consumption would be significant either way. There's a larger overhead with the loggedfs method which might be significant for files that are read very often but modified only occasionally, because you'll pay the overhead for all accesses, not just writes. Additionally the loggedfs method makes a shadow view of the files, and if you're worried about malware, it might bypass the shadow view and access the original, unmonitored view directly. So for your use case audit is more appropriate.

The rule is something like (untested)

auditctl -a exit,always -F path=/var/www -p w

This gives you real-time logging, which may or may not be useful. I suspect that the detailed information would be useful for forensics, but not so much for alerts, because you'd have too much detail to sift through, but that really depends on the patterns of changes. There are programs that list files on demand and report changes since the last run, for example AIDE and Tripwire. They fit in th general class of intrusion detection systems, and more advanced software definitely exists, but this isn't a topic that I'm familiar with.


How to force a browser when connecting to a specific domain to be https only using only the client machine?

You've found already that this can be done with an extension like HTTPS Everywhere. And you've found out that the browser will not do this by default. Thus there is the option of "doing nothing with the browser", which doesn't provide the protection or the option of "doing something in the client" which is already a solved problem by installing a plugin. Apart from that there is HSTS preloading where the browser knows that some specific sites will always use HTTPS even if the browser has never connected to these sites before.

If you want something like HSTS preloading but for domains which are not in the HSTS public preload list it is possible in Chrome to add additional domains to the local HSTS list by accessing chrome://net-internals/#hsts. See also Manually enforcing HSTS in Google Chrome.


Is it possible to salt the SHA1 or SHA256 hash function of OpenSSL?

SHA-1 and SHA-256 are cryptographic hash functions. They take as input an arbitrary sequence of bits -- and only that. There is no "salt" in hash functions.

When a hash function is said to be "salted", then this is not a hash function; this is some other construction that uses, among its input parameters, one that is deemed to be a "salt", and that may use, internally, a hash function as a building element. One example of such a construction is PBKDF2.

The distinction is important, because when someone says "I want to salt my hash", then this can mean one of the two following things:

That someone is trying to implement some existing, well-specified construction like PBKDF2, and merely calls it "a salted hash". The right way is to look for an existing implementation of the complete construction, or, failing that, to implement it by using the specification which will tell exactly what sequence of bits is injected into whatever hash function is used internally. In any case, the question of "how to salt a hash" becomes meaningless.
That someone is in the process of making his own, homemade construction involving a hash function, and tries to mix together some values and a few cryptographic functions, hoping that all the ingredients will somehow interact well together and result in "security", envisioned like a sort of cake. This is a known recipe for disaster; only sorrow lies down that path.

Usually, the notion of "salt" comes from the concept of hashing passwords, where passwords are "weak secrets" ("secrets" because they are supposed to remain confidential, "weak" because they can be remembered by human brains, and human brains are really bad at remembering random values). Hashing passwords is not something that tolerates improvisation well; there is a lot of theory and research on the subject, and experience has repeatedly shown that homemade schemes are almost invariably pathetically weak. Read this answer as an introduction on the subject.


How to prevent HTTP header injection attack in J2EE Web application? Is there any library (Maven dependency) available for this purpose?

I think that implementing a library for specifically 1 vulnerability like this, which has an easy fix, is overkill.
Is user input from the headers necessary? If not, then eliminate it.
If user input from the headers is necessary, can you whitelist this input?
If you cannot whitelist the input, can you sanitize the input by stripping newline (i.e. %0d%0a, \r\n) characters?
If you cannot strip newline characters, can you escape them?
If all above fails, you should look into a WAF solution.


Web server interaction with a database server

For a reasonable level of security, the answer is really neither.  The database should be housed in it's own zone, not the DMZ with the web server, or in the internal network zone.   This allows additional levels of protection both against intrusion from the public Internet should the web server or web application be compromised, and against attacks from the internal network which are a very real problem.  It also offers a defense in depth mechanism to protect the internal network should an attacker who penetrates the DMZ figure out how to piviot into the DB zone...While they own the DB at this point, you don't want to them to own the internal network as well.

So, something like this:


Same session cookies for a user logging from different browser/machine

Having the session cookie specific to the machine or browser offers at least the possibility to associate machine/browser specific information with the cookie (like some kind of browser fingerprint). Such associated information might then be used to better detect if the cookie was used on a different machine, i.e. impersonation done via cookie theft.

Note that this cookie protection is purely optional, i.e. just because the cookie is machine/browser specific does not mean that such information will be definitely associated with the cookie but only that this could be done.

If the session cookie is instead machine/browser independent such protection is not possible at all, but instead a stolen cookie could easily be used from other systems. This means the risk of impersonation would be higher.

  Which is more vulnerable ...

None of this actually presents a vulnerability. A vulnerability would be if some attacker could steal the session cookie, for example using XSS or by sniffing unprotected connections. The options you present only offer more or less ways to mitigate the impact of the vulnerability by making it harder or easier for the attacker to misuse the stolen cookie.


Increasing fail2ban ban time with each attempt

As Schroeder has suggested, if you don't want to alter the fail2ban alerting then the best way is to simply ignore the IP address entirely. What you're looking to do is more complex than you need to make it. Simply ignoring the IP is probably the most efficient way of doing this.
This article should show you briefly how to set it up, but as already mentioned it's just a case of using ignoreip then specifying the IP(s) you want to ignore.
An example of this would be the following ignoreip = 192.168.0.1/24 in this example it would ignore the range 192.168.0.1 - 192.168.0.254 I think this would perfectly suit what you're trying to achieve as you've said you've got 3 specific IPs so just replace my example with the addresses you're trying to block, obviously if it's only 3 IPs and not a whole range, don't block a whole range or you could run into issues if any legitimate clients have an IP in that range.


What's the risk in putting semantically meaningful data in an HTTP session identifier?

If you'll be using this solely as an accelerator tag, then I don't see any reasons why not. You've mentioned you considered the possibility of this cookie data being tempered with, so if you're already designing your user identification (when it applies) with this possibility in mind, it really shouldn't be an additional security issue.

As for that EU "cookie directive", here's a quick digest of it:

  The law requires companies to obtain “explicit consent” before using
  or storing data in ways that may be considered to be “intrusive.”

IANAL applies, but in my book an accelerator that isn't neither too space/bandwidth consuming, nor “intrusive” by identifying or helping to identify the user in any way whatsoever, really doesn't fall within this "cookie paranoia" category. If anything, it's there to the benefit of the end user. But to be sure, you should check with the lawyer of the company you're designing your solution for, as they'll be the ones responsible for how their services operate. You will be required to notify users of the use of cookies on the website anyway ("this website uses cookies... blah, blah, blah..."),

  "Member States shall ensure that the storing of information, or the
  gaining of access to information already stored, in the terminal
  equipment of a subscriber or user is only allowed on condition that
  the subscriber or user concerned has given his or her consent, having
  been provided with clear and comprehensive information."

so that notification could point to a page describing each cookie value. Not too descriptive to be a security issue on its own, but enough to help clear the user's mind of it. Any other requirements regarding this "cookie law" really depend on what other cookies you'll be using and for what purpose.

The only other "issue" that I can think of is that you should take into account that users might be enabling/disabling or even deleting cookies at random and at any stage of using your website (especially with all these required by law warnings reminding them they ought to be more paranoid than it's worth or mentally healthy being), and that this switching on its own shouldn't present any issues with how your code functions. In a nutshell, you should never depend on any cookie values and rather consider them as "helpers", as you suggested you already do anyway.


How Vulnerable Is An Older Version Of Outlook As An Email Application?

What kind of threats will I face from unknown senders that won't be a problem in Outlook 2016

Outlook 2000 is vulnerable to known attacks, but the key difference compared to 2016 is that there is no effort from Microsoft to close the Outlook 2000 vulnerabilities. Any bugs that are found now that support is dropped, will not be patched, so there can only become more known vulnerabilities as time passes.

  Most email security seems to center on safe reading habits.

Take CVE-2006-1305. The attack was conducted with malformed email headers. This attack would trigger when the message is downloaded from the server, and thus be underway before you decide to open the message or not.

  I intend to continue using the rest of Office 2000 (Word, Excel, etc.) alongside firewall rules which prevent internet access.

While your firewall might stop the applications themselves from contacting the internet, there is nothing stopping an attack from using a different program to connect to the internet. A macro included in a document might instruct information to be copied to a shared folder on disk, or it could open some other program, for example a spyware application.

In short, running unpatched and unsupported software is a very bad idea, and should be avoided as long as the system is connected to the internet.


Is this how to implement CTR around a system that only implements CBC, CFB, CTS, ECB and OFB?

The texts you quote are correct: CTR mode is indeed about encrypting the successive values of a counter, and XORing the resulting stream of bytes with the data to encrypt.

CTR mode is an "approved" mode of operation, as the NIST states. For the "increment", it can be about any way of going through 128-bit values as you want (I am assuming a block cipher with 128-bit blocks, such as AES), but if you seek interoperability, then "the" standard CTR mode is the following:

The counter is a 128-bit unsigned integer, i.e. a value between 0 and 2128-1.
The counter is encoded as a sequence of 16 bytes using big-endian convention (first byte is most significant).
The Initial Value (IV) is the big-endian encoding of the first counter value; in other words, with AES/CTR, the first 16 bytes of the ciphertext are the result of the XOR of the first 16 bytes of the plaintext with the encryption of the IV (as a 16-byte block).

Since most programming languages do not have 128-bit integer values, the counter increment is usually done byte by byte (begin with byte 15, increment it; if the result is 0, there is a carry and you continue with byte 14, and so on; otherwise, just stop there).

CTR mode security relies on never having the same counter value be used twice for a given key. 128-bit blocks are a large space; choosing the IV randomly and uniformly is sufficient to ensure this no-reuse policy. Using CTR mode with a block cipher which has smaller blocks (e.g. 3DES and its 64-bit blocks) could be dangerous, because a 264 space is not that large.

One way of viewing CTR mode is that it turns a block cipher into a generator for a long stream of pseudo-random bytes; XORing this stream with the data to encrypt makes it a stream cipher.


What's the difference between these MD5 hashes?

The first example looks like a shadow file format: ID (admin) Algorithm (1 = MD5) Salt (none) Hash (oLN1UCc1Y3T30QkMcKMSx0), with the hash in what seems to be Base64 format.
The second (5f4dcc3b5aa765d61d8327deb882cf99) appears to be a hex string of 128 bits consistent with being an MD5 hash as well.
However, converting both to binary & then back to their opposite formats, the two hashes do not match:

Base64 of the binary value represented by the hex string (5f4dcc3b5aa765d61d8327deb882cf99) is X03MO1qnZdYdgyfeuILPmQ.

Conversely the hex string of the base64 hash (oLN1UCc1Y3T30QkMcKMSx0) is
a0b3755027356374f7d1090c70a312c7.
       ------- Edit -----

As user1686 pointed out: oLN1UCc1Y3T30QkMcKMSx0 is MD5crypt, which is a thousand rounds of MD5 with extras at each round. If both of these hashes are in fact from the same password, it should be possible to convert the straight MD5 hash to its equivalent no-salt MD5Crypt by bypassing the first MD5 calculation in the MD5Crypt and feeding it the hash instead of the password.


Report an email address being used by a phisher

Since it's so easy to anonymously register an email address, I doubt it belongs to a legitimate user. Legitimate servers/websites are often hijacked for use in phising/malware distribution/C&C since it can make attacks look more legitimate, and because it's easier than to anonymously pay for and run it. This doesn't really apply to emails.

I absolutely think you should report it.

Since it's Google, you can report it here:

https://support.google.com/mail/contact/abuse?hl=en&rd=2
http://support.google.com/bin/static.py?hl=en&ts=1114905&page=ts.cs

I wouldn't expect a response though. As is often the case with reports like this; they may go ignored. I've not personally dealt with Google regarding problems like this so maybe they handle it well.


Is the installed certificate used for school wifi able to track me at home?

The certificate is one part of the whole system. The other part is the school router which should be CyberHound Appliance.

When your browser connects with a site with https, the flow goes roughly like this:

Browser initiates connection with the server
Server returns its own certificate and a chain of certificates reaching up to a well known Certificate Authority (CA)
You browser checks the server's certificate is valid, and the chain of certificates reach to a CA that it already trusts.
If the chain of certificates does not reach to a CA that your browser already trusts, it will show you a warning that your connection is not secure

When you install the Cyberhound certificate, you are adding to the list of trusted root Certificate Authorities.

This means Cyberhound appliance can now do following:

When your browser makes an https connection to any server, cyber hound will intercept the request and generate a certificate for that server signed by its own root CA
Your browser will receive a certificate from Cyberhound appliance instead of the actual server you were trying to use. As the browser on your computer already trusts the cyber hound root CA, it will trust the certificate
Now Cyberhound appliance will be able to decrypt the communication between your browser and target server. It may log your activity and enforce other school policies.

As you see the certificate and the router (appliance) work together to intercept your https communication. So unless your home network is also being intercepted by a router that has access to Cyberhound private keys, you home internet usage can not be monitored by your school or Cyberhound.

TL;DR: You home internet connection can not be monitored just because the certificate is installed on your computer. There must be a router on your network with access to Cyberhound private keys to generate the certificates in order to intercept the communication.

Note: I have left some details out to keep the answer easier to understand.


Is email less secure than voicemail, snail mail, or internet portals for transferring sensitive information?

Yes, email is insecure, and should not be used to deliver sensitive data.  That doesn't mean that they should need to refuse to send anything via email, but given HIPAA and the potential penalties for non-compliance, I'm not surprised that some providers would choose to err on the side of extreme caution and shun email entirely.

Here is why email is insecure:  The provider does not control the entire channel.  Once an email had left their system, they have no way of guaranteeing that it will be encrypted and protected from prying eyes as it wends its way through the Internet and to your inbox.  In fact, with the state of email today, its quite likely that it will not be encrypted along the entire transit path.   Hence, if they were to send PHI via email and it was stolen or misused, it would not be unreasonable to argue that they failed to show due care and should have known better, thus, be held liable for the leakage.  When you're looking their web site in a browser, they can confidently assert that the information is being delivered securely to your screen by using HTTPS.

This risk can be (virtually) eliminated through the use of encryption such as PGP.  Do you know what the uptake of PGP is?  Percentage-wise of all email-users, in the low single digits at best.  And even those users tend to hate it and view it as a necessary evil.  That may change in the future, but that's the reality today.  Do you know what the uptake is for HTTPS use over the web?  100%.  Every browser supports it, and it's completely painless for the end user.  Use what works for your users.

Is snail mail more insecure?   No.  Why not?  Because the piece of mail has a single physical location, and can't be stolen without the physical presence of, and personal risk to the thief.  Stealing things off the Internet is easy.  That network captures trap, and mail servers log unencrypted email is not so much a risk as it is a given.  Snail mail is very unlikely to be intercepted.  The USPS has an entire law enforcement division to protect it.  They have a stellar (not perfect by any stretch of the imagination, but very very good) record of delivering mail to the intended recipients.  It is reasonable for a company to entrust the USPS to deliver confidential information to you unmolested.  It is not reasonable to expect the same from SMTP email.

So, yes, the fact that they won't provide any information to you over email is excessively conservative.  The fact that they won't provider PHI that way, is certainly not.


Depending on the type of attack you can either do this with ip tables ( if you are running Linux) or request your ISP to see where the traffic is coming from. The latter is actually the best option as the traffic might contain spoofed IP addresses. Your ISP should be able to locate where the traffic is coming from ( roughly) and see if they can block it using BGP.

You can't do anything against a DDoS locally, once the traffic reaches you it's already way too late.


It should be -rw-rw-r--. The vulnerability scan is warning you that every other shouldn't write (w) on this file.


would client-side encryption help hide messages being sent/received, so that [my local network administrator] would not be able to read them?

Client-side encryption is not about transport encryption. The point of client-side encryption is not whether an eavesdropper can capture your communication on the way to a server. Rather it's about encrypting data without involving another party (i.e. the service provider, "the server") in the process.

Client-side encryption just means that the server doesn't encrypt the data which it's storing for a user by itself, but leaves the encryption to the client, giving the client full control over the process. This way  the service provider is proving that they can't access the plaintext because they never handled the encryption keys in the first place. In theory, this means you don't need to trust the service provider to handle your data confidentially. (In practice, you'd have to verify that the provided client application actually implements CSE as promised by the provider.)

Whether the client-side-encrypted data is transferred securely (over an encrypted channel between you and the server) is a separate issue.


Chrome is generally not too secure
You have an IP address that is tracked, many general spam recommendations will be based on that
History is irrelevant and so are cookies (in this case), but cache is not
Your browser has an unique ID that you can be identified by (this is used by the very advanced trackers)

What to do:

Use a private browser instance (and I recommend you use Opera - way more secure)
Do not be logged in into absolutely anything (no google, fb, y, skype etc)
Use a web proxy on the private instance (Opera has extensions with multiple selectable big proxies - browsec as example)
Use an unique ID changer to identify your browser as a general version wide-spread one (yes, there's an extension for that too)


Should user IDs be implemented in online banking?

All the banks I use require me to make a user ID. I believe having an issued ID would be better security, but from a business standpoint you are just making things extremely unpleasant for your users.

I don't think it would be realistic to assign a credit card number as an ID because users could have multiple credit cards or accounts under the same bank, and again the bank wouldn't want to make things difficult for the users. Let's not forget too that everyone would be forced to have very long user names!

Also, you would think that your credit card number is something you want to keep secret as well, but having it as an ID may very well hurt security. Imagine the scenario where someone is lazy and types very slowly(maybe doesn't have a numpad as well). So, this person decides to leave his/her credit card number somewhere and copy paste that when going on the banking site. Well, now it's entirely possible that this person will accidentally post it somewhere else if he/she doesn't remember to copy something else to the clipboard.

All in all it just seems like a lose lose situation


Basically you just need to force a user on that network to disassociate with the wifi, then when it reconnects, the ssid will be transmitted in plain text.

Check out this guide.

http://www.thelinuxgeek.com/content/find-hidden-ssids


Does it increase the security if we split data to n pieces and encrypt each one with different key and different algorithm?

It depends what you're worried about, and what you are really trying to protect.

If each of these slices is individually important (say a 1 MB list of credit cards), then you're basically just encrypting each chunk by itself. The total strength of protection for each chunk is just the size of the key you used for that chunk (modulo strength/weakness of the algorithm used).
Regarding that last point - swapping around the encryption algorithms does not add any protection, you will still be only as strong (or as weak) as the algorithm you use for that chunk.

Likewise, if a breach of confidentiality of ANY CHUNK is gameover to you (i.e. the attacker only needs to break any one chunk, and once he does so he is not interested in the rest. E.g. a list of usable entry codes, the attacker only needs one) - then the total protection is the strength of the SHORTEST key used - and/or the WEAKEST algorithm of any of the nodes.
So unless all your nodes are using the same strong algorithm and the same keysize, you would be effectively weakening the solution.

On the other hand, if the only risk you are worried about is theft of ALL the chunks (e.g. even 9 out of 10 chunks stolen is not a threat) - then, assuming all the nodes are using the same strong algorithm (e.g. AES), the total protection achieved is the SUM of all the keysizes. (e.g. 10 x 256 bits).
In this specific scenario, it seems like you did achieve in overall improvement, since the attacker would need to brute force 10 keys of 256 bits, instead of just one.

However.
Even if that was the case, you would achieve the same affect by just using a longer key, or cycling keys on the whole batch.
I won't even try to get into the mathy parts of cryptanalysis, if that would make it overall easier...

Since when it comes down to it, if you're using a proper strong algorithm, like AES, and a long enough key, brute force has already become irrelevant, so any possible increase in strength would be academic, with only a possible downside to this complicated solution. (At the very least, complexity is the last thing you want in your cryptosystem).

TL;DR:
Don't bother splitting it up.
In most cases it is directly worse.
In other cases, even if hypothetically there were any benefits, they would be irrelevant and come at a high cost.


Man in the Middle how to read incoming traffic for victims on the network

In order to truly man in the middle them you'll need to arpspoof them. By arp poisoning the router and your target, you can make them both forward traffic to you instead of each other. Then you forward it on, after inspecting it or modifying it.

assuming you're on kali or parrot

echo 1 > /proc/sys/net/ipv4/ip_forward

arpspoof -i <your interface> -t <router ip> -r <target ip>

arpspoof -i <your interface> -t <target ip> -r <router ip>

at this point you can either start wireshark, mitmf, etc etc etc

  References

What is arp spoofing

Tutorial on MiTM With kali