So what happens when we encrypt the config file? Wouldn't that gain some strength in the above scenario? What about a module that checks the config file's CRC hash over the botnet and executes a remotely triggered cmd_die in the case of a failing CRC check? In short, there are many possible measures to prevent the above from happening.guppy wrote:Uhm .. no one actually brute forces the passwords in a userfile. They just modify the config file and kill -HUP the bot or shutdown the bot, modify the userfile, and restart it. It doesn't matter if yer using Blowfish, MD5, etc ...
Yes, but that's not what I am trying to say. I actually think there's no real reason to encrypt the userfile entirely unless you have some privacy issues with hostmasks and the alike. What i meant was more of a form of "Security-Through-Obscurity". For example, if you systematicly change all the procedure names and procedure call names in your sources to something harder to understand before you compile, and make little smart use of encryption, the average 'they' will give up much sooner than when you dont.guppy wrote:As for encrypted bot packs -- if your entire userfile is encrypted, there's no real reason to encrypt the passwords seperately.
Wouldn't it be a great challenge to decrease this percentage?guppy wrote:Also, 99% of botpacks are insecure and can be gotten around by anyone with half a brain in a couple of hours.
No, this would either require a static key compiled into the binary, or one passed over the command line, which can then be read from memory.Mapherick wrote: So what happens when we encrypt the config file? Wouldn't that gain some strength in the above scenario?
This would imply that you have a botnet.Mapherick wrote: What about a module that checks the config file's CRC hash over the botnet and executes a remotely triggered cmd_die in the case of a failing CRC check?
Visit http://developer.microsft.com/job-application/ . MS would love to have you helping themMapherick wrote: What i meant was more of a form of "Security-Through-Obscurity".
straces on encryption functions would simply show that blowfish is not operating as it should.Mapherick wrote: What if i call my SHA1 module blowfish.so and even better: make this file the same size as the blowfish.so originally compiled with the eggdrop?
Yes it would.Mapherick wrote: Wouldn't it be a great challenge to decrease this percentage?
I don't say it's perfect, but perfect security doesn't exist anyway. That's not what I'm going for here. Good security does exist and that's my goal.ppslim wrote:No, this would either require a static key compiled into the binary, or one passed over the command line, which can then be read from memory.
I am not aiming at those users that have services on their IRC networks. I am unlucky to have lived my e-life on EFNet so far and thus for me, and with me 80k other EFNet users, bots are the primary security measure (next to ofcourse the 'new' chanfix.) Securing the security is actually what I am trying to do.ppslim wrote:Many users use eggdrop on servers which have services enabled and available. In this situation, the service does primary control, while eggdrop is there to do customisable automatic managment. As such, the need for a bot is only one.
Oof! You're right, thanks. I'm actually really scared of doing -bot, but maybe a 'force unlink' flag, like how +d works for users, would do. Near perfect segmentation of the bottree in combination with trusted hosting of the main hub would ofcourse be demanded. As for just killing the bot, forced startup from remote should be possible (costs a process tho)ppslim wrote:The idea of using cmd_die is just stupid. Many eggdrop crackers will try and obtain access to the channel using a hack on the userfile. If this option isn't available to them, they will simply try and kill the bot.
I never said anything about not fixing problems. Look at it as an extra layer.ppslim wrote:This is the worst kind of security you can have. You shouldn't hide the problems, you should fix them.
From what i experienced personally, most takeover people aren't THAT sophisticated. I wouldn't even call the most of them crackers, rather 'scriptkids' (was trying to avoid this term.) I'm not underestimating people, it's just that most of the takeovers are not sophisticated and I'm sure the largest part is caused by leaked passwords.ppslim wrote:If a cracker is smart enough to get onto the shell, and work through eggdrop without modification, they are only a few steps off doing the same with modifications.
Especially step 3 is very true. Security is the opponent of functionality. The more functionality you remove, the more secure your eggdrop will be, and the more security you add, the lesser functional the eggdrop will be. For this reason i remove everything i dont use from the sources, the identify function is always off, masters/owners have no hostmasks attached to their user record, dcc chat is off, just a few examples.ppslim wrote:Step 1: Force users to read documetation somehow (telepathy)
Step 2: Add bloat to eggdrop, to destingush if certain setting could pose security risk. Warn user at startup 500 times before going to background.
Step 3: Refuse to add all hostmasks on the ground they are weak, because the user doesn't understand the concept of how hostmasks work, and how they could relate to other users.
Step 4: Force user to change password every 12hours
Step 5: Give all shell providers a clue
Security is ALWAYS down to user attitude. And guess what, i never had no ignorant users, anywhere. Next to that, someone who can permit to annoy the wrong person because the security is tight would have alot more fun. Anyone can probably remember from his youth not to [censored] around with the big boys, unless you like to be beaten up, that is.ppslim wrote:Cracking eggdrop is usualy 99% down to user attitude. Some1 annoys the wrong person, they think they are same coz of there |337 eggdrop.
I guess that's what i'm trying to do: to do something about it.ppslim wrote:Unless a owner understads security, and tries to do somthing about it, they are wide open.
Rather true.Mapherick wrote: I am conveinced that if NASA started to write their own operating system or modify the standards, their intrusion rate would become drasticly lower. If it would work for them, why wouldn't it work for us?
The force unlink flag is allready available.Mapherick wrote: Oof! You're right, thanks. I'm actually really scared of doing -bot, but maybe a 'force unlink' flag, like how +d works for users, would do. Near perfect segmentation of the bottree in combination with trusted hosting of the main hub would ofcourse be demanded.
This is the responisbility of the user.Mapherick wrote: For this reason i remove everything i dont use from the sources, the identify function is always off, masters/owners have no hostmasks attached to their user record, dcc chat is off, just a few examples
Exactly. Why should the development team, or any1 else for that matter, provide script/code to add security to eggdrop (as above, thus removing functionality), for a user that can't be bothered doing it themselves.Mapherick wrote: However, if someone who implements eggdrop for security doesn't care about security and doesnt read manuals, isn't interested in best practises and doesn't get a strategy on security, then is such user worth worrying about?
Point taken.ppslim wrote:In our case, the OS is the shell provider or the eggdrop user, and this we can't change.
I should rtfm more often, so I actually remember what I readppslim wrote:The force unlink flag is allready available.
Should security scripts/mods be made on request only then? I can't really imagine someone who doesn't have coding experience to know exactly what should be secured. For example, by testing a modified cookieop script for a friend, I suddenly realized the problem of bot authentication, while I had been running a botnet for over 2 years prior to that, without any takeovers. I did *some* assesments on my net, but really, do we expect eggdrop users to do a complete security audit on their bot(s) before they implement it? I would have that done for my business, but I think that even I wouldn't have done audits if I didn't put efforts into security a little more than a year back, because my boss asked me to.ppslim wrote:Exactly. Why should the development team, or any1 else for that matter, provide script/code to add security to eggdrop (as above, thus removing functionality), for a user that can't be bothered doing it themselves.
They don't need scripting knowledge to add secuirty. Many of eggdrop's settings can be changed to close a lot of areas.
If I run my net of a shell provider that is insecure, the problem would be mine as well. Even worse, if a FreeBSD coder doesn't care about security and my provider runs it, it's still my problem. If there would be some providers that actually did apply all patches on 0-day, whom I think do not exist as of yet, the solution would be simple. However, since there is as far as I know no such thing as a trusted commercial shell provider, the solution isn't that simple and we might want to look into dealing with those problems.ppslim wrote: Once this is done, the only real means of access is through insecure hostmasks, or via the shell. One again, is down the user, and the other is the shell providers problem. Thus, eggdev can't do anything about this.
True, increasing security awareness is always a good thing to do, although in this case it's not a simple task to put yourself to.ppslim wrote: In genral - we should be trying to educate users, not give out free "get out of **** fast" patches.
DCC might be more secure in protocol than MSG, but a DCC console does offer a lot more functionality (and thus insecurity).ppslim wrote: All MSG commands where banned, with the exception of ident, which was rebound to myident (lame yes, but a crude and effective way (yes, this probably is security through obscurity, but can you tell me any other method of providing a ident command)) and config settign being changed to the most secure value.
Other methods available are flood protection.Mapherick wrote: Example: What I used to do is restricting +p to masters and keep only the msg:op. On my channels, the botnet is divine, the ops are just privileged users on the channel, not on the botnet. Ops are NOT trusted. I started with this after the only takeover I ever had to deal with was done by a trusted insider, not an outsider. If he would have had console access and in a worse case, ident access, I'm sure it would've been much more of a mess and I wouldn't have had the channel back after 2 hours.