October 2018 – Doug's Core Dumps

What is it with spammers, crackers and the like? Before doing my previous post, I took a quick look at some comments left on a couple of posts which I had noticed a few days ago, but which were lower on my priority list. As noted in my privacy policy, when you leave a comment, your IP address is tracked. Indeed, this is true if you even access the website, or any website or most any service for that matter. If you want to see just the beginnings of the things which can be found easily when you connect to a web page, take a look at https://whatismyipaddress.com/ for a sample. For the commenters, here is an example of what I see…

If you notice, there is an email address… but I could care less about that. The more interesting part is the 5.188.210.10. And guess what… I can tell that that belongs to yet another Russian IP, which somehow made it through my firewall, because the databases missed noting that it is a Russian address.

[bg_collapse view=”button-orange” color=”#4a4949″ expand_text=”Show the information for my first pass” collapse_text=”Show Less” ]

[root@]# whois 5.188.210.10
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
% To receive output for a database update, use the “-B” flag.

% Information related to ‘5.188.210.0 – 5.188.210.255’

% Abuse contact for ‘5.188.210.0 – 5.188.210.255’ is ‘alkonavtnetwork@gmail.com’

inetnum: 5.188.210.0 – 5.188.210.255
netname: AlkonavtNetwork
descr: Dedicated Servers & Hosting
remarks: abuse contact: alkonavtnetwork@gmail.com [1]
country: RU
admin-c: BJA12-RIPE
org: ORG-BJA2-RIPE
tech-c: BJA12-RIPE
status: SUB-ALLOCATED PA
mnt-by: MNT-PINSUPPORT
created: 2018-07-22T18:47:38Z
last-modified: 2018-07-22T18:47:38Z
source: RIPE

organisation: ORG-BJA2-RIPE
org-name: Bashilov Jurij Alekseevich
org-type: OTHER
address: Data center: Russia, Saint-Petersburg, Sedova str. 80. PIN Co. LTD (ru.pin)
abuse-c: BJA13-RIPE
mnt-ref: MNT-PINSUPPORT
mnt-by: MNT-PINSUPPORT
created: 2015-12-17T21:42:47Z
last-modified: 2018-07-22T18:50:42Z
source: RIPE # Filtered

person: Bashilov Jurij Alekseevich
address: 111398, Russia, Moscow, Plehanova str. 29/1-90
phone: +79778635845
nic-hdl: BJA12-RIPE
mnt-by: MNT-PINSUPPORT
created: 2015-12-16T04:19:25Z
last-modified: 2018-07-22T18:58:31Z
source: RIPE

% Information related to ‘5.188.210.0/24AS44050’

route: 5.188.210.0/24
descr: AlkonavtNetwork
origin: AS44050
mnt-by: MNT-PINSUPPORT
created: 2016-12-22T14:39:55Z
last-modified: 2018-07-22T18:52:24Z
source: RIPE

% This query was served by the RIPE Database Query Service version 1.92.6 (ANGUS)

[root@]# whois -h whois.arin.net ‘n < 5.188.210.10’

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/whois_reporting/index.html
#
# Copyright 1997-2018, American Registry for Internet Numbers, Ltd.
#

NetRange: 5.0.0.0 – 5.255.255.255
CIDR: 5.0.0.0/8
NetName: RIPE-5
NetHandle: NET-5-0-0-0-1
Parent: ()
NetType: Allocated to RIPE NCC
OriginAS:
Organization: RIPE Network Coordination Centre (RIPE)
RegDate: 2010-11-30
Updated: 2010-12-13
Comment: These addresses have been further assigned to users in
Comment: the RIPE NCC region. Contact information can be found in
Comment: the RIPE database at http://www.ripe.net/whois
Ref: https://rdap.arin.net/registry/ip/5.0.0.0

ResourceLink: https://apps.db.ripe.net/search/query.html
ResourceLink: whois.ripe.net

OrgName: RIPE Network Coordination Centre
OrgId: RIPE
Address: P.O. Box 10096
City: Amsterdam
StateProv:
PostalCode: 1001EB
Country: NL
RegDate:
Updated: 2013-07-29
Ref: https://rdap.arin.net/registry/entity/RIPE

ReferralServer: whois://whois.ripe.net
ResourceLink: https://apps.db.ripe.net/search/query.html

OrgTechHandle: RNO29-ARIN
OrgTechName: RIPE NCC Operations
OrgTechPhone: +31 20 535 4444
OrgTechEmail: hostmaster@ripe.net
OrgTechRef: https://rdap.arin.net/registry/entity/RNO29-ARIN

OrgAbuseHandle: ABUSE3850-ARIN
OrgAbuseName: Abuse Contact
OrgAbusePhone: +31205354444
OrgAbuseEmail: abuse@ripe.net
OrgAbuseRef: https://rdap.arin.net/registry/entity/ABUSE3850-ARIN

[/bg_collapse]

Oh well… that is solved easily enough, though I am still enhancing the automated processing, and have to do a manual step or two. The point I am designing right now is to find points where I may want to consider automatically inserting blackhole rules into my firewall. And that means parsing information such as this… and guess what… anyone obtaining their IP services via Petersburg Internet Network ltd. (talk about redundancy) on that subnet will now get sent to the black hole. No “permission denied” response, no “not available” response… nothing…nada…zilch…ничего. So if someone tries to scan me (which I can also detect) or do similar acts from their subnets (5.188.200.0/21 and several others, at a minimum) will be waiting for responses they will never receive, which is my way of putting treacle where the assholes are trying to go.

I have been looking at tuleap for a personal Agile tool, to help me track tasks as I work on personal coding projects. For example, I might be working on a new version of a disk partitioning script to use with my kickstart installs, and come up with ideas I don’t want to forget. So, to keep track of it, I have been creating tasks in Eclipse Mylyn using the stand-alone task list. But that list can be less than optimal, and it does not integrate with things like Jenkins, etc. Well, I took a little bit of time today to read up on the installation and get it up and running. Unfortunately, at the bottom of the requirements is the following line:

You must disable SELinux prior to the install.

To me, this is a huge issue… not quite to the point of storing passwords, social security numbers, credit card numbers, and such in cleartext. Indeed, in my book, passwords should be stored using a secure, one-way hash, except when it is a password needed by a system to connect to another system, and those should be stored encrypted, or at least as secure as possible. And as for social security numbers, they should be treated like passwords, but only stored if ABSOLUTELY NECESSARY!! As for credit card numbers… if anyone can show me a valid reason why a server should ever have to store one, with or without the CVV, outside of a very transient submission queue… I will be absolutely shocked. But when it comes to disabling SELinux outside of a development environment, to me this is perhaps one step down from those. The reason I say this is that SELinux was created for a very good reason… to help place limitations upon processes/applications to keep them from being able to do things which they should not. And to disable SELinux is just pure laziness.

A number of years ago, a client of mine wanted to use Zend Framework with the community edition of Zend Server, and I ran into the same thing during the install of that package. Just like tuleap, you had to disable SELinux before installing, and leave it disabled. And for a web application, this to me is about like putting a sign pointing to the pocket where your wallet is at. When I was done with the first install for that project, I had an install wrapper script which temporarily disabled SELinux, but only long enough to install it and then patch up the security modules so that I could turn SELinux back on. And when done, I sent a polite but scolding letter to them, telling them how this was a huge mistake, and gave them the information they needed to fix things in the RPMs. And tomorrow (or should I say later today), I will be using tools like ausearch, and beginning with trying to login, I will be forking the repos up on GitHub, creating patches, and begin solving this issue with a SELinux policy. And as I find more things which need fixed, I will add those as well. But this is a major piece of technical debt for which I will be opening a critical security bug, as soon as I have the beginnings of a patch ready to include. Because, regardless of what they think, it is that big of an issue.

Month: October 2018

Spammers

SELinux and Tuleap (part 1)