Blocking BGP Hijacking Attempts with Radware DefensePro

Using Radware DefensePro to block BGP hijacking attempts requires more than reacting to unreachable websites. A more-specific route can attract traffic meant for your network, while an accidental BGP route leak can divert internal flows onto an expensive or unsafe path. Establish which routing event occurred before applying mitigation.

DefensePro is a network and application defence platform, not a route registry. Its value here is focused traffic filtering, attack mitigation and, where the installed release provides it, BGP-aware detection. Route origin validation, border gateway policies and provider blackholing agreements still depend on your transit providers and internal routing architecture.

A layered approach combines RPKI route origin validation, registry filtering, provider-side BGP policies and tightly scoped traffic rules. Keep an inventory of legitimate prefixes, watch route updates from several directions and preserve evidence. For teams in Sydney or Melbourne, include cloud-facing address space as well as branch and partner services.

Have a look at the routing paths before changing the firewall. The same symptom can be caused by a genuine prefix hijack, an overly specific advertisement, a failed upstream session or your own filter. The controls below prioritise field verification, narrow scope and tested rollback.

Recognising BGP hijacking symptoms

Unexpected traffic loss, rising transit costs or traffic arriving from an unfamiliar ASN can indicate prefix hijacking. Compare route collectors with observations from your own border routers, then check whether the affected prefix has gained a new origin ASN or unexpected AS_PATH. A traffic diversion and a simple blackhole can look similar from the application layer.

Perth operators should also expect international changes to surface through Singapore or other Asian transit hubs. That geography can make a hijacked route appear closer than it is. Treat an ASN change as a signal to investigate, not automatic proof of malicious activity; a misconfigured customer or provider can cause the same pattern.

Confirming route origin and path changes

Correlate the event with RPKI validation results and registry records. RPKI checks the origin ASN and maximum prefix length, but it does not prove that every AS_PATH hop is safe. A route leak retaining the legitimate origin ASN may still validate. IRR route objects add useful intent, although stale objects can also mislead.

Check the filtering policy offered by each Australian carrier, including Telstra, Optus and TPG where they provide your connectivity. Their customer-prefix and community policies can differ. Ask for route filtering against your authorised origin ASN, maintain an emergency change channel and know which team can apply a temporary reject.

Building an accurate protected-prefix inventory

Create an authoritative inventory of prefixes that genuinely serve your organisation, including production prefixes, regional anycast addresses and customer routes announced through your ASN. Record the expected origin, covering ASN, prefix length and owner. Keep provider-assigned space separate from third-party CDN space.

Australian-facing .com.au services often rely on shared CDN addresses, so do not list every destination used by a website as your own. A DNS lookup proves the current endpoint, not prefix ownership. Obtain provider data, validate it against BGP announcements and include only verified ranges in high-priority protection policies.

Configuring scoped DefensePro protections

On a lab appliance, enable the BGP anomaly or hijack-protection capability supported by your licensed DefensePro release. Feature names and actions vary, so confirm the documentation for the installed build. Import the protected-prefix inventory, assign expected origin ASNs and choose an action that matches your provider’s blackholing process.

Create narrow rules for confirmed malicious sources or traffic characteristics, with thresholds based on a normal baseline. Broad ASN blocks can interrupt legitimate customers, while blocking an entire destination prefix can affect your own users during a route leak. The wider IT Diversified guides can support the surrounding automation and infrastructure workflow.

For route-level containment, use an upstream deny policy, FlowSpec where supported, or a provider-operated remote-triggered blackhole. The provider normally announces the agreed blackhole community and drops matching traffic before it reaches your network. DefensePro remains useful for filtering residual attacks and maintaining application protections. Temporary route changes need an expiry and owner.

Testing mitigation without causing an outage

Run a controlled exercise using a home-lab route reflector, a second upstream and a small test prefix. Reproduce route preference and the arrival of a more-specific announcement without touching production prefixes. Mike Patt’s network engineering notes are a useful companion for the surrounding BGP and lab workflow.

Test deliberate hijack scenarios and benign changes, such as a customer requesting a larger route. Check that hold-down timers, thresholds and rollback behave as expected. Verify service reachability from Melbourne, Perth and a relevant cloud region, using synthetic transactions rather than ping alone, before restoring normal traffic.

Coordinating the active incident response

During an incident, freeze unrelated changes, record exact update times and preserve BGP logs, flow records and appliance alarms. Contact the upstream network operations centre with the affected prefix, observed origin ASN, collector timestamps and customer impact. For significant cyber incidents, follow ACSC guidance and any applicable APRA notification requirements.

Give the provider a short run sheet describing what changed, what protection is requested and when it must be rolled back. A temporary route reject or RTBH action may remove the diversion, but monitoring must confirm that customer traffic has returned before removing the rule. Keep the blocked-source list under active review because attackers rotate infrastructure.

Maintaining an Australian route-security practice

Review the prefix inventory monthly and test the runbook quarterly. Feed RPKI invalid-prefix and origin-change alerts into operations, validate IRR objects against current announcements and audit emergency filter changes. Record whether each event was malicious, accidental or operational so thresholds can be tuned without weakening ordinary traffic protection.

Australian governance frameworks such as the ASD Essential Eight and APRA CPS 230 do not certify BGP resilience, but they support consistent access control, change management and incident records. Local coordination through AusNOG and IX Australia can expose path changes hidden from a single viewpoint. The runbook should leave every operator with the same prefix list, provider contacts, rollback steps and evidence trail.