hpr-knowledge-base/hpr_transcripts/hpr0465.txt

Episode: 465
Title: HPR0465: Failsafe security
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0465/hpr0465.mp3
Transcribed: 2025-10-07 21:10:17

---

.
Hello ladies and gentlemen my name is Ken Fallon and this is another episode of Hacker Public Radio.
Today I'm going to be talking about fail safe security.
Now when I use the term fail safe you're probably going to jump to the marketing term
of that Ken is now going to supply me with a computer that's completely safe.
And no I'm not doing that.
What I'm talking about here is fail safe in the strictly engineering term.
Some examples that you might have of failing safe would be the dead man switch on the train
to prevent runaway trains if the driver has a heart attack or becomes unconscious for some reason
that the train will stop if the button or the foot pedal is impressed in five or ten minutes
the train will essentially automatically stop.
Even on trucks and trains as well.
If there's a failure in the brake system the hydraulic or the pneumatic brake system
and air leaks or oil leaks by default the brakes will automatically apply.
That's failing safe.
If you ever wondered why in the old movies the doors of the car has opened the other way
so you know they opened the hinge was at your shoulder and you could step out obviously
if you do that it's easier to get in and out of the car.
But the problem with that is if you leave your car door ajar and you drive off
then the wind will catch the door and the door will come flying off and whack somebody in the head.
So to make the system safer they have implemented a system where the door opens on your side
and you have to open the door fully that way when you drive off
and the wind catches the door it will fail into a safe mode of operation i.e. it'll close.
Now right there we have introduced a little bit of inconvenience for a huge gain in safety
and this is what I want to do to you now is talk about a system with a little bit more inconvenience to you
but with a lot more safety.
Now by default computer systems have been shipped with a whole go of ports open
and a whole go of additional services and by ports it comes from the French word meaning door or entrance
so essentially you have a system with all go of doors that are open and listening.
Now you may put somebody at each door but the best option I believe is to shut all the doors
so that there are no doors accessible from the outside and the only way that you can get in is in response to a request that goes out.
So when you build a system first thing that you should do before you put it on the internet
ideally download your ISO and take it off the network install it and then you can look at the amount of services that are running.
How you can do that is you run the command nest that space minus A and P and that stands for all the processes
and you want the numeric versions of them as opposed to saying SMTP or whatever.
You want to get the port numbers and the dash P is it shows the process that started up.
So for instance if you get an Apache server running you'll see 0.0.0.0.0 colon 80 and then beside that we'll say ETC in a D slash Apache or HTTPD something like that.
That will allow you to identify what services are running on what ports.
The first time you do that you might be alarmed at the number of services.
So have a look through and see what services you can and should disable.
Now it's handy to have another computer on the internet that you can go look up some of these.
If you don't know don't be too panicked about it but there are quite a number of services that can be turned off.
Top of my list is UPMP which is a protocol designed to make it easier to configure your new network.
Yes insofar that your computer can then go and open up a port in the firewall to allow traffic in.
Now I don't know about you but I don't like to give that ability to any program.
So say for example my one of my PCs gets hijacked then that can go and configure my firewall.
Naturally I turn off UPMP everywhere and you should do that on your PC as well.
I also turn off a Vahi because I don't see any reason for computers to know what other services are running on all the computers.
I know what services are running on all the computers because I'm the admin.
Okay but enough about that rant.
Ideally what you want to do is go into the system and see what services are running and see if you can turn off as many as you possibly can.
Then you can go and edit the files ETC forward slash host.deny and ETC forward slash host.allow.
And the one you're most going to be interested in is the host.deny.deny and in there you're going to put in all, call on all.
And what that will do is deny all protocols from everywhere.
And in your host.allow file you will remove anything that's or comment out at least anything that's allowed coming in.
And what that does is it says nobody's allowed in and there are no exceptions to allow people in.
You should also set up an IP tables script to block all ports, all incoming ports and only established connections going out.
And what an established connection is is you have requested a piece of information and you're only allowing that in.
So for instance the door is shut to all purveyors of goods except for the pizza guy who is delivering the pizza that you've just ordered.
There will be some additional notes in the show notes giving you some start off points on how to do all this stuff.
Now if you do need to allow ports in and out you have to ask yourself what is the risk.
Now for most people running a laptop or running a desktop computer there is no need to allow any ports coming in because all traffic should be originating from you out.
You should not advertise any additional services because that is just waving a big flag.
Hey everybody I've got this system over here and just keep a look out and as soon as it becomes vulnerable you can attack it because I'm broadcasting on the network what it is.
No don't do that keep everything short and don't allow anybody to do anything onto your computer.
If you do need to do stuff it's amazing what you can get away with by just running everything over SSH.
Say for example you want to test a web server out what you can do is install Apache and configure Apache to run and listen only on local host.
And local host when you do a net stat you will see it operating on 127.0.0.1 or that to the 3.4.5 or whatever but 127.0.0 and that means that's a local host and that's not accessible from the outside.
But if you do an SSH in you can then SSH to port 80 on local host by doing a port forward.
So that's ideal for that sort of thing.
You might consider running SSH on a non-standard port.
Now in over the last period of time I've seen a marked increase in the number of attempts to connect to SSH on port 22.
And I switched it over to another port and I was surprised to find additional attacks on that other port after a week or two.
So the guy obviously knew that the port was open and then did a full nest of scan or some scan and found out that it was listening on another port and attempted to brute force attack on that side.
And what you'll see in your log files is first of all thousands of attempts to connect as a route.
And you will then see attempts to connect at non-common user names.
So my advice is absolutely imperative that you disable route access from the SSH config.
And there will be information as shown also obviously has to have to do that.
But I would also suggest disabling anything any access except from users connecting with SSH keys.
Pre-shared public and private keys.
Now if you absolutely must have SSH and you must have it open to the world, what I would suggest is limited SSH.
So well, first of all, you're going to need to edit your EDC hosts that allow file and have the line SSH D colon all.
But rather than have it open to the entire internet, what you can do in there is you can list certain IP addresses that are friendly IP addresses.
So for instance, if you need to connect in from work or if you need to connect in from your parents PC or your family or some other PC.
If you're only ever connected to your home PC from known machines on the internet, it makes absolutely no sense to have all IP addresses open.
Why not restrict it to certain number of IP addresses?
And even if you don't know what IP addresses that they are going to be, what you can do is restrict it to subnet.
So if you've got a mobile phone connection with some phone provider and their IP address range is this for the mobile phone, then you can put in that IP address range so that you know I will allow connections in from that network, but at least you're restricting it to that network.
So the potential hacker or cracker will be restricted to that network.
There is a script called Denyhost, it will be in the show notes, which you can run that goes through your log files and adds the IP addresses of machines that have been attacking your network.
The only problem is it doesn't, it's not real time.
There are some real time scripts that will go and modify your IP tables so that they are blocking IP addresses that are trying to connect.
I think if you can restrict it to no one else, you're in a far better situation.
Again, as I mentioned, in the previous show, log watch, in episode 431, I give you a rundown on a tool that will send you an email with information about your system.
And not only does it include disk and temperatures and stuff, but it will also give you a rundown of who has been connecting to your system, what they've been doing and fail to log in the attempts.
That is basically that. Once you have that done, you can then connect to the internet.
I recommend on the local LAN assigning machines static IP addresses.
If you have a network and you've got only a small number of machines, you should set it up so that it gets a static IP address.
That way, on the other machines, you can specify static IP addresses and MAC addresses from which they can come in.
On your local network, do not trust any machines. In fact, do not trust any machines anywhere with anything.
Assume that all other machines are also vulnerable and under attack.
If you need to expose files, for instance, from a central media server to a play out player, there is no reason why that play out device needs right access to all your stuff.
If they're only going to be playing MP3s, for instance, so make sure that that share is a restricted to the fixed IP address of the device that's connecting, and also that they only have read access to those things.
Review your log files is the key here.
Ideally, you would also want to have a full-blown firewall with independent logs.
Not only are you logging what's going in, but what's going out.
But that's beyond the scope of what I'm trying to do here. What I'm trying to do is give you an overview of things that you can immediately do to make your machine more secure and less vulnerable to fail into a safe state or to operate in a safe state.
This isn't all that we can do, but it's a good start.
Don't forget to change your root password. Don't forget to change user passwords. Don't forget that if you are going on the internet, try and use a bog standard browser like Dillow or one text only mode that gets rid of a lot of the crud.
If you must browse with a full web 2.0 browser, use Firefox with the no script plug-in and flash block.
Not only will this make browsing a lot faster, it will give you a sense of where the scripts are being run from.
It will give you an additional layer of security.
Yes, there will be additional layer a little bit of inconvenience, but that's a lot better than the other option of your machine getting poned.
The point here is that Linux machines can no longer be assumed to be not a target.
Linux machines have always been a target. The only thing is that Linux admins, up until now, have been reasonably well informed, staff members who run machines and big server farms or whatever.
We're beginning to set up machines that are maybe not as by default secure as they could be.
So, I hope this helps. Again, have a look at the show notes. There will be links to additional information in there.
With that, I will close the show. Thank you very much.
June and tomorrow for another exciting episode of Hackerel.
Thank you for listening to Hackerel Public Radio.
HPR is sponsored by Kero.net, so head on over to C-A-R-O.N-E-T for all of us in here.
Thank you very much.