Tag Info

New answers tagged

2

Short answer Yes it is possible and aside from gpg-checking there are still several possible attacks! To tackle it, I would make sure that the automated update process does at least signature checking, use HTTPS for my repos, and possibly run a validating caching nameserver locally (DNSSEC) like Joe Sniderman suggests All this does still not ensure you ...


-1

It really depends on your threat model. If you are hosting some Wikileaks-grade document, that might be a very real threat. If it's just a casual server on the Internet, you'll just want to update as often as possible way before worrying about this kind of attack.


4

Yes it is possible to do a cache poisoning attack, and yes it is possible to protect yourself. In addition to the rather standard practice of signing the package files with GPG, some distros use DNSSEC to protect the domains that serve those files against DNS spoofing. Notice the 'ad' flag in the dns answer below: $ dig +dnssec security.debian.org. ; ...


1

My vote would be number 3, with number 2 as a close second. I suppose it depends on the rest of your infrastructure. To my knowledge, AJP doesn't support encryption between hosts. Number 3 allows you to implement an N Tiered architecture. Ideally the Apache server would be parsing/URL filtering for malicious traffic and not blindly proxying all requests to ...


2

To answer your question, it is possible to spoof the update servers DNS; then, your packet manager should not install unsigned packets, an attacker could send you bad data, but you wouldn't accept it. Most distributions use OpenPGP to sign their updates. Fedora and Debian do for example. You just have to make sure that your automated option validates ...


2

Whether traditional "protections" for sensitive data in desktop RAM (e.g. SecureString) are really needed or not, is debatable. When attackers can read the RAM contents, they already have a lot of control on the machine. We can still justify some proactive measures in the following sense: RAM in a machine may leak to disk, through virtual memory. The ...


-1

The files are public for the users' browsers to be able to play them, so you cannot prevent users downloading them for other reasons (or indeed just saving the copy in their browser cache). If you want to stop people reusing them in-place from your website (which might be your main aim - someone else referring to the file on your site causes you server load ...


1

Most of Steve DL's points are good, the "best" approach is to use a run-time linker (RTLD) that you have more control over. The "LD_" variables are hard-coded into glibc (start with elf/rtld.c). The glibc RTLD has many "features", and even ELF itself has a few surprises with its DT_RPATH and DT_RUNPATH entries, and $ORIGIN (see ...


1

Yes, there is a way: don't let that user run arbitrary code. Give them a restricted shell, or better, only a predefined set of commands. You wouldn't prevent any malware from running, unless you've used some non-standard privilege escalation mechanism that doesn't erase these variables. Normal privilege escalation mechanisms (setuid, setgid or setcap ...


0

So, what do you exactly mean by "safe"? Are you concerning of the data security or privacy? (i.e. others can hack into your pc via the server applications and view/control your local data)? Or are you worrying about your php code or the software that will make damage to your computer? For 1), it is generally not possible to have access to your computer ...


2

Essentially, you need to control the execution environment of the apps. There's no magic about it. A couple of solutions that come to mind: You could somehow set all the binaries that worry you as setuid/setgid (that does not mean they must be owned by root, as far as I know). Linux normally prevents attaching to a setuid/setgid process. Please do verify ...


11

Everything Parthian said was spot on. HEAD requests are a like a 'short' GET request that avoids the network extra traffic and potentially the rendering overhead of a GET request. There are a variety of reasons you, your browser, or your search engine may want to do a HEAD request. Some websites may just be pulling meta information off you, and your ...


30

No. Relevant quote from the link: HEAD Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content. If you disabled it, you'd just increase your throughput cost. A person ...


1

It is possible for the admin to access the underlying Untangle system via ssh or the local console and use any commonly available Linux tool to see the raw packets. Untangle discourages it as automatic updates may remove your tools, or the tools may break the system.


1

A local certificate authority (CA) must be setup by an administrator. The administrator tells your browser that this CA is trustworthy. The proxy server uses this CA to sign the forged certificates at which point the HTTPS proxy (in this case, the Untangle server) would now have the ability to decrypt the HTTPS traffic. Can the administrator track what ...


4

It depends. Untangle has the capability of intercepting HTTPS using a man in the middle proxy (https://www.untangle.com/store/https-inspector.html). If this is enabled, the HTTPS inspector can see all HTTPS traffic. This however requires that all desktop client install a root certificate issued by the Untangle device.


2

I think the traceability of your connections will be recorded on the log file of untangle server but not the content of your conversations .


2

Putting an xinetd server in front of your web server will reduce security: in addition to any security holes in the web server, you now also are vulnerable to any security holes in xinetd. Any security measures you can apply through xinetd, you can apply instead through the firewall or the web server.



Top 50 recent answers are included