Firewall LAB on Juniper

--> Proteksi router: DOS, warm
--> Limitasi akses: illegal access

Task:
1. deploy suatu rule dimana PC1 hanya bisa melakukan telnet ke R2 saja


tambahkan route R2 untuk advertise route dari PC1
set routing-options static route 10.10.10.0/24 next-hop 172.10.160.1

Pastikan PC1 bisa ping dan telnet R1 dan R2
Ping 192.168.1.1 rapid count 100
Ping 192.168.1.2 rapid count 100
telnet 192.168.1.1
telnet 192.168.1.2

Pastikan PC1 hanya bisa telnet R2
R1
set firewall filter no-telnet term 1 from source-address 10.10.10.2/32
set firewall filter no-telnet term 1 from destination-address 192.168.1.1/32
set firewall filter no-telnet term 1 from port telnet
set firewall filter no-telnet term 1 then reject
set firewall filter no-telnet term 2 then accept

Apply policy no-telnet pada interface face to PC1

set interfaces em3 unit 0 family inet filter input no-telnet

Redistribution Overview

- Redistribution rules and guidelines:
 -- Redistributed routes cannot be redistributed again on the same router (RIP > OSPF > EIGRP)
 -- Manual Split-Horizon - Never redistribute a prefix injected from domain-A into domain-B back to  domain-A.

-- You cannot change the EIGRP external AD (170) per-route. It can only be done for all prefixes or none.
--  Sub-optimal routing in the lab is not a problem unless specified, as long as there is full reachability.
-- The redistribute command redistributes only routes which are in the router’s current IP routing table (RIB).
-- Before enabling any redistribution, make sure each protocol have full reachability within itself.
-- The metric assigned using the "redistribute metric" command takes precedence over metrics assigned with the "default-metric" command.

- When redistributing into RIP and EIGRP:
-- The metrics must be set via configuration as RIP and EIGRP have no default values.
-- RIP cannot use a 0 metric, the hop count must be between 1 and 16.
-- The 0 metric is also incompatible with the EIGRP multi-metric format.

- When redistributing into OSPF:
-- By default, routes are redistributed into OSPF as external type-2 (E2) routes, with a metric of 20.

- These logical steps happen when redistribution is enabled:
-- The router ONLY looks at the routing table to get the routes that are to be redistributed.
-- Not all the routes that the redistributed protocol sends to the routing table, will be redistributed.
-- Verify what routes, with "sh ip route " before redistribution is enabled.
-- The router takes all connected subnets matched by that routing protocol’s network commands.
-- Verify these interfaces, by looking at the redistributed protocol's network statements OR look at the individual routes with "sh ip route x.x.x.x" as listed with "advertised by".
-- Passive-interfaces for the redistributed protocol ARE included when redistributing.
-- This hidden step is the equivalent of the following: (Hidden: H>)
#router ospf 1
#redistribute rip subnets
    >redistribute connected subnets route-map NAME
    >route-map NAME permit
    >match interface fa0/0 s0/1 <--- All the RIP enabled interfaces
-- If ever asked to redistribute specific interfaces, ALWAYS INCLUDE the interfaces that the redistributed
protocol runs on.
- Mutual Router Redistribution
-- Redistributing from a low AD protocol(eg OSPF) to a higher AD protocol(eg RIP) won’t cause feedback as the lower AD is always preferred.
-- But redistributing from a high AD protocol to a low AD protocol could create problems, because the high AD protocol routes might prefer the redistributed low AD routes to a destination.

SQL Injection

SQL Injection is a technique where an attacker creates or alters existing SQL commands (by using some special symbol) to gain access to unintended data or even the ability to execute system level commands in the server. SQL injections are the result of Poor Input Validation and can be blocked by proper input validation.

Application that do not correctly validate and/or sanitize the user input, can potentially be exploited in several ways:

· Changing SQL values.
· Concatenating SQL Values.
· Adding Function calls & stored Procedures to a statement.
· Typecast and concatenate retrieved data.
· Adding system functions & procedure to find out critical information about the server.

Peeking at a Sniffer

Let's begin by peeking into a Wireshark (Ethereal) capture file http://www.milw0rm.com

Looking at this for the first time might be overwhelming. However, let's take that deep breath, examine the packet capture line by line and implement our knowledge in TCP/IP.

Packet 1: ARP Broadcast. We've attempted to send a packet to the Internet, and before our computer can actually send it, it needs to identify the default gateway on the local network. The default gateway IP address is configured on the requesting machine, but the default gateway MAC address is unknown. My

machine sends a broadcast to the whole network, asking “Who has 192.168.0.1?,

Tell 192.168.0.186”.

Packet 2: All computers on the local subnet receive this broadcast and check whether 192.168.0.1 belongs to them. Only 192.168.0.1 responds to this ARP broadcast and sends an ARP unicast reply to 192.168.0.186, informing it of the MAC address requested.

Packet 3: Now that our computer knows where to send its packets in order for them to reach the internet, we need to resolve the IP of www.milw0rm.com. Our computer sends a DNS query to the DNS server defined in our TCP/IP settings and asks the DNS server for the IP address of www.milw0rm.com.

Packet 4: The DNS server replies and tells our computer that the FQDN www.milw0rm.com is an alias for milw0rm.com.

Packet 5: Our computer insists on an answer and asks the DNS server, once again, for the IP address of milw0rm.com (notice, no www).

Packet 6: The DNS server replies and tells our computer that the IP address for milw0rm.com is 213.150.45.196.

Packet 7: Armed with this information, our computer attempts a 3 way handshake (remember that buzzword from TCP/IP?) with 213.150.45.196 on port 80 and sends a SYN request.

Packet 8: The web server responds with an ACK and sends a SYN to our machine.

Packet 9: We send a final ACK to the web server and complete the 3 way handshake.

Packet 10: Now that the handshake is complete our computer can start talking with the service using a specific protocol. Since we are using a web browser, our computer sends an HTTP GET request which retrieves the index page, and all linked images, to our browser.

Packets 11 – end: The main page of milw0rm.com, including all linked images, are loaded in our browser.

After analyzing this dump we can see that sniffers actually make sense and can provide us with detailed information about what goes on in our network.

(Continued)