Protocols are ways for computers to communicate. This is fairly fundamentally in opposition to your aim of security through obscurity - they don't know what language you're speaking, therefore they cannot hack it.
You'll filter out _most_ of your automated attacks, by simply moving services onto another port. For everything else, you'll need the same security/authentication layers that you'll need anyway.
What are you really trying to achieve? Reduced bot traffic? Just move ports. Even if you use a new protocol (which for a lot of reasons, isn't a good idea) then there will still be packets from the bots, bouncing off your firewall. So you might as well just run your webserver on a different port, and block all traffic on port 80. It'll achieve pretty much the same result - firewall can easily reject the traffic based on the port number.
If you're thinking your new protocol will improve security, then ... well, there's an old adage: Security through obscurity, isn't. It's all well and good to work on the basis that if people don't know that you're using some unusual protocol, then they can't get in, but the fact that this protocol is going 'out onto the net' means it is impossible to guarantee that. And therefore, you still need to authenticate etc. everyone, and have an additional layer of complexity for your end users.
| [reply] |
| [reply] |
"What I actually advocate is security through proper management of technology where it's necessary rather than always borrowing blindly from someone else."
And yet you're looking at tty, because 'badbots don't use it these days'. Seriously, a protocol isn't secure because stuff doesn't use it, it's secure because stuff _does_ and it's still proven pretty resilient.
"It is professionally incompetent to go looking from the outset for technology to solve your problems."
If I need to open a tin can, I will go and buy a can opener. If I find that the can opener I buy is not suitable for the job, then I may look at inventing my own. But more likely, I'll go and find someone else who makes can openers to see if theirs does a better job.
Which is more or less what you're doing when you're looking at using perl, NetServer::Generic to implement your new project.
"Correct technical design is a from-scratch process in which only when it is complete and harmonious do you go looking for shortcuts and trade-offs and even then you need to know the full functional story 100% rather than assembling together a bunch of things you don't fully understand."
Maybe, but by definition if you're doing so on a computer system build by someone else, running an OS written by someone else, using an interpreted language designed by someone else, you're _not_ starting from scratch.
It's not necessary to start from scratch. Look at what you've got. Look at what you're trying to do. Then try and figure out how to get from one to the other. Personally, I don't think implementing a new protocol is the way to go, since you'll pretty much _have_ to have traffic hitting your firewall anyway. Unless you're not planning to use the IP suite, but at that point you're going to have traffic that's not routable across the public internet. It's actually more intensive for a firewall to perform protocol inspection - look at a whole packet, and try and understand what it 'is' than it is to just check the 'inbound port' field in the IP packet, and base it on that.
| [reply] |