LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 07-23-2008, 01:24 AM   #1
backroger
Member
 
Registered: Dec 2004
Posts: 81

Rep: Reputation: 15
How to block this....


Hi guys...

Everyday I always get this in my log. The iptables seems to work fine but how do I get rid of this?

Code:
[root@eapi log]# grep eth0 messages
Jul 22 14:59:53 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=271 PROTO=UDP SPT=10106 DPT=33436 LEN=12
Jul 22 14:59:57 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=271 PROTO=UDP SPT=10106 DPT=33436 LEN=12
Jul 22 15:00:02 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=272 PROTO=UDP SPT=10106 DPT=33436 LEN=12
Jul 22 15:00:07 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=786 PROTO=UDP SPT=10106 DPT=33438 LEN=12
Jul 22 15:00:11 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=786 PROTO=UDP SPT=10106 DPT=33438 LEN=12
Jul 22 15:00:16 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=787 PROTO=UDP SPT=10106 DPT=33438 LEN=12
Jul 22 15:00:21 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=787 PROTO=UDP SPT=10106 DPT=33438 LEN=12
Jul 22 15:00:26 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=3 ID=788 PROTO=UDP SPT=10106 DPT=33438 LEN=12
Jul 22 15:00:31 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=72.19.129.117 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=3 ID=788 PROTO=UDP SPT=10106 DPT=33438 LEN=12
Jul 22 06:19:30 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=64.94.150.152 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=782 PROTO=UDP SPT=11467 DPT=33438 LEN=12 
Jul 22 06:19:35 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=64.94.150.152 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=782 PROTO=UDP SPT=11467 DPT=33438 LEN=12
Jul 23 06:19:41 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=64.94.150.152 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=783 PROTO=UDP SPT=11467 DPT=33438 LEN=12
Jul 23 06:19:47 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=64.94.150.152 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=783 PROTO=UDP SPT=11467 DPT=33438 LEN=12
Jul 23 06:19:53 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=64.94.150.144 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=1043 PROTO=UDP SPT=11467 DPT=33439 LEN=12
Jul 23 06:19:59 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=64.94.150.144 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=1043 PROTO=UDP SPT=11467 DPT=33439 LEN=12
Jul 23 06:20:05 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=64.94.150.144 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=1044 PROTO=UDP SPT=11467 DPT=33439 LEN=12
Jul 23 06:20:11 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=64.94.150.144 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=1044 PROTO=UDP SPT=11467 DPT=33439 LEN=12
Or just ignore this?

Thanks in advance.

Last edited by backroger; 07-23-2008 at 01:25 AM.
 
Old 07-23-2008, 01:32 AM   #2
Mr. C.
Senior Member
 
Registered: Jun 2008
Posts: 2,529

Rep: Reputation: 63
What UDP-based application do you have running that are communicating with performance-4.chi.pnap.net.and 72-19-129-117.network.mesanetworks.net.
 
Old 07-23-2008, 02:45 AM   #3
backroger
Member
 
Registered: Dec 2004
Posts: 81

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by Mr. C. View Post
What UDP-based application do you have running that are communicating with performance-4.chi.pnap.net.and 72-19-129-117.network.mesanetworks.net.
It started 2 weeks & I didn't change anything for the last 2 months. Nor using any UDP Application. Sorry for the wrong title....its already blocked...I just want to get rid of it. ^_^


Btw...thanks Mr. C for this & the termcap thingy. I still have not done that yet. I temporarily used the VT220.

Last edited by backroger; 07-23-2008 at 03:08 AM.
 
Old 07-23-2008, 03:08 AM   #4
Mr. C.
Senior Member
 
Registered: Jun 2008
Posts: 2,529

Rep: Reputation: 63
My guess is that there is a site monitoring your network for reachability.
This occurs when, for exmaple, you are running a P2P app, or other service.
This isn't uncommon, and the connection is blocked anyway.
You could create a specific rule to drop the packet without logging, but this
is what logs are for.
 
Old 07-23-2008, 12:42 PM   #5
nx5000
Senior Member
 
Registered: Sep 2005
Location: Out
Posts: 3,307

Rep: Reputation: 57
yes it's a traceroute (ttl increase)coming from a linux (using udp).
You get this everyday? Do you host a server on this machine?
 
Old 07-23-2008, 01:25 PM   #6
Mr. C.
Senior Member
 
Registered: Jun 2008
Posts: 2,529

Rep: Reputation: 63
Quote:
Originally Posted by nx5000 View Post
yes it's a traceroute (ttl increase)coming from a linux (using udp).
Good catch.
I did note the non-routable RFC 1918 address, and thought traceroute, but let it drift by.
I'm afraid I was on my way towards sleep when I review the thread.

Last edited by Mr. C.; 07-23-2008 at 01:27 PM.
 
Old 07-23-2008, 07:08 PM   #7
backroger
Member
 
Registered: Dec 2004
Posts: 81

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by nx5000 View Post
yes it's a traceroute (ttl increase)coming from a linux (using udp).
You get this everyday? Do you host a server on this machine?
Yes this is a webserver. And yes I get this everyday and below is for today July 24.

Code:
Jul 24 05:23:13 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=69.25.172.24 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=782 PROTO=UDP SPT=10991 DPT=33438 LEN=12
Jul 24 05:23:18 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=69.25.172.24 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=782 PROTO=UDP SPT=10991 DPT=33438 LEN=12
Jul 24 05:23:24 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=69.25.172.24 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=783 PROTO=UDP SPT=10991 DPT=33438 LEN=12
Jul 24 05:23:30 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=69.25.172.24 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=783 PROTO=UDP SPT=10991 DPT=33438 LEN=12
Jul 24 05:23:36 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=69.25.172.16 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=1298 PROTO=UDP SPT=10991 DPT=33440 LEN=12
Jul 24 05:23:41 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=69.25.172.16 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=1298 PROTO=UDP SPT=10991 DPT=33440 LEN=12
Jul 24 05:23:47 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=69.25.172.16 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=1299 PROTO=UDP SPT=10991 DPT=33440 LEN=12
Jul 24 05:23:53 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=69.25.172.16 DST=10.66.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=2 ID=1299 PROTO=UDP SPT=10991 DPT=33440 LEN=12
Thanks.

Last edited by backroger; 07-23-2008 at 07:10 PM.
 
Old 07-24-2008, 12:01 AM   #8
Hendronicus
Member
 
Registered: Feb 2006
Location: Oldsmar, Fl. USA
Distribution: Slackware, Ubuntu
Posts: 176

Rep: Reputation: 50
Throw their address in your /etc/hosts.deny file and forget about it. Unless you need them for something.
 
Old 07-24-2008, 01:51 AM   #9
Mr. C.
Senior Member
 
Registered: Jun 2008
Posts: 2,529

Rep: Reputation: 63
Quote:
Originally Posted by Hendronicus View Post
Throw their address in your /etc/hosts.deny file and forget about it. Unless you need them for something.
That doesn't make sense; iptables gets the packet and logs the event before tcpwrappers ever sees it. It is too late for tcpwrappers.
 
Old 07-24-2008, 02:41 AM   #10
backroger
Member
 
Registered: Dec 2004
Posts: 81

Original Poster
Rep: Reputation: 15
Well...I will just ignore this for the time being as suggested by Mr. C.. Its just funny that it was started last 2 weeks ago.

Seems it is only a few hits once a day and as long as the box can handle it (running 24/7). Probably a zombie machine tracerouting every domain name from his/her favorite or bookmark.

Thanks guys.

Last edited by backroger; 07-24-2008 at 02:54 AM.
 
Old 07-24-2008, 11:37 PM   #11
backroger
Member
 
Registered: Dec 2004
Posts: 81

Original Poster
Rep: Reputation: 15
Hmmm...its a coincidence that this is a part of DNS poisoning? Come to think of it. It started 2 weeks thats just about the same day within 07/10/08.

Excerpt from https://rhn.redhat.com/errata/RHSA-2008-0533.html

The DNS protocol protects against spoofing attacks by requiring an attacker to predict both the DNS transaction ID and UDP source port of a request.
In recent years, a number of papers have found problems with DNS implementations which make it easier for an attacker to perform DNS cache-poisoning attacks.

Previous versions of BIND did not use randomized UDP source ports. If an attacker was able to predict the random DNS transaction ID,
this could make DNS cache-poisoning attacks easier. In order to provide more resilience, BIND has been updated to use a range of random UDP source ports.
(CVE-2008-1447)


Is it?
 
Old 07-24-2008, 11:59 PM   #12
Mr. C.
Senior Member
 
Registered: Jun 2008
Posts: 2,529

Rep: Reputation: 63
Why do you this has anything to do with DNS cache poisoning? It appears to be a simple traceroute.
Anyone can start one, and some applications you use can cause other servers to attempt to measure your distance and latency.
I traceroute a number of sites constantly, to maintain a graph of network health.

Look at the source address: 69.25.172.16. That the IP maps to performance-4.phx003.pnap.net makes a pretty strong case there is
nothing malicious here.

If they bother you, create an iptables rule that blocks/drops the packet w/out logging it.
 
Old 07-25-2008, 12:09 AM   #13
backroger
Member
 
Registered: Dec 2004
Posts: 81

Original Poster
Rep: Reputation: 15
Hi..Mr C.

Because I tried the test...and sad to say...

Code:
This tool checks for DNS cache poisoning susceptibility, a serious security flaw in DNS recently acknowledged by CERT (US Computer Emergency Readiness Team). US-CERT VU#800113 

This DNS server is vulnerable!
The DNS server at IP address XXX.XXX.XXX.XXX is susceptible to a DNS cache poisoning attack. The server is not changing its source port, query id, or both, between queries. This means it is easier than average for an attacker to spoof responses to DNS queries from this server, causing the server to serve a potentially malicious DNS record in response to any query. 

Click here for more details on this vulnerability and how to patch it.

If you are not in control of your own DNS server, contact your DNS provider but do not be unduly concerned in the near term. IT administrators have only recently been apprised of this issue, and should have time to safely evaluate and deploy a fix.

DNS Server Address Query source port Query ID 
XXX.XXX.XXX.XXX 32768 50674 
XXX.XXX.XXX.XXX 32768 8899 

How do I read the results table?
Based on the results, a DNS server is vulnerable if:
The IPs AND the Query source ports match or the query IDs match. Matching query source ports or query IDs make it easier to spoof fake results to the DNS server, poisoning its cache. 

How can I check for other DNS issues related to my domain or email?
We encourage you to run DNSreport to make sure your DNS is configured properly. This comprehensive health check runs 55 tests against your domain, pinpoints the issue and offers mitigation steps on how to fix it. You can automate this report with DNSalerts - we will monitor your DNS around-the-clock and notify you via email if problems arise.
snip..
 
Old 07-25-2008, 01:29 AM   #14
Mr. C.
Senior Member
 
Registered: Jun 2008
Posts: 2,529

Rep: Reputation: 63
You've shown you have the DNS vulnerability, but haven't demonstrated a connection between the two.

Regardless, get the DNS problem fixed.
 
Old 07-28-2008, 12:43 AM   #15
backroger
Member
 
Registered: Dec 2004
Posts: 81

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by Mr. C. View Post
Look at the source address: 69.25.172.16. That the IP maps to performance-4.phx003.pnap.net makes a pretty strong case there is nothing malicious here.
Hi..Mr. C.

How do I know (or trace) if the IP is hostile or not? Example below...

Code:
Jul 28 09:26:04 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=122.52.99.10 DST=10.66.0.1 LEN=56 TOS=0x00 PREC=0x00 TTL=52 ID=49464 PROTO=ICMP TYPE=3 CODE=3 [SRC=10.66.0.1 DST=122.52.99.10 LEN=1484 TOS=0x00 PREC=0x00 TTL=52 ID=46334 DF PROTO=TCP INCOMPLETE [8 bytes] ]
Jul 28 09:26:04 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=122.52.99.10 DST=10.66.0.1 LEN=56 TOS=0x00 PREC=0x00 TTL=52 ID=49466 PROTO=ICMP TYPE=3 CODE=3 [SRC=10.66.0.1 DST=122.52.99.10 LEN=1484 TOS=0x00 PREC=0x00 TTL=52 ID=46336 DF PROTO=TCP INCOMPLETE [8 bytes] ]
Jul 28 09:26:04 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=122.52.99.10 DST=10.66.0.1 LEN=56 TOS=0x00 PREC=0x00 TTL=52 ID=49468 PROTO=ICMP TYPE=3 CODE=3 [SRC=10.66.0.1 DST=122.52.99.10 LEN=1484 TOS=0x00 PREC=0x00 TTL=52 ID=46338 DF PROTO=TCP INCOMPLETE [8 bytes] ]
Jul 28 09:26:04 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=122.52.99.10 DST=10.66.0.1 LEN=56 TOS=0x00 PREC=0x00 TTL=52 ID=49470 PROTO=ICMP TYPE=3 CODE=3 [SRC=10.66.0.1 DST=122.52.99.10 LEN=1484 TOS=0x00 PREC=0x00 TTL=52 ID=46340 DF PROTO=TCP INCOMPLETE [8 bytes] ]
Jul 28 09:26:04 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=122.52.99.10 DST=10.66.0.1 LEN=56 TOS=0x00 PREC=0x00 TTL=52 ID=49472 PROTO=ICMP TYPE=3 CODE=3 [SRC=10.66.0.1 DST=122.52.99.10 LEN=1484 TOS=0x00 PREC=0x00 TTL=52 ID=46342 DF PROTO=TCP INCOMPLETE [8 bytes] ]
Jul 28 09:36:49 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=122.52.99.10 DST=10.66.0.1 LEN=56 TOS=0x00 PREC=0x00 TTL=52 ID=52676 DF PROTO=ICMP TYPE=3 CODE=3 [SRC=10.66.0.1 DST=122.52.99.10 LEN=1484 TOS=0x00 PREC=0x00 TTL=52 ID=13147 DF PROTO=TCP INCOMPLETE [8 bytes] ]
Jul 28 09:36:49 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=122.52.99.10 DST=10.66.0.1 LEN=56 TOS=0x00 PREC=0x00 TTL=52 ID=52678 PROTO=ICMP TYPE=3 CODE=3 [SRC=10.66.0.1 DST=122.52.99.10 LEN=1484 TOS=0x00 PREC=0x00 TTL=52 ID=13149 DF PROTO=TCP INCOMPLETE [8 bytes] ]
Jul 28 09:36:49 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=122.52.99.10 DST=10.66.0.1 LEN=56 TOS=0x00 PREC=0x00 TTL=52 ID=52680 PROTO=ICMP TYPE=3 CODE=3 [SRC=10.66.0.1 DST=122.52.99.10 LEN=1484 TOS=0x00 PREC=0x00 TTL=52 ID=13151 DF PROTO=TCP INCOMPLETE [8 bytes] ]
Jul 28 09:36:49 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=122.52.99.10 DST=10.66.0.1 LEN=56 TOS=0x00 PREC=0x00 TTL=52 ID=52682 PROTO=ICMP TYPE=3 CODE=3 [SRC=10.66.0.1 DST=122.52.99.10 LEN=1484 TOS=0x00 PREC=0x00 TTL=52 ID=13153 DF PROTO=TCP INCOMPLETE [8 bytes] ]
Jul 28 09:36:49 eapi kernel: Inbound IN=eth0 OUT= MAC=00:13:d3:66:da:62:00:30:48:8a:3d:61:08:00 SRC=122.52.99.10 DST=10.66.0.1 LEN=56 TOS=0x00 PREC=0x00 TTL=52 ID=52684 PROTO=ICMP TYPE=3 CODE=3 [SRC=10.66.0.1 DST=122.52.99.10 LEN=1484 TOS=0x00 PREC=0x00 TTL=52 ID=13155 DF PROTO=TCP INCOMPLETE [8 bytes] ]
Thanks in advance.

Last edited by backroger; 07-28-2008 at 12:48 AM.
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Error reading block "x" (Attempt to read block from....... pvandyk2005 Slackware 6 07-06-2008 05:25 AM
New on the block... yhtomit LinuxQuestions.org Member Intro 2 07-29-2007 02:33 PM
IPTables and PPTPD :S (to block or not to block) thewonka Linux - Networking 0 03-24-2005 06:58 PM
help me block an ip Zac2003 Linux - Security 1 11-03-2004 09:48 PM
how to block an ip porous Linux - Security 2 10-13-2003 02:55 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 11:06 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration