berklix.com

BSD-PIE icon

berklix.net

berklix.org

BSD icon
Gnu icon
Linux icon

flag_uk_de_icon_v.gif

Disclaimer

IDACAS

Internet Deterrent And Automatic Counter Attack Systems

British flag

English

Estonian For NATO
via google
Translator tools at imtranslator.net
German flag

Deutsch
Via google
Translator tools at imtranslator.net
French flag

Francais
Via google
Translator tools at imtranslator.net

Cyber defence to punitively deter net perpetrators (eg DDOS flood attackers, Intruders, Fraudulent Bank Web Site Criminals, etc)

This is: www.berklix.com/deter/  
Enable Counter Attack Capability!
Defence requires robust deterrence:
Logo: Counter Attack Enabled

Wasp, my picture, my copyright :-)
( Global Position Probably NOT Current,
Click For Real Global Position)

earth orthographic
Laws can't stop global attack.
So DETECT & DETER

Index

Summary For Email Inclusion

http://berklix.com/deter/ :

Active Automatic Detect & Deter capability to enhance Internet defence,
(passive national defence of Internet is insufficient).

USA first developed active Internet deterrent capabilities,
various countries now have & are getting hostile Internet capability.

Major European countries need to co-operate for active deterrence,
to more effectively deter potential attack, sharing development effort.

Government Required:
  • Not a passive cyber defence study to be spun off to a university.
  • A weapon systems development by a company or multi- national quango.
  • Operational control needs discipline & security (USA Command is military).
  • Operations will require Secretary of State permits.
  • Governmental purview of list of co-operating national control centres.

Purpose

To develop technology to enable automatic responses up to punitive counter attack, To Deter Internet Attackers that launch un- provoked security probes, intrusion attempts, &/or attacks.
  • Internet attacks are increasing . A few nations have had counter technologies for years. Most developed countries have nothing.
  • Escape crippling assumptions that nothing can be done, &/or that anything we might do would be too difficult or somehow illegal.
  • Remaining unprotected is too dangerous.
  • Technical capability can & should be developed.
  • Governments should fund it, (as net services need active protection, not just passive defence, & governments & society will probably Not want to step aside & let industry & commerce control it. )
  • Governments need to clarify or change law to allow operation.
  • Operators must later be selected, licensed, &/or authorised, by government agency &/or industry quango (quasi autonomous non governmental organisation).
  • First we need to start finance of early development, as that will likely take longest to develop.
  • This will never be a system or product for end users.
    • General public will never have access to run active response modules.
    • Home MS PCs will not run this (except possibly passive honey pots)
    • Nodes (feeding to & controlled by NOCs) will be installed in Internet data centres with substantial net resources.
    • The system will be installed & supervised by disciplined organised professionals.
  • The page below needs re-shaping. (A Sisyphus job, (like painting the Forth Bridge) tracking & linking for:
    • Changing nature of attacks.
    • Changing detection methodologies
    • Possible response options
    • Legal stances & possible changes in a myriad of countries.
  • See Also: Disclaimer.

Top of Page

The Problem

The General Problem

  • Many criminals & other hostiles are attempting Internet server intrusion, with more hostile intent than foolish `Script Kiddies' (who waste valuable administrator time for fun).
  • Criminals run Fake Bank Sites to defraud. (Some perhaps on other's suborned systems, discovered as insecure & invaded by criminals). Some system owners won't know, or much care if [part of] their system is [perhaps unknowingly] invaded & suborned, so as long as they don't notice, others get hurt, not them, & it mostly continues to work, (Sensible zombie designers probably ensure to not disturb the host of their parasite).
  • Here's one example of a criminal fraud, that took very little time to analyse, & trace back.
  • DDOS flood attacks etc.
  • The problem is world wide, so trying to deal with it individually in different European countries is a poor solution, better to standardise & share detection detection networks & analysis techniques & jointly develop response options, even if not all responders use all response techniques.

The Traditional Soft Headed European Method Fails To Deter

  • Have a firewall, possibly with dynamic components, eg traffic filters, access failure detectors, Denial of service (DOS) traffic filters etc.
  • Have an intrusion detection system.
  • Log attempted & actual intrusions, & collect evidence to maybe much later prosecute with (expensive) lawyers.
  • Weeks quicker & cheaper than determining language of attacker,
  • Waste time every day, viewing logs bloated with details of intrusion attempts that have failed this day, every day.
  • If one intrusion attempt catches the eye as particularly annoying, hand analyse it (wasting more time) write a complaint email (knowing it will probably be ignore or bounce, determine recipients language, pay to get it translated to whatever, send it maybe half way round the world to Asia or somewhere, wait days or weeks for it probably to be ignored, unanswered.
  • One day discover one of those many unpunished attempted intruders finally succeeded, & now you have Serious trouble.
  • See that Law is a failure, a waste of time & money & does not protect.

Logging Intrusion Attempts

  • Good security is of prime importance, but we can't be complacent knowing criminals are constantly trying to pick our locks every day.
  • Logging is worth while to improve security, justify a security budget, or counter attack, not just for itself.
  • Logging without use or a response is just a self deceiving feel good factor for management &/or self.
  • A waste of time = money, if after admins view logs each day, intrusion attempts are seen, yawned at, & discarded as usual.
  • Many attempts are global, eg from Asia & ex Soviet territory etc.
  • Some countries, groups & people will obviously be next to impossible to pursue.
  • No more than an occasional snowball's chance in hell of sueing & successfully collecting from &/or punishing some intruders if caught.
  • Even if you sue an attacker - So What !?
    It's a well known business ploy of corporate adversaries, to waste & delay & distract the time of competitor's management, by frivolous law suits, counter suits, threats against management individuals, or any other distractions to take their eye of the ball, always implicit tactics in play, such as ~Our corporate lawyer is bigger (& more expensively funded) than yours!~" ... How can you be sure the agressor attacking doesn't have a bigger lawyer than you can afford ? Or is not operating from a regime with tacit approval of attacks, or at least no interest in inhibiting attacks.
    Better to respond to an attacker Fast ! Not delay waiting for lawyers.
  • Companies don't need possible financial compensation paid years later if by some miracle they sue an intruder & receive judgement against intruder & manage to avoid going bankrupt in the interim after their secrets are stolen or database damaged, & finally bailiffs somewhere globally manage to collect cash damages.
  • Companies (& administrator's careers ;-) would prefer the damage Not to occur in the first place.
  • For many firms, the extra time off line, sealing original attacked media as evidence, & preparing new on line duplicates, would be business lost, & bad publicity admitting it happened.
  • Cost example: Apparently (in 2005) German (or Bavarian ?) police won't even forward an incident worth less than 50K Euro to their USA compatriots if incident launched from there, as not cost effective for less.
  • Even more so for government systems, often damage will not easily have a fiscal worth, & no chance of sueing & collecting compensation, just a lot of damage after intrusion, (& egg on faces ;-).

A polite response (reporting to ISPs) usually fails:

  • Reporting un- provoked attacks to ISPs (Internet Service Providers) often fails to work, even with details, eg intrusion complaint complete with log.
  • ISPs (& others) often just ignore complaints of being attacked by their customers or their users.
    (Not just ISPs are irresponsible, other net access providers too eg: This author's own ex university computer lab. (decades after graduation) failed to respond to complaint, when author reported one of their current students, complete with address of which 3 bedroom terraced house student attacked from ! (Yes, reports narrowed down to which individual house!))
  • ISPs usually try to hide behind their Terms Of Service (TOS), which are irrelevant excrement to the innocent person who was attacked by the ISP's criminal customer.
    The terms of some contract between net provider & attacker, & even local national laws in that jurisdiction of provider & attacker, are all No Excuse, & Irrelevant to the innocent attacked victim.
  • If ISPs reply, they never report who the miscreant was from their site/ customer base, & what _disciplinary_ action was taken. They merely occasionally remove a customer.
  • That is Not punitive discipline. Reporting customer or user to the authorities & or public page of dumped miscreants could be some discipline.
  • As ISPs never report that as done, a regularly attacked victim (& many of us Are attacked every day, consult your logs ) may consider himself entitled to revenge himself direct, to damage the attacker to prevent a repeat attack on self & others, & punitively deter other attackers.
  • Some ISPs are truly complacent, criminal accomplices, making extra revenue from criminal negligence, by paying for insufficient staffing to control their subset of criminal users. That under cuts more responsible ISPs.
  • The most criminally complacent ISP most deserve counter attack to coerce them to purge their criminal customers.

Top of Page

Better To Deter!

More Cost Effective To Deter

  • Invest in a deterrent totally automatic co-operative response / counter attack system, to flood/ attack/ disable attacking hosts & nets, (regardless if `innocent & subsumed zombies' or not.
  • Turn back Your problem to be Their Problem - & Advertise Your Counter Attack facility prominently as a deterrent,
  • When the owners of the hosts the attacks come from, finally see it Is their problem too, then they will fix Their problem they have been hosting & tolerating until now, as it didn't hurt till now, just hurt other innocents, eg us.
  • Some attackers will be unattended compromised / cuckoo proxies hosts)
  • Some attackers will be irresponsible large sub nets, who don't really care until your problem becomes their problem, eg Universities, Coffee shops with `Hot spots', Drive by bluetooth (`war driving') connections, Lax ISPs with dynamic IPs, etc.
  • Where originator can be classified by type, maybe different responses may be appropriate, but it's better to Respond than continue with.

Time to Escalate Response:

  • Active automatic defence will work better (eg dynamic firewalls).
  • Why we need automatic systems not individual manual (or even worse, infinitely slow legal) response:
    The industrialised `West' has always been ahead of the curve on technology, automating, while other countries play catch up deploying cheap mass labour. Just as once we ran machines to make clothes while poorer countries hand stitched clothes, so today, some poorer countries & or some criminals can more easily employ lots of people at low rates, to attempt various types of internet incursions (eg This author has received those himself too, eg the unsolicited phone call from a noisey call centre, with Indian accent, "You have a virus, we can remove it for you, point your browser at our web site." (to which the answer was "Liar!" & phone call terminated.) We cant afford the manpower to manually fight all those criminals. We need to Automate Internet Defence.
  • Hostile counter attack will work yet better still. Nothing less will encourage some sites to discipline themselves &/or their users.
  • It's time to take action against sites & irresponsible ISPs etc who host script kiddies, criminal fraudsters, & the negligent who run insecure systems suborned by criminals to perpetrate crime.

Americans (& Others) Have Deterrence

  • The American Government & (Others) Have Systems has long been reported as having counter attack capabilities. (References to American counter attack test networks: DETER & EMIST)
  • The rest of the world needs to develop its own deterrents, as USA has consistently showed (from approx 1982 to 2003), that it is prepared to embargo sensitive software source exports, eg crypt.c etc, even to close allies such as Britain.
  • The rest of the (non American) world needs to develop their own systems to [hopefully] co-operate with American systems.
  • Hoping to just beg from the American plate would fail: Even if American technologists might be prepared to share source code, the USA government is likely to [now or later] munitions embargo either code &/or databases.
  • We non Americans eg Europeans etc don't get stuff free reliably forever by waiting & begging.
    • That's why Britain & France developed own nuclear weapons technologies through half a century,
    • That's why Europe today develops Galileo v. GPS etc:
  • Russians have had some capability apparently (strike if perhaps not counter strike ?
  • The Chinese Government now has facilities apparently.
  • Being dependant on variant whims of future USA (or other) political control is not an option, especially when this technology is so comparatively cheap to develop. Time we Started !

Top of Page

Some Problems We Will Not Deal With

Some problems we will deal with, some we will not, some are optional, & some we may co-operate with other organisations.

Some We Will Deal With

Which sort of attacks are best & easiest dealt with needs ongoing analysis, some thoughts: We may have multiple input modules feeding a common collator stream (on a distributed net, no single point of vulnerability of course) If you have technical comments, mail author or join deter mail list.

Detect & analyse for eg:

  • DDOS Distributed Denial Of Service - Flood Attacks, deliberate overloads.
  • PWD & SSH Password cracking flood attacks.
  • SMTP open relay Spammers running automatic search tools seeking open mail relays :
How:
In most cases above, by adding source code to the daemon (background process) programs (eg add code to Generic version of bind for DNS on FreeBSD). Initially one could also use autonomous 'tail -f' of logs. Case marked (*) by other OS specific measures.

Some Might Be Appropriate for Co- Operation With Others

Some net abuse could not be easily automaticly detected, but could be automatically penalised by optional automatic outputs of this project, eg counter attacks on sites hosting:
  • Originating sites from ssh intruders.
  • Originating (or controlling) bank fraud spam traffic.
  • Bank fraud spoof we sites , ( after manual analysis of Phishing spams).
  • FTPD write access probes bases
    It's not worth initially including, except perhaps as a later module from sensing Honey Pots traps, as real sites that are trusted to run Deter software can be assumed to have configured their FTPDs sensibly & not be at risk from this.

    ( `Warez' Illegal Bootleggers, (who invade un- safeguarded ftp servers & write bootleg copyright films/ movies, music, pictures, sometimes also with illegal &/or offensive content, beyond stolen copyright. The upload often overflows discs & causes loss of service to genuine users, & wasted time for administrators. The mass parallel downloads cause excessive telecoms bills from networking providers, & lack of availability / performance for genuine users.) )

Some We Will Not Deal With

Other net abuse phenomena, though bad, are not aimed to be detected/ responded here for a variety of reasons, (eg technical, not real time etc, &/or others deal with it, or too political, or too innumerate, hard to define, we shouldn't bite off more than we can chew, etc.)

  • Spammers who flood
    (Be it alphabet flood or from lists, & be it with or without viral payload). The reduction/ prevention of spam is dealt with efficiently by many others already well established, eg
  • Excretia dumps in Web Forms:
    Some `Script Kiddies' launch robots that fill web forms with rubbish. Web forms detecting this will be too variant, too much work for us to provide hooks. Some form data collection may be only later be human analysed so not appropriate for real time response; data privacy issues, commercial firms wont want to give us data, we wont want it & do Not want personal data harvesting issues, Don't want any personal data (registrar/ privacy hassles)).
  • Bootleg (commercial copyright) software & music & videos etc.:
    Outside of remit. ( Publisher monopolists get little sympathy, they get enough millions, despite free software.
  • Child porn, {Race & religious etc} hates, Terrorist, Bomb builder & Criminal site etc
    Outside remit. Dealt with by national police & Europol etc. Not phenomena appropriate to real time (sub second) automatic detection & response.

Top of Page

Detection

Wasp, my picture, my copyright :-) Direct attacks should be relatively easily to detect & trace, eg either by having the attacked domain host one of our boxes, or by attacked domain including one of our detector IPs in their DNS etc.

Most attacks will probably be from bot nets: PCs probably running Microsoft, subverted by viruses, to the command of remote botnet controllers. We will need some Honey Pots deliberately open to sense attack, so we can see where attacks come from)

One example of a honey pot: a modified ftpd that runs open to write & read (sought by Warez script kiddies with smallish initial test files), that slowly throttles big uploads after initially allowing it fast, that runs traceroute & whois etc during upload, & that then either deletes or slows & corrupts those downloads to buy more time to attack uploaders, [& maybe report downloaders]. Script kiddies will think they've found a sucker ftpd but we'vre traced them before they can alert most of their clients to download.

Top of Page

Analysis & Tracing

Spanner
  • Our first targets may be larger criminal &/or state sponsored brute force attacks against particular governmental infrastructure, large organisational or corporate/industrial (semi predictable grudge-match) targets: The easier identifiable low hanging fruit, that attracts press, public, business & political interest & funding.
  • Later we will need to also respond to smaller more random, less predictable offenders, eg general criminal/ commercial etc botnet exploiters, that may be harder to analyse.
  • We can't limit ourselves to warning or counter- attacking just lots of small botnet zombie'd PCs; That'd be as effective as swatting mosquitoes, (& a firewall is only about as effective as a mosquito net), we need to analyse botnet DNA, then toss DTD in their swamp.
  • Cracking Botnets to find who is controlling them has a project of its own: Know your Enemy: Tracking Botnets - The Honeynet Project.
  • Most Honey Pots based on Microsoft OSs (prime target), may (or not) be internal or externally configured by co-operating 3rd parties, ie Anti virus companies, (the R&D departments of those companies that presumably set out their own Honey Pots to trap future unknown viruses to document for next release of their own virus detection software).
  • Other Honey Pots based on forms of Unix (eg Linux, BSD, Solaris etc) could be configured by our own internal Unix staff (as Unix core skills are needed also for the rest of the project). These will capable of deepest monitoring for analysis.
  • There may also be access to 3rd party Honey Pots (by definition they're open to some extent anyway, but extreme care would be needed for that, not to trigger deadly mutual embraces between counter nets), especially with 3rd party Honey Pots undeclared to us as Honey Pots, & non declaration of some (or many) is inevitable).
  • Tracing of active direct attacks is relatively easy, same core Unix etc skill sets as above.
  • Tracing of indirect attacks managed by anonymous botnet controllers will be more difficult, needs more thought,will need more MS skills than Unix skills, (& our project core staff will be largely Unix skilled), so we will either need co-operation with anti virus companies etc familiar with MS, or need to recruit some staff experienced with MS.
  • Public logs of sites that have launched un- provoked attacks, could help co-ordinate automatic analysis of sites appropriate for automatic defence or counter attack; This would be just a subset of the info available to trusted project members.
  • Analysis of some Distributed Denial Of Service (DDOS) tools;
    (As intruders already have used these tools, we should analyse them & also could consider using similar techniques for defence by deterrent counter attack.) :

Top of Page

Response Options (including Counter Attack etc)

demolition claw as used on building sites After detection, comes response : Optionally a warning, disabling, counter attack, flood, or demolition by legal enforcement, whatever responders find appropriate.

Types Of Response

People tend to distract to debate what they think might be morally & legally appropriate responses not just for them, but globally, & for various sorts of incident. Such debate is endless & distracts & delays project design, so serves none but the ultra pacifist who might want to block all action.

To avoid distraction into argument, the project will aim for a modular approach, modular in detection & modular in response, so different response policies are usable for each mix of { recipient & responder } & { country legal precepts & organisation / agency policy, & individual operational chief } & type/ gravity of attack detected by initial innocent victim, & intensity & timing repeat factors. Responder sub nets can then decide configure & change their own response policy, not subject to global agreement/ endless dispute.

Options For Passive & Active Cyber Defence & Response

These are ideas subject to discussion & refinement, & to promote discussion on mail list, to show there are ways to respond once the tracing/ analysis is done, but first we need to fund the design & development of detection & tracing/ analysis phases.
  • Starting with mildest first, for civilian agencies operating from pacificist inclined nations) ...
  • Automatic emails to hostmaster@ virus/ zombie'd PC's &/ or abuser hosts, basically saying
    "WARNING We have identified you !, Control your user ! Log attached!" see eg README
  • Increased frequency: They may wake up faster if we send 12 then 60 mails an hour. (A colleague of an absent administrator may get tired of the "You have new mail" audio prompt, & look at screen).
  • Later harsher wordings (including countdown ?) at higher frequencies, as imminence of counter measures approaches.
  • Flood repeat that mail to their in box till it fills, for several reasons: Force attention; Mild punishment; Guarantee our warning is seen & not lost among other mail.
  • Disabling The Network Interface Configuration of botnet - zombies (while leaving other internal components intact eg botnet subsumed individuals' files & editors etc) :
    • Install a README displayed at boot.
    • Reboot or (if PC BIOS supports it) halt the zombie PC. (Halt is better as people will more likely notice their machine has been turned off, gives them more time to get it fixed before they need it perhaps urgently.
  • Pass To Human Agencies occasionally to arrange raids by police or other law enforcement/ at remote site, (if some responder sub nets consider that more appropriate for that cluster of detector reports)
  • Black Lists of: IP numbers & ports (Unix/ FreeBSD /etc/services)
    • Input To Black Lists:
      • As well as trusted members of the deter network contributing directly to database of attackers , also ...
      • Just as organisations such as spamhaus & other RBL providers) generate black lists of spam senders,
      • The honey pot data could be monitored, traced, & noted, for IP numbers of attackers, route relays & attacked target IPs & ports (Unix/ FreeBSD /etc/services)
    • Output: Broadcast of Black Lists (of IPs ( & ports (Unix/ FreeBSD /etc/services) )
      • Those IPs could be fed to dynamic firewalls, direct or via live relay co-operating firewall manufacturers.
        • Fed via 2 methods: (active sending (encrypted mail?) &/ or passively made available for polled fetching) (ftp?).
        • (We have contacts at one firewall company to discuss data format possibilities, more contacts welcome, to author or to deter mail list))
      • [Some of] Those IPs [To certain criteria] could be web published for others not yet integrated, (some firewall manufacturers, OS providers (free projects & commercial) & intelligent end user sites.
      • The IPs & ports will also be fed to other trusted nodes in our own internal Deter network.
    • Just like anti spam lists, there's the risk of blocking a few innocent with many guilty - but if it's that or see your net servers die from DDOS, there's some discretionary level at which one may want to automatically enable dynamic filtering.
  • If/ when we detect zombie botnet controllers,
    • Optional human confirmed delay, if R-DNS tools suggest attacker is in a friendly country where we can arrange Quick response by police or equivalent to catch attackers red handed.
    • Otherwise, Automatic Co-ordinated mass
      Counter Attack from our co-operating net nodes. Targeting IPs & ports at frequencies considered appropriate.
  • River Isar in flood. Flood Attack of packets, mail flood, web overload & DNS overload counter DDOS.
    (Counter flood of compromised equally harmful proxies/ &/or zombies may be necessary, to alert the upstream adjacent carriers, to realise _they_ have a problem customer to terminate immediately, & that our problem is not theirs to ignore, but theirs to resolve, urgently).
For Design Notes see below

Morality, Law, Who Operates

Morality

Consider some analogies :

  • An illegally parked vehicle doesn't necessarily get a warning to driver or owner before it gets wheel clamped.
  • Police in stolen car chases can throw concertina lines of claws across the road, to cripple the tires, then later contact owner to inform them the vehicle was used by criminals, & question owner if vehicle was locked before it was stolen. Here's a notice could be served on owners of detected & disabled zombie PCs.
  • If someone deliberately used a catapult to fire stuff at or through through your window, would you feel entitled to grab & damage the catapult. Would you carefully ask if the user was the owner before you snatched it or broke it ?
  • If you saw daily attempts to pick your door lock at home, would you be complacent ? wouldn't you worry they'd one day get lucky & break in ? If you could see where the criminals came from, would tracing the criminals back seem sensible ? Or would you just wait for your locks to be picked ? Wouldn't deterrence seem better ?)
  • Might you install a weak lock on one door (a honey pot), & arm the room with flash lights, cheap net cameras, & a silent alarm to the police station ? (& perhaps an optional deep hole if law allowed ? rather like the optional alternate response modules of this project).
If you'd approve some of the above, best urge decision takers to fund some initial development of Internet detection & tracing/ analysis capability; then while we are developing you will have plenty of time to consider what the dangers are, & decide what optional response modules you may later want to help fund &/or enable / deploy.

Law

  • 40px-US_Department_of_Justice_Scales_Of_Justice.png from http://de.wikipedia.org/wiki/Rechtsstaat Some people knee jerk & say doing anything active would be illegal.
  • They probably don't realise: General public will never have access to run the active response modules.
  • Maybe legal constraints some places, there's an opportunity for those interested more in law to get engaged, explaining issues to local politicians, to change their local laws while we develop this project, so when it's ready for delivery, those places can use it too.
  • If some places can't easily or quickly get their local law changed to allow response by counter attack, they'll still be able to operate honey pot which will generate data for less active responses (eg packet black lists)..
  • The rest of the world won't wait, both attackers & defenders have been developing techniques, botnets & counter methods for years.
  • Law fails currently: doesn't protect us from incoming attacks.
  • In a world where both attackers & attacked could be in any of (singular or multiple collections of) 190 nations , that's 36100 combinations: hoping local law might defend us is ridiculous. Especially as most attackers may well be be in other states, some may be in rogue states, failed states, ineffectively controlled states, terrorist tolerant states, states with a more tolerant view or benefiting from piracy, or cross border criminal bands &/or groups of anarchists, or companies/ groups / religions / whatever attacking rivals, etc.
  • Laws (in some jurisdictions) prevent counter attack to deter/ penalise attackers, especially by civilian groups, - a problem to rectify.
  • Laws in aggregate can not protect, more hinder from responding to attacks.
  • Different response modules will be available, so different people / organisations in different jurisdictions can respond with differing methods & intensities, (Choice of response modules Also avoids a distracting fruitless debate for consensus on uniform appropriate intensity, frequency, & type of response).
  • Court cases would take years, at vast expense, to fail to deter a minute percentage of attacks.
    Automatic counter attack deterrents could be issued effectively in seconds ... As quick as a child learns not to poke a wasp again ! Wasp, my picture, my copyright :-)

Early & Late Adopters - Countries

Countries & peoples/ sectors will present a spectrum of early & late adopters, some background:

Top of Page

Budget, & Funding

  • euro notes pound notes If you are a government or EU agency, company, organisation, or perhaps with budget to help sponsor this, or later that might help pay for some Internet Intruder detection, passive &/or active defence, optionally with active deterrent counter attack systems, services, &/or consultancy , Vector Systems Ltd & associates would be pleased to discuss ideas free of charge, please feel free to make contact.
  • Yes, we have ideas of what it will cost. It depends on various factors, Contact us to discuss
  • Subscribe free to the deter mail list, to show interest, & keep track, if you are a programmer interested to develop, Or a system or net administrator interested to later perhaps use, Or a manager who may later have a budget for purchase of licences/ donations/ or funding consultants employees or students to help develop the technology.
  • If funding is insufficient, to encourage it, (or possibly for security reasons) we might need to restrict source repository read access so that funders nominate who gets access to newer code, & public access is only to older code.
  • To avoid the possibility of some funders (nations or organisations) waiting till others alone have funded the development:
    The founding nations etc who initially fund the development, will be given the keys to form an initial net of NOC Command & Control Databases
    Other nations/ operators who later seek to join the NOC net may be required by those who already paid to be in the NOC net to make a contribution to past & perhaps ongoing further development costs, before the international net of NOCs will accept incident & response records from the newcomer NOC. (Not foolproof, but encouragement to help fund the moderate costs now to get started, & not all wait for each other to contribute funds smiley icon

Top of Page

Mail List(s)

  • Currently we have just one mail list:
  • deter@ To discuss how best to design automatic counter attack technologies.
  • Click to subscribe to deter@berklix .org
    (Help page for majordomo@berklix.org robot.)
  • Later the list may be split into sub lists, eg :
    • deter-announce@ moderated to ensure low traffic, Announcements of funding, affiliations, calls for staff, releases available, operational status changes.
    • deter-dev@ for developers to discuss source code
    • deter-users@ a self help mutual assistance group for users of the code & service. Users will be experienced server administrators.
    • deter-finance@ to arrange funding of central service portions of the project
    • deter-law@ to discuss how to get politicians to modify obstructive laws.

Top of Page

IDACAS Etymology

The name IDACAS (for international page of Internet Deterrent And Automatic Counter Attack System) may acoustically remind one of the Greek name Icarus, who ignored warning & flew too near the sun & melted his wings. The similarity is somewhat apposite: There are dangers & responsibilities to neither over react, nor under react to attacks.

Currently nearly all countries are asleep at the wheel, not reacting.

`Hackers Versus Crackers : There's A Difference !

Hacker': An Ignorant Name,
`Cracker': The Correct Name.

Mislabelling Hackers & Crackers Displays Ignorance

The label `Hacker' is mostly wrongly used, a useful indicator the user is probably ignorant (& that their opinions are worth less & sometimes worthless ;-). Most journalists & politicians mis-lead the public, mis-using the word Hacker, exhibiting their ignorance smiley icon Learn the difference !
`Hackers' Examples:
  • Programmers who efficiently hack up (ie generate/ improve / adapt) existing source code in minimum time, (much quicker than commercial programmers with proprietary sources who have to start from scratch), usually to give away Free eg
    Mail archive of a hackers group, from March 2003 on, for the FreeBSD.org free operating system:, No evil Crackers there !, just innocent Hackers improving free software to give away. Called Hackers long before ignorant journalists & politicians mis-understood & hi-jacked the term Hacker & mis-lead the public. The FreeBSD Foundation is listed as a public charity by the USA IRS, read its web to see what it does.
  • Journalists - long known as Hacks - hack up articles, sometimes from pre-existent pre-supplied text eg press releases etc. (Hacking of text ... akin to hacking of program sources ) - How come journalists are so clueless they don't understand the similarity ?)
  • Hacks are general purpose non specialist horses, Hacking is a form of riding.
`Cracker' is the much better pejorative to apply to criminal Internet system intruders & vandals etc. ... "Cracker" as in "Safe Cracker" etc !
Some Crackers mis-appropriate the name Hackers, but that only fools the ignorant. A thief may call himself a fund manager or investment manager or banker, doesn't mean you have to believe him either, nor assume all of them are criminals. Similarly most Hackers are not criminals. Use the right word: Cracker not Hacker.

Design & Solutions: List, Tools & Services

  • The aim is to co-operate with lists & tools for active dynamic defence & / or counter attack.
  • BSD daemon logon Preference is to initially develop on BSD (even nicer than Linux), to work with tools compatible with the extensive ports collection of FreeBSD.
  • Using code extensively security reviewed. Based on open free co-operative international standards (not proprietary commercial pseudo standards attempting to monopolise the market).
  • Particularly ports/net.html & ports/security.html There is no question of basing these systems on Microsoft proprietary binary, un-sourced, virus compatible OS's (though some honey pot will use MS.)
  • Later porting anything necessary later to NetBSD (If multiple platforms are needed. - But most design will be for supplemental cheap BSD boxes to be connected to other heterogenous Unix servers, so we won't need full native run support on all Unixes direct); &/or OpenBSD (if security features there appeal above other BSDs at assessment time).
  • Systems envisaged to be based on standard cheap PC Server hardware bases, linked to existing major organisations gateways.
  • Later it can be ported to other Unixes eg Linux if need be, but note: The software will NOT need to, or be allowed, or trusted to, run on normal end user PCs, it will only run on resilient hardware in server environments, next to gateways & routers, accessible only to some net administrators. There is no need, & No intention to port or run it on any OS such as Microsoft, that does not provide OS public source code.
  • Flood deterrence by counter flood is dangerous will need careful design, management & discipline, not to spill over to other similar systems, recurse within itself, or mutually deadlock, etc.
    (Variable escalation criteria dependent on time zones, work days, public holidays, root national domains, if targeting offender direct, or escalation alert levels for innocent but possibly lethargic neighbouring carrier etc.)
  • We may pre compile lists of R-DNS & routings etc, in background during normal peaceful times, (like search engines use web crawlers, but we would only store IPs & routes (not text) for internal reference (no external public enquiry load), so a minute fraction of the load of search providers). We would keep this in reserve, patched to our DNS etc, for when our own DNS & other deter services were inevitably attacked.
  •   The previous point raises questions of DNS & BGP protocol services & resilience of existing services that have been addressed in other forums for some time, eg here in French , & how those service might be secured more, other bodies are looking at that, we will aim to track/ co-operate with that.
  • Security: Some work proposed may require people to sign to eg: the British official secrets act, or German or French equivalents, eg:
    French Agence nationale de la sécurité des systèmes d'information requires : noter : ces postes nécessitant d'accéder à des informations relevant du secret de la défense nationale, le titulaire fera l'objet d'une procédure d'habilitation, au niveau Secret Défense.
  • DNSSEC & amp; IPSEC etc will probably be needed internally on the project, they are tools to help build the projected solution, they are not tools that as of themselves would be obviate the project.

Sample Past List of Attacker Hosts Wasp, my picture, my copyright :-)

A sample of some some hosts that launched un- provoked attacks on author 's hosts over a short window of time (just a tiny example of a much wider problem).
Links to other lists welcome. Mail author URLs.
A later list of hosts that co-operate to automatically combat intruders most probably won't ever appear here, but will be be automatically updated by the protection software to be developed.

Top of Page

Sample Past Incident Log, List Format

Format subject to change:
"|" separated fields (not normal Unix convention of ":" eg for tbl, as dates use ":".
Column Order
  1. DATE[s] of attack (TZ=CET or CEST, ie GMT+01:00 or GMT+02:00 in summer). There may have been numerous attack before & since. A minimum of one date is noted. This column is first to ensure a sort will recreate chronological log order.
  2. Number Of Attacker
  3. DNS Address of Attacker OK or a Lie ?
    Whether via nslookup, after using RARP to match the IP# to name, the name then maps back full circle to IP number, as it should.
    Possible Values: (In sequential test & possible result order)
    Key Explanation Conclusion Action Possible
    "!RARP" R-ARP Fails: No DNS record maps number to name. Secretive Counter attack.
    "!FARP" Forward Lookup fails (Inverse of R-ARP Fails): No DNS record maps name to number. (Even if number to name succeeds). Secretive Counter attack.
    "!A" A Fails: No DNS record maps resultant name back to a number. Liar Counter attack.
    "False" R-ARP & then DNS A-Name don't agree. Liar Counter attack.
    "Match" DNS R-ARP & subsequent A records match, (even if A rec might be a cluster of IP numbers) Perhaps a properly & honestly configured IP, with rogue user(s) Warn First.
  4. NAMEParent IP Domain Name of abuse@ owner of domain (may well not be the same as the IP number of the attacking host, eg attacking host chopok.fns.uniba.sk gets mapped to owner uniba.sk )
  5. REPLY Response if any.
    "Fixed+Detail" They fixed their problem, ie purged their customer or their customer server purged the user account etc. They appear to be an innocent provider doing their best to responsibly purge miscreants. They should Not be counter attacked. They are merely listed here to show what (small) percentage of providers take such responsible policing action.
    "Auto" Automatic standard email reply
    "NS" Not Sent: The results of nslookup &/ or http:// access made the domain too suspicious to complain to.

Top of Page

Future Incident Report Record Format

A draft code fragment to stimulate discussion on mail list &/ or with author.

Top of Page

Tools & Source Code Repository

  • An initial source code repository will be provided, probably initially on Berklix servers; probably using Subversion, a set of SVN tools now standardly used on FreeBSD.
  • Access to this repository will be discussed with funders before policy is firmly decided.
  • Our starting point is, most nation states are too small to operate a Deter/Idacas system alone, so will have to co-operate, & for that we need common standards developed, eg for incident report records, so it is proposed source code of the project will be open to all to read & comment on,
  • Yes, public read access means rogues will be able to read our code too; inevitable, the normal price to be paid to allow a lot more reviewers to check & report potential loopholes, & to contribute fixes & enhancements to source code. The old "security by obscurity" paradigm used by proprietary for-profit companies has long been abandoned on international public secure software projects.
  • Of course only a subset of developers will have commit privileges to write to the source code repository.

Later Distributed/ Mirrored Source Repositories

  • The source repository will be replicated/ mirrored on multiple (*) servers in Europe (etc?), to achieve immunity to disruption from any nationalist &/or ignorant politicians eg USA in particular who might want to again disrupt international developer co-cooperation, (as USA government did with Crypt.c & Munitions laws between about 1982 & 2003, (despite the fact their then enemy already long had Crypt code, & ignorant USA government was just pointlessly annoying innocent friendly 3rd parties).
  • Multiple servers in different countries so that no one country's laws can disrupt the project. We will need encryption technologies etc. What we produce may be argued to come under purview of USA style munitions laws. Ignorant politicians in various countries from time to time consider the only valid users for encryption are the state & criminals. (Ridiculous) It is recalled France at one time had laws restricting encryption (current status Here); other countries have considered similar, USA had the clipper chip, they wanted to force on others 'cos it was CIA (or other) cracked already), - So we'll insulate ourselves from individual daft politicians by having a distributed base.
  • If some country passes too restrictive law, & that country happens to be the master of the mirrored repositories, other operators of other source repositories in other countries will simply cease mirroring the old master, & designate a new master repository. (Akin to & extending from situation when FreeBSD insulated itself from daft USA politicians by having cryptography developed internationally, but Not repository mastered in USA, but in South Africa, so it was only ever imported into USA, never exported from USA, & daft USA law was thus not breached.

Top of Page

NOCs: Network Operation Centres: Command & Control

  • A distributed command & control database (not a source code repository) will be hosted elsewhere on several replicated/ dual-redundant sites ( to make the service more secure from attack).
    • This will be a high security system it will contain records of past & current attacks & counter response etc.
    • It will be designed as a co-operative secure net, with no central master node (both to make it more secure from attack, & to avoid nations distracting to debate which one might best be ceded control of a singular master.
    • Probably each country fronting development funding (which will be cheap) will probably also want to fund its own national NOC (Network Operating Centre), th e design will allow for distributed co-operative functioning.
    • The various national government's funding agencies will later (perhaps towards end of development) inform us who are to be the operators for their country, so initial sets of security keys can be exchanged & documented in the database.

Links To Other Sites

Extra Disclaimer: Content of links may or may not be agreed with, but may have pointers to technology, laws, disputes, etc.

Top of Page

Disclaimers & Cautions

More legal verbiage may be necessary here later, but when reading this page, writing tools, or reading the list, etc note:
  • Re. Un-provoked Attackers List
  • New entries to the Un-provoked Attackers List may be innocent, they may just not have had time to track & kill their rogue user account & report back yet.
  • Some hosts may be innocent, just having DNS entries screwed, or in transition.
  • Some sites may be innocent, just having guilty host computer(s).
  • Some hosts may have been for innocent purposes, but been cracked & compromised.
  • Some administrators may be innocent, but clueless or incompetent.
  • Some hosts may be largely innocent, but with one or more guilty users.
  • Recipient (of attack & investigating ISPs return mail) may have been away & not received response yet.
  • Occasional mail failure may occur.
  • IP spoofing etc exists.
  • Use your own detective skills, including comparing this list to other intrusion lists, to decide yourself which sites merit counter attack.
  • No guarantee all intrusion attempts will be logged. (Some recipients of un- provoked attack may not want that). Others may qualify for immediate defence or hostile counter attack etc, particularly repeat offenders.
  • The Disclaimer on the side bar also applies.
  • Counter attacking is doubtless illegal in some jurisdictions. Especially where politicians haven't woken up to the fact the Internet has no national boundaries, & local laws do Not protect their citizens & state infrastructure, local laws often just hinder defence by deterrence.
  • Where counter attack would be illegal, don't do it, But do consider pushing to get local laws changed, & perhaps also help develop the technologies in parallel while the politicians take their time changing their local national laws.
  • It's Your responsibility to comply with Your laws, wherever you are on planet Earth.
  • Author & others hereby disclaim everything in & out of sight & & any & all inference etc.
  • Use your common sense ! Determine yourself what's moral, legal, technically feasible, reasonably or likely safe, unsafe etc.

Top of Page

Author Julian Stacey of Vector Systems Ltd

Apache: Web Server FreeBSD: Operating System