Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. Καλησπέρα, θέλουμε να κάνουμε στην εταιρεία αναβάθμιση των υποδομών. Από εμπειρία τι είναι καλύτερο να προχωρήσουμε σε υλοποίηση Exchange ή να πάμε σε Office 365 που δίνει 50GB+50GB email χώρο +1TB για αποθήκευση αρχείων. Δεν υπάρχει αντίστοιχος εξοπλισμός hardware. Η λύση θα αφορά 400 χρήστες με office εγκατεστημένο στους υπολογιστές τους και συνολική χωρητικότητα e-mail 190GB. Τι θα προτείνατε και γιατί;;; Η γνώμη μου είναι η δεύτερη λύση, αλλά μήπως κάνω λάθος, γιατί έχει σταθερό κόστος, περίπου 1000€/μήνα, αλλά δεν έχεις θέματα χωρητικότητας, back-up, διαθεσιμότητος κλπ.
  3. Καλησπέρα, Έχουμε το παρακάτω υποθετικό σενάριο: Μια εταιρία έχει 10 servers που βρίσκονται in the wild, σε data center, στο azure, on premise πελατών, και γενικά δεν είναι κάπου συγκεντρωμένοι. Όταν ένας programmer θέλει να συνδεθεί σε 3 server α) στην καλύτερη περίπτωση θα πρέπει να μπει κάποιος σε 3 διαφορετικά srv και να ανοίξει 3 φορές τον ίδιο user. Και στην χειρότερη περίπτωση β) να του δώσουν ένα admin account και να μπει όπου θέλει, ακόμα και στα υπόλοιπα που δεν έχει καμία δουλειά εκεί. Από αυτό προκύπτουν διάφορα προβλήματα διαχείρισης. Π.χ. όταν φύγει ο εν λόγο programmer άντε βρες που του είχες δώσει access και άντε μάζεψε το. Μην μιλήσω για άλλα διαχειριστικά πράματα όπως το patching π.χ. Με δεδομένο ότι έχουμε 365 & azure account τι μπορούμε να κάνουμε για να μπορούμε να δίνουμε κεντρικά access σε users σε συγκεκριμένους srv ? Υ.γ το active dir είναι hq.etairia.gr και το 365 είναι στο etairia.gr οπότε o win user είναι user@hq.etairia.gr και το mail του είναι user@etairia.gr.
  4. Last week
  5. Earlier
  6. https://nato.taleo.net/careersection/1/jobdetail.ftl System Administrator (191019) Primary Location Netherlands-The Hague NATO Body NATO Communications and Information Agency (NCI Agency) Schedule Full-time Application Deadline 05-Jan-2020 Salary (Pay Basis) 4,538.44Euro (EUR) Monthly Grade B.5 Clearance Level NS Description NATO offers you more than a job. It gives you a mission: building peace and security for one billion people in Europe and North America. The NATO Communications & Information Agency is leading NATO’s Digital Endeavour. We are NATO’s technology and cyber leaders, helping NATO Nations to communicate and work together in smarter ways. Our work is challenging and meaningful, and you will develop and apply your expertise as part of a dynamic international team of civilian and military professionals. Come and be part of the most successful alliance in history. NATO Communications and Information Agency (NCI Agency) is looking for a System administrator. The Command and Control (C2) Service Line is accountable for planning and executing all lifecycle management activities (design, transition and operations) for Joint/Maritime/Land C2 services (including: subject matter expertise; research and development; software engineering; acquisition; operations and maintenance; and, disposal) in the following C3 Community of Interest (COI) technical service areas: Land; Maritime; Joint; Special Operations; Environmental including Meteorological and Oceanographic (METOC); Civil Military Co-operation (CIMIC); Chemical, Biological, Radiation and Nuclear (CBRN); Operational planning ; Tasking and order services; Situational awareness ; Special C2 services NATO Nuclear Planning System (NNPS), NATO Nuclear Command, Control and Reporting System (NNCCRS), Shared Early Warning (SEW); The Service Line also retains accountability for the acquisition of AirC2IS Increment 1. The C2 Enabling Services Branch is responsible for the full lifecycle support of the Joint COI systems and also for C2 interoperability and standardisation. This includes responsibility for current operational systems including Joint Tactical Chat (JChat); Joint Operations Centre Watch Tool (JOCWatch); Joint Targeting System (JTS)/NATO Joint Targeting System and Joint Time Sensitive Targeting Tool (FAST); and, Network Interoperable Real-time Information Services (NIRIS); as well as the acquisition of future Joint C2 systems including the Combine Joined Operations Functional Services Project (CJOPS) FS. The branch is also responsible for interoperability between C2 systems, including work on tactical data link (TDL) systems. Role Responsibilities Under the direction of an allocated project manager, team leader or system manager, you will perform duties such as the following: Support all phases of IT Service Lifecycle system administration as well as contributing to IT research, software development and acquisition projects with providing technical expertise; Implement, document, and test software using relevant software engineering technologies and methods using the available tools to support the full software lifecycle; Support analysis, implementation and maintenance of authorized software changes, related applications software and the integration/tailoring of vendor supplied components, following established procedures for quality, configuration control, testing, documentation and security; Assist in service transition of systems and services to the operational environment; Support required Cloud system engineering work, including technical duties associated with Cloud deployments, Cloud infrastructure design, planning, management, maintenance and support; Provide expeditious technical support services to the NATO Functional Area Services, including emergency troubleshooting and on-site assistance (at NATO and national sites), to ensure key information systems remain operational; Be responsible for maintenance and upgrading of documentation related to supported systems; Interact with peers on other projects within and between NCI Agency Service Lines, and provide guidance and subject matter expertise Assist in preparation of, and occasionally deliver, briefings and presentations; Assist in preparation of scientific reports; Deputize for higher grade staff, if required; Perform other duties as may be required. Qualifications Required: Vocational training at higher level in a relevant discipline, leading to a professional qualification or equivalent combination of qualifications and experience. A higher educational qualification but less practical experience or a less formal educational background combined with particularly relevant practical experience may also be acceptable; A minimum 8 years of relevant experience in some (but not necessarily all) of the following areas. Experience required: Installation, implementation, large scale deployment, administration, testing and maintenance of software for modern information systems in a networked and distributed environment; Knowledge of operating systems that are currently used for modern information systems, particularly Linux and Windows; Solid experience in and TCP/IP networking techniques, associated standards and protocols; Experience in the deployment and maintenance of Database Servers; Experience in the deployment of endpoint Antivirus and security systems (Host-based firewalls, Data Lost Prevention, etc.) and associated management consoles; Experience in MS Active Directory on-premises deployments and integration or integrations with Cloud systems such as MS Azure; Knowledge and experience in Cloud computing and infrastructure: Scripting, Storage, Virtual machines, Networking, etc; Knowledge in DevOps and associated technologies, processes and tools toolbox; Experience in Business continuity, disaster recovery and backup solutions; Knowledge and experience in the implementation and testing of military security requirements, including security policies; Technical knowledge of and experience in military Command and Control Information Systems or similar civilian systems; Knowledge of Server Virtualization technologies, Virtual Desktop Infrastructure (VDI) and Containers; Writing technical documentation and user guides such as technical notes, training material, reports, and reference documents. It would be considered highly desirable if you are able to display any experience or knowledge of: Knowledge of Command and Control concepts, processes and tools; Knowledge of Security cross-domain information exchange methodologies, tools and techniques; Experience of deployment and maintenance of software products targeted at large end-user customer base; Technical certifications within Linux, Microsoft, Cisco, Cloud technologies; Technical certifications within Microsoft MCITP, MCSA, MCTP or similar; Experience with Server Clustering and Data Center resilience; Experience of systems support and maintenance in the NATO environment; Prior experience of working in an international environment comprising both military and civilian elements; Knowledge of NATO responsibilities and organization, including ACO and ACT) Competencies Required: Working with People - Shows respect for the views and contributions of other team members; shows empathy; listens, supports and cares for others; consults others and shares information and expertise with them; builds team spirit and reconciles conflict; adapts to the team and fits in well. Applying Expertise and Technology - Applies specialist and detailed technical expertise; uses technology to achieve work objectives; develops job knowledge and expertise (theoretical and practical) through continual professional development; demonstrates an understanding of different organisational departments and functions. Writing and Reporting - Writes convincingly; writes clearly, succinctly and correctly; avoids the unnecessary use of jargon or complicated language; writes in a well-structured and logical way; structures information to meet the needs and understanding of the intended audience; Planning and Organising - Sets clearly defined objectives; plans activities and projects well in advance and takes account of possible changing circumstances; identifies and organises resources needed to accomplish tasks; manages time effectively; monitors performance against deadlines and milestones. Travel: Business travel to NATO and national (NATO and non-NATO) facilities as well as frequent travel between the NCIA offices; you may be required to undertake duty travel to operational theatres inside and outside NATO boundaries. Language skills: A thorough knowledge of one of the two NATO languages, both written and spoken, is essential and some knowledge of the other is desirable. NOTE: Most of the work of the NCI Agency is conducted in the English language. Contract NCI Agency normally offers contracts of employment of a definite duration, not exceeding three years. Contracts may be for less than three years as required to support short-term projects, meet uncertainty with respect to the business outlook, staff performance and other factors. Definite duration contracts may be extended for further periods. When extending contracts, the following is taken into consideration: Renewal is in the interest of the Agency; Staff member's desire to remain with the Agency; The financial situation provides sufficient funding for the post held; The skills, competencies and behaviours, potential and work experience of the staff, versus the requirements of the Agency's work and/or availability of funding; Staff member has served the Agency with performance to the required standard as defined by the Agency; Staff member's deployability to operational theatre; Serving civilian members of NATO will be offered a contract in accordance with the NATO Civilian Personnel Regulations. The first six months of definite duration contracts are a probationary period. During this period the staff member's work is assessed to ensure that he/she has the ability to carry out the duties of the post. At or before the end of the probationary period, the staff member will be notified in writing that the appointment is confirmed or terminated or, in exceptional cases, that the probationary period is extended. Please note: Due to the Agency’s transition into a new structure in the near future, this post may be subject to transfer to one of our other locations, as well as to a change of reporting lines. The final decision will be made at the time of a firm offer. The Agency’s recruitment team advises you that due to the large volume of applications it receives the screening process may take up to 2 months. We appreciate your patience
  7. https://www.virusbulletin.com/about-vb/job-vacancy/ Virus Bulletin is a small company with a largely remote team based all over Europe that is placed at the heart of the IT security industry. Through its product testing, annual conference and ad hoc activities, Virus Bulletin works with security vendors, researchers and practitioners. As Security Evangelist, you will be the public face of the company. This broad role involves putting together a wide and varied conference programme, writing reports, talking to (prospective) customers, and attending trade shows and conferences. You will also be actively involved in determining the strategy of the company. Though a commercial company, Virus Bulletin cares strongly about ethics and values, making an actual contribution to the industry. As Security Evangelist, you are the person to maintain this ethical profile for the company. We are looking for someone who is passionate about security and has some affinity for the security industry who has some technical understanding of how threats and security products work who can write shorter or longer articles and reports who can work with and lead a remote team who doesn’t mind speaking to people or standing on a conference stage who is flexible and can keep to deadlines. We are not necessarily looking for someone with specific technical skills (though there is the possibility for this role to involve some technical work, this depends on the candidate) who is a native English speaker (all articles Virus Bulletin publishes are edited) who has a specific degree (or a degree at all) who fits a very specific profile: there is some flexibility in the exact job description to match the candidate’s strengths who is based in a very specific location: the job can be done remotely, or from our office in the UK. Preferably, the candidate will be based in Europe though. To apply for this position email recruitment@virusbulletin.com with your CV. Please also contact us if you have any questions about this role.
  8. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  9. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  10. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  11. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  12. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  13. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  14. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  15. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  16. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  17. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  18. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  19. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  20. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  21. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  22. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  23. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  24. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  25. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  26. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  27. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  28. At the previous post we created an Azure Front Door to scale our web apps across Azure Regions and also publish them only through the Front Door’s URL. At this post we will create Web Application Firewall (WAF) rules, to protect our web apps. To add WAF functionality to the Front Door we need first to create WAF rules and then attach them to the Front Door Create the WAF Rule From the Azure Marketplace search for WAF and create a Web Application Firewall At the “Create a WAF policy” wizard select “Global WAF (Front Door) for policy, provide the subscription and resource group, give a name for the policy and select if you want it to be created enabled or disabled. At the next step select if the policy will prevent the action or just detect and report it. You can change this later too. You can provide a Redirect URL for rules that support redirection. The default status code is 403 but we can change it to e.g. 404. We can also add a custom response body. The next step is the rule. We can select one or more predefined rule sets and then customize at will. To customize, expand the rule set and select a rule. You can enable / disable the rule and you can change the action to Allow, Block, Lod or Redirect. WAF Custom Rule The next step is the custom rules. There’s a lot to customise here. First are the rule type settings. Select status of the rule, enabled or disabled. Select the Rule type between Match and Rate limit. If you select rate limit you will be prompt to set rate limit and threshold. The final rule tupe setting is to set the priority of the rule. Next is the Conditions (If this) and the action (then that). The condition can be Geolocation, IP address, Size or String. After selecting the Match Type the rest options are altered accordingly. The action can be Allow traffic, Deny traffic, Log traffic only or Redirect traffic For the demo I created a rule that will Deny all traffic from The Netherlands, because I can test it from an Azure VM located at the West Europe Region. The next step is to associate the rule to the Front Door. After that assign Tags if needed and create the rule. Once the Rule is ready, a “Front Door WAF policy” resource will be at the selected Resource Group. Inside the Front Door, at the Web application firewall section, you can review the assigned rules. Test 1 From an Azure VM at West Europe Region, I tried to access the Front Door’s URL and we can see my custom 403 body text! Test 2 From my Computer I tested a typical SQL Injection attack from https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) . Again my custom 403 page! The post Use Web Application Firewall (WAF) Rules with the Front Door to protect your app appeared first on Apostolidis IT Corner.
  1. Load more activity
×
×
  • Create New...