PHP Protective Service Prospective Rules

[Damien]

Hi readers,

For those who rember, i've taken the task of creating a fully TS compliant PHP server. I'm at a stage where I can start developing the security module in hope to address some problems we've recieved on our 4-server network. Due to being a PHP-only coder, I can't modify any other services such as OperServ, BOPM, etc etc so i've decided to port all the useful features that we use from the services into a script that i'm able to edit and change.

I'm really asking apon anyone who has had any problems running a IRCD/Channel if they could submit possible cures to everyday situations faced by running a popular server, such as clones, floods, drones, etc.

I will then hope to include this into the script, and release as a project.

So far, basic brainstorming has given me the following ideas (sorry for the form its written in...)

1) Check for x name changes in x seconds by x users
2) Check for multiple repeats in main channels. +mi -v *
3) Check for x connects in x seconds
4) Check for similar (by percentage?) USER params and/or idents
5) Check for similar hosts (see 6)
6) Scan well known proxy ports or predefined ports
7) Create custom sendq's and maxsendq's for main channels and inforce. (see 7b)
7b) If flood < sendqmax BUT > sendq KB else kill/kline
8) Hold current USERHOST list in DB every 10 mins. On activation, kill all not matching hosts (see 8b)
8b) Once "USERLIST" activated, kill all connecting clients untill flood has been delt with.
9) Kill users that are in more than x channels (NOT OPERS!)
10) Check for x JOINS/PARTS in x seconds
11) Kill users matchin pattern (*!????@*)

Some of these may seem drastic, but I emphasise that this is a local server, for local people (;)) and if anything, it will come in use to whoever uses it (be it for a single-IRCd "network").

If anything, just reply with how great I look in these shoes... or comment on any of the above rules :)

-Damien

[-wassup-]

i must say i love your shoes damien....you look so nice in em

would it be possible to make aurora communicate with other services? for example sentinel's SERVICES which tells tcm/oomon bots information? the more interaction between services the tighter our network will be.

[Hwy]

Is this an actual ircd, or a services package?

[-wassup-]

its actually a services package. we dont really have any plans for it to accept client connections as of now. accepting clients is best done to the ircds it seems.

[Hwy]

A service can't see the two "unused" USER parameters (used during registration) and can't see PRIVMSG/NOTICE's to channels unless it is in that channel. These are limitations of the s-s protocol that would prevent some of what you propose from being possible.

[-wassup-]

well we do plan to have Aurora join and stay in channels we choose.

Damien - do you think it would be possible to make that service available to everyone by having them reg with aurora and they get a small control panel access?

[Damien]

Hwy - Aurora will stay in the main, official channels so we'll recive text information and be able to regulate the traffic flow.

Wassup - I've thought about running it so it will interact with other services, and to make the network function fully if either Aurora of the other services are down then yes, I will get Aurora to communicate and relay relitive information to/from, however, to message OperServ to kill a user is a bit much.

Hwy - it is simply a service, i've got the theory of the code on how to get "her" to implement user sessions, yet I see no need to - there is a PHP IRCd out there and i've no intention on competing... however, she is fully DCC ("partyline") compatiable and that's all we'll need.

Wassup - I am thinking about allowing users to reg for certain permissions, but atm, I think the services cover all they need to. However, I will be creating a webbased control panel, to interact with Aurora if you are ever behin a firewall with only webaccess... i'm sure later I can allow users a little tiny itchy corner of my webspace/traffic

-Damien