alex49201 wrote:
> I'm gonna try to clarify this a little bit, perhaps that will help
> everyone. I'm running just a simple web/mail server for various
> clients. I design most of the websites on the server, but not all of
> them. Some of the ones I've not designed are operating very insecuring,
> such as they are vulnerable to including remote pages.

If an attacker is able to include remote scripts in dynamic pages
on your server, then your problem is _a lot_ bigger than just spam
relaying.
>
> So the result of this, is these insecure php pages are being attacked
> and are sending spam directly from the php scripts to other mail

And probably the attackers are
-- installing back doors and zombie clients,
-- inspecting every document on the server that will be readable
with the access rights of your http daemon,
-- using your server to attack other systems,
-- doing everything you can imagine, or even more.
_Their_ imagination is the limit.

> servers. The mails are not being sent from the local sendmail.
> Basically, the php scripts are acting as a client, sending to a remote
> smtp server. I could of course block connects to any outgoing port 25,
> but that would also block mail being sent from sendmail.
>
> How can I create a rule that allows only sendmail to establish a
> connection to a remote port 25?

Packet filters act only on IP numbers and port numbers. So you
cannot do this with a simple packet filter.

>
> I want to block ALL outgoing mail from the server, unless it comes from
> sendmail. How can i do that?

You can't.
And your problem is not outgoing mail. Your problem is third parties
being able to run any software they choose on your system. If there
is any "suid root" executable on your system with a local exploitable
bug they might even gain root privilege.

The first thing to do is shut down at least those web pages that are
proved vulnerable.
You should at least inspect your system thoroughly for further damage,
but it might be safer and less work to do a complete reinstall from
known good media/backups.

Regards,

Kees.

--
Kees Theunissen.