Что такое abuse mailbox
И вообще, если у человека нет публичного IP, то насколько сложно спецслужбам/мошенникам и прочим кулхацкерам выйти на реального человека (т.е. адрес, телефон и т.п.).
Прошу сильно не пинать, для меня это все темный лес.
в общем, если у вас айпи не статический (постоянный), а динамический (меняется каждый раз в пределах определенного набора цифр), то конкретно квартиру там по нему сходу не увидеть, но в пределах города, а то и района-квартала локацию уже можно установить. хотя и города тупит бывает. но регион-то точно определяет.
quote: Originally posted by Серрргей:
И вообще, если у человека нет публичного IP, то насколько сложно спецслужбам/мошенникам и прочим кулхацкерам выйти на реального человека (т.е. адрес, телефон и т.п.).
но вот например мой 79.134.68.209 из темы про форефронт в этом разделе
проверяем его whois, результат:
role: DigitOne Podolsk Network Operation Center
address: Revolucionniy prospekt, 54, Podolsk, MO, Russian Federation,
142100
remarks: trouble: DigitOne Podolsk NOC contacts:
remarks: trouble:
———————————————————————-remarks: trouble: Routing and peering issues:
noc-podolsk@cifra1.ru
remarks: trouble: Report SPAM and abuse:
abuse-podolsk@cifra1.ru
remarks: trouble: Customer support:
support-podolsk@cifra1.ru
remarks: trouble: General information:
info-podolsk@cifra1.ru
remarks: trouble:
———————————————————————-abuse-mailbox: abuse-podolsk@cifra1.ru
admin-c: DOP5-RIPE
tech-c: DOP5-RIPE
nic-hdl: DPNO1-RIPE
mnt-by: MNT-DIGIT1
source: RIPE # Filtered
route: 79.134.64.0/19
descr: INET
origin: AS15658
mnt-by: INET-MNT
source: RIPE # Filtered
следовательно это подольское отделение цифры один, теперь необходимо (самое простое) вступить в преступный сговор с админом из подольской цифры один и спросить его:
Кому принадлежал 79.134.68.209 (адрес внешний присвоение динамическое) в такое то время (берем время в теме поста про форефронт) и админ соответственно сообщает нам номер договора, адрес, ФИО на кого заключен договор.
вот примерно так
Если вы находитесь за «натом», то есть за одним публичным адресом скрывается нное количество человек, то это тоже как бы не проблема, провайдер вас органам сольет, т.к. обязан вести статистику кто куда в какое время ходил (хотя некоторые и не ведут, но это их головняк, пойдут за укрывательство ).
quote: вступить в преступный сговор с админом из подольской цифры один и спросить его:
Что такое abuse mailbox
Тема затронута администратором другого форума, но она очень интересна, поэтому я цитирую его высказывание (проверенное кстати высказывание)
Практически все места в результатах поиска занимают страницы сайтов:
смотрим, кому же принадлежат эти домены:
descr: Domain for hosting
changed: awmmaker@mail.ru 20060321
person: Sergey V. Mesyura
address: Vinnitsa, Ukraine
phone: +38 0432 447714
changed: domains@sim.vn.ua 20050905
comment: +38 067 4307328
Ничего интересного, скорее всего подставное, несуществующее в реале лицо, но когда смотрим кому же принадлежит айпишник на котором эти домены висят получаем интересную информацию:
descr: Yandex corporate network
status: ASSIGNED PA
source: RIPE # Filtered
role: Yandex LLC Network Operations
address: Yandex LLC
address: 40A Vavilova st.
address: 117333, Moscow, Russia
remarks: phone: +7 095 9743555
phone: +7 495 9743555
remarks: fax-no: +7 095 9743565
fax-no: +7 495 9743565
remarks: trouble: Points of contact for Yandex LLC Network Operations
remarks: trouble: Routing and peering issues: noc@yandex.net
remarks: trouble: SPAM issues: abuse@yandex.ru
remarks: trouble: Network security issues: abuse@yandex.ru
remarks: trouble: Mail issues: postmaster@yandex.ru
remarks: trouble: General information: info@yandex.ru
source: RIPE # Filtered
remarks: modified for Russian phone area changes
descr: Yandex enterprise network
source: RIPE # Filtered
Еще интересно, что все эти дорвеи редиректом отправляют посетителей на сайт rupoisk.ru
Письма с «жалобой на поисковый спам» Яндексом игнорируются, тема с вопросами по этой проблеме на форуме самого Яндекса сразу же была удалена.
Инетересно почему так? Пока что у меня больше вопросов чем ответов по данной проблеме. Имеется еще информация по заспамливанию форумов для «раскрутки» таких дорвеев, но это уже другая история
Специалисты, блин, «ущучили», типа, Яндекс.
Бедный Серега и не знал, что его не существует )
Вцелом, абсолютно согласен с Jeurey, от того, что делает Яндекс, и Яндекс ли ☝, им меньше не станут пользоваться.
А какие выводы и том, что Яндекс делает бизнес по-русски (своровали вагон водки, продали, деньги пропили) 🙂
от того, что делает так или иначе Я зависит, как к нему относятся пользователи, и соответственно пользуются ли его услугами.
Выше Eagle сам сказал, и сам ответил. Репутация в бизнесе важнее денег, т.к. при ее падении теряются деньги. Это кажимость, что чем выше положение фирмы, чем более она свободна. Тем более адсурд, чтобы играть против собственных правил, т.к. это означает пилить сук на котором сидишь.
FAQs for abuse-c
The abuse email address is contained in the «abuse-mailbox:» attribute in a role object. It is this role object that is referenced by the «abuse-c:» attribute in the organisation object. That means in order to change the email address used, you need to change the relevant role object containing the «abuse-mailbox:» attribute.
Both RIPE NCC members and PI or ASN resource holders can update the «abuse-mailbox:» attribute in the relevant role object using the Webupdates tool.
1. Look up your organisation object in the RIPE Database
2. Check which role object has been created for you in the «abuse-c:» attribute. Note the NIC handle of this role account.
3. Go to the Webupdates tool
4. Search for: NIC Handle role object > object type: role > click on search
5. Edit the email address in the «abuse-mailbox:» attribute
6. Click edit and your abuse contact has now been changed
If you have delegated responsibility for handling abuse to a customer for the part of your network they use, they need a similar set-up to your own. Either you can set this up for them, if you maintain all the RIPE Database objects, or they can partly set it up themselves. However, in most cases, you will maintain the inet(6)num assignment objects, so you will have to add the organisation reference to these objects.
You first need a role object for the customer and it must contain an «abuse-mailbox:» attribute. If the customer already has one, you can use that one. Otherwise, you will need to create a new one. This role object does not need to reference any person objects. It will be public with no query limits, so all information it contains is assumed to be business data, not personal or private data.
When creating a new organisation object with «org-type: OTHER» or editing an existing one using Webupdates, you will be able to search for an existing abuse role account in the «abuse-c:» attribute, or create a new one seamlessly.
Finally, reference this organisation object in the customer’s assignment object(s). Any query for the customer’s IP address(es) will now return their abuse contact details instead of the contact details you set up for the parent allocation.
Note: You do not need to update the «abuse-c:» attribute in order to update the email address used for your abuse contact. To change the email address, you simply need to update the role object. See this FAQ about how to do that.
However, you might wish to change the «abuse-c:» attribute itself. For example, you might want to change the role object that your «abuse-c:» references. Please ensure you do the following when updating your «abuse-c:» attribute:
RIPE NCC members:
PI assignments, ASNs and PA created out of your allocation:
The abuse email address is contained in the «abuse-mailbox:» attribute in a role object. It is this role object that is referenced by the «abuse-c:» attribute in the organisation object. This has to be done for all the organisation objects linked to the resources you manage.
First make sure you have created an organsiation object for the assignment and that it is also referenced in the assignment itself.
To update your organisation with an abuse contact:
You can have an “abuse-c:” attribute on both your ORGANISATION object AND your RESOURCE object (inetnum, inet6num and aut-num). The “abuse-c:” reference on applicable RESOURCE objects will override the value in the “abuse-c:” of your ORGANISATION object. This means that, when querying an Internet resource in the RIPE Database, it will show the abuse contact registered in your RESOURCE object.
Validation of «abuse-mailbox»
Appeal: The proposer appealed against the decision of the WG Chairs on October 5, 2020
https://www.ripe.net/ripe/mail/archives/policy-announce/2020-October/000569.html
Summary of Proposal:
The current policy, “Abuse Contact Management in the RIPE Database” does not sufficiently validate the actual availability of the abuse-mailbox. It provides a technical validation that the mailbox/server exists – but not whether if it accepts new messages or even if it is monitored.
As a result, some resource holders (LIRs and End Users) might not keep this contact information up-to-date or might use a non-responsive or fake mailbox. In practice, this contact becomes ineffective to report abuse and generally gives rise to security issues and costs for the victims.
The RIPE NCC impact analysis of 2017-02, which turned into ripe-705, already recognised that false negatives and false positives are possible, and that there is a need to avoid them.
This proposal aims to solve this problem by ensuring the existence of a proper abuse-c contact and establishing a process for its utilisation.
Policy Text:
a. Current Policy Text (ripe-705)
1.0 Abuse Contact Information
The «abuse-c:» will reference a role object holding abuse contact information. The positioning of the “abuse-c:” attributes will make use of the hierarchical nature of the resource data to minimize the workload on resource holders. Internet number resources need to have an “abuse-c:” attribute.
The “abuse-c:” will be mandatory for all aut-nums.
Due the hierarchical nature of IP address objects, at least every direct allocated inetnum and inet6num needs to have an “abuse-c:”. Inherited objects might have their own “abuse-c:” attribute or they will be covered by the higher level objects.
The role objects used for abuse contact information will be required to contain a single “abuse-mailbox:” attribute which is intended for receiving automatic and manual reports about abusive behavior originating in the resource holders’ networks.
The “abuse-mailbox:” attribute must be available in an unrestricted way via whois, APIs and future techniques.
The RIPE NCC will validate the “abuse-mailbox:” attribute at least annually. Where the attribute is deemed incorrect, it will follow up in compliance with relevant RIPE Policies and RIPE NCC procedures.
As per current practice, other «e-mail:» attributes can be included for any other purposes.
b. New Policy Text
1.0 Abuse Contact Information
The «abuse-c:» will reference a role object holding abuse contact information. The positioning of the “abuse-c:” attributes will make use of the hierarchical nature of the resource data to minimise the workload on resource holders. Internet number resources need to have an “abuse-c:” attribute.
The “abuse-c:” will be mandatory for all aut-nums.
Due the hierarchical nature of IP address objects, at least every direct allocated inetnum and inet6num needs to have an “abuse-c:”. Inherited objects might have their own “abuse-c:” attribute or they will be covered by the higher-level objects.
The role objects used for abuse contact information will be required to contain a single “abuse-mailbox:” attribute, which must receive messages, either for automatic (e.g. X-ARF/RFC5965/RFC6650) or manual reports about abusive behaviour originating in the resource holders’ networks and must not force the sender to use a form.
The “abuse-mailbox:” attribute must be available in an unrestricted way via whois, APIs and future techniques.
The RIPE NCC will validate if the “abuse-mailbox:” attribute is present and can receive messages at least every six months*. If the validation fails, the RIPE NCC will follow-up in compliance with the relevant RIPE Policies and RIPE NCC procedures.
This validation process will not check how the abuse cases are processed. The community should escalate/report back to the RIPE NCC, so anonymised statistics can be collected and periodically published.
As per current practice, other «e-mail:» attributes can be included for any other purposes.
*The RIPE NCC may change the validation period depending on the level of accuracy of the contacts. For example, switching from a six-month to one-year period once contact accuracy has improved.
Additional information:
It should be clear that the policy intent is not to look into how the abuse mailbox is monitored or how abuse cases are handled.
However, the community should report any situation to the RIPE NCC, which can provide (anonymous) periodical statistics to the community, which can take further decisions about that.
Rationale:
a. Arguments Supporting the Proposal
The Internet community is based on collaboration. However, in many cases this is not enough, and we need to be able to contact resource holders (LIRs or End Users) who may be experiencing a problem in their networks and are unaware of the situation.
This proposal solves this problem by means of a simple, periodical verification, and establishes basic rules for performing such verification. It thus avoids unnecessary costs to third parties who need to contact the persons responsible for solving abuse from a specific network.
The proposal guarantees that the cost of processing the abuse report falls on the resource holder responsible (or its customers, from whom they receive financial compensation for the service), instead of falling on the victim, as would be the case if they had to resort to a legal claim. This avoids costs in terms of investigations (and lawyers, solicitors, etc.) and saves time for both parties.
Having an equivalent policy in different regions has the advantage of improving the overall response to abuse cases, reduces the cost for handling them, and facilitates the work of all people involved in the operation of the Internet.
b. Arguments Opposing the Proposal
RIPE NCC members have to verify and update (if required) their abuse-c objects periodically.
References:
A similar proposal has been accepted in APNIC (already implemented) and LACNIC. It is under discussion in AFRINIC. ARIN has a similar policy.
Impact Analysis
A. The RIPE NCC’s Understanding of the Proposed Policy
Definition of “abuse-mailbox:” attribute
In the context of “Abuse Contact Management in the RIPE Database” and this impact analysis, the term ““abuse-mailbox:” attribute” refers to an email address that is entered in role objects in the RIPE Database. These role objects are referenced as “abuse-c:” attributes directly or indirectly to Internet Number resource objects (such as inetnum, inet6num, aut-num).
Scope
It is the RIPE NCC’s understanding that this policy change aims to change the abuse-mailbox validation process not to just check if the attribute is configured correctly but to ensure that the mailbox can receive messages.
This proposal also increases the frequency of the validations to every six months. Whilst increasing the current frequency of the validations it also provides the RIPE NCC a possibility to change this frequency in the future again, should the accuracy of the contacts improve. It does not provide an indicator of the levels of accuracy required for a change in frequency, leaving it open for the future interpretation of the RIPE NCC.
It is the RIPE NCC’s understanding that this policy change considers ““abuse-mailbox:” attributes” which force the sender to use a form in violation of this policy. However, during the validation process the RIPE NCC will only check if “abuse-mailbox:” attribute can receive messages. If the RIPE NCC receives a report with the report form that the “abuse-mailbox:” forces the sender to use the form, it will have to follow up in compliance with relevant RIPE Policies and RIPE NCC procedures..
Not in scope are “abuse-mailbox:” attributes that are solely referenced in Internet number resources with the status LEGACY. The RIPE Policy “RIPE NCC Services to Legacy Internet Resource Holders” requires other RIPE policies to mention legacy resources explicitly in their scope if they are to apply to legacy resources. This is not the case with the proposed policy change.
Also not in scope for this validation are scenarios where the “abuse-mailbox:” can receive messages but reports are not followed up in a way that the reporter would like. The proposal states that the community should report back such cases to the RIPE NCC, so that anonymised statistics can be collected and periodically published. These reports can be submitted with the report form however the RIPE NCC will make clear on its response that it has no mandate to interfere with the internal abuse handling procedures of resource holders and it will only archive the report.
Current Validation method
The RIPE NCC has already a process to proactively validate “abuse-mailbox:” attributes on a yearly basis, based on the accepted policy proposal 2017-02, “Regular abuse-c Validation”.
The current validation process starts with a verification tool which checks that there are no formatting errors in the email address, verifies DNS entries, looks for bogus or honeypot emails, and uses ping to check that the mailbox exists and can accept mail. This tool does not send any emails and won’t require any action on the part of the abuse contact. 92.5% of the abuse mailbox addresses passed this automated validated check.
After running the tool, email addresses that failed the test are marked as invalid, we send a validation link only to these addresses and tickets are created in our system. There were about 6000 tickets created during the implementation of the proposal 2017-02 in 2019.
A separate ticket is created for each LIR organisation abuse mailbox (
3,900 tickets in 2019).
LIR resource abuse mailboxes are grouped per corresponding LIR. The LIR needs to make sure that the abuse mailbox is validated (
600 tickets in 2019).
End User abuse mailboxes are grouped per sponsoring LIR. The sponsoring LIR needs to make sure that the abuse mailbox is validated (
1,500 tickets in 2019).
If the validation link on the ticket is clicked or the abuse-mailbox attribute is updated and the verification tool recognises it as valid within three weeks, the ticket is closed without any manual input needed from the RIPE NCC.
In about 30% of the cases, manual intervention is required from the RIPE NCC to follow up with the LIRs.
A more detailed report on the current validation method is available on this RIPE Labs article.
New Validation method
If this policy change is accepted, the RIPE NCC can no longer use the verification tool as part of the validation process as this process does not send emails thus it cannot ensure that emails are received.
The rest of the validation process will remain as it currently stands. The only difference will be that the RIPE NCC will send validation links to each abuse-mailbox in the RIPE database. Previously, it was only sent to addresses deemed invalid.
The RIPE NCC expects that each validation round will need the creation of more than 32,000 tickets according to the categories below:
Impact on Members
If this policy change is accepted there will be an increased workload for RIPE NCC members who are sponsoring End Users or have an abuse-c contact listed in their resources. We will rely on these LIRs to validate more than 70,000 abuse mailboxes. The RIPE NCC will send the validation links to all abuse mailboxes. However, it will open tickets only with the corresponding members. These members will need to follow up with their End Users/customers to make sure that they validate the abuse mailbox.
B. Impact of Policy on Registry and Addressing System
If this proposed policy change reaches consensus, an improvement of the registry data is expected as more “abuse-mailbox:” attributes will be current and correct.
The proposal does not have an impact on fragmentation and the routing system.
C. Impact of Policy on RIPE NCC Operations/Services
The RIPE Database contains around 93,000 distinct abuse-mailbox attributes. The RIPE NCC expects that each validation round will need the creation of more than 32,000 tickets or 64,000 tickets per given year (in 2019 we opened around 6,000 tickets).
While the process will be automated as much as possible, a considerable number of these tickets (around 30% according to 2019’s figures) will need to be checked manually (
19,200 tickets per year).
The estimated workload would exceed the current capacity of Registration Services. A significant increase in FTEs (employee on a full-time basis) would be required to handle this regular workload (10 times the current level). In comparison, three additional temporary FTEs were needed in 2019 to handle the manual workload generated by the initial validation of the current policy.
This amount of workload will continue until the RIPE NCC decides that the level of accuracy of the abuse mailbox attribute in the RIPE database has improved and the frequency of validation sessions can decrease. At this point, the RIPE NCC cannot reliably estimate when this may happen.
A slight increase of workload is expected from reports of abuse mailboxes forcing members to use a form.
The ARC process can play a supporting role, especially if there are indications that the incorrect “abuse-mailbox:” attributes are part of a bigger issue of incorrect contact information for an LIR. In such situations, an ARC can be scheduled immediately. However, full coverage via the ARC process is not possible due to the differing scope and frequency of the processes. This policy change would require the validation every six months of all abuse contact email addresses (for allocated and independent resources), while the ARC process aims to verify the registration details of LIRs only.
D. Legal Impact
If the policy proposal reaches consensus, it will impose the following two criteria for a valid “abuse-mailbox:” attribute: it must receive messages and it must not force the sender to use a form. During the validation process the RIPE NCC will only check that the attribute is present and can receive messages. Cases of “abuse-mailbox:” attribute that forces the sender to use a form, if brought to the RIPE NCC’s attention, will also constitute policy violation and RIPE NCC will follow up as per relevant RIPE Policies and RIPE NCC procedures, such as “Closure of Members, De-registration of Internet Resources and Legacy Internet Resources” procedural document.
If this policy proposal reaches consensus, the RIPE NCC will make sure that all email validation checks are performed in accordance with the EU data protection legislation.
The RIPE NCC may also need to update relevant procedural documents, including the RIPE NCC procedural document “Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources”.
E. Implementation
With the information currently available, it is expected that implementation of the proposal would have a medium impact (about three months) in terms of the software development needed to facilitate the policy change. All current “abuse-mailbox:” attributes will be validated in batches.
The start of the implementation of this proposal requires a significant increase in FTE’s which would need to be included in the RIPE NCC Draft Activity Plan and Budget. This document is published in September and reviewed by the RIPE NCC membership during the autumn General Meeting. The PDP cycle of this proposal is expected to finish after the upcoming publication. This might considerably delay the start of the implementation.
The implementation will be considered completed after every “abuse-mailbox:” attribute has been validated for the first time.
