Tag Info

Hot answers tagged

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 ...


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 ...


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. ; ...


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.


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 ...


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 ...


1

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

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 ...


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 ...


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 ...



Only top voted, non community-wiki answers of a minimum length are eligible