pixelserv - Jarmka's thread

[jarmka]

Is ssl caching anything like tls session ticketing in pixelserv-tls? What is the difference? Enabling session tickets we effectively lose forward secrecy; an integral part of securing TLS. This leaves me curious as to how pixelserv uses tls certs and session tickets. Does pixelserv use and cache the exact same certs issued to a specific application like a web browser? How does it affect all the clients on a network using pixelserv-tls, and if the router is compromised, can this cache can be used to decipher users encrypted sessions? If so this could potentially make routers using pixelsrv-tls targets for ransom. These are potential issues that should be emphasized if they are offered these features, and it would be useful to have options to disable TLS session tickets, allow cert storage only in volatile memory, as well as purge rotation periods. Personally I prefer security over speed.

#1 ssllabs/ssllabs-scan#367

As explained in the second link below,

"To support session resumption via session IDs the server must maintain a cache that maps past session IDs to those sessions’ secret states. The cache itself is the main weak spot, stealing the cache contents allows to decrypt all sessions whose session IDs are contained in it."

"The forward secrecy of a connection is thus bounded by how long the session information is retained on the server. Ideally, your server would use a medium-sized cache that is purged daily. Purging your cache might however not help if the cache itself lives on a persistent storage as it might be feasible to restore deleted data from it. An in-memory storage should be more resistant to these kind of attacks if it turns over about once a day and ensures old data is overridden properly."

#2 https://timtaubert.de/blog/2014/11/...-side-tls-session-resumption-implementations/

Is it possible to disable ssl cache & tls session ticketing in pixelsrv-tls?

and

Is it possible to implement a feature in pixelsrv-tls to disable tls-session tickets globally; that would benefit an entire network enforcing strict forward secrecy globally? I'm searching for a solution for chrome but I cannot find any means of disabling them; as https://www.ssllabs.com/ssltest/viewMyClient.html demonstrates.

 

[jarmka]

It is possible to disable TLS tickets for example in IIS within windows Schannel, ASP.NET at the application and or page level, and Firefox, (There I notice minimal performance impact) but I do not see an option for this in Chrome. OpenSSL contexts support the SSL_OP_NO_TICKET option as of OpenSSL 1.0.0 that disables the use of TLS Session Tickets (RRC 4507) in order to protect perfect forward secrecy. I believe it is not possible in java applets and many other pieces of software. Such an option would benefit client security tremendously; including but not limited to highly secure environments like banks and institutions. Pixelsrv-tls is largely used to improve security by blocking malware-domains and potentially dangerous ads. To argue in favor to make it less so and less extensible is rather counter intuitive. There are many scenarios where this could be potentially extremely useful and beneficial for clients and users. https://timtaubert.de/blog/2014/11/...-side-tls-session-resumption-implementations/

Although disabling session tickets will undoubtedly have a negative performance impact, for the moment being you will need to do that in order to provide forward secrecy"

The best you can do to provide forward secrecy to visitors is thus again switch off session ticket support until a proper solution is available.

 

[jarmka]

Does Pixselserv-tls keep its own TLS session tickets or does it strictly use open connections of a given application?

 

[kvic]

@jarmka

are you the same person cross posting on Github, my blog and here literally like within one hour? If you have such urgency and worries, the best approach is to stop using it, and then wait for responses.

TLS connections between pixelserv-tls and your client (browser/apps etc) are only limited between the two. It won't affect your browser's other TLS connections in any way.

 

[jarmka]

@jarmka TLS connections between [I]pixelserv-tls[/I] and your client (browser/apps etc) are only limited between the two. It won't affect your browser's other TLS connections in any way.

OH thank you kvic, I'm beginning to understand this a bit better now. You are saying pixelserv is only using TLS connections and certs strictly to interface between pixelserv-tls and the given connection from an app/browser (etc)..., NOT as a proxy through which the outside web is tunneled? Thus the app/browsers TLS connection is unaffected. But is Pixselserv-tls somewhat of an HTTPS proxy of sorts? I don't yet understand how it can insert a pixel into encrypted traffic otherwise. I am curious if it has the potential to evolve to block/modify individual parameters within a hello/handshake https packet; this would be a great way to ensure forward secrecy and blocking depreciated ciphers globally.

 

[kvic]

OH thank you kvic, I'm beginning to understand this a bit better now. You are saying pixelserv is only using TLS connections and certs strictly to interface between pixelserv-tls and the given connection from an app/browser (etc)..., NOT as a proxy through which the outside web is tunneled? Thus the app/browsers TLS connection is unaffected. But is Pixselserv-tls somewhat of an HTTPS proxy of sorts? I don't yet understand how it can insert a pixel into encrypted traffic otherwise. I am curious if it has the potential to evolve to block/modify individual parameters within a hello/handshake https packet; this would be a great way to ensure forward secrecy and blocking depreciated ciphers globally.

pixelserv-tls is a server in which ad requests are terminated there. It's _not_ a proxy. Non ad requests will not even reach pixelserv-tls.

Regarding forward secrecy, you've better started checking with your banks and other external servers of critical importance. You don't have to worry about pixelserv-tls sitting on your LAN that only serves empty ads.

 

[jarmka]

@kvic, thank you for your response! non ad requests are not reached by pixselserv but pixselserv still must be able to modify content within an encrypted https connection, which includes all resources not just ads, that means it must be able to have access to the keys of a given https session in order to decrypt and inject pixels, hence, why it caches and saves copies of the certs to disk. Please correct me if I am wrong. So if the router is compromised and pixelserv certs are stolen, can this pose a risk for a mitm, and endanger in anyway other connections? If so, does pixselserv rotate certs regularly to avoid such a potential security risk?

In part, forward secrecy simply means rotating keys, either on client or server side, or both, to avoid these kind of scenarios.

Neither Apache, nor Nginx or HAproxy purged stale entries from the session cache or rotated session tickets automatically, potentially harming forward secrecy of resumed TLS session.

Enabling session resumption is an important tool for speeding up HTTPS websites, especially in a pre-HTTP/2 world where a client may have to open concurrent connections to the same host to quickly render a page. Subresource requests would ideally resume the session that for example a GET / HTTP/1.1 request started.

DID WEB SERVERS REACT?
No, not as far as I’m aware. None of the three web servers mentioned above has taken steps to make it easier to properly configure session resumption. But to be fair, OpenSSL didn’t add any new APIs or options to help them either.

All popular TLS 1.2 web servers still don’t evict cache entries when they expire, keeping them around until a client tries to resume — for performance or ease of implementation. They generate a session ticket key at startup and will never automatically rotate it so that admins have to manually reload server configs and provide new keys.

THE CADDY WEB SERVER
I want to seize the chance and positively highlight the Caddy web server, a relative newcomer with the advantage of not having any historical baggage, that enables and configures HTTPS by default, including automatically acquiring and renewing certificates.

source: https://timtaubert.de/blog/2017/02/the-future-of-session-resumption/

 

[DonnyJohnny]

@kvic, thank you for your response! non ad requests are not reached by pixselserv but pixselserv still must be able to modify content within an encrypted https connection, which includes all resources not just ads, that means it must be able to have access to the keys of a given https session in order to decrypt and inject pixels, hence, why it caches and saves copies of the certs to disk. Please correct me if I am wrong. So if the router is compromised and pixelserv certs are stolen, can this pose a risk for a mitm, and endanger in anyway other connections? If so, does pixselserv rotate certs regularly to avoid such a potential security risk?

In part, forward secrecy simply means rotating keys, either on client or server side, or both, to avoid these kind of scenarios.

If ever the router has been compromised. Do you think it is pixelserv fault? The invader probably will just do anything they like since the router is root mode. What talking you? So whose fault is it when router is compromised? Maybe you should complain to manufacturer and ask how come their router can be compromised.

 

[kvic]

non ad requests are not reached by pixselserv but pixselserv still must be able to modify content within an encrypted https connection, which includes all resources not just ads

No, that's not true.

"Non ad requests" are colloquial use. More precisely any domains that do not exist in your DNS-based adblock list will not have their requests to such domains being redirected to pixelserv-tls.

You shall run pixelserv-tls with log LEVEL 4, and see first hand what sorts of domains and requests reaching pixelserv-tls.

 

[jarmka]

@kvic thank you brother I appreciate your support. This is all I am seeing, not sure exactly what any of it means or why it says rgom10-en.url.trendmicro.com:80; It is a 'local' address; Malicious site blocking is disabled. I had originally assumed it was a sign it was at the top of the host file/blocklist, but that does not appear to be the case.

Local foreign
tcp 0 0 rgom10-en.url.trendmicro.com:www 0.0.0.0:* LISTEN
tcp 0 0 rgom10-en.url.trendmicro.com:https 0.0.0.0:* LISTEN

Jun  6 08:19:25 pixelserv-tls[13913]: 192.168.50.2 rgom10-en.url.trendmicro.com:80 GET /T/88/s4lP0xpMJNJ37bWI-poXwM82KxYcTiMp5aToJ0dkdOt8ZhlY-D8TBsI_fNdAdo8X8Ap00HKmGzBKz8z1jQ7eVQ== HTTP/1.1
Jun  6 08:19:26 pixelserv-tls[13913]: 192.168.50.2 rgom10-en.url.trendmicro.com:80 GET /T/88/88ag54SqhI4cLLSxuvhedkLT5yHjG0Kj0KO-fermCl5MUngtPrLlU3_gHevW-zpDvNK3emDKHL56UIVZb9Tiyw== HTTP/1.1
Jun  6 08:19:26 pixelserv-tls[13913]: 192.168.50.2 rgom10-en.url.trendmicro.com:80 GET /T/88/K3Fj_R_ThIKDUnsc33Efd9rFzqk_x7g6iP1pZs9UtF8-pzkAVo3MDcSdaTB9zVkyWoo6_0O7OiFCEoRwuuAupg== HTTP/1.1
Jun  6 08:19:27 pixelserv-tls[13913]: 192.168.50.2 rgom10-en.url.trendmicro.com:80 GET /T/108/SzdtnQEMxiDD6aFrA2Lyht1ru0SlzdMceIBpMj8jwVsd69ahL0BebEsThQ33529D6OltpDVBhhr5idNr9eWuJ701DUL_o7IHblbDIvKj9cg= HTTP/1.1
Jun  6 08:19:31 pixelserv-tls[13913]: 192.168.50.2 rgom10-en.url.trendmicro.com:80 GET /T/108/-CQeiAUqKPl-jjEYboyR0FAQTarOyDTWvCLMA0BfFy6pVMC8tjmOZYnUi9QQUdMTInKbeNINVaEmmJgWnn8cxVuLodKIGNroeg4NSTH7vr8= HTTP/1.1
Jun  6 08:19:32 pixelserv-tls[13913]: 192.168.50.2 rgom10-en.url.trendmicro.com:80 GET /T/88/c1Ior4qBFSx14ThXfRtvF6MPYWycBPE3NABUcKQeSK5wIhfTdg_LtiT2q4jWeA4lxSqol_hBnPUNJmiHnBTPyA== HTTP/1.1
Jun  6 08:19:33 pixelserv-tls[13913]: 192.168.50.2 rgom10-en.url.trendmicro.com:80 GET /T/88/vbvVDVsL32vmKdpyjAPMyUCnrlIbkM4Tl9ryfclmhY5jAnCi0nMpB7cmOxjRPcc9hlfod4eJSBvmHU6h7XU4Wg== HTTP/1.1
Jun  6 08:19:34 pixelserv-tls[13913]: 192.168.50.2 rgom10-en.url.trendmicro.com:80 GET /T/108/zZvF7dBiaNYQJHRro6vjMM9ijysPnXPIG716VmAfHSlRTqB7pLpJSCu09Uc7e_mU-ahnkRNKz0mzG6v5Z-MEkp9ieIfd0k9Dq_eot_6Nsgo= HTTP/1.1

 

[kvic]

This is all I am seeing, not sure exactly what any of it means or why it says rgom10-en.url.trendmicro.com:80; It is a 'local' address; Malicious site blocking is disabled. I had originally assumed it was a sign it was at the top of the host file/blocklist, but that does not appear to be the case.

It simply means two things:
1. the domain is included by your adblock script or other means in the blocking list and is pointed to your "pixelserv ip"
2. by dnsmasq's internal arrangement this domain is the first one. Hence, when you do reverse DNS lookup on your "pixelserv ip", it's resolved to this domain.

It's not necessary the "first" domain in your host files that might be a misunderstanding.

With respect to why this domain is included, ask yourself. Check what adblock script you're using, and why it's included.

Nevertheless, there is nothing harmful. I guess it's included to prevent your router calling home (i.e. TrendMicro's home).

 

[jarmka]

It simply means two things:
1. the domain is included by your adblock script or other means in the blocking list and is pointed to your "pixelserv ip"
2. by dnsmasq's internal arrangement this domain is the first one. Hence, when you do reverse DNS lookup on your "pixelserv ip", it's resolved to this domain.
Nevertheless, there is nothing harmful. I guess it's included to prevent your router calling home (i.e. TrendMicro's home).

You were correct! I had thought I missed something, and in fact it is on the top of dnsmasq hosts list. Just fyi this was part of some code I had experimented with, some users had reported a 10x increase in pixelserv's tav and tmax with the following FIRST TWO codes; I found browsing sped up by an average of 20-40% or so. The primary benefit came from blocking PTR (reverse dns) and arpa.

Speed up browsing by 25-40%, block nearly all querys flagged by DNSCRYPT suspicious.log, and block AsusWRT signaling to Google Safe Browsing and google.com. This is accomplished by blocking PTR or reverse DNS querys. This will stop DNS name resolutions in some AsusWRT apps like itfop; Other than that it should not be a problem for except those using custom scripts for automated logging with host resolution. Alternatively you can selectively block in-addr.arpa IPs collected from dnscrypt suspicious.log directly in dnsmaq hosts.

Create/Add to bottom of /jffs/scripts/dnsmasq.postconf

################################################
####   Block PTR on localhost, allow PTR for Clients
################################################

CONFIG=$1
source /usr/sbin/helper.sh
sed -i '$a\ ' $CONFIG
sed -i '$a\###############################################' $CONFIG
sed -i '$a\#Block PTR on localhost, allow PTR for clients#' $CONFIG
sed -i '$a\###############################################' $CONFIG
sed -i '$a\ ' $CONFIG
sed -i '$a\####################################' $CONFIG
sed -i '$a\#May Speed up Browsing Considerably#' $CONFIG
sed -i '$a\####################################' $CONFIG
sed -i '$a\ ' $CONFIG
pc_append "server=/0.168.192.in-addr.arpa/#" $CONFIG
pc_append "server=/in-addr.arpa/" $CONFIG
pc_append "#Or block all arpa for added security (may break QoS! I use this, and disable QoS)" $CONFIG
pc_append "#bogus-priv" $CONFIG
pc_append "#server=/arpa/" $CONFIG

To confirm this worked, simply type dnsmasq, and hit 'enter' while watching your dnsmasq logs in ab-solution for the following:

May 5 15:53:27 dnsmasq[10947]: using local addresses only for domain in-addr.arpa
May 5 15:53:27 dnsmasq[10947]: using standard nameservers for domain 0.168.192.in-addr.arpa
May 5 15:53:17 dnsmasq[10793]: using nameserver 127.0.0.1#65053

Block AsusWRT built in signaling to Trendmicro, Google & other entities:
Create/Add to bottom of /jffs/scripts/hosts.postconf

#!/bin/sh

#################################################
#### Block Trendmicro / Asus / Google / Other Entities
#################################################

######################################################
#### Block redundant NXDOMAIN dnsmasq querys and logs
######################################################

# Blocks most 10-14 second reoccurring querys to google
# Blocks all reoccurring querys to Asus / Trend Micro / Google.com
# Stops redundant logging for cleaner logs if blocking trendmicro, and google

####################################################################################
# 1. Note, repeated querys to google safe browsing servers become apparent if:
# (A) The items listed below have been blocked by dnscrypt or dnsmasq
# (B) You've compiled and blocked whatever unique suspicious entries appear for you in dnscrypt.
# (C) You disable in-addr.arpa (PTR/Reverse DNS altogether for localhost) (recommended)
# This will break DNS name resolutions in AsusWRT apps like itfop; And possibly some websites
# Alternatively you may selectively block IP's collected from dnscrypt suspicious.log via dnsmasq hosts
# Rebooting the router with suspicious entry logs enabled will give you the list.
#
# 2. Note, repeated AsusWRT probes to google.com become apparent only when blocking AsusWRT querys to google
# safe browsing; the only solution for this without breaking google.com is a custom host entry in dnsmasq
# as provided here.
#
# Exact order of reoccurring query's found in dnscrypt blocked.log after compiling hundreds of entries from
# suspicious.log and importing them to blacklist.txt
#
# 144.159.185.198.in-addr.arpa AT&T Services, Inc https://otx.alienvault.com/indicator/ip/144.159.185.198
# 145.159.185.198.in-addr.arpa RIPE Network Coordination Centre
# 145.23.49.198.in-addr.arpa   RIPE Network Coordination Centre
# 217.197.79.204.in-addr.arpa  RIPE Network Coordination Centre
# 91.149.5.103.in-addr.arpa    RIPE Network Coordination Centre
# 134.84.85.88.in-addr.arpa    University of Minnesota, Office of Information Technology
# 144.23.49.198.in-addr.arpa   Latin American and Caribbean IP address Regional Registry
# 133.36.101.151.in-addr.arpa  JAPAN-INET Asia Pacific Network Information Centre
# 84.36.101.151.in-addr.arpa   RIPE Network Coordination Centre
# 42.40.189.107.in-addr.arpa   JAPAN-INET Asia Pacific Network Information Centre
# rgom10-en.url.trendmicro.com
#####################################################################################

#Ensure AB-Solution is Installed:
#Code /usr/sbin/curl -Os https://raw.githubusercontent.com/decoderman/amtm/master/amtm && sh amtm
#Make sure to ping google.com and replace IP with local version under the first pc_append line

CONFIG=$1
source /usr/sbin/helper.sh
sed -i '$a\#' $CONFIG
sed -i '$a\## begin of silently block all redundant querys to Google, TrendMicro, and Asus ##' $CONFIG
pc_append "74.125.205.147 google.com" $CONFIG
pc_append "192.168.50.2 rgom10-en.url.trendmicro.com" $CONFIG
pc_append "192.168.50.2 fbsv1.trendmicro.com" $CONFIG
pc_append "192.168.50.2 fbsv2.trendmicro.com" $CONFIG
pc_append "192.168.50.2 ntd-asus-2014b-en.fbs20.trendmicro.com" $CONFIG
pc_append "192.168.50.2 gslb1.fbs.trendmicro.com.akadns.net" $CONFIG
pc_append "192.168.50.2 rgom10-en.url.trendmicro.com" $CONFIG
pc_append "192.168.50.2 trendmicro.com.edgesuite.net" $CONFIG
pc_append "192.168.50.2 slb1.fbs.trendmicro.com.akadns.net" $CONFIG
pc_append "192.168.50.2 activeupdate.trendmicro.co.jp" $CONFIG
pc_append "192.168.50.2 backup21.url.trendmicro.com" $CONFIG
pc_append "192.168.50.2 wrs.trendmicro.com" $CONFIG
pc_append "192.168.50.2 e5110.dscd.akamaiedge.net" $CONFIG
pc_append "192.168.50.2 wideip-dlcdnets.isoi.asia" $CONFIG
pc_append "192.168.50.2 dlcdnets.asus.com" $CONFIG
pc_append "192.168.50.2 dlcdnets-ds.asus.com.edgekey.net" $CONFIG
sed -i '$a\## end of Silently Block All Redundant Querys to Google, TrendMicro, and Asus ##' $CONFIG
sed -i '$a\#' $CONFIG

These first two "codes" have reportedly attended massive speed improvements.

 

[Adamm]

You were correct! I had thought I missed something, and in fact it is on the top of dnsmasq hosts list. Just fyi this was part of some code I had experimented with, some users had reported a 10x increase in pixelserv's tav and tmax with the following FIRST TWO codes; I found browsing sped up by an average of 20-40% or so. The primary benefit came from blocking PTR (reverse dns) and arpa.

Speed up browsing by 25-40%, block nearly all querys flagged by DNSCRYPT suspicious.log, and block AsusWRT signaling to Google Safe Browsing and google.com. This is accomplished by blocking PTR or reverse DNS querys. This will stop DNS name resolutions in some AsusWRT apps like itfop; Other than that it should not be a problem for except those using custom scripts for automated logging with host resolution. Alternatively you can selectively block in-addr.arpa IPs collected from dnscrypt suspicious.log directly in dnsmaq hosts.

Create/Add to bottom of /jffs/scripts/dnsmasq.postconf

################################################
####   Block PTR on localhost, allow PTR for Clients
################################################

CONFIG=$1
source /usr/sbin/helper.sh
sed -i '$a\ ' $CONFIG
sed -i '$a\###############################################' $CONFIG
sed -i '$a\#Block PTR on localhost, allow PTR for clients#' $CONFIG
sed -i '$a\###############################################' $CONFIG
sed -i '$a\ ' $CONFIG
sed -i '$a\####################################' $CONFIG
sed -i '$a\#May Speed up Browsing Considerably#' $CONFIG
sed -i '$a\####################################' $CONFIG
sed -i '$a\ ' $CONFIG
pc_append "server=/0.168.192.in-addr.arpa/#" $CONFIG
pc_append "server=/in-addr.arpa/" $CONFIG
pc_append "#Or block all arpa for added security (may break QoS! I use this, and disable QoS)" $CONFIG
pc_append "#bogus-priv" $CONFIG
pc_append "#server=/arpa/" $CONFIG

To confirm this worked, simply type dnsmasq, and hit 'enter' while watching your dnsmasq logs in ab-solution for the following:

Block AsusWRT built in signaling to Trendmicro, Google & other entities:
Create/Add to bottom of /jffs/scripts/hosts.postconf

#!/bin/sh

#################################################
#### Block Trendmicro / Asus / Google / Other Entities
#################################################

######################################################
#### Block redundant NXDOMAIN dnsmasq querys and logs
######################################################

# Blocks most 10-14 second reoccurring querys to google
# Blocks all reoccurring querys to Asus / Trend Micro / Google.com
# Stops redundant logging for cleaner logs if blocking trendmicro, and google

####################################################################################
# 1. Note, repeated querys to google safe browsing servers become apparent if:
# (A) The items listed below have been blocked by dnscrypt or dnsmasq
# (B) You've compiled and blocked whatever unique suspicious entries appear for you in dnscrypt.
# (C) You disable in-addr.arpa (PTR/Reverse DNS altogether for localhost) (recommended)
# This will break DNS name resolutions in AsusWRT apps like itfop; And possibly some websites
# Alternatively you may selectively block IP's collected from dnscrypt suspicious.log via dnsmasq hosts
# Rebooting the router with suspicious entry logs enabled will give you the list.
#
# 2. Note, repeated AsusWRT probes to google.com become apparent only when blocking AsusWRT querys to google
# safe browsing; the only solution for this without breaking google.com is a custom host entry in dnsmasq
# as provided here.
#
# Exact order of reoccurring query's found in dnscrypt blocked.log after compiling hundreds of entries from
# suspicious.log and importing them to blacklist.txt
#
# 144.159.185.198.in-addr.arpa AT&T Services, Inc https://otx.alienvault.com/indicator/ip/144.159.185.198
# 145.159.185.198.in-addr.arpa RIPE Network Coordination Centre
# 145.23.49.198.in-addr.arpa   RIPE Network Coordination Centre
# 217.197.79.204.in-addr.arpa  RIPE Network Coordination Centre
# 91.149.5.103.in-addr.arpa    RIPE Network Coordination Centre
# 134.84.85.88.in-addr.arpa    University of Minnesota, Office of Information Technology
# 144.23.49.198.in-addr.arpa   Latin American and Caribbean IP address Regional Registry
# 133.36.101.151.in-addr.arpa  JAPAN-INET Asia Pacific Network Information Centre
# 84.36.101.151.in-addr.arpa   RIPE Network Coordination Centre
# 42.40.189.107.in-addr.arpa   JAPAN-INET Asia Pacific Network Information Centre
# rgom10-en.url.trendmicro.com
#####################################################################################

#Ensure AB-Solution is Installed:
#Code /usr/sbin/curl -Os https://raw.githubusercontent.com/decoderman/amtm/master/amtm && sh amtm
#Make sure to ping google.com and replace IP with local version under the first pc_append line

CONFIG=$1
source /usr/sbin/helper.sh
sed -i '$a\#' $CONFIG
sed -i '$a\## begin of silently block all redundant querys to Google, TrendMicro, and Asus ##' $CONFIG
pc_append "74.125.205.147 google.com" $CONFIG
pc_append "192.168.50.2 rgom10-en.url.trendmicro.com" $CONFIG
pc_append "192.168.50.2 fbsv1.trendmicro.com" $CONFIG
pc_append "192.168.50.2 fbsv2.trendmicro.com" $CONFIG
pc_append "192.168.50.2 ntd-asus-2014b-en.fbs20.trendmicro.com" $CONFIG
pc_append "192.168.50.2 gslb1.fbs.trendmicro.com.akadns.net" $CONFIG
pc_append "192.168.50.2 rgom10-en.url.trendmicro.com" $CONFIG
pc_append "192.168.50.2 trendmicro.com.edgesuite.net" $CONFIG
pc_append "192.168.50.2 slb1.fbs.trendmicro.com.akadns.net" $CONFIG
pc_append "192.168.50.2 activeupdate.trendmicro.co.jp" $CONFIG
pc_append "192.168.50.2 backup21.url.trendmicro.com" $CONFIG
pc_append "192.168.50.2 wrs.trendmicro.com" $CONFIG
pc_append "192.168.50.2 e5110.dscd.akamaiedge.net" $CONFIG
pc_append "192.168.50.2 wideip-dlcdnets.isoi.asia" $CONFIG
pc_append "192.168.50.2 dlcdnets.asus.com" $CONFIG
pc_append "192.168.50.2 dlcdnets-ds.asus.com.edgekey.net" $CONFIG
sed -i '$a\## end of Silently Block All Redundant Querys to Google, TrendMicro, and Asus ##' $CONFIG
sed -i '$a\#' $CONFIG

These first two "codes" have reportedly attended massive speed improvements. The following are extras which I recommend as well.

Block reverse Ipv6 with dnscrypt blacklist (reverse ipv6 escapes block_ipv6 = true):

edit /jffs/dnscrypt/dnscrypt-proxy.toml enable blacklist, blacklist.log, and suspicious.log
create/edit /jffs/dnscrypt/blacklist.txt add *ip6.arpa*
create suspicious.log

Block AsusWRT from probing Microsoft every few seconds:

nvram show | grep dns_probe
dns_probe_host=dns.msftncsi.com
dns_probe_content=131.107.255.255 fd3e:4f5a:5b81::1

nvram set dns_probe_content=127.0.0.1 (or 0.0.0.0 as I prefer actually just leave it bank turns it off, but turning it off breaks dual wan)

Block reoccurring incoming google connections (8.8.8.8): block 8.8.8.8 in skynet or iptables. (skynet required)

sh /jffs/scripts/firewall ban ip 8.8.8.8 AsusWRT Google Probe

Please don’t hijack others threads with a copy and paste of your own, common courtesy.

 

[Beherit]

These first two "codes" have reportedly attended massive speed improvements.

Reportedly? *cough* According to which reports? Haven't we been through this already? I tried out the recommendations in a now deleted thread on this forum, and the wild promises of "massive speed improvements" were nothing but a hoax.

 

[jarmka]

I hope you @kvic find this information incredibly useful and helpful. @Beherit, well to be more accurate, I could have said "one user's report, including my own..." though everything including what he and I posted was deleted, so I only have the backup info provided here. I personally noticed a 25%-40% increase of browsing speed on the majority of sites I had visited; The other user from the snbform reported a 10x improvement in pixelserv's tav or tmax. If you genuinely tested this and followed instructions properly, I guess all you got was better security, but it certainly improved our browsing speeds. What will be necessary for scientific purposes is to have as many people report their results as possible. Also reporting their Router and firmware versions may suggest it benefits specific hardware / firmware combinations. Only one user reported their results, and his results were surprising. @kvic if you would report any noted speed improvements, or lack thereof, that would be appreciated.

OH here it is:


Updated 5/10/2018

Jarmka,

This is so useful !!!
Using all the latest changes I am getting 10 times the speed during browsing.
Pages now refresh instantly.

From pixelserv: (After 12+ Hours)
tav 8 ms average processing time (per request)
tmx 219 ms longest processing time (per request)

Previously I was getting tav of 90+ ms and tmx of 8100+ ms !!!

Src [link no longer available]

 

[Beherit]

If you genuinely tested this and followed instructions properly

I tested it alright, by putting it through a series of tests using both pings and a stop watch to measure throughput, loading times and latency. Emailing, page loading in web browsers, gaming, torrents, file transfers, dns hostname resolving and what else I forgot... there was absolutely no change at all in any way. It's just as much of a hoax as your claim of "better security".

The thread you mention was deleted for several, all very, good reasons. Yet you keep up your not-so-subtle attempts to hijack other threads to pursue your agenda.

I won't comment any further on this, as it just derails this thread further into off-topic territory.

 

[joe scian]

I hope you @kvic find this information incredibly useful and helpful. @Beherit, well to be more accurate, I could have said "one user's report, including my own..." though everything including what he and I posted was deleted, so I only have the backup info provided here. I personally noticed a 25%-40% increase of browsing speed on the majority of sites I had visited; The other user from the snbform reported a 10x improvement in pixelserv's tav or tmax. If you genuinely tested this and followed instructions properly, I guess all you got was better security, but it certainly improved our browsing speeds. What will be necessary for scientific purposes is to have as many people report their results as possible. Also reporting their Router and firmware versions may suggest it benefits specific hardware / firmware combinations. Only one user reported their results, and his results were surprising. @kvic if you would report any noted speed improvements, or lack thereof, that would be appreciated.

OH here it is:


Updated 5/10/2018

yes I will report too - what a load of BS - no changes in speed whatsoever - if anything there is a speed decrease

 

[jarmka]

I tested it alright, by putting it through a series of tests using both pings and a stop watch to measure throughput, loading times and latency. Emailing, page loading in web browsers, gaming, torrents, file transfers, dns hostname resolving and what else I forgot... there was absolutely no change at all in any way. It's just as much of a hoax as your claim of "better security".

If what you say is true [regarding your speeds] it is good to know it doesn't effect all systems equally. I certainly have, and twigglets reported faster browsing speeds. In terms of security what the first two codes do is eliminate up to a dozen arpa protocols including ipv6 PTR [and link #2] [important], blocks Trendmicro & inbuilt Asus probes from calling home, [increasing privacy & possibly security] and blocks the vast majority of "suspicious" entries detected and logged by dnscrypt. If there are any potential backdoors or security bugs within any of these protocols, the router software itself, or suspicious PTR entries, disabling them will decrease attack surface. Also given Asus routers are plagued with reoccurring security flaws, blocking the home calling is not a bad idea. The reason is that the more features you enable, or are accessible to the internet, the larger your attack surface is. It means you have more to defend. And one vulnerable feature is all it takes to get hacked. Now attackers know a lot about the security bugs in the system – that’s how they attack. If you go live on the internet with all features turned on, the attacker could have a lot of choices. If you disable unused features, then they'd have less to play with. After more than a month of testing, I have had zero issues, not to mention speed improvements.

 

[kfp]

It’s cool that you’re interested in security and trying new things, but please don’t use a thread as your diary.

I bet you will see the same speed increase if you turn off all the DPI related stuff, otherwise those processes are just waiting for the response for the PTR lookups you disabled and just wasting CPU cycles. Your scripts look redundant.

Also, title of thread is extremely misleading.

Edit: a letter

 

[thiggins]

It’s cool that you’re interested in security and trying new things, but please don’t use a thread as your diary.

I bet you will see the same speed increase if you turn off all the DPI related stuff, otherwise those processes are just waiting for the response for the PTR lookups you disabled and just wasting CPU cycles. Your scripts look redundant.

Also, title of thread is extremely misleading.

Edit: a letter

He is free to post as long as he sticks to the topic. You are free to read or ignore. What is misleading about the thread title?