About UDP not using ports: https://en.wikipedia.org/wiki/UDP_Port and https://www.bleepingcomputer.com/tut...rts-explained/ so actually applications using UDP packets DO use ports. And if you can move an application (UDP or TCP) to an unexpected port then scanners must not only probe, but then re-probe the detected ports to make measurements that will allow them to detect WHAT is listening on that port, then probe that for access. This gives you MANY more opportunities to detect and block the source of the probes.

About encryption: one company I worked for used encrypted application traffic, much like that of ssh sessions. They tunneled that through an encrypted SITE/SITE VPN tunnel that uses both certificates and PSK (Pre Shared Keys) that were unique to that customer. And that was the part I can TELL you about! That degree of security was possible because the endpoints agreed on the VPN security details, because no one OTHER than those parties would or could get access, and because the application parts were WRITTEN by one of the parties and could incorporate the additional features and security the parties agreed upon. That is not often the case for a casual home users. If you are running a home web site that allows general access from the internet (I have), you can jump through hoops in terms of security, but it is always wise to assume that if it is not compromised today it will be by morning and take steps to make sure that does not expose anything you do not care to lose.

If you cannot be extreme and use security techniques that are not documented ANYWHERE except in your (locked) safe, then simply operate so that if someone breaks your machine and steals everything in it, you do not need to care. Take REASONABLE steps (because reloading your machine every day would get old REAL fast), and make sure you keep sensitive information off of your machines (or at least it is there only passing through and leaving no lasting trace), and stop worrying. Leave the extreme stuff and constant worrying to the people who get PAID for it, that is what we are HERE for. ;-) And, some of us REALLY enjoy it!

I am currently running a Pinebook Pro. I have the clean OS image on an SD card. At anytime I want (or if I think it is compromised) I can easily shot down, load the SD card, and in a few minutes be running from the original image and have the SD card back in the safe. I like that a lot, and for more reasons than security alone.

I have run an old HP laptop before, with VirtualBox installed. I could run anything to the internet in a VB session of a different operating system (BSD on Linux works well) and know that if I hit malware the odds were good I could blow away the VB guest and restore the backup and be hot again in minutes uninfected.

The question is: what is fun for you and how far are you willing to go to isolate, lock down, secure, and monitor? (Because no safe is secure unless you have a guard on it watching that no one is taking a metaphorical hacksaw to it!) Even then, putting all your trust on any ONE security plan may be wasted effort, you need to think LAYERS of security: if someone penetrates ONE the find themselves at another safe door or locked in an oubliette. Because there is not ONE way they "do it", they create scripts and systems they can use to probe multiple possible ways of penetration at the same time and either penetrates or "phones home" to say "here is an open window".

(We can discuss the network "honeypot" and blocking on penetration attempts another day.)

It's on a VPS, with a static IP. I don't know about the provider's IP range policies, but this server is for my personal use, not a business.

The words thatjumped out from post #46 at me were
They have lost all patient records Mind you, the FVH hospitals have some stuff. I rang about my wife, and they could tell me the date she was last treated (2018) so it's not as bad there.

Curiouser & curiouser - the Wizard Spider group have handed over their decryption tool for free, although they are promising to sell a lot of data they have lifted unless they are paid. The HSE are testing the tool - presumably making copies or mirroring disks. I'll hear more about it tonight. There's reasonable tech coverage as relevant here.


On the sshd discussion, I would like a link on making sshd more secure, if anyone has a good walkthrough on doing that. I happen to have a fixed IP on the basis that I might want it some day,but I'd like to put up some feeble objection if I ever had to expose it online.

I don't have a link to a particular online resource, but I recommend approaching the issue in the same manner as one would when it comes to securing any service.

SSH provides two basic services: Authentication and secure (remote) access.

You secure the authentication part by implementing whatever measures you find to be adequate for preventing unauthorized access. In order to do that, you'll have to figure out what the threats are, what possible vulnerabilities might exist for this service in particular, and what would constitute an adequate security level in your particular case.

An SSH service exposed to the Internet will be the subject of opportunistic probing, regardless of what it provides access to. Bots will attempt to log on using commonly found usernames and passwords, often lifted directly from the CVE database or from known account database breaches, so make sure you're prepared for that.

Generally, you secure SSH against such attacks by not using low-quality passwords, and by making sure any software you install don't leave behind default accounts/passwords. You may also want to implement firewall rules to block the sources of repeated login attempts, at least temporarily, if nothing else then to keep such attempts from filling up your logs. You can accomplish this with some simple rate limiting firewall rules, or by using software like fail2ban (which can be described as a very rudimentary IPS).

Whether you also need to implement a strict password policy and/or some form of 2-factor authentication, depends on your userbase and what the service is protecting. If the userbase is yourself and the protected network is your private LAN, this is obviously overkill.

As for the transport part, you can tweak the encryption algorithms to ensure you get an adequate level of confidentiality. Very few encryption algorithms can actually be said to be compromised or insecure; even SHA1 isn't really likely to present a real-world problem in this context.

As long as you enforce a sufficient key length for the various symmetric and asymmetric algorithms, you'll be fine. The (current) rule of thumb is that symmetric algorithms should have a key length of 128 bits or more, while asymmetric algorithms need at least 2048 bit keys (I never go below 3072 bits myself). That means the ancient DES with its 56-bit keys is out, while 3DES, horribly outdated as it may be, would actually be OK security-wise.

Hashing algorithms need to be evaluated on an algorithm-by-algorithm basis; as mentioned, SHA1 is considered weak/compromised with serious collision issues, MD5 has some known collision vulnerabilities, while SHA256/384/512 and SHA3 (Keccak) offer state-of-the-art protection.

Then there's the service itself. Not many know that in addition to providing basic remote access, the SSH protocol also offers port redirection, proxying, and at least two file transfer protocols (SCP and SFTP). It's generally a good idea to disable any services you won't be using, in order to reduce the attack surface.

New vulnerabilities may of course be discovered in the future, so you need to keep yourself updated with news from the security community, implement mitigation strategies whenever necessary, and update/patch your system quickly whenever an update becomes available.

Thanks, Ser Olmy. That's a good summary of what I need to do.

Just keeping folks up to date on the news here, the HSE tech heads have tested the tool, which apparently a single file decryption tool. It works. They're now modifying it. I imagine that it's a unix tool that they now have to compile on windows, get on usb keys, and send around to the multiple offices all round the country, which is a crazy difficult task, especially the half-assed way they seem to be organising it. Then they'll have to bring the network up again, and they will be every bit as hackable as they were before. Of course, it could be for linux, BSD, Darwin64, Solaris, whatever, and could take a savvy programmer to convert it. That's not someone they are likely to have in the Civil service, which is strictly windows only. Then there's the question of checking for back doors … it's a national disaster of Epic proportions and has opened the door on how poorly our IT infrastructure is set up.

The ransom asked for was €20,000,000. News bulletins have highlighted the suffering of patients denied regular cancer treatment, Parkinson's patients, everyone. The vast number of appointment cancellations was also stressed. The news leads off with this stuff, as if they were making a point. They are bigging up the distress caused.

The Irish Government have repeated that no ransom was paid. But the Irish Government are 'nice guys' in terms of foreign policy, and we basically have no enemies. It seems our Foreign Minister met Sergei Lavrov, Putin's Foreign Minister, and we exerted diplomatic pressure in other ways. If the Russians were to turn a blind eye to this lot in St Petersburgh, which resulted in the death of many Irish citizens, it would be tantamount to an Act of War. That could be argued. We don't know what was said or done, but a few phone calls might have been made … hence the decryption tool.

They could probably have run the tool without modification by using usb keys. Take something like Alien Bob's live usb, add the decryption tool, mount the encrypted disk and go. Hang it online on the hse site and send offices the link. Instead, we have some dimwit(s) trying to replace unix libraries with windows ones And then rejig the code to work. They might even have to run it in a container, VM, or shell. Heavy stuff for a civil servant!

What's irritating about this is that if it was done in parallel, the work would be halved. There's loads of linux experts here - sysadmins, tech heads, mobile startups, and that could be handed out very quickly. There's even tech heads with Russian! Guys from Poland educated before 1990 all have Russian & German. After 1990, it was German, French & English. Plenty of Central Europeans in tech here too, all of which have Russian.

Correction: "USB uses 'ports', but does not use sockets."

The entire Internet networking architecture is built around "layers," each one of which builds upon – and employs – those that are beneath it. Therefore, "TCP/IP" builds upon the "UDP" layer, which is just a "one-way non-sequenced datagram" layer, to construct a two-way sequence-guaranteed protocol which involves "senders" and "listeners." The abstract which this layer introduces is called the "socket."

TCP/IP servers open these "sockets" and then "listen" to them, waiting for connection requests – the mechanics of which are handled by the protocol. It is therefore possible for any computer to "port-scan" – actually "socket-scan" the target IP-address, to discover which services are "listening." It can then open its side of the socket and begin to send arbitrary data to it: the physical process of doing so is handled at a lower level by the TCP/IP layer of the protocol stack. Each "conversation" is distinct.

UDP, being strictly "one-way," relies upon application program logic to define the notion of "connections," and the proper sequencing thereof. A client which sends a string of datagrams to a server might receive a response to none of them, or to any, and if so might receive them in an unpredictable sequence. All of these things being what the higher-level "TCP" protocol would have handled for them, had they used it.

An OpenVPN server which uses the UDP protocol is therefore "aware of" incoming packets, but it is not externally visible as "listening for" them.

Correct correction: UDP uses ports, and sockets. Ask any programmer. Or read virtually anything about UDP, for instance the authoritative sources provided earlier.

Here's an example of a TCP socket: 192.168.1.1/TCP/80. And here's a UDP socket: 10.0.0.1/UDP/53.

And here's the socket the OpenVPN server usually listens on: 0.0.0.0/UDP/1194.

Surely the difference is that a TCP socket can be permanently connected to another one so that they can converse. That means it has an open and a closed state like a file descriptor, and a sniffer program can find out which sockets are open at a given time. UDP sockets don't have a recognisable connection state. They just pop out an addressed datagram at irregular intervals.

The difference is that TCP is connection-oriented, while UDP is not.

When you connect to a TCP port, the IP stack is responsible for the initial reply, not the application. Only when the three-way handshake is completed is the application alerted to the presence of an incoming request. And the application continues to see just a two-way data stream, while the IP stack handles all the details with regards to packet/segment size, fragmentation, retransmissions, and connection teardown when one of the parties closes the socket.

With UDP, everything gets handed to the listening application immediately. Yes, that means it's up to the application to decide whether a response is warranted or not, but it also means it's now responsible for all the functions mentioned above.

For just about all UDP-based services there's still a connection and in most cases also a session, it's just that the state handling is done exclusively by the application.

And of course a UDP service is by definition totally exposed to attacks of all kinds, including blind spoofing DoS attacks which would have no effect at all against modern TCP implementations.

1 members found this post helpful.

Yes, I've heard plenty of talk about various TCP/IP stacks, but none about UDP stacks …

In other news, the HSE lot have more or less patched up the Decryption tool and are setting about decrypting everything, in order of priority. It seems what it took Wizard Spider a day to do is going to take the HSE months to undo. Then there's the 'next-to-impossible' task of bringing up the network country wide. Don't you feel

1. That's Civil Service efficiency for you?
2. Would it not have been a bright idea to get a team arranging priorities while another lot were patching up the decryption tool?
3. Wouldn't a backup have been a good idea? Is there a law against common sense?
4. Wasn't it kinda stupid to keep all disks online all together so that they could all get encrypted at the same time?

/hangs head in (national) shame .

That's just a case of a somewhat unfortunate choice of name.

"TCP/IP" is the name for the whole protocol. That includes TCP, UDP, ICMP, IGMP, ARP, and a bunch more. As a result, the IP stack (which is the precise name) is sometimes called the "TCP/IP Stack."

But that doesn't mean that UDP isn't part of the "stack"; it features prominently in diagrams of the old 4- or 5-layer TCP/IP model, as well at the more recent 7-layer OSI model.

2 members found this post helpful.

On JBS meats:
https://www.axios.com/jbs-meat-suppl...09bc8be11.html

There's a good few links off that page.

Not that this particular vegan is worried about the fate of a meat supplier, or that, heaven forbid, You may even have to pay 5¢ more per burger in the Excited States.

Here, the HSE web services are still down. But I know a guy in commercial IT support, and an interesting tit bit came out. It appears the HSE had got a (competitor to my friend's) company in to do a security audit when they got hacked. To me, that was reason to fire them straight away. They were doing a security audit while Russian hackers were setting themselves up, and preparing the stage, and they were never noticed by the security audit! But instead of that, they got the job of recovering from the hack

All new hardware going in, I gather - they don't trust the old stuff. That will take even more time.

My friend in the know also gathered that the backup system was on the same network as the main system, because the hackers could encrypt that as well as the main system at the same time. Apparently the stupidity of doing that is well known, but that didn't stop the HSE.

In typical Irish fashion,They released a statement saying that the work of recovering from the hack was 50% complete, but full service everywhere was months away. I gather they are working first on the greatest concentrations (cities) and then venturing out into rural parts with lower population concentrations.

I wonder if they will be selling off this hacked equipment cheap? It can't all be junk.

Yes, "the stack" consists of layers of software which each build on one another. The UDP protocol is a lower-level layer in that stack, providing base services which higher levels (including "bidrectional sequence-guaranteed 'sockets'") build from.