Had to kill my firewall to login to KF...

[elludium_q-36]

Hello,

This MAY seem like a thread for "KubuntuForums Feedback", where we "Post your input on changes...", but it doesn't seem to fit the categories of suggestions for "Site Improvements", and is not a suggestion for a new forum category. Besides, there are only 2 threads on that board. :-|

Anyway, I just tried to log in, and it would accept the username & password, go to the redirect screen (click here if your browser does not automatically redirect), then it would dump back to the default board, withOUT the username credentials, at the top.

If I went to the dedicated login screen, it would show that I had used a login attempt, and called it an attempt of using an incorrect username / password. HOWEVER, those are saved in the browser, and autofill.

I disabled my firewall, temporarily, and it logged in, as normal. I assume that since I have the correct cookie, I am able to use the site normally.

Does KF now use a CDN (Content Delivery Network), like AKAMAI? I certainly have that blocked, as it would have a 'perpetual' inbound connection, with a LONG TTL; VERY persistent, and they would keep trying to get traffic into my machine.

Whatever the issue, it is something I have blocked in my firewall, but it's a fairly recent change...

[SteveRiley]

No, we don't use a CDN. And I am not aware of any Akamai behavior like you describe. Mind telling us more?

How is your firewall configured?

Did you erase the cookie before each test?

[elludium_q-36]

Currently use Firestarter...

I'm currently using package Firestarter, which, uses a few files for configuration, unlike guarddog.

I noticed, with the firewall running, the browser (Firefox), was "unable to establish a connection to the server at www.indiegogo.com.", in a frame of KF.

Kubuntuforums.net is allowed session cookies. I did not delete the cookies between login attempts, nor any that remained, between Firefox crashes.

Here is,
/etc/firestarter/outbound/deny-to

216.151.187.0/24, AKAMAI
77.67.0.0/17, AKAMAI-TINET - Network Architecture Role Account
165.215.0.0/16, PROQUEST
165.215.162.66, proquest.com
50.97.96.0/19, softlayer.com
174.36.0.0/15, softlayer.com
208.43.0.0/16, softlayer.com
208.43.160.0/19, softlayer.net
208.43.174.192/29, softlayer.net
64.185.229.236, Unknown - NO WHOIS
50.63.202.71, 50-63-202-71.ip.secureserver.net "Long-Shore.com"
184.168.221.87, long-shore.com
82.103.128.0/20, secure.informaction.com - tcp - EASYSPEEDY-NETWORK
69.195.141.178, informaction.com
69.195.141.179, informaction.com
178.63.197.160/28, rsync.sanesecurity.net - tcp - SOFTWAREUNDCOMPUTER - Software&Computer - Germany
216.74.0.0/18, ?? rsync ??  NET-216-74-0-0-1 - WCP/32POINTS INTERMEDIATE HOLDING COMPANY\c INC.
216.59.38.123, statcounter.com
72.21.91.19, gs1.wac.v2cdn.net
216.146.38.125, pureleads.com
140.234.254.55, nextreads.com
140.234.252.108, pdc-novselect.ebscohost.com
204.93.32.0/19, nLayer Communications\c Inc. NLYR-ARIN-BLK5 - tied to AKAMAI
224.0.0.22, igmp.mcast.net
1.2.3.4, Unknown reserved address which connects...
203.186.75.192/26, Reasonable Software House - China
x.54.240.190.114, d1ge0kk1l5kms0.cloudfront.net
173.222.0.0/15, AKAMAI
194.8.197.0/24, NETCOLOGNE
88.191.158.0/24, FR-DEDIBOX
93.191.174.0/24, Moneybookers Ltd
67.228.0.0/16, SoftLayer Technologies Inc.
173.192.0.0/15, rackAID LLC - SoftLayer Technologies Inc.
50.22.0.0/15, Softlayer
224.0.0.0/3,
72.32.20.56/29, boldchat

And,
/etc/firestarter/outbound/deny-service

Rsync, 873, everyone,
Unknown, 57510, everyone, RSYNC Outbound
Unknown, 43200, everyone, RSYNC - OUTBOUND
Unknown, 56963, everyone, RSYNC - Outbound
Unknown, 51638, everyone, Long-Shore.com
Unknown, 60430, everyone, Google Analytics
Unknown, 60058, everyone, Google-Analytics
Unknown, 60062, everyone, google-analytics
Unknown, 50000-60000, everyone,
Unknown, 60000-65535, everyone,
Unknown, 47218, everyone, googlecode.l.googleusercontent.com
Afs3-fileserver, 7000, everyone, Unknown Listening
, 10050, everyone, Unknown listening
Unknown, 474-2627, everyone,
Unknown, 2629-4568, everyone,
Unknown, 4570-5037, everyone,
Unknown, 5038-49999, everyone,

[SteveRiley]

If I'm reading this correctly, your deny-service is unnecessarily large. You are preventing your computer from making connections to very wide range of destination port numbers: 474..65535, except 2628 and 4569. While this is unlikely to be the cause of your cookie problem, it very likely will cause other services to malfunction.

Indiegogo is the crowd-funding platform Canonical is using to raise funds for the Ubuntu Edge phone. We have a picture of the phone on our home page. Indiegogo relies on Akamai for content delivery. You're seeing the connection failure in that frame because you're blocking a set of Akamai addresses. Out of curiousity, would you please disable the firewall, run the following commands, and reply here with the output of the second and third commands:

sudo apt-get install traceroute

dig www.indiegogo.com

sudo traceroute -T www.indiegogo.com

Please try logging into the forum on the dedicated login page and using the fields at the top of the home page. Clear your cookies and close your browser after each attempt. Do this with the firewall disabled and with it enabled.

I'm curious why you think blocking Akamai is worthwhile? They carry a large portion of the Internet's traffic. If you want to block just ads, there are better ways.

Also...you should know that development ceased on Firestarter many years ago. It is no longer maintained.

[elludium_q-36]

Not sure what happened...

Thanks for responding, SteveRiley.

With AKAMAI, and others, I had found many questionable connections, made OUTBOUND, and therefore triggering, or if unblocked, allowing INBOUND. These were PERSISTENT, with a status of "ESTABLISHED", and VERY long TTLs (Time To Live). I can understand the CDN finding the fastest route between my device and the server hosting the content, and that they may want to leave behind a cookie, to lighten the traffic and load on the path/hop checking subroutine, but this is not solid with transportable/wireless devices. Also, what possible reason do they have for keeping open a PERSISTENT connection? Like so many weeds, kill them and they pop right back up again; PERSISTENT!!! This is LONG, LONG after the content has been served. I would see MANY INBOUND connection attempts, per second, from AKAMAI servers!

*************
I wonder about the future of Net Neutrality, when it's throttled or controlled by mega content entities...
https://en.wikipedia.org/wiki/Network_neutrality


http://www.google.com/search?lr=lang...y%22+%22CDN%22
***********************
I thought that one possible origin of the connections is client side scripting/ JavaScript. This, probably, is more so, in browsers not using a blocker like NoScript. I use NoScript and prefer to block ALL sites, if possible. I have had many a script hang, and crash the browser, plus bog down the whole system, not to mention, not knowing what the script may be doing.

I have read that client side JavaScript only helps security and load reduction OF THE SERVER. It can open vulnerabilities on the client, XSS attack (cross Site Scripting), for example. Naturally it causes an added load on the client system.

Javascript is not good or bad, in the same way that a hammer is not good or bad. It's what you do with it that is good or bad. Many of the sites that use Javascript, use it where it is not actually necessary.

Some reasons why Javascript should not be overused:

• search engines don't pick up script-generated content
• creating a nontrivial script that works in all browsers can be tricky
• many basic things can be achieved using CSS instead, which degrades more gracefully
• XSS (as recursive mentioned) can make bad things happen to your visitors if you screw up (although scripts might still be injected even if your site is Javascript-free, of course)
• you might think that every browser nowadays supports Javascript, but with more and more people using script-blocker extensions like NoScript for Firefox, this does not have to be true

Bottom line: Javascript should be used to enhance the website, but so far as humanly possible, the site should still work without it.
http://stackoverflow.com/a/373854

I would rather have ALL connections blocked, with chosen exceptions; white-listing instead of black-listing.

I also have been using Adblock+, flashblock, and the like
Excellent work SteveRiley:
http://www.kubuntuforums.net/showthread.php?56419
I should implement that post haste!

I don't use many services, outside of port 80 (8080) or 443.
I still have a VERY slow 3G connection, due to signal and use older hardware.

Yes, I was aware that Firestarter, unfortunately, while not dead, has no active development.

I think guarddog may be more comprehensive with "restrictive by default", in regard to ports, and may be a better GUI firewall frontend, as far as specifying what is allowed and denied. I have been drafting a Guarddog rules/config file. However, firestarter offers a live representation of connections, and can resolve hostnames. Yet, I have been iptstate {IP State Tables Top), rather than running wireshark, which uses a good chunk of resources, and makes LARGE files. Iptstate offers the ability to kill connections. Firestarter offers the ability to click on a button and lock, or unlock the firewall, and another to stop or start the firewall. This is helpful, when used in conjunction with IPTState, to go offline and kill questionable connections, especially after going DMZ, or having allowed all connections by temporarily taking down the firewall. It would be nice if someone developed a GUI firewall frontend, which rolled in functionality of all three, plus other packages

I already had traceroute, in a GUI package gnome-nettool "Network Tools 2.30.0", and had both netwox & netwag installed. But, as is often the case, the CLI offers more funtionality, than even an old dos menu style program; for those who have the commands & syntax memorized, or a damn good cheat sheet.

As requested, I disabled the firewall:

Luser@LocalHost:~$ dig www.indiegogo.com

; <<>> DiG 9.7.0-P1 <<>> www.indiegogo.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3546
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.indiegogo.com.		IN	A

;; ANSWER SECTION:
www.indiegogo.com.	185	IN	CNAME	www.indiegogo.com.edgekey.net.
www.indiegogo.com.edgekey.net. 17383 IN	CNAME	e3071.b.akamaiedge.net.
e3071.b.akamaiedge.net.	20	IN	A	23.33.140.148

;; Query time: 766 msec
;; SERVER: 205.204.88.60#53(205.204.88.60)
;; WHEN: Fri Aug 16 14:53:20 2013
;; MSG SIZE  rcvd: 127

Luser@LocalHost:~$ sudo traceroute -T www.indiegogo.com
[sudo] password for Luser: 
traceroute to www.indiegogo.com (23.33.140.148), 30 hops max, 44 byte packets
 1  192.168.0.1 (192.168.0.1)  44.749 ms  47.720 ms *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * a23-33-140-148.deploy.static.akamaitechnologies.com (23.33.140.148)  1816.691 ms
Luser@LocalHost:~$

Okay, I deleted cookies, then closed Firefox.
JavaScript disabled for KF, as normal with all but a few websites.
I may have missed steps, but here goes:

1st login attempt - Firewall ENABLED: 
1. http://www.kubuntuforums.net/forum.php 
2. Blank User Name & Password fields, click "Log in" 
3. goes to: http://www.kubuntuforums.net/login.php?do=login (tryihg link directly, redirects to /forum.php) "...1 out of 5 login attempts."
4. User Name & Password autofilled, Clicked "login"
5. navigates to "redirect" screen, "Thank you for logging in", Elludium_Q-36", "If your browser does not automatically redirect, click here." [paraphrased].
6. Browser redirects to http://www.kubuntuforums.net/forum.php withOUT login credentials at the top of page.
7. Cleared cookies
8. closed Firefox

2nd login attempt - Firewall ENABLED:

1. http://www.kubuntuforums.net/forum.php 
2. cleared cookies AGAIN.  Reloaded /forum.php
3. noted the following KF cookies: bb_sessionhash, bb_lastvisit, bb_lastactivity
4. ACCIDENTIALLY clicked on the big graphic, Kubuntu Forums.  This time, the url as a string variable: /forum.php?s=* where * matches the content of cookie bb_sessionhash.
5. deleted the cookies, reloaded /forum.php and this time, no cookie: bb_sessionhash.
6. I clicked on the big KF logo, again, the URL contains an "S" variable, appears to be the same, by glance. I recorded the string.
7. I deleted the cookies, and reloaded a tab, WITHOUT the string. Noted bb_lastvisit & bb_lastactivity cookies.  Noticed hovering over links, included a, now, different, session string, but no cookie. 
8. Cleared cookies, closed Firefox browser.

3rd login attempt - Firewall ENABLED:

1. http://www.kubuntuforums.net/forum.php 
2. noted cookies: bb_sessionhash, bb_lastvisit, bb_lastactivity.  Hovering over links did NOT contain a alphanumeric string. 
3. Autocomplete filled in User Name & Password fields, click "Log in"
4. Used "Print Screen" to capture the redirect screen: "Redirecting...", "Thank you for logging in, elludium_q-36.", "Click here if your browser does not automatically redirect you."
5. NOW, it appears as a normal login, EVEN WITH the firewall enabled!  The login credentials ARE at the top of the page.
7. The three cookies are there: bb_lastvisit, bb_lastactivity, & bb_sessionhash, but no string when hovering over links, and no string in the URL, after clicking on the big KF logo...

Puzzling! It seems that AFTER cliking on the big KF logo, things are normal.

I had NOT changed cookie permissions, blocked by default, nor did I change firewall blacklists.

In the past few days, only disabling the firewall caused an effect.
NOW, it seems back to normal...

Funny... While in the middle of posting, my session timed out. This time, there was no auto redirect, I had to click a button, to continue past the "redirect" screen. I had enabled javascript, to get the bb code syntax for adding URLs, then disabled again, but changed NOTHING ELSE.

Did you guys change something?

A Firefox glitch?
(It has been known to happen, OFTEN)...

[SteveRiley]

cookie permissions, blocked by default... While in the middle of posting, my session timed out... I had enabled javascript, to get the bb code syntax for adding URLs, then disabled again

If you are blocking our cookie and Javascript from our site, I can't predict how the forum will behave. You need to allow our cookie so that your login timer doesn't expire. We don't use the cookie for anything else; read-message-tracking is stored in a forum database. You need to allow JavaScript for certain vBulletin functionality that executes locally in your browser.

I have seen some instances of objects from KFN that are cached by browsers aren't properly updated. My suspicion is that's something unusual in the HTML that vBulletin writes. I actually disable local browser caches to avoid such problems.

I have read that client side JavaScript only helps security and load reduction OF THE SERVER. It can open vulnerabilities on the client, XSS attack (cross Site Scripting), for example. Naturally it causes an added load on the client system.

As a categorical statement, this is false. JavaScript has a place on the client, for enabling a wide variety of client-side utility. The modern web would be useless with AJAX and JSON, of which JavaScript is the foundation. While it's true that JavaScript can be used to perform XSS and XSRF attacks, this is no fault of JavaScript itself: the fault lies with poorly-designed web pages. Both these attack types can be mitigated with well-known defenses.

I would rather have ALL connections blocked, with chosen exceptions; white-listing instead of black-listing.

But you're blocking outbound connections, which zero practical utility for increasing the security posture of your computer.

With AKAMAI, and others, I had found many questionable connections, made OUTBOUND, and therefore triggering, or if unblocked, allowing INBOUND. These were PERSISTENT, with a status of "ESTABLISHED", and VERY long TTLs (Time To Live)... they may want to leave behind a cookie, to lighten the traffic and load on the path/hop checking subroutine... Also, what possible reason do they have for keeping open a PERSISTENT connection? Like so many weeds, kill them and they pop right back up again; PERSISTENT!!! This is LONG, LONG after the content has been served. I would see MANY INBOUND connection attempts, per second, from AKAMAI servers!

You should block all third-party cookies, always. Akamai does use cookies, but they are considered third party, because they aren't delivered by the site you're actually visiting. Blocking these cookies will not break any of Akamai's CDN functionality.

Do you have some specific examples of these outbound, persistent, established, long TTL connections? How did you measure this? I'd be very interested in the details. In TCP, a TTL indicates not actual time (like HH:MM:SS) but instead the maximum number of hops a datagram may travel before it is discarded. Each processing node (router, usually) decrements the TTL. If the TTL becomes zero before the datagram reaches its target, the datagram is dropped. In HTTP, the Expires header can specify a specific date and time that an HTTP response should be treated as stale and dropped from a cache or otherwise ignored.

More generally, you seem to have a misunderstanding of the function CDNs serve in the Internet. Not only do I work in information security, but I'm also engaged in a fair amount of network traffic and performance engineering. CDNs play a significant role here, reducing traffic across the major switching points and keeping content close to users. Without CDNs, YouTube would suck greatly (more than it does now, lol), your Amazon ordering experience would drive you to drink, general site reliability would go down, and the Internet could not effectively compete against MPLS WANs. The search link you provided included an article that debunks the "CDNs kill network neutrality" logic quite well; I suggest you read it.

Excellent work SteveRiley: http://www.kubuntuforums.net/showthread.php?56419 I should implement that post haste!

Thank you. Yes, you should

[jlittle]

Just a general thought, I'd have thought the NoScript add-on would be your thing. It shows one what's trying to run, and doesn't let it until you allow it, either temporarily or added to a white list.

Regards, John Little

[SteveRiley]

Just a general thought, I'd have thought the NoScript add-on would be your thing. It shows one what's trying to run, and doesn't let it until you allow it, either temporarily or added to a white list.

Konqueror is my primary browser; I keep Firefox around for the odd site that Konqueror can't handle. So NoScript really isn't an option for me, alas.