Kernel.org – Jupiter Broadcasting https://www.jupiterbroadcasting.com Open Source Entertainment, on Demand. Mon, 22 Feb 2016 02:45:13 +0000 en-US hourly 1 https://wordpress.org/?v=5.5.3 https://original.jupiterbroadcasting.net/wp-content/uploads/2019/04/cropped-favicon-32x32.png Kernel.org – Jupiter Broadcasting https://www.jupiterbroadcasting.com 32 32 Worst Server Practices | TechSNAP 154 https://original.jupiterbroadcasting.net/53692/worst-server-practices-techsnap-154/ Thu, 20 Mar 2014 17:57:35 +0000 https://original.jupiterbroadcasting.net/?p=53692 25k UNIX systems spread infections to over half a million Windows boxes, and the method of attack simply put, is brilliant we’ll share the details!

The post Worst Server Practices | TechSNAP 154 first appeared on Jupiter Broadcasting.

]]>

post thumbnail

25k UNIX systems spread infections to over half a million Windows boxes, and the method of attack simply put, is brilliant we’ll share the details!

Google DNS gets hijacked we’ll explain how, and then a great big batch of your question, a rocking round up, and much much more!

On this week’s TechSNAP!

Thanks to:


\"GoDaddy\"

\"Ting\"

\"iXsystems\"

Direct Download:

HD Video | Mobile Video | MP3 Audio | Ogg Audio | YouTube | HD Torrent | Mobile Torrent

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feeds | Torrent Feed

— Show Notes: —

Allan’s Trip

Operation Windigo

  • The attack leverages previously compromised (how is unknown) servers, and using them to scan for other hosts to compromise, serve malware, infect sites hosted on the compromised servers with malware, and to send spam

  • Victims have included cPanel and Kernel.org (the official Linux kernel archive)

  • “The Ebury backdoor deployed by the Windigo cybercrime operation does not exploit a vulnerability in Linux or OpenSSH,”

  • During an analysis of stolen credentials, the researchers found:

    • 66% of the stolen passwords contained only alpha numeric characters

    • 41% of the stolen credentials were for the root user

  • Remote login as root should never be allowed. Disable root login over SSH and login as a regular user and use su or sudo. If you use sudo you should read Sudo Mastery and probably SSH Mastery too.

  • The researchers also found 23 victims running Windows 98, and 1 running Windows 95

  • “We found an official mirror of CentOS packages infected with Linux/Ebury. Fortunately, no package files were seemingly altered by the malicious operators. However knowing that Linux RPM packages are cryptographically signed such tampering is probably infeasible”

  • However, amateur administrators have been conditioned to accept unknown GPG keys for CentOS repositories.

  • When users visit an infected site, Windows users are given malware, Mac users are served ads for dating sites, and iPhone users are served ads for “strong pornography”, likely as these are each the most profitable way to exploit such users

  • The operators maintain control on the infected servers by installing a backdoor in the OpenSSH instance. The backdoor provides them with a remote root shell even if local credentials are changed on the infected host

  • The attackers used a number of techniques to remain stealthy:

    • Use Unix pipes as much as possible when deploying their backdoor to avoid landing files on the filesystem

    • Leave no trace in log files when using the backdoor

    • Change original signatures in the package manager for the modified file

    • Avoid exfiltrating information when a network interface is in promiscuous mode

    • Use POSIX shared memory segments with random system user owners to store stolen credentials

    • Inject code at runtime into three OpenSSH binaries instead of modifying the original OpenSSH files on disk

    • Change OpenSSH daemon configuration in memory instead of on disk

  • Centralize their backdoor in a library instead of an executable (libkeyutils.so)

  • Researcher PDF

Google Public DNS (8.8.8.8) suffers brief BGP hijack redirecting it to Venezuela

  • At approximately 17:23 UTC on March 15th, a router on the British Telecom Latin America network (BT LATAM, AS 7908) in Venezuela began announcing 8.8.8.8/32

  • A /32 prefix is unusual, most BGP routers will not propagate such short prefixes, only passing routes of /24 or larger. This resulted in the bad route not spreading as far, however because routing tables always take the ‘most specific’ match, it resulted in more of the traffic being rerouted than would have normally been the case

  • This resulted in most all traffic in Venezuela and Brazil, among other networks, including a University Network in Florida, to be misdirected to a server in Venezuela

  • The false BGP (Border Gateway Protocol) announcement was retracted 23 minutes later

  • It is possible that this was an effort by the Venezuelan government to intercept traffic bound for the Google Public DNS service, and it was accidently leaked upstream, disrupting the internet outside of Venezuela

  • Similar cases have happened in Pakistan and other countries attempting to block Youtube and other services

  • The network that sent the request, Madory said, “leaked other internal routes earlier in the day. So I suppose someone was tinkering with the network over the weekend. We see routing goof-ups like this almost every day.”

  • Additional Coverage

  • There are BCPs and RFCs that cover ways to prevent this kind of hijacking, by only allowing ASs to announce prefixes they control, however there is a lot of administrative overhead, especially when an ISP announces routes for its customers

  • There is another system, RPKI, that allows a network to specify which AS numbers are allowed to announce an IP block, as well as specifying the maximum prefix length, to prevent someone from announcing a more specific prefix (like in this case)

  • However RPKI has not yet received wide adoption

  • Providers ignore routing and DNS security

Feedback:

Round Up:

The post Worst Server Practices | TechSNAP 154 first appeared on Jupiter Broadcasting.

]]> Ubuntu 11.10 Preview | LAS | s18e06 https://original.jupiterbroadcasting.net/11998/ubuntu-11-10-preview-las-s18e06/ Sun, 11 Sep 2011 15:15:31 +0000 https://original.jupiterbroadcasting.net/?p=11998 It’s our preview look at Ubuntu 11.10. Are they are on the right course? Or is this release turning into another disaster? We find out!

The post Ubuntu 11.10 Preview | LAS | s18e06 first appeared on Jupiter Broadcasting.

]]>

post thumbnail

The security breach that rocked Linux to it’s core has expanded, and we cover the breaking details.

Then – It’s our preview look at Ubuntu 11.10. Are they are on the right course? Or is this release turning into another disaster? We find out!

All this week on, The Linux Action Show!

Thanks to:

GoDaddy.com Use our codes LINUX to save 10% at checkout, or LINUX20 to save 20% on hosting!

Direct Episode Download Links:

HD Video | Large Video | Mobile Video| MP3 | OGG Audio | OGG Video | YouTube


[ad#shownotes]

Episode Show Notes:

Runs Linux:

Marcos Garcia software enables entire Industries, to Run Linux!

Android Pick:

Linux Pick:

BSD Pick:

  • Many computer systems around the world have been possessed by penguins; some have even been possessed by dead rats. In light of this, it is desirable to exorcise these evil spirits, and replace them with a nice, friendly daemon
  • More to the point, there are a number of dedicated server hosting companies which only offer Linux; being able to remotely replace Linux with FreeBSD makes the offerings from these companies available to those who want to run FreeBSD.
News:
Ubuntu 11.10 Preview:

Find us on Google+

Find us on Twitter:

Follow the network on Facebook:

Catch the show LIVE at 10am on Sunday:

The post Ubuntu 11.10 Preview | LAS | s18e06 first appeared on Jupiter Broadcasting.

]]> Mandriva 2011 Review | LAS | s18e05 https://original.jupiterbroadcasting.net/11726/mandriva-2011-review-las-s18e05/ Sun, 04 Sep 2011 13:34:27 +0000 https://original.jupiterbroadcasting.net/?p=11726 A review of Mandriva 2011, plus the early rumors of MeeGo’s death, and the major security issues that struck Linux this week.

The post Mandriva 2011 Review | LAS | s18e05 first appeared on Jupiter Broadcasting.

]]>

post thumbnail

It’s our review of Mandriva 2011!

Plus we cover the early rumors of MeeGo’s death, Mark Shuttleworth’s bet against the mobile operators, and the major security issues that struck Linux this week.

All this week on, The Linux Action Show!

Thanks to:

GoDaddy.com Use our codes LINUX to save 10% at checkout, or LINUX20 to save 20% on hosting!

Direct Episode Download Links:

HD Video | Large Video | Mobile Video | WebM Video | MP3 | OGG Audio | OGG Video | YouTube


[ad#shownotes]

Episode Show Notes:

Runs Linux:

Dual-band Wi-Fi router, Runs Linux

Android Pick:

Linux Pick:

News:

Mandriva 2011 Review:

Find us on Google+

Find us on Twitter:

Follow the network on Facebook:

Catch the show LIVE at 10am on Sunday:

The post Mandriva 2011 Review | LAS | s18e05 first appeared on Jupiter Broadcasting.

]]> Smarter Google DNS | TechSNAP 21 https://original.jupiterbroadcasting.net/11691/smarter-google-dns-techsnap-21/ Thu, 01 Sep 2011 22:42:23 +0000 https://original.jupiterbroadcasting.net/?p=11691 Google and openDNS join forces to improve the speed of your downloads, find out what they are doing and how it works!

The post Smarter Google DNS | TechSNAP 21 first appeared on Jupiter Broadcasting.

]]>

post thumbnail

Google and openDNS join forces to improve the speed of your downloads, find out what they are doing and how it works!

Plus gmail suffered another man in the middle attack, and Kernel.org gets some egg on their face!

All that and more, on this week’s episode of TechSNAP!

Direct Download Links:

HD Video | Large Video | Mobile Video | WebM Video | MP3 Audio | OGG Audio | YouTube

Subscribe via RSS and iTunes:

[ad#shownotes]

Show Notes:

Another SSL Certificate Authority Compromised, MitM Attack on Gmail

  • Sometime before July 10th, the Dutch Certificate Authority DigiNotar was compromised and the attackers we able to issue a number (apparently as many as 200) of fraudulent certificates, including a wildcard certificate for *.google.com. The attack was only detected by DigiNotar on July 19th. DigiNotar revoked the certificates, and an external security audit determined that all invalid certificates had been revoked. However, it seemed that probably the most important certificate, *.google.com was in fact not revoked. This raises serious questions and seems to point to a coverup by DigiNotar. Detailed Article Additional Article
  • Newer versions of Chrome were not effected, because Google specifically listed a small subset of CAs who would ever be allowed to issue a certificate for gmail. This also prevents self-signed certificates, which some users fall for regardless of the giant scary browser warning. Chrome Security Notes for June
  • Mozilla and the other browsers have taken more direct action disabled than they did with the Comodo compromise. All major browsers have entirely removed the the DigiNotar root certificate from their trust list. With the Comodo compromise, the effected certificates were blacklisted, but the rest of the Comodo CA was left untouched. One wonders if this was done as strong signal to all CAs that that must take security more seriously, or if DigiNotar was in fact cooperating with the Iranian government in its efforts to launch MitM attacks on its citizens. Mozilla Security Blog
  • Part of the issue is that some of the certificates issued were for the browser manufacturers them selves, such as Mozilla.org. With a fake certificate from Mozilla, it is possible that the MitM attack could block updates to your browser, or worse, feed you a spyware laden version of the browser.
  • Press Release from Parent Company VASCO
  • Pastebin of the fraudulent Certificate

  • Allan’s blog post about the previous CA compromise, and more detail than can fit even in an episode of TechSNAP
    *

    GoogleDNS and OpenDNS launch ‘A Faster Internet’

  • The site promoted a DNS protocol extension called edns-client-subnet that would have the recursive DNS server pass along the IP Subnet (not the full IP, for privacy) of the requesting client, to allow the authoritative DNS server to make a better Geo Targetting Decision.
  • A number of large content distributors and CDNs rely on GeoIP technology at DNS time to direct users to the nearest (and as such, usually fastest) server. However this approach is often defeated when a large portion of users are using GoogleDNS and OpenDNS and all of those requests come from a specific IP range. As this technology takes hold, it should make it possible for the Authoritative DNS servers to target the user rather than the Recursive DNS Server, resulting in more accurate results.
  • Internet Engineering Task Force Draft Specification
  • This change has already started effecting users, many users of services such as iTunes had complained of much slower download speeds when using Google or Open DNS. This was a result of being sent to a far-away node, and that node getting a disproportionate amount of the total load. Now that this DNS extension has started to come online and is backed by a number of major CDNs, it should alleviate the problem.

  • ScaleEngine is in the process of implementing this, and already has some test edns enabled authoritative name servers online.
    *

    Kernel.org Compromised

  • Attackers were able to compromise a number of Kernel.org machines
  • Attackers appear to have compromised a single user account, and then through unknown means, gained root access.
  • Attackers replaced the running OpenSSH server with a trojaned version, likely leaking the credentials of users who authenticated against it.
  • Kernel.org is working with the 448 people who have accounts there, to replace their passwords and SSH keys.
  • The attack was only discovered due to an extraneous error message about /dev/mem
  • Additional Article

Feedback:

Q: (DreamsVoid) I have a server setup, and I am wondering what it would take to setup a backup server, that would automatically take over if the first server were to go down. What are some of the ways I could accomplish this?

A: This is a rather lengthy answer, so I will actually break it apart, and have given one possible answer each week, for the last few weeks. This weeks solution is Anycast. This is by far the most complicated and resource intensive solution, but it is also the most scalable. Standard connections on the Internet are Unicast, meaning they go from a single point to another single point (typically, from a client to a specific server). The are also Broadcast (send to all nodes in the broadcast domain, such as your local LAN), and Multicast (send to a group of subscribed peers, used extensively by routers to distribute routing table updates, but does not work on the Internet). Anycast is different than a Unicast, instead of sending the packet to a specific host, the packet is sent to the nearest host (in network terms, hops, not necessarily geographic terms). The way Anycast works is your BGP enabled routers broadcast a route to your subnet to the Internet from each of the different locations, and the other routers on the Internet update their routing tables with the route to the location that is the fewest hops away. In this way, your traffic is diverted to the nearest location. If one of your locations goes down, when the other routers do not get an update from the downed router, they automatically change their route to the next nearest location. If you want only fail over, and not to distribute traffic geographically, you can have your routers prefix their routes with their own AS number a sufficient number of times to make the backup location always more hops than the main location, so it is only used if the main is down. There are some caveats with this solution, the first being that TCP packets were never meant to randomly redirect to another location, if a route change happens in the middle of an active session, that session will not exist at the second location, and the connection will be dropped. This makes Anycast unsuitable for long-lived connections, as routes on the Internet change constantly, routing around faults and congestion. Connections also cannot be made outbound from an Anycast IP, as the route back may end up going to a different server, and so a response will never be received, so servers would require a regular Unicast address, plus the Anycast address. A common solution to overcome the limitations of Anycast, is to do DNS (which is primarily UDP) via Anycast, and have each location serve a different version of the authoritative zone, which the local IP address of the web server, this way the users are routed to the nearest DNS server, which then returns the regular IP of the web server at the same location (this solution suffers from the same problems mentioned above in the Google DNS story). Another limitation is that due to the size of the address space on the Internet, most provides will not accept a route for a subnet smaller than a /24, meaning than an entire 256 ip address subnet must be dedicated to Anycast, and your servers will each require a regular address in a normal subnet. Broadcasting routes to the Internet also requires your own Autonomous System number, which are only granted to largish providers, or an ISP willing to announce your subnet on their AS number, but this requires a Letter of Authorization from the owner of the IP block.
*

ROUND-UP:

Bitcoin-Blaster:

The post Smarter Google DNS | TechSNAP 21 first appeared on Jupiter Broadcasting.

]]>