Hálózatbiztonság a gyakorlatban

Hálózatbiztonság a gyakorlatban Firewalls continued 2015. május 22. Budapest Dr. Bencsáth Boldizsár adjunktus BME Híradástechnikai Tanszék bencsath@crysys.hit.bme.hu

Ghost in the shell control box http://gitscb.silentsignal.hu/regisztracio Indul: Hétfőn 2

SOE is hacked in Sony hacking event Old apache servers and no firewalls in sony s network Fail: "LastPass, a popular Web based password management firm, advised its customers to change the password they use to access the service following what the company said are signs that its network may have been compromised." Weird: In addition to forcing its more than 1 million users to upgrade the master password used to access their account, LastPass is also accelerating the roll out of a new encryption scheme that will use a SHA-256 bit algorithm on the server and a 256-bit salt using 100,000 rounds, the company said. 3

Sha-256 rounds 4

Main functions of Linux Netfilter Filter Nat Packet filtering (rejecting, dropping or accepting packets) Network Address Translation including DNAT, SNAT and Masquerading Mangle General packet header modification such as setting the TOS value or marking packets for policy routing and traffic shaping. Close interaction with routing 5

Basics Rules are divided into tables : Filter (filtering what is allowed standard firewall) Nat (modifying source or destination address) Raw (if access to the raw packet is needed without any processing) Mangle (to modify packets) Tables are divided into chains Input (packets intended to go to the firewall itself, local flows) Output (from the firewall) Prerouting Postrouting Forward (not local) User defined (chains) 6

Packet processing 7

Rules Rules can be inserted by the iptables tool from the command line Scripts can be made with multiple iptables calls For some distributions, graphical tools help editing firewall rules There are numerous specific tools for netfilter/iptables rule editing Using graphical tools might make it harder to understand what is done deep inside 8

Packet processing Consider a rule list: The first rule matches with an appropriate target (ACCEPT,DROP,REJECT, ) stops the processing of the packet and the other rules are not used Drop: do not do anything, drop the packet Reject: send ICMP port unreachable LOG rule makes a log item on the packet, but the processing of the packet goes forward Chain target series of rules in separate chains (see later) At last, the default policy (ACCEPT, DROP) is used 9

http://hydra.geht.net/tino/howto/linux/net/ netfilter/packet_flow10.png 10

11

http://www.linuxhomenetworking.com/wiki/images/f/f0/iptables.gif 12

Iptables netfilter initialization Clearing/flushing rules: E.g. iptables -F INPUT iptables -F OUTPUT iptables -F FORWARD iptables -t nat -F INPUT iptables -t nat -F OUTPUT iptables -t nat -F POSTROUTING iptables -t nat -F PREROUTING Cleared tables: root@hbgyak:~# iptables -L -v n Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination As You can see, there are no rules in the chains and the default policy is accept. 13

Basic Iptables parameters -I, -A : Insert or Add rule. Add puts the rule at the end, I at the beginning of the list of existing rules -D,-R,-L: Delete, Replace, List -t: table selection. Default: filter table Matching rules: -p tcp: protocol match -i eth0, -o eth0: input interface match. Only usable in correspoing chain (e.g. o cannot be used in input chain) --dport 80: destination port match, only usable combined with protocol match -j ACCEPT: target rule. Check the net for more information. 14

Setting default policy: root@hbgyak:~# iptables -L INPUT -v Chain INPUT (policy ACCEPT 135 packets, 17592 bytes) pkts bytes target prot opt in out source destination root@hbgyak:~# iptables -I INPUT -j ACCEPT root@hbgyak:~# iptables -P INPUT DROP root@hbgyak:~# iptables -L INPUT -v -n Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 291 31532 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Subnet bits The default policy -P is what to do with packets that do not match any other rule Flushing the INPUT table and setting the default policy to DROP can cause problems = cannot connect to the computer anymore Counters show the number of packets and bytes matched by this rule 15

A very simple firewall root@hbgyak:/root/bin# iptables -L INPUT -v -n Chain INPUT (policy ACCEPT 527K packets, 68M bytes) pkts bytes target prot opt in out source destination 141K 13M ACCEPT tcp -- tcp dpt:22 * * 0.0.0.0/0 1.2.3.151 544 2342K ACCEPT tcp -- tcp dpt:25 lo * 0.0.0.0/0 1.2.3.151 154K 18M ACCEPT tcp -- tcp dpt:80 * * 0.0.0.0/0 1.2.3.151 10 857 ACCEPT tcp -- tcp dpt:443 * * 0.0.0.0/0 1.2.3.151 37 2220 ACCEPT tcp -- tcp dpt:113 * * 1.2.3.151 1.2.3.151 0 0 ACCEPT tcp -- tcp dpt:113 * * 1.2.3.177 1.2.3.151 1 52 REJECT tcp -- * * 0.0.0.0/0 1.2.3.151 tcp dpt:113 reject-with icmp-port-unreachable 0 0 LOG tcp -- * * 0.0.0.0/0 1.2.3.151 tcp dpt:110 LOG flags 0 level 4 60 3158 DROP tcp -- tcp dpts:1:1024 * * 0.0.0.0/0 1.2.3.151 Simple reject: ICMP port unreachable as answer portmap can/should discover it. Another option: -j REJECT --reject-with-tcp-reset 16

How to Debug netfilter rule sets It is a hard task to figure out what is wrong with a large ruleset Simply put a full accept into the specific chains (INPUT, FORWARD, etc.) and check if it helps If the traffic is going through, the problematic rule is in the specific chain this method makes us vulnerable for a short time, and it is possible to forget such generic accept rules, therefore, it cannot be used in corporate environment Ad-hoc modification of firewall rules is not a good thing Another possibility is to observe/zero packet counters Zero the counters Start test traffic Check rules with non-zero counters: these are the candidates for the error (DROP, REJECT) Rules with 0 counters can also indicate problems (ACCEPT) Rules with 0 packets for a long time might indicate unneeded rules 17

chains With hundreds of rules it is very hard to understand Especially within a chain (e.g. INPUT) Chains make it easier to understand the ruleset, as a subchain can be understood and analyzed easier 18

A new chain - web root@hbgyak:~# iptables -N web root@hbgyak:~# iptables -L -v -n Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 8435 1351K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 271 packets, 32550 bytes) pkts bytes target prot opt in out source destination Chain web (0 references) pkts bytes target prot opt in out source destination 19

Two rules in the new chain root@hbgyak:~# iptables -A web -p tcp --dport 443 -j ACCEPT root@hbgyak:~# iptables -A web -p tcp --dport 80 -j ACCEPT root@hbgyak:~# iptables -L web -v -n Chain web (0 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 20

The return rule pkts bytes target prot opt in out source root@hbgyak:~# iptables -I web -p udp -j RETURN root@hbgyak:~# iptables -L web -v -n Chain web (0 references) destination 0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 The return rule makes the processing more complicated to analyze (branch point) But helps debugging, and clear set of policies: e.g. in the upper case the web chain surely not processes udp packets 21

Finally: use the web chain as a terget root@hbgyak:~# iptables -I INPUT -j web root@hbgyak:~# iptables -L -v -n Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 36 2912 web all -- * * 0.0.0.0/0 0.0.0.0/0 10057 1557K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 770 packets, 83660 bytes) pkts bytes target prot opt in out source destination Chain web (1 references) pkts bytes target prot opt in out source destination 4 384 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 22

Target combined with match root@hbgyak:~# iptables -I INPUT -j web -p tcp In this case the Return rule with UDP is useless Still, Return rules can be helpful in some examples root@hbgyak:~# iptables -L -v -n Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 60 3596 web tcp -- * * 0.0.0.0/0 0.0.0.0/0 88 8256 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 60 packets, 17843 bytes) pkts bytes target prot opt in out source destination Chain web (1 references) pkts bytes target prot opt in out source destination 0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 Note: Web counters are 0, but the rule in the INPUT chain shows 60 packets. The web chain was used, but no packets matched. Default policy: Return. 23

Example: Mangling MTU iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j TCPMSS --clamp-mss-to-pmtu This causes netfilter to modify MSS value in TCP handshake to be modified to match to the MTU of the interface (MSS=MTU-40 (generally or always?)) 24

Other mangle features Strip all IP options Change TOS values Change TTL values Strip ECN values Clamp MSS to PMTU Mark packets within kernel Mark connections within kernel 25

Connection tracking / basics only Netfilter is a stateful firewall/networking stack Example: stateless forwarding rule: root@hbgyak:~# iptables -A FORWARD -j ACCEPT -s 1.2.3.4 -d 5.5.5.5 -p tcp --dport 80 root@hbgyak:~# iptables -A FORWARD -j ACCEPT -d 1.2.3.4 -s 5.5.5.5 -p tcp --sport 80 root@hbgyak:~# iptables -L FORWARD -v -n Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 1.2.3.4 5.5.5.5 tcp dpt:80 0 0 ACCEPT tcp -- * * 5.5.5.5 1.2.3.4 tcp spt:80 Problem: An attacker who owns 5.5.5.5 can connect to any port of 1.2.3.4 by disabling the web server and using port 80 as a source port. 26

A stateful accept rule root@hbgyak:~# iptables -A FORWARD -j ACCEPT -s 1.2.3.4 -d 5.5.5.5 -p tcp --dport 80 root@hbgyak:~# iptables -A FORWARD -j ACCEPT -s 0/0 -d 0/0 -m state --state ESTABLISHED,RELATED -v ACCEPT all opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0 state RELATED,ESTABLISHED root@hbgyak:~# iptables -L FORWARD -v -n Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 1.2.3.4 5.5.5.5 tcp dpt:80 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED Now: 1.2.3.4 can connect to the web server on 5.5.5.5 and any packet related to valid TCP connections are accepted back in. However, if the attacker, who owns 5.5.5.5 cannot initiate any connection to 1.2.3.4 to any port, unless 1.2.3.4 wants to do so. 27

Rate limiting example We can set rate limits to avoid DoS attacks root@hbgyak:~# iptables -P INPUT ACCEPT root@hbgyak:~# iptables -F INPUT root@hbgyak:~# iptables -A INPUT -p tcp --dport 25 --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT -v ACCEPT tcp opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0 tcp dpt:25 flags:0x17/0x02 limit: avg 1/sec burst 3 root@hbgyak:~# iptables -L INPUT -v -n Chain INPUT (policy ACCEPT 644 packets, 70669 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 flags:0x17/0x02 limit: avg 1/sec burst 3 But this rule alone is not enough! The limit target matches to 1 packet each second and accepts it The rest is processed through the normal ruleset (possibly also accepted) 28

Rate limiting #2 Adding the following rule: root@hbgyak:~# iptables -A INPUT -p tcp --dport 25 --syn -j DROP -v DROP tcp opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0 tcp dpt:25 flags:0x17/0x02 root@hbgyak:~# iptables -L INPUT -v -n Chain INPUT (policy ACCEPT 1052 packets, 129K bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 flags:0x17/0x02 limit: avg 1/sec burst 3 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 flags:0x17/0x02 Now, SYN packets at the rate of 1/sec to the SMTP are accepted, the rest is dropped. Lesson learned: the LIMIT is just a matching rule, it does not processes packets just helps to match the appropriate packets. Hierarchical limits can be done: e.g. 500/hour 60/minute, 3/sec You have to understand how Netfilter works to work efficiently and in a secure fashion! 29

Interaction with routing Step 1. Define a iproute2 rule in rt_tables: root@hbgyak:~# cat /etc/iproute2/rt_tables # # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep 200 proba 30

FWMARK target Marks packet with a specific ID that can be used in the routing or in netfilter for numerous reasons (routing, QoS, filtering, etc.) E.g.: root@hbgyak:~# iptables -t nat -A PREROUTING -d 1.2.3.4 -j MARK --set-mark 0xace root@hbgyak:~# iptables -t nat -A PREROUTING -d 1.2.3.4 -p tcp -j MARK --set-mark 0xacd root@hbgyak:~# iptables -L PREROUTING -v -n -t nat Chain PREROUTING (policy ACCEPT 4 packets, 688 bytes) pkts bytes target prot opt in out source destination 0 0 MARK all -- * * 0.0.0.0/0 1.2.3.4 MARK xset 0xace/0xffffffff 0 0 MARK tcp -- * * 0.0.0.0/0 1.2.3.4 MARK xset 0xacd/0xffffffff This means, first, every packet to 1.2.3.4 are marked with 0xace. But then, this mark is overwritten for TCP packets with a different mark (0xacd). Only one mark is left on the packet at the end. 31

Ip rule setting Now, set a rule in the advanced ip rules: root@hbgyak:~# ip rule add fwmark 0xace table proba root@hbgyak:~# ip rule show 0: from all lookup local 32764: from all fwmark 0xace lookup proba 32765: from all lookup main 32767: from all lookup default This means, that whenever a packet has a 0xace mark (see previous slide for what packets are affected), the proba routing table should be used 32

Proba routing table Finally, set the proba routing table root@hbgyak:~# ip route add 5.4.3.2 via 10.105.1.254 table proba root@hbgyak:~# ip route show table proba 5.4.3.2 via 10.105.1.254 dev eth0 root@hbgyak:~# Now, if a packet matches the appropriate iptables/netfilter rules Then the ip rule puts the routing processing onto the proba table And a different route is going to be selected to that specific packet 33

Netfilter implementation Nf_conntrack_irc.c Nf_nat_irc.c 34

Conclusions Netfilter is a very sophisticated tool, handle with care Remote administration is dangerous! (You can disconnect yourself, ) A lot other functions, possibilities and modules exist what is not investigated within this lecture Every need can be fulfilled in numerous ways, it is not easy to choose the easiest It is very hard to understand what somebody other did in netfilter due to the different philosophy Netfilter rule sets can contain security problems! It is very hard to make, maintain a consistent, understandable, simple, secure rule set that really fulfills the needs of the company and complies to the security policy Mostly, security holes of the firewall are not that important Cannot be mapped, figured out Cannot be exploited Most critical errors can be identified by security assessment tools 35

Checkpoint firewall Uses both Stateful Inspection and application proxies. New version: Check Point R70, based on the Software Blade. Check point security modules that include (firewall, and IPS sofware modules) The trial of Check Point R70 includes the following blades(http://www.checkpoint.com/try/): Server side: Security Management server. FW module, IPS modul, Client side: SmartDashBoard, SmartConsole. GUI clients. 36

Client side Server side 37

Configure the security management server: Windows Server 2003 Start > Run > cpstart, cpstop be/kikapcsol. Start > Run > cpconfig configuration. Licenses: Generates a license for the Security Management server and the gateway. Administrators: Creates an administrator with Security Management serveraccess permissions. The administrator must have Read/Write permissions in order to create the first security policy. GUI Clients: Creates a list of names or IP addresses for machines that canconnect to the Security Management server using SmartConsole. Fingerprint: Verifies the identity of the Security Management server the firsttime you log in to SmartConsole. Upon SmartConsole login, a Fingerprint isdisplayed. This Fingerprint must match the Fingerprint shown in the Configuration Tool window in order for authentication to succeed. 38

Graphical client: SmartDashBoard. Objects List Pane -The Objects Listdisplays current information for a selected object category. E.g., when alogical Server Network Object is selected in the Objects Tree, the Objects Listdisplays a list of Logical Servers, with certain details displayed. Rule Base Pane Objects are implemented across various Rule Bases. E.g., Network Objects are generally used inthe Source, Destination or Install On columns, while Time objects can be applied inany Rule Base with a Time column. SmartMap Pane -A graphical display of objects in the system. -Thisview is a visual representation of the network topology. - Only physical objects are diplayed. Objects Tree Pane -The main view for managing and displaying objects. -Objects aredistributed among logical categories (called tabs), such as Network Objects and Services. 39

Connecting to the security management server via SmartDashBoard. You have to verify the Fingerprint of the server Bulding a rulebase. Rulebase: 1. user-defined rules and 2. implied rules. Packet inspection (first matching rule). Example rule: HTTP connections that originate from any ofthe Alaska_LAN group hosts, and directed to any destination, will be accepted and logged. Allows you to configure whether the rule applies to any connection (encryptedor clear) or only to VPN Connections. accepted, rejected, or dropped Specifies the Security Gateway on which the rule is installed. Specifies the days and the time of day to enforce this rule. 40

Bulding a rulebase (continued). Implied rules: Apart from those rules defined by an administrator, the Security Gateway also creates implied rules, which are derived from the Policy > Global Propertiesdefinitions. Examples of implied rules include rules that enable Security Gateway control connections and outgoing packets originating from the Security Gateway. Network Address Translation(NAT): Hide NAT: all private addresses is tranlated to one public address. Static NAT: translates each private address to a corresponding public address. Manually/Automatically generated NAT rules. NAT rules: (1. user-defined, 2. automaticaly generated rules) 41

Advanced configuration. Compressing content in HTTP responses is a way of increasing the speed of the connection. However, content security checks such as HTML weeding and CVPchecking cannot be performed on compressed content. Compressionof the content encoding data is allowed. 42

SmartMap. Graphical representation of the logical layout of your network. Edit objects displayed in SmartMap. (name, IP address, NAT, connection to, ) Add new objects into SmartMap. (GW, hosts, Checkpoint GW, Networks, Internet, ) Print SmartMap, Export SmartMap as an image file. 43

Checkpoint IPS Integrated with the Check Point Security Gateway. Comparing packet contents with over 2000 attack definitions. Detection and prevention of specific known exploits. Detection and prevention of protocol misuse (E.g., HTTP, SMTP, POP, and IMAP.) (partially,.) Detection and prevention outbound malware communications. Detection and prevention of tunneling attempts.(may indicatedata leakage, circumvent web filtering.) no perfect solution possible Restriction of bandwidth consuming applications(peer to peer, Instant message). (what happens with modified port numbers, encrypted traffic?) Detection and prevention of attack types without any pre-defined signatures Malicious Code Protector : detect buffer overflow attacks. Analysis of executable code in a Virtual Server environment. 44

Protection activation Detect:allows traffic pass but logs them. Prevent: blocks identified traffic/ logs or track them. Active: activate either detect or prevent. Inactive: deactivates the protection. Types of Protections (group of protections.) Application Controls: prevents the use of specific end-user applications. Engine Settings: settings that alter the behavior of other protections. Protocol Anomalies: identifies traffic that does not comply with protocol standards. Signatures: identifies traffic that attempts to exploit a specific vulnerability. Protection Parameters Confidence Level: how confident IPS is that recognized attacks are really attack. Performance Impact: how much a protectionaffects the gateway s performance. Protections Type: whether a protection applies to server-related traffic or client-related traffic. Severity: the likelihood that an attack can cause damage to your environment; Eg., an attack that could allow the attacker to execute code on the hostis considered Critical. Functions Follow Up: identifying protections that require further configuration or attention. Network Exception: used to exclude traffic from IPSinspection based on protections, source, destination, service, and gateway. Profile Terms IPS Mode: the default action(detect or Prevent) that an activated protection takes when it identifies a threat IPS Policy: a set of rules that determines which protections are activated for aprofile Profile: a set of protection configurations, based on IPS Mode and IPS Policy,that can be applied to enforcing gateways. Troubleshooting: options that can be used to temporarily change the behavior ofips protections, for example, Detect-Only for Troubleshooting. 45

Basic IPS implementation: IPS provides two pre-defined profiles that can be used to immediately implementips protection in your environment: Default_Protection provides excellent performance with a good level of protection. IPS Mode: Prevent IPS Policy: Signature protections. Very low performance impact. Update policy: Online Updates are set to Prevents. Recommended_Protection provides the best security with a very good performance level. IPS Mode: Prevent IPS Policy: All Signature, Protocol Anomaly protections Medium orhigher Severity and Confidence-level excluding protections with Critical Performance Impact. Updates Policy: Online Updates are set to Detect. 46

Changing the Assigned Profile: IDS > enforcing GW > Add > Select GW > OK. Installing Policy to Gateways: 1. Select File > Save. 2. Select Policy > Install. 3. Click OK. To bypass IPS inspection under heavy load: 47

To configure the definition of heavy load: Protection Browsers: Severity: Probable severity of a successful attack on your environment Confidence level: How confident IPS is that recognized attacks are actually undesirable traffic Performance impact: How much this protection affects the gateway s performance 48

Monitoring Traffic and Events: 1. In SmartDashboard, select Window > SmartView Tracker. 2. In the Network & Endpoint tab, expand Predefined > Network Security Blades > IPS Blade. 3. Double-click All. Most important: Critical Not Prevented: Events for protections with severity value of Medium or High but are set to detect. Follow Up: Events for protection marked for Follow Up. Protocol Anomaly: Events for protocol anomaly protections. Application Control: Events for application control protections. 49

Viewing Event Details: 50

Protections: I. By Type 51

I. By type: by Signature by Protocol anomalies 52

Protections: I. By type (continued): by Application Controls by Engine Settings 53

II. By Protocol: Configuring Web intelligence: Proactive protection against unknown attacks using virtual server simulator. Use Stateful Inspection technology. inspects traffic passing to Web servers to ensure that it does not contain malicious code. Malicious Code Protector: Kernel-based protection. Defining HTTP Worm Patterns: Uses pattern matching to recognize and block worms. To define patterns: Detects possibilityof executable code passing through a network. 1. Disassemble binary data into machine assembly language. 2. Monitors data streams and looks for a sequence of data that the can be translated into machine assembly language. Determine whether a suspected data is actually.execode False detection:.gif file canbe seen as.exe file..exe code does not means malicious code in every case. 54

Configuring Web intelligence: IPS tab: Protections > By Protocol > Web Intelligence > Malicious Code > General HTTP Worm Catcher. leave the checkboxes of the worms that you want to block as selected 55

Application Layer Inspection: 1. Cross-site scripting. HTTP requests that use the POST command with scripting code are rejected. The scripting code is not stripped from the request, but rather the whole request is rejected. Web Intelligence > Application Layer > Cross-site scripting. These protections have lists of commands or Distinguished Names(DN) for IPS to recognize Action: Prevent/Detect/Inactive High:Reject all tags. Medium: Reject HTML tags. Allow a command (exclude it from inspection and blocking) for a profile: select a profile, scroll down to the list of commands, and clear the command checkbox. Add a command to the blocked list. Edit a blocked command. 56

Application Layer Inspection (continued): 2. SQL Injection prevention. Looks for pre-defined SQL commands in forms and in URLs. rejects the connection,and a customizable error web page can be displayedto users. Web Intelligence > Application Layer: SQL Injection prevention. Security Level. High:Reject requests that contain special SQL characters and distinc or non-distinc SQL commands in the entire URL and body. Medium: Reject requests that contain special SQL characters and distinc or non-distinc SQL commands in the path and from fields. Low:, reject distinct SQL commands in path & form fields. 57

Information Disclosure Protection: Attackeranalyzesthe web server responseto get info. (1.info in header, 2. directory listing, 3. info in error msg.) Protection provides possibilities to change specific values to user defined ones. Web Intelligence > Information Disclosure 1. Header spoofing: provides possibilities to change version and server name values in the response header. 2. Directory Listing:identifies web pagesnot properly access controlled, and containing directory listings and blocks them. 3. Error Concealment: looks for web server error messages in HTTP responses, and if it finds them, prevents the web page reaching the user. conceals HTTP Responses containing those 4XX and 5XX error status codes that reveal unnecessary information. hides error messages generated by the web application engine. 58

Information Disclosure Protection (continued): Header spoofing: provides possibilities to change version and server name values in the response header. Directory Listing: identifies web pages not properly access controlled, and containing directory listings and blocks them. Error Concealment: looks for web server error messages in HTTP responses, and if it finds them, prevents the web page reaching the user. conceals HTTP Responses containing those 4XX and 5XX error status codes that reveal unnecessary information. hides error messages generated by the web application engine. 59

HTTP protocol inspection: Provides strict enforcement of the HTTP protocol, ensuring these sessions comply with RFC standards. IPS performs high performance kernel-level inspection of all connections passing through the gateway Web Intelligence > HTTP protocol inspection: 1. HTTP Format size:the sizes of different elements in the HTTP request and response are not limited. This can used to perform a Denial of Service attack on a web server. (E.g., Buffer Overflow) Protection: allows to limit the sizes of different elements in HTTP request and response. 2. Header rejection:web servers and applications parse not only the URL, but also the rest of the HTTP header data. Wrong parsing can lead to buffer overrun attacks and other vulnerabilities. Protection: allows Administrators to configure signatures that will be detected and blocked by Gateways. 60

HTTP protocol inspection (continued): 1. HTTP Format size:the sizes of different elements in the HTTP request and response are not limited. This can used to perform a Denial of Service attack on a web server. (E.g., Buffer Overflow) Protection: allows to limit the sizes of different elements in HTTP request and response. 2. Header rejection: Web servers and applications parse not only the URL, but also the rest of the HTTP header data. Wrong parsing can lead to buffer overrun attacks and other vulnerabilities. Protection: allows Administrators to configure signatures that will be detected and blocked by Gateways. 61

Kérdések? KÖSZÖNÖM A FIGYELMET! Dr. Bencsáth Boldizsár adjunktus BME Híradástechnikai Tanszék bencsath@crysys.hit.bme.hu 62