One of the determined mime types on the greylist should be enough to trigger analysis.

Shouldn't this look more like the following?

for m in s.mimetypes:
	if m in set(greylist):
		return ...

We should look into the possibility to simplify the cuckoo rules using a custom signature inside Cuckoo.

Currently we maintain a list of strings which are matched against the signatures reported by Cuckoo.

It might be possible and more efficient to handle this inside Cuckoo using a kind of meta-signature which detects the matching/firing of all the other signatures we consider "bad", accumulates them into a binary decision "good"/"bad" or even some kind of score and reports just that single value back to Peekaboo.

Suggested by @Jack28.

Hi Felix
There's just another issue I figured out with my peekaboo installation.
I ran the peekaboo test.py and got the following output:

test_attribute_dict (main.TestSample) ... ok
test_job_hash_regex (main.TestSample) ... ok
test_sample_attributes (main.TestSample) ... No handlers could be found for logger "peekaboo.sample"
FAIL
test_sample_attributes_with_meta_info (main.TestSample) ... ok
test_sample_without_suffix (main.TestSample) ... ok
ERROR
test_1_analysis2db (main.TestDatabase) ... ok
test_2_sample_info_fetch (main.TestDatabase) ... ok
test_3_sample_info_update (main.TestDatabase) ... ok
test_4_fetch_rule_result (main.TestDatabase) ... ok
test_5_known (main.TestDatabase) ... ok
ERROR

ERROR: tearDownClass (main.TestSample)

Traceback (most recent call last):
File "test.py", line 223, in tearDownClass
cls.conf.db_con.close()
AttributeError: 'PeekabooDatabase' object has no attribute 'close'

ERROR: tearDownClass (main.TestDatabase)

Traceback (most recent call last):
File "test.py", line 140, in tearDownClass
cls.conf.db_con.close()
AttributeError: 'PeekabooDatabase' object has no attribute 'close'

FAIL: test_sample_attributes (main.TestSample)

Traceback (most recent call last):
File "test.py", line 183, in test_sample_attributes
'Ausschlaggebendes Ergebnis laut Datenbank: Datei ist dem System noch nicht bekannt')
AssertionError: u'Ausschlaggebendes Ergebnis laut Datenbank: This is another test case.' != 'Ausschlaggebendes Ergebnis laut Datenbank: Datei ist dem System noch nicht bekannt'

Ran 10 tests in 0.041s

FAILED (failures=1, errors=2)
`

Hi.

I am trying to run PeekabooAV after the installation and I received the following output.
$ sudo peekaboo

PEEKABOO 1.6.1

Peekaboo Extended Email Attachment Behavior Observation Owl

               _a_aa                    a_aa,
                '*U4UUUULa_aa_aa_aajUUU4XU7'
                  aX''''''UUXU4XUU'''''!Ua
                _U'        -U4UU'   _    'U,
                ?i   jLd1   ?#Wi   4L01   Ui
                -U,        4#000P        _U'
                 -*Xa_a_a_WUW##KUL_a_a_aX7'
                _aXUXUUU4UUX4XX444UUUUUUXLa,
               _UXXUXUXU47'!'!'!'!*X444U4UXX,
               ?XU4U4''   _   __   -'UUXUUi
               ?4U4'     / | / /_     'UUXi
                *Xi      | || '_ \     ?X7
                 *L      | || (_) |     j7
                  *a     |_(_)___/      jY
                   -L,                _/'
                     'l,            _/'
                       j7_a_;  aaa/4
           _aaaaaa#0000#00000##0##00000000aaaaaa,
    aaad0P!!!!!!                             '!!!!!!Laaa

_aa!!!! !! _,
(never mind the K)

2018-07-29 08:29:58,219 - peekaboo.config - (MainThread) - CRITICAL - configuration section not found
2018-07-29 08:29:58,219 - peekaboo.config - (MainThread) - ERROR - No section: 'logging'
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/peekaboo/config.py", line 108, in __parse
log_level = config.get('logging', 'log_level')
File "/usr/lib/python2.7/ConfigParser.py", line 607, in get
raise NoSectionError(section)
NoSectionError: No section: 'logging'

How do I solve this error?

We need to go through the code and documentation and update authors and possibly other outdated references.

If a file gets processed the hash and result is logged to the Sample database. If this file gets processed again the hash will identify it as the same file and the former result will be used. The file extension is not part of this process. An attacker could submit a malicious file with an extension that will cause the file to be opened with an application which is not vulnerable to the attack. Hence the report doesn't include malicious activity. The actual attack is then performed with the same file but a different file extension. The scan is passed because latest analysis doesn't show any suspicious activities while the client will be infected.

I propose an additional database field that holds the file extension this sample was analysed with.

File A "info.txt"
File B "playlist.pl"
Same content, same SHA256 hash, but opened with different applications eg. Notepad and VLC. Causes exploit to not be detectedable for the actual analysis (first time) and won't be analysed subsequently.

I was developing Grafana Dashboard and development would be straight forward if the table names wouldn't contain the version number of the database. You could also check the meta table for the current version.

Best
Jan

Peekabo marks the attachments as bad because there "is" an error. But according to Analysis and Cuckoo log there isn't one

Expected Behavior

If there isn't an error, peekaboo shouldn't mark it as bad (current intended behavior of peekaboo)

Current Behavior

Peekaboo marks the attachment as bad

Possible Solution

I don't see any errors in the logs mentioned above
But I do see, that the log doesn't contain the string "analysis completed successfully"
If I understood it correctly, peekaboo determines with that string if the analysis has failed?

Hope this issue belongs to Peekaboo, or should I create an issue at cuckoo?

Steps to Reproduce

1. Instance installed with the latest version of the installer
2. Attachment: f.docx

Analysis: 85.zip

Context (Environment)

Some versions before, there wasn't such a problem. But sadly I cannot say which version was installed

Thank you for your help!!

We want to support running multiple instances of Peekaboo in parallel to increase throughput. We use the database to coordinate these instances, especially to avoid parallel analysis of the same sample by multiple instances. This is now working in multiple ways currently:

1. We add inProgress entries to the database but do not fully clean them upon shutdown/startup. This causes gradual startup slowdown. The first attemt to fix it failed. (#60, #48).

2. We do not seem to actually check these inProgress entries when starting analysis on a sample.

Currently Peekaboo dies/shuts down if the embedded Cuckoo child dies. With PR #35 merged we could look into trying to recover from that by restarting.

Things to consider:

• Now that we also have a REST API mode, should we spend effort on that or rather improve API support?
• How often do we try to restart Cuckoo at what intervals?
• What do we need to improve on the queueing/worker side to bridge the time until Cuckoo is restarted and accepting samples again. In the simplest case we could just have the submit retry a number of times with a waiting period and overall timeout, blocking their worker until successful or giving up.

We sometimes get

error: The 'pyasn1' distribution was not found and is required by service-identity

from setup.py. Tracked this into setuptools and opened an issue for it: pypa/setuptools#1752. Currently no idea what we can do about this other than telling the user to run setup.py twice (no real option, IMO).

Expected Behavior

Original filenames are displayed in cuckoo web instead of their checksum

Current Behavior

Cuckoo web displays some long checksums

Possible Solution

Display the real file name on cuckoo web

Context (Environment)

That makes sometime debugging not easy when you want to find a specific analysis

Ahoi,
I installed cuckoo in a different directory and have to start it with --cwd /data/cuckoo

because of that peekaboo is using a default configuration I assume and can't find my VMs.
My VMs have other names, cuckoo1 is the default name.

2018-02-05 11:46:39,493 - peekaboo.toolbox.cuckoo - (MainThread) - DEBUG - STDERR 2018-02-05 11:46:39,493 [cuckoo.core.scheduler] INFO: Using "virtualbox" as machine manager 2018-02-05 11:46:39,830 - peekaboo.toolbox.cuckoo - (MainThread) - DEBUG - STDERR 2018-02-05 11:46:39,829 [cuckoo] CRITICAL: CuckooCriticalError: Please update your configuration. Unable to shut 'cuckoo1' down or find the machine in its proper state: The virtual machine 'cuckoo1' doesn't exist! Please create one or more Cuckoo analysis VMs and properly fill out the Cuckoo configuration! 2018-02-05 11:46:39,948 - peekaboo.toolbox.cuckoo - (MainThread) - WARNING - Cuckoo closed STDERR

Where can I change the path within peekaboo so it will use my Cuckoo-Conf-Files ?

Best regards
peacemaker

We need to add an exception for GPG signatures similar to S/MIME (#39) to avoid false positivies.

Suggested by @Jack28.

Discussion on #29 showed that mapping from MIME type to file extension throws up lots of questions. We should look into whether the whole issue can be avoided by using other means than the file type extension to give cuckoo a hint about how it needs to analyse a file. One possibility might be providing the MIME type itself to cuckoo and let it figure out what to do with it. This might be especially easy using the REST API.

Suggested by @Jack28.

When running multiple instances of Peekaboo with the same database, the changes from PR #48 cause records of all currently running analysis to be removed on restart/startup of a single instance. This causes all currently running analysis of the other instances to fail. We need some improved code to track this distinction. Until then we should back out this change.

Currently our decisions on malware are binary and the ruleset terminates on the first positive decision (i.e. malware detected). Changing this to an accumulated score allows for fuzzy decisions and therefore greater flexibility in configuration and thresholds what is considered malware.

This could be implemented in the current ruleset engine or paired with a switch to a different implementation, e.g. YARA or a Custom Signature in Cuckoo.

Suggested by @Jack28.

We are currently working on a dashbard extension.
To get access to the detailed cuckoo report on the dashboard we either
need a entry in the peekaboo database of "cuckoo.tasks.id" or the direct
link to the cuckoo summary.
With the current database design of cuckoo the information should be
stored in "sample_info_v2".

After installing with the great installer (Thanks! It makes the whole thing for me alot easier :D ), I get an error when submitting an example attachment.

Steps to reproduce
Sending an email with the tool swaks and putty.exe in the attachment

Expected behavior
Email is relayed with the original attachment since the attachment is just putty.

Actual behaviour
Mail is not relayed to the actual recipient. Admin is notfified, this mail states also: No viruses were found.

Testing the file directly on the socket, like in the docs of the installer, the exe is not detected as harmful (in my understanding)

/var/log/mail.log:

Apr 23 14:31:22 peekaboo-debian amavis[8476]: (08476-01) (!)run_av (Peekaboo-Analysis) FAILED - unexpected , output="Hallo das ist Peekaboo\n\nDatei "p002" 4f81b422c9f73f4a6167267e03d3d51c76f894b12d500ff1fb1f8bfc249931d2 wird analysiert$
Apr 23 14:31:22 peekaboo-debian amavis[8476]: (08476-01) (!)Peekaboo-Analysis av-scanner FAILED: CODE(0x5612b3c36680) unexpected , output="Hallo das ist Peekaboo\n\nDatei "p002" 4f81b422c9f73f4a6167267e03d3d51c76f894b12d500ff1fb1f8bfc24$Apr 23 14:31:22 peekaboo-debian amavis[8476]: (08476-01) (!)...ingestuft\n\n" at (eval 99) line 951.
Apr 23 14:31:22 peekaboo-debian amavis[8476]: (08476-01) (!)WARN: all primary virus scanners failed, considering backups
Apr 23 14:31:22 peekaboo-debian amavis[8476]: (08476-01) (!!)AV: ALL VIRUS SCANNERS FAILED
Apr 23 14:31:23 peekaboo-debian amavis[8476]: (08476-01) Negative SMTP resp. to DATA: 554 5.5.1 Error: no valid recipients
Apr 23 14:31:23 peekaboo-debian amavis[8476]: (08476-01) (!)fipKy3OmPW8h(jvMoxGQxK759) SEND from <> -> <[email protected]>, [email protected] BODY=7BIT 454 4.7.1 from MTA(smtp:[192.168.56.1]:10025):$Apr 23 14:31:23 peekaboo-debian amavis[8476]: (08476-01) (!!)TROUBLE in check_mail: delivery-notification FAILED: temporarily unable to send DSN to <[email protected]>: 454 4.7.1 from MTA(smtp:[192.168.56.1]:10025): 454 4.7.1 <[email protected]$Apr 23 14:31:23 peekaboo-debian amavis[8476]: (08476-01) (!)PRESERVING EVIDENCE in /var/lib/amavis/tmp/amavis-20180423T143122-08476-bObvfHaH

Could someone please help me to solve my problem?

Hopefully, I did not something wrong while installing.

Our documentation has gone a bit stale. Review and update as necessary for the next release.

The current REST API mode works but needs additional error handling and testing for exceptional conditions and erros.

Hi

After a few consultations to improve the whole performance of our systems we want to let one vm running in the RAM and create linked copies, so it could run a bit faster.
With our incoming traffic, specially in the morning and afternoon, peekaboo sometimes can't handle the mass and throttles down.
How did you implement this sceanario? As far as I know you need to have a dhcp-server running that cuckoo sandbox doesn't get ip conflicts... But we're not sure how to adjust the <machinery>.conf.

It would be very helpful to us.

Kind regards
Michael

We need a test suite we can run regularly and particularly before releases to test the whole suite for regressions.

Hi
I have a question about amavis & peekaboo processes.
On my server i'm running about 80 vm's. I configured $max_servers in amavisd.conf to 36.

Is this correct or should I decrease this value?
How did you managed it?

regards, Michael

Hi,

I've got a problem with starting the peekaboo.service. Systemctl starts the service and creates the peekaboo.sock. Even though after a few seconds the socket disappears und the service changes from active to activating...
Here's the error. I hope you could maybe help me.

Nov 10 13:31:41 host.example.com systemd[1]: Starting Peekaboo Extended Email Attachment Behavior Observation Owl...
Nov 10 13:31:41 host.example.com python[4391]: Starting Peekaboo 1.3.
Nov 10 13:31:41 host.example.com python[4391]: 2017-11-10 13:31:41,810 - peekaboo.daemon - (MainThread) - DEBUG - <PeekabooConfig({'db': {'url': 'postgresql://peekaboo:peekaboo@localhost:5432/peekaboo'}, 'global': {'job_hash_regex': '/var/lib/amavis/tmp/([^/]+)/parts.*', 'group': 'peekaboo', 'sample_base_dir': '/tmp', 'socket_file': '/opt/peekaboo/peekaboo.sock', 'worker_count': '3', 'use_debug_module': 'no', 'user': 'peekaboo', 'chown2me_exec': '/opt/peekaboo/bin/chown2me', 'pid_file': '/opt/peekaboo/peekaboo.pid', 'interpreter': '/usr/bin/python'}, 'logging': {'log_format': '%(asctime)s - %(name)s - (%(threadName)s) - %(levelname)s - %(message)s', 'log_level': 'DEBUG'}, 'cuckoo': {'storage_path': '/opt/cuckootest/storage', 'submit': '/usr/bin/cuckoo submit', 'exec': '/usr/bin/cuckoo'}})>
Nov 10 13:31:41 host.example.com python[4391]: 2017-11-10 13:31:41,845 - peekaboo.db - (MainThread) - DEBUG - Cleared the database from "inProgress" entries.
Nov 10 13:31:41 host.example.com python[4391]: 2017-11-10 13:31:41,845 - peekaboo.pjobs - (MainThread) - DEBUG - Create Worker 0
Nov 10 13:31:41 host.example.com python[4391]: 2017-11-10 13:31:41,845 - peekaboo.pjobs - (Thread-1) - DEBUG - Worker is ready
Nov 10 13:31:41 host.example.com python[4391]: 2017-11-10 13:31:41,845 - peekaboo.pjobs - (MainThread) - DEBUG - Create Worker 1
Nov 10 13:31:41 host.example.com python[4391]: 2017-11-10 13:31:41,846 - peekaboo.pjobs - (Thread-2) - DEBUG - Worker is ready
Nov 10 13:31:41 host.example.com python[4391]: 2017-11-10 13:31:41,846 - peekaboo.pjobs - (MainThread) - DEBUG - Create Worker 2
Nov 10 13:31:41 host.example.com python[4391]: 2017-11-10 13:31:41,846 - peekaboo.pjobs - (Thread-3) - DEBUG - Worker is ready
Nov 10 13:31:41 host.example.com python[4391]: Traceback (most recent call last):
Nov 10 13:31:41 host.example.com python[4391]: File "/usr/bin/peekaboo", line 9, in
Nov 10 13:31:41 host.example.com python[4391]: load_entry_point('Peekaboo==1.3', 'console_scripts', 'peekaboo')()
Nov 10 13:31:41 host.example.com python[4391]: File "build/bdist.linux-x86_64/egg/peekaboo/daemon.py", line 195, in run
Nov 10 13:31:41 host.example.com python[4391]: File "build/bdist.linux-x86_64/egg/peekaboo/daemon.py", line 63, in init
Nov 10 13:31:41 host.example.com python[4391]: File "/usr/lib64/python2.7/SocketServer.py", line 417, in init
Nov 10 13:31:41 host.example.com python[4391]: self.server_bind()
Nov 10 13:31:41 host.example.com python[4391]: File "/usr/lib64/python2.7/SocketServer.py", line 431, in server_bind
Nov 10 13:31:41 host.example.com python[4391]: self.socket.bind(self.server_address)
Nov 10 13:31:41 host.example.com python[4391]: File "/usr/lib64/python2.7/socket.py", line 228, in meth
Nov 10 13:31:41 host.example.com python[4391]: return getattr(self._sock,name)(*args)
Nov 10 13:31:41 host.example.com python[4391]: socket.error: [Errno 98] Address already in use

regards, Michael

We could use a mechanism to make sure that the whole peekaboo/cuckoo pipeline works, ideally without submitting and including in the distribution any actual or test malware.

The vision is to have a custom community signature in cuckoo which accepts a random cookie upon job submit and then looks for exactly this cookie as an existing file of that name or a file of that content in a fixed location. Peekaboo could then submit that trigger file to cuckoo and thus test the whole pipeline from beginning to end.

The signature could be enabled all the time in cuckoo because peekaboo can control if and when it submits a test job with the signature's cookie parameter, e.g. when started in debug or a special system-test-on-startup mode. This would avoid a need for reconfiguration of any system components to test them.

This would replace the current PeekabooYar EICAR-signature-like approach.

Suggested by @Jack28.

In cuckoo.py in line 189
config.cuckoo_storage, 'run_analysis/%d/reports/report.json'
shoud be
config.cuckoo_storage, 'analyses/%d/reports/report.json'

Hi Felix,

I've got some new stuff for you to troubleshoot :D
The following three images will show you my Problem.

On the first one, you can see the ending of the files that were analyzed. *.ARRAY(0x51c9d30) !strange!

Then if I open the summary, the type of the file is an PDF document. So IMO the endig of the file should be .pdf and not ARRAY.

And because cuckoo cannot find a package to analyze, it generates this signatures. One of them (Queries the disk size*) blocks the email and will not forward it.

This is a very interesting bug. Maybe you noticed the same.

regards, Michael

An attacker can simply specify the mime-type for an attachment to be plaintext (which is on the whitelist) and avoid detection.
The mistake is in the test for filetypeonwhitelist. Rather than checking if any of the file types determined is on the whitelist it should check if all file types are on the whitelist.

Hi Felix

I'v got only a small question about the four analysis result states inProgress, uknown, ignored, bad.
Actually I only know what inProgress and bad mean. But the other two I cannot assing to something. unknown maybe that the attachment is good but with ignored I don't have a clue.

Cloud you help me out there?

Thank you for your help.
Best
Michael

We should support python3. We're currently explicitly requiring python2.7 and do not test with python3. As far as we know all our current dependencies support python3. cuckoo itself does not (yet) but we only spawn it as a process and do not load any modules from it. Insofar we "only" need to look at our own code.

Suggested by @SebastianDeiss.

We should rework the S/MIME (#39) and GPG signature exceptions (#40) to be more generic, e.g. inside the ruleset to avoid polluting the Sample class with this specific kind of exception.

Hi Felix,
Since wednesday, I'm not able to start the peekaboo.service via systemd. Unfortunately I can't figure out where the origin of this error is.
The problem doesn't occure if I start peekaboo with /usr/bin/python /usr/bin/peekaboo -c peekaboo.conf.
It should be possible to increase the timeout, I hope so.

Underlying you'll see my log file, which isn't really meaningful to me:
Dec 01 08:21:11 hostname python[2215]: 2017-12-01 08:21:11,481 - peekaboo.daemon - (MainThread) - DEBUG - <PeekabooConfig({'db': {'url': 'postgresql://peekaboo:peekaboo@localhost:5432/peekaboo'}, 'global': {'job_hash_regex': '/var/spool/amavis/tmp/([^/]+)/parts.*', 'group': 'amavis', 'sample_base_dir': '/tmp', 'socket_file': '/var/run/peekaboo/peekaboo.sock', 'worker_count': '300', 'use_debug_module': 'yes', 'user': 'peekaboo', 'chown2me_exec': '/opt/peekaboo/bin/chown2me', 'pid_file': '/var/run/peekaboo/peekaboo.pid', 'interpreter': '/usr/bin/python'}, 'logging': {'log_format': '%(asctime)s - %(name)s - (%(threadName)s) - %(levelname)s - %(message)s', 'log_level': 'DEBUG'}, 'cuckoo': {'storage_path': '/opt/peekaboo/.cuckoo/storage', 'submit': '/usr/bin/cuckoo submit --unique', 'exec': '/usr/bin/cuckoo'}})> Dec 01 08:22:35 hostname systemd[1]: peekaboo.service: Start operation timed out. Terminating. Dec 01 08:22:35 hostname systemd[1]: Failed to start Peekaboo Extended Email Attachment Behavior Observation Owl. Dec 01 08:22:35 hostname systemd[1]: peekaboo.service: Unit entered failed state. Dec 01 08:22:35 hostname systemd[1]: peekaboo.service: Failed with result 'timeout'. Dec 01 08:22:35 hostname systemd[1]: peekaboo.service: Service hold-off time over, scheduling restart. Dec 01 08:22:35 hostname systemd[1]: Stopped Peekaboo Extended Email Attachment Behavior Observation Owl. Dec 01 08:22:35 hostname systemd[1]: Starting Peekaboo Extended Email Attachment Behavior Observation Owl... Dec 01 08:22:36 hostname python[6542]: PEEKABOO 1.3 Dec 01 08:22:36 hostname python[6542]: Peekaboo Extended Email Attachment Behavior Observation Owl

regards, Michael

Hi,
I've got a question. Not the first time. 😆
Over the weekend I let PeekabooAV run and wanted to see what's going on.
Then I checked on saturday and realized, that there's a really frightening amount of pending analysis.
I absolutely cannot tell where this is coming from.

First of all, we never ever get this amount of attachments in such a short period of hours. And second I adjusted the PeekabooAV white- and greylist.
Also there aren't any results you can see.

I seems like PeekabooAV tries to analyze the whitelisted MIME-types even though it shouldn't.

If analysis fails we currently report this as bad to amavis, i.e. as if we had found a virus. This causes mails to be quarantined simply because Cuckoo is somehow not working. This should changed to indicated that we do not know if it's good or bad. Ideally this could be reported to amavis as UNCHECKED.

1. As random local user: ln -s /etc/passwd /tmp/amavis-123
2. Run /opt/peekaboo/bin/chown2me as peekaboo:peekaboo
3. Ooops…file /etc/passwd belongs to peekaboo:peekaboo

Not sure what a proper fix could be, maybe lchown() rather chown(). Yes, systemd's ProtectSystem might help to prevent this – if systemd is being used.

Hi Felix,
It's me again.
I adjusted the $max_servers value to 150. After that, when I relay an example domain to the peekaboo server, I get huge mailq. Even if the emails do not have any attachments it really takes very long until they pass the server.
I just tried to disable the peekabooav and used only amavisd. If only amavis is working it doesn't generate a mailq. Looks like i'm having timing issuses. :-(
Do you have any ideas or tips?

regards, Michael

Hi
I was trying to install PeekabooAV again. The installations of all software-packages were successful.
Running Cuckoo itselfs works witout issues and same goes for PeekabooAV.
If I then try to send emails trough the server, PeekabooAV can't process and upload the file to Cuckoo. I'm getting the following error. I attached a file where you cant find my log.
peekabooavlog.txt

Software:

• PeekabooAV v1.5
• Cuckoo v2.0.5

We need to retest if our SMIME attachment exception to avoid false positives actually works. There have been reports that it doesn't.

I have successfully tested with the following requirements.tst:

root@someubuntu:~/PeekabooAV-Installer/PeekabooAV# cat requirements.txt
sqlalchemy>=1.0.8
Twisted>=17.1.0
service_identity>=16.0.0
python-magic>=0.4.12
oletools>=0.51
sdnotify>=0.3.1
enum34>=1.0.4
yara-python>=3.6.3
requests>=2.19.1

Which results in the following installed versions:

root@someubuntu:~/PeekabooAV-Installer/PeekabooAV# pip list | grep -f <(sed 's/>.*//' requirements.txt )
enum34                             1.1.6
oletools                           0.51
python-magic                       0.4.12
requests                           2.13.0
sdnotify                           0.3.1
Twisted                            18.9.0
yara-python                        3.6.3

Please comment and/or update

Change supported Ubuntu LTS

Expected Behavior

Newer software, especially amavis (2.11)
For its support of sha-256 hashes

Current Behavior

amavis 2.10
Config option doesn't exist

Context (Environment)

CuckooSandbox states they work best with the latest LTS Ubuntu release

Detailed Description

Testing and adaption to support Ubuntu 18.04

Based on scVENUS/PeekabooAV-Installer#21 we should implement logic that allows for having configuration files include each other in a modular fashion, e.g. /opt/peekaboo/etc/peekaboo.conf.local or /opt/peekaboo/etc/peekaboo.d/*.conf. This would allow for local changes to be placed in separate include files which do not get overwritten on upgrade.

Use the "original" name and path of the file that is run in Cuckoo. To avoid detection of the analysis environment.

We should update our documentation to reflect best practice to install Cuckoo and Peekaboo into separate virtualenvs. This would bring it in line with what the installer now does. This causes the following changes:

• some devel packages are needed, depending on the database used (libmysqlclient-dev, libpq-dev)
• python modules need to be installed into the respective virtualenvs as well as possibly globally for other tools which aren't virtualenv'd

After merging #27 generic file scanning functionality likely needs to be restored.

We should add codign style tests and document how to run them in README.md.

Suggested by @SebastianDeiss.

Hi

I'm not sure if it is an error caused by me, but if I manually alter a specific mime type or bad signature in the peekaboo rules file peekaboo/ruleset/rules.py then run python setup.py install and restart peekaboo, it doesn't seem the specified options are being applied.

For example I added the mime type application/pkcs7-signature and commented out a signature.

Kind regards
Michael

setup.py:52 calls cd bin/ && make chown2me – but it seems like the Makefile is missing?

Currently we speak a mix of the AMaViS AV protocol and our own JSON-based protocol on a UNIX domain socket between the client and Peekaboo. As discussed in rspamd/rspamd#1860 there are multiple reasons to put this on a more well-defined basis, using HTTP(S) and REST protocols and mechanisms.

Peekaboo's server, the scan_file.py client and the AMaViS plugin would need extension to support:

• other socket types than UNIX domain
• HTTP as basic transfer protocol
• definition and usage of REST/JSON for all operations, input and output
• HTTPS for secure scaling across machine boundaries including
  • server authentication (server certificate and CRL checking)
  • client authentication (e.g. pre-shared keys and TLS client certificates)

Hi Felix,

I'm really sorry to open up a new issue. Now that all is working fine, I get Peekaboo error in my maillog.
(!)Peekaboo-Analysis av-scanner FAILED: run_av error: ask_daemon_internal: Exceeded allowed time at (eval 749) line 657.\n

Not sure, where to find this configuration, but I think it'll be in the amavis configuration.