Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm trying to compile a list of post and or protocols that are known to be insecure and/or obsolete.
When doing vulnerability tests, and NMap scans, it would be handy to have this information to compare to the results to identify possible weaknesses on the network.
The only things I can think of off the top of my head are:
blady - Flipped through the IETF doc, didn't see a seciton specifically on what I was looking for.
teebones - that is best practice, but I am specifically looking for port and protocols that are weak so that this information may be used in a penetration test. Of course the recommendation would be to only allow certain ports, but during a pen test, to provide proof of concept, we would like to have the information I am requesting.
There isn't a section on "weak" ports / protocols, the point being ANY port that is open presents potential opportunities for intrusion. teebones is bang on - ONLY open services you need and make sure you are using the most secure implementations of these services and that they are up to date.
I appreciate the advice, but again that isn't the intention of this question. It often isn't practical to recommend just closing ports. If a client is running FTP it is very possible they need it, so I can't tell them to close port 21. No, I have to provide them with a solution such as an SFTP alternative. Ports have to be open - it is the classic usability VS security problem.
So, I am looking for other ports like Telnet and FTP that a hacker might see on a port scan and think - "Bingo." This was, when I see them myself I can recommend to my clients to use an alternative. If I told them what you are telling me I would be fired, or at least laughed and and lose credibility.
insecure
[in-si-kyoor] Origin
in·se·cure
[in-si-kyoor]
adjective
1.
subject to fears, doubts, etc.; not self-confident or assured: an insecure person.
2.
not confident or certain; uneasy; anxious: He was insecure about the examination.
3.
not secure; exposed or liable to risk, loss, or danger: an insecure stock portfolio.
4.
not firmly or reliably placed or fastened: an insecure ladder.
unsecure
[si-kyoor] Origin
se·cure
[si-kyoor] adjective, -cur·er, -cur·est, verb, -cured, -cur·ing.
adjective
1.
free from or not exposed to danger or harm; safe.
2.
dependable; firm; not liable to fail, yield, become displaced, etc., as a support or a fastening: The building was secure, even in an earthquake.
3.
affording safety, as a place: He needed a secure hideout.
4.
in safe custody or keeping: Here in the vault the necklace was secure.
5.
free from care; without anxiety: emotionally secure.
Hence my comment, only open ports you NEED. If FTP is needed then its needed. You then need to go on and consider how secure your ftp implementation is and weather you shouldn't be insisting on SFTP etc.
If your network security policy is based on "shut ports down that some bloke on the interwebs told me was unsecure" then you are already in trouble.
If it is your job to secure the network then you should know exactly what ports are open and exactly what each one does and who it is used by. Anything less would be what will produce the dire results you detailed above.
There is no shortcut for due dilgence here I'm afraid. You should be port scanning your own network for open ports and identifying what and who for every single one, and then applying your security policy appropriately.
It just sounded funny to me when I read it. An insecure port, hiding out there, worried it might be laughed at. Might be going to a tcp/ip doctor for help.
jefro, according to the definition of insecure that you provided:
"
3.
not secure; exposed or liable to risk, loss, or danger: an insecure stock portfolio.
4.
not firmly or reliably placed or fastened: an insecure ladder.
"
I can see that I'm not going to get the exact answer that I am looking for here, so thanks everyone, for you time.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.